On 1/11/2012 2:10 PM, David B Funk wrote:
Problem with all those methods is that they're reactive, will not hit
until -after- somebody has seen the bad crap and created filers,
RBL-lists, taught Bayes, etc.
The OP explicitly said that the first spam run was at 06:39 and by
06:42 it was hitting RBLs (pretty darned quick by my book;).
However he has some fussy customers who weren't understanding and
so was asking for a method of dealing with this.
Only one I could come up with was graylisting to defer the messages
until sanesecurity, uri filters, etc could catch them.
I only apply greylisting if there's already something suspicious about
the DNS (mismatching or missing forward or reverse entries), reason to
believe that a connection might be from a dynamic IP, a stupid or
invalid HELO/EHLO, SPF soft-fail and/or possibly a few other criteria.
This setup generally allows a competently run mail server to get through
on the first try without any delays at all, but gives poorly run mail
servers a second chance after greylisting has given DNSBLs a bit of time
to catch up.
Luckily since email isn't an instant messenger, greylisting is an
option. You can implement it on a per-user basis too, based on whether a
user would prefer spam filters err on the side of being quick or right.
Yes, this is on an IMAP server but he was an impatient critter.
I just tossed that out as an illustration of how unreasonable/impatient
some people can be.
The point is that most modern IMAP servers support IDLE, which pushes
mail to the client as soon as the server knows about it. No polling, no
waiting.
--
Dave Warren, CEO
Hire A Hit Consulting Services
http://ca.linkedin.com/in/davejwarren
