Milter-greylist

At Thu, 2 Nov 2006 12:45:11 -0500,
eclark wrote:
> 
> Jon, please refer to Matthias' previous email, regarding use of rbls to do 
> greylisting, not blacklisting. Specifically these bits:
> 
> dnsrbl "SORBS DUN" dnsbl.sorbs.net 127.0.0.10
> acl greylist dnsrbl "SORBS DUN" delay 12h
> 
> We get about 110 million emails a day inbound to our network at peak, with 
> averages around 90 both out and in. We greylist everything and are pretty 
> much not having any issues with our million+ mail addresses. The occasional 
> domain may need to be whitelisted. While I am sure the BBC is a vast 
> organization with many millions of messages being handled daily, the issue at 
> hand is more one of how you decide to persue a resolution. I see that you 
> handle about 1 million emails a day inbound. To be completely and totally 
> frank with you, this is peanuts. In my humble opinion, you really should be 
> running a much more draconian policy that utilizes third party databases of 
> dynamic ips and overall broad greylisting, and only except that policy for 
> particularly vociferous clients. Its far easier to greylist everything under 
> the sun with varied durations and whitelist one problem user, than white list 
> everyone and try to force a handful regular expressions to compensate for 
> your overly lenient policy. In short, I would again suggest the following:
> 
> greylist everything for some minute time period (1-5 minutesish)
> use dnsbl.sorbs to extend greylist durations as appropriate (2-8hours)
> whitelist per complainy client
> 
> While Matt's regex hack he supplied does indeed cut memory costs, it is still 
> by far the absolute most ineffecient way of doing things, simply because it 
> will have to come before your default whitelist, causing everything thats not 
> on a shortened greylist to be matched against it. The greylist all + 1min 
> delay on non-dynamic ips (we greylist those in sorbs for 6 hours) has slashed 
> our network bandwidth costs by 30%, and has knocked out a clean 78-85% of our 
> inbound mail traffic. The principle behind the extremely short duration 
> greylist is to obliterate botnets. Our broke mta whitelist numbers a meager 
> 84 entries; the combination of these settings allow us to handle the mail as 
> previously mentioned with very little effect on performance (actually, we 
> have seen a performance _gain_, due to the effect of not having to deal with 
> mail delivery overhead), and run additional mail filtering in the way of 
> spamassassin. 
> 
> Again, these are all just suggestions, but I very strongly feel your overly 
> broad and resource intensive regex approach to the issue will ultimately bite 
> you in the ass.

I strongly object you. Your "default to greylist" approach makes too
many false positives. I'm sure BBC do not want even one false
positive. It is important that false positives are most likely at big
ISP's outgoing mxes. In contrast, small hosts, which often lack rDNS
or have numeric rDNS, are tend to run well-known MTAs in simple
configurations. They are less likely to suffer false positives.
Perkin's "greylist end-user-looking hosts only" approach is quite
reasonable.