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.
JM2CW .. YMMV
Bill Hacker
--
韓家標
