At 10:21 AM 9/8/03 -0400, Chris Lewis wrote:
[snip]
We're considering greylisting as an adjunct to our filters. However,
since we have 8 inbound gateways, it could get rather messy. A
simple-minded implementation with a half hour delay would have a four
hour worst-case delay... Not acceptable.
Unfortunately, it's worse because the delay isn't up to you,
it's up to the sender.
Most servers have a "flat" retry of 20 minutes, but some have much longer.
I've seen one case were it was 12 hours.
(better would be a logarithmic back off,
1 minute then 5 minutes then 25 then 2 hours...)
Of course, if /they/ think 12 hours is acceptable, then perhaps
they wouldn't object to a 4 day delay.
[snip]
The simple fact of the matter is that open proxy/socks code will _not_
queue - so they won't try a second time[2]. I would strongly suspect
that if you made your greylisting timeout _zero_, and simply 400'd the
first appearance of a given sender/IP/recipient tuple and accept the
next appearance, no matter how quickly, you'd still be getting 90% of
what greylisting with a very long timeout would give you.
Closer to 98% if my logs are to be believed.
And you can get damn near 100% if you insist that they reconnect.
(451 everything on the first connect)
Of course, spamming tools will evolve, so then you consider increasing
the timeouts. Too far, tho, and it's worse than where you started. And
I don't think you'd ever get to where you'll be able to take into
account DNSBL latency.
It's really a matter of scale.
The more users, the quicker the response can be.
(i.e. the faster we can tell if a given IP is spewing)
At 0.1%, a list delay averages the amount of time needed
to send to 1000 servers.
I would think 1 hour would be quite sufficient.
Scott Nelson <scott(_at_)spamwolf(_dot_)com>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg