After that point, it starts to get ugly. We currently manage to have 96% efficiency (false positives around 0.001%), and thats a daily battle. Spam traps and new rules almost every day (5 days a week, at least).
For those interested, these are the RBLs I use: sbl-xbl.spamhaus.org relays.ordb.org dnsbl.njabl.org
Dropped spamcop some months ago.
[]s
Rodrigo Barbosa
One other thing that it may be good to point out is the course that the postfix group seems to be taking which is sanity checking incoming email before the DATA state. This is well worth checking out and I would guess that any well-maintained MTA would support this type of thing. So your rbl checks/helo checks/hostname and mx checks happen before the mail is received. This greatly reduces the amount of processing time on the MTA and allows it to handle far more mail in these spam-predominant times. You don't want to block most of your spam with a perl script IMHO. On our MTA, between the aforementioned and greylisting we block enough spam for it to be manageable on the back end with very, very few false-positives and close to zero maintenance. I'm sure that if we wanted to block more we could spend a lot more time setting up traps/writing SpamAssassin rules etc. But we're quite happy with this setup.
FYI, rbls we use are: relays.ordb.org list.dsbl.org sbl-xbl.spamhaus.org <-- best one dul.dnsbl.sorbs.net
the last being the only one I've seen any false positives on and only 2 since we set it up. YMMV.
alex
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Oct 25, 2006 at 10:39:33AM -0500, Alex Palenschat wrote:
One other thing that it may be good to point out is the course that the postfix group seems to be taking which is sanity checking incoming email before the DATA state. This is well worth checking out and I would guess that any well-maintained MTA would support this type of thing. So your rbl checks/helo checks/hostname and mx checks happen before the mail is received. This greatly reduces the amount of processing time on the MTA and allows it to handle far more mail in these spam-predominant times. You don't want to block most of your spam with a perl script IMHO.
True. I particually enjoy Exim ACLs for this kind of job. For bigger setups (10000+ mailboxes), I usually split my mail cluster on a backend/frontend setup, which also helps a lot.
Greylisting can be pretty tricky to implement, if you need speed. Constant updates of your database (filebased or dbms based) can slow you hard, so having some good rules when (and when not) to update is a must.
Sanity checks are, of course, a must. The sooner you can drop the message (and the connection, in some cases), the faster you can handle valid e-mail.
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
-
Alex Palenschat -
Rodrigo Barbosa