Re: [exim] delaying inbound messages

Top Page

Reply to this message
Author: W B Hacker
To: exim-users
Subject: Re: [exim] delaying inbound messages
Phil Pennock wrote:
> On 2011-09-01 at 11:05 -0700, Jeff Lasman wrote:
>>    # Accept hosts who are polite enough to wait rather than just send, as spammers do
>>    accept hosts = *
>>          delay = 3s

>> Is there a community concensus on whether or no this is reasonable?
> This is email. There's no community consensus on _anything_.

LOL! Second that!

> That said, I am one of those who does a delay, to expose the protocol
> pumpers which don't synchronise correctly.
> Make sure to whitelist your monitoring system. It's also handy to
> whitelist all IPs configured on this host: @[]
> What I do reduces down to:
> acl_connect:
>    accept hosts = @[] : +remote_hosts_nodelay
>    warn set acl_c_delay = 0
>    # ...
>    warn set acl_c_delay = ${eval10:3+$acl_c_delay}
>    # add 2 seconds if on an RBL, etc etc
>    # No delays at connect for submission, it's in the user-path:
>    accept  condition = ${if =={$received_port}{587}}
>    accept  hosts = *
>            delay = ${acl_c_delay}s

> together with a hostlist "remote_hosts_nodelay" which includes
> +relay_from_hosts. The real ACL is more complex than that, because
> that's how I roll.
> Arguably, you might use a DNS reputation whitelist to reset the delay
> down to zero before the end there.
> You'll probably want to end up whitelisting the high-volume senders you
> trust, if you want to keep them happy.
> -Phil

I'd add that 3 seconds probably doesn't gain enough often enough to bother.

We've found that ten seconds is about as long as a 'well engineered' bot
will wait, but most WILL wait ten seconds (and a few 'forever' unless
otherwise dumped/timed-out). Only a fraction quit at sub 4 seconds.

Ergo we now use 13 seconds and target primarily the initial
acl_smtp_connect phase. That DOES pay off, as it can save on rDNS
lookups et al.

W/R rudeness - the loading placed on correspondents?

Well ... 13 seconds hasn't seemed to bother anyone. But DO exempt those
you can do.

The rest will be far less inconvenienced by a short inline delay than if
they were to hit the average (read 'poorly implemented) greylisting
needeing multiple retry and clogging logs - or a slow SA or AV scan return.

Overall, a short up-front delay is perhaps 'cheaper' for both parties
AND their bandwidth than even 'well-run' greylisting.


Bill Hacker