ClientPortOptions Not Being Respected

bpkroth

unread,

Jan 13, 2012, 11:38:16 AM1/13/12

to

I've got a mail server dedicated to handling outbound mail to the rest
of the world. It has service IPs (both IPv4 and IPv6) that I use
DAEMON_OPTIONS (DaemonPortOptions) and CLIENT_OPTIONS
(ClientPortOptions) to force it to use for all inbound and outbound
connections. Examples are below (addresses mangled slightly).

DAEMON_OPTIONS(`Name=MTA-v4, M=AEfr, Port=smtp, Family=inet,
Address=10.2.0.54')dnl
DAEMON_OPTIONS(`Name=MTA-v6, M=Efr, Port=smtp, Family=inet6,
Address=fded::9592:1317:8309:5893')

DAEMON_OPTIONS(`Name=MTA-v4-local, Port=smtp, Family=inet,
Address=127.0.0.1')

DAEMON_OPTIONS(`Name=MTA-v6-local, Port=smtp, Family=inet6, Address=::
1')

CLIENT_OPTIONS(`Family=inet, Address=10.2.0.54')dnl
CLIENT_OPTIONS(`Family=inet6, Address=fded::0:9592:1317:8309:5893')

Internally it receives everything on IPv6 addresses, so I can't
specify M=b on the DAEMON_OPTIONS, else most mail won't go out since
most external mx servers don't have IPv6 advertised.

However, sometimes (perhaps 1 out of 50 messages?), the CLIENT_OPTIONS
are ignored and a connection is made to a remote server over the
machine's management ip (10.2.0.175 - it's on the same interface eth0
and subnet - the service ip is on eth0:1).

To prevent this I've temporarily added iptables rules to reject
outbound port 25 connections from the management ip. No errors show
up in the sendmail logs, and the mail appears to still be successfully
delivered over the service ip.

Can anyone explain what's going on here? Is it a bug? I tried
reading through some of the source code, but can't quite see why this
should be happening.

Let me know if you need any more info.

Thanks,
Brian

Andrzej Adam Filip

unread,

Jan 15, 2012, 5:01:20 AM1/15/12

to

bpkroth <bpk...@gmail.com> wrote:
> [...]

> However, sometimes (perhaps 1 out of 50 messages?), the CLIENT_OPTIONS
> are ignored and a connection is made to a remote server over the
> machine's management ip (10.2.0.175 - it's on the same interface eth0
> and subnet - the service ip is on eth0:1).
>
> To prevent this I've temporarily added iptables rules to reject
> outbound port 25 connections from the management ip. No errors show
> up in the sendmail logs, and the mail appears to still be successfully
> delivered over the service ip.
>
> Can anyone explain what's going on here? Is it a bug? I tried
> reading through some of the source code, but can't quite see why this
> should be happening.
>
> Let me know if you need any more info.

Are you sure the "bad connections" had been made by sendmail?
[ it may explain lack of errors in sendmail logs after firewalling out]

alexander.yegorov

unread,

Jan 21, 2012, 8:57:28 PM1/21/12

to

What if you add the LOG target before rejection?
Also, you may try to add the logging into sendmail.cf, which writes
the ${server_addr} and ,say, ${mail_addr} to syslog

bpkroth

unread,

Jan 22, 2012, 12:57:08 PM1/22/12

to

On Jan 15, 5:01 am, Andrzej Adam Filip <a...@onet.eu> wrote:

Fairly certain. sendmail is the only thing the machine runs (well
ssh, cron, cfengine, etc. for internal management purposes). I've
added the --log-uid option to my iptables LOG before REJECT rules to
confirm.

bpkroth

unread,

Jan 22, 2012, 1:07:13 PM1/22/12

to

Confirmed. Rejected packets are coming from root:smmsp. The only
processes running with those uid/gid are sendmail.

Brian

bpkroth

unread,

Jan 22, 2012, 12:59:40 PM1/22/12

to

On Jan 21, 8:57 pm, "alexander.yegorov" <alex.yego...@gmail.com>
wrote:

Had done that. It helps me confirm that the failed attempts get
delivered properly on the service ip. As noted in the previous post,
I've added the --log-uid option to the rule to confirm that it is in
fact the sendmail user process making the connections.

> Also, you may try to add the logging into sendmail.cf, which writes
> the ${server_addr} and ,say, ${mail_addr} to syslog

Thanks. I'll look into this sometime on Monday.

Brian

Message has been deleted

bpkroth

unread,

Apr 24, 2012, 2:42:00 PM4/24/12

to

I forgot to respond to this. I never found a way to log these macros explicitly. Setting LogLevel higher also does not appear to include them either. At least not exactly. The responding server may tell us what we connected with in its response to our EHLO/HELO. Anyways, I'll continue to watch those and see what I find.

Thanks,
Brian