Timeout before data read

[Jim Klimov]

Hello,

Every once in a while I inspect the SPAM which makes it into my
inbox to see why it passed. Sometimes I see no headers added by
milter-greylist which is of course curious. In one case I tracked
it to this snippet in the sendmail/milter debug-log on the relay:

Feb 28 13:46:51 relay-mta sendmail[11077]: [ID 801593 mail.info]
s1QEJTG9025599: to=<gooduser-IQev58gowAEdjvzEOXFxkprFOQ4/***@public.gmane.org>, delay=1+19:27:20,
xdelay=00:00:00, mailer=esmtp, pri=709686123,
relay=good.remote.domain.ru., dsn=4.0.0, stat=Deferred: Connection
timed out with good.remote.domain.ru.

Feb 28 13:46:53 relay-mta sendmail[9494]: [ID 801593 mail.error]
s1S9fS5u009494: Milter (greylist): timeout before data read, where=rcpt

Feb 28 13:46:53 relay-mta sendmail[9494]: [ID 801593 mail.info]
s1S9fS5u009494: Milter (greylist): to error state

Feb 28 13:46:55 relay-mta sendmail[9494]: [ID 801593 mail.info]
s1S9fS5u009494: from=<office-***@public.gmane.org>, size=5510, class=0,
nrcpts=1, msgid=<201402281741071561977354520-***@public.gmane.org>,
proto=SMTP, daemon=relay-mta.cos.ru, relay=[199.36.72.246]

So, in this case I see lots of un-deliveries to the (obfuscated)
"@good.remote.domain.ru" whose relay is apparently under maintenance.
Maybe this is related, maybe not, to the milter-greylist timeout
reported further on. The daemon is up and running since about
midnight, and it has been properly processing messages more
recently than that log entry, so it was some intermittent hiccup.
And due to this hiccup the relay happened to be unprotected at all,
and accepted the spam message (a few minutes later it did process
another delivery attempt and put it off into the 8-hour greylist):

Feb 28 13:55:00 relay-mta milter-greylist: [ID 751384 mail.info]
s1S9fS5u009494: addr [199.36.72.246][199.36.72.246] from
<office-***@public.gmane.org> to <info-***@public.gmane.org> delayed for 08:00:00
(ACL 1825)

Feb 28 13:55:00 relay-mta milter-greylist: [ID 765981 mail.info]
(199.36.72.246 SP:+0) SPF unknown: undefined result received while
evaluating SPF for sender domain 'buyouproduct.pw', accept any relay

Feb 28 13:55:00 relay-mta milter-greylist: [ID 902047 mail.info]
MGL-TEMPFAIL-DNS-480: IP:'199.36.72.246' DOMAIN:'[199.36.72.246]'
HELO:'VPS-30E0C4FBE64' FROM:'office-***@public.gmane.org'
RCPT:'info-***@public.gmane.org': Source looks like a probable spam-source
(scored 20 in DNS, 5 in P0F) (max delay 480m)

Feb 28 13:55:00 relay-mtc milter-greylist: [ID 556459 mail.debug]
created: 199.36.72.246 from <office-***@public.gmane.org> to <info-***@public.gmane.org>
delayed for 08:00:00

So... are there any ideas why could milter-greylist be considered
offline by sendmail for a short while, and what can be done to prevent
this? It is running on the same host as the relay, version 4.5.7.

Apparently, things like these happen on all of our relays once in
a while with no noticed correlation. Maybe something to do with load
and thus latency (CPU or RAM overbooking)?

I wonder if it would make sense to require that sendmail uses the
milter or tempfails the message submission attempt... and if it is
possible to not-use the milter for local (LAN) addresses at all :)
Ideas/doclinks on this are also welcome, thanks in advance ;)

//Jim

[Bruncsak, Attila]

Post by Jim Klimov
And due to this hiccup the relay happened to be unprotected at all,
and accepted the spam message

Do you use the F=T or F=R flag in the sendmail configuration
for the milter-greylist filter? If not, the sendmail will just deliver
the mail like no milter-greylist is defined in the configuration
if the communication fails between them.

[Jim Klimov]

Post by Bruncsak, Attila

Post by Jim Klimov
And due to this hiccup the relay happened to be unprotected at all,
and accepted the spam message

Do you use the F=T or F=R flag in the sendmail configuration
for the milter-greylist filter? If not, the sendmail will just deliver
the mail like no milter-greylist is defined in the configuration
if the communication fails between them.

Rrright, thanks for reminding ;)

Now, do you remember also if there is a trick to skip a milter
altogether for some clients (i.e. the LAN addresses or those
allowed to relay in accesdb)?

Thanks a lot,
//Jim

[Bruncsak, Attila]

Post by Jim Klimov
Now, do you remember also if there is a trick to skip a milter
altogether for some clients (i.e. the LAN addresses or those
allowed to relay in accesdb)?

Unfortunately I am not a sendmail configuration expert
but I imagine that there might be trick to avoid calling
a milter filter on any arbitrary condition available
on macro level.

On the other hand it isn't very expensive to have
the milter-greylist always hooked in
and at the top of the RACL and DACL list
to have a whitelist statement
with the appropriate condition.

[Jim Klimov]

Post by Bruncsak, Attila
On the other hand it isn't very expensive to have
the milter-greylist always hooked in
and at the top of the RACL and DACL list
to have a whitelist statement
with the appropriate condition.

In fact, it is expensive :) Not too much, but still: we
now use p0f fingerprinting, and the daemon was configured
to exclude the LAN subnets. Presence of "p0fsock" keyword
in greylist.conf currently causes the p0f client to request
the information from the daemon, regardless of presence of
any p0f ACLs. This causes delays while the milter retries
the requests for the case that p0f might come up with a
result a bit later than the first query (per my recent
patch, I'm not sure if Manu integrated it into the common
repository).

Also, if we choose to tempfail or reject in case of milter
unavailability, this is okay for messages incoming from the
internet, but not okay for generation of messages from the
LAN (some hardware monitoring etc. submits mails to the
same relays as mailhosts).

So skipping the milter for LAN sources altogether would be
preferred for at least a couple of good reasons :) And the
LAN for this case might be defined as the hosts allowed to
relay per sendmail's access database configuration. Gotta
read up on macros, I guess...

//Jim

[manu-S783fYmB3Ccdnm+]

Post by Jim Klimov
This causes delays while the milter retries
the requests for the case that p0f might come up with a
result a bit later than the first query (per my recent
patch, I'm not sure if Manu integrated it into the common
repository).

I am not aware of any pending patches after 4.5.11. If you have
something not included, it means I missed it.

Post by Jim Klimov
So skipping the milter for LAN sources altogether would be
preferred for at least a couple of good reasons :) And the
LAN for this case might be defined as the hosts allowed to
relay per sendmail's access database configuration. Gotta
read up on macros, I guess...

It looks you need two different sendmail daemons, ont servicing LAN, the
other servicing internet.

[Johann Klasek]

[..]

Post by manu-S783fYmB3Ccdnm+

Post by Jim Klimov
So skipping the milter for LAN sources altogether would be
preferred for at least a couple of good reasons :) And the
LAN for this case might be defined as the hosts allowed to
relay per sendmail's access database configuration. Gotta
read up on macros, I guess...

It looks you need two different sendmail daemons, ont servicing LAN, the
other servicing internet.

If you have different interfaces for each, you could setup
the IFs with different milter settings via DEAMON_OPTIONS.

E.g. a mc file could be read like this:

dnl lan connections no milter at all:
DAEMON_OPTIONS(`Name=MTA-lan, ADDR=192.168.x.x, M=E')dnl
dnl wan connections with milter:
DAEMON_OPTIONS(`Name=MTA-wan, ADDR=a.b.c.d M=E,InputMailFilters=milter-greylist')dnl


As far as I know there is no milter inherent function which allows to disable
milterprocessing at all under some circumstances. This stuff has to be
handled by each milter on its own ...


Johann E. Klasek