At 10:21 AM -0400 2003/09/08, Chris Lewis wrote:
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.
Whereas a place like AOL (which had over 45 inbound gateways at
the time I left) would be much, much worse. This is why places with
multiple MXes should implement a shared central database for the
greylisting, so that all machines can benefit from the traffic seen
by the others.
Due to how our DNSBL system works (we do our own zone downloads),
and with a eye to not bashing the DNSBL originating servers too much,
the latency (for 3rd party DNSBLs) averages around 12 hours. So,
greylisting-delay-for-DNSBL-catchup isn't going to help (us).
Indeed.
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.
Fair enough. But then you get people like Vernon Schryver who
complain that you're not compliant with RFC 2821 if the sender
doesn't implement a minimum thirty minute retry period, despite being
unable to provide a reference for this requirement.
At the very least, I'd like to see some testing showing how much
greylisting minimum required latency helps, or fails to help.
--
Brad Knowles, <brad(_dot_)knowles(_at_)skynet(_dot_)be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg