Re: [bitfolk] Spam overwhelming my mail server

Hi all, I'd strongly recommend greylisting. From experience I can say that most concerns about delays are easily dealt with. I wrote a greylisting system for exim back in 2003. We used it to filter all e-mail to Aberystwyth University from 2003 until the powers-that-be decided to outsource to Microsoft last year. It caused almost no problems over those 10 years. You can get around most delivery delay issues by having a whitelist of legit hosts that send lots of mail to your machine and a whitelist of sender/recipient pairs - you make outgoing mail create the whitelist entry and you can then accept inbound mail without delaying it. My greylisting implementation managed both the host and sender/recipient whitelists automatically. It used MySQL as the backend because we were running a cluster of several mail servers and I wanted the greylist to be common to all. It should be quite easy to change it to use SQLite, for example. Here's a link: http://users.aber.ac.uk/auj/spam/ Spamassassin should really be your last resort when trying to deal with high throughput. It can take several seconds for a message to pass through the filters, so knocking off the worst cases nice and early is worthwhile. Here's a bit of sneaky stuff to put in your "acl_smtp_connect" ACL. # ACL for initial connects. # Let's try and deter them here. check_connect: # Internal addresses. accept hosts = +relay_hosts # Addresses in one of these DNSBLs get delayed for 60 seconds. accept dnslists = sbl.spamhaus.org logwrite = Delayed $sender_host_address - dnsbl $dnslist_domain delay = 60s # Addresses without a reverse DNS get delayed for 10 seconds. accept condition = ${if def:sender_host_name {no}{yes}} logwrite = Delayed $sender_host_address - missing reverse DNS delay = 10s # Everyone else gets 2 seconds to screw them up if they're # trying to "pump and dump" accept delay = 2s Basically, every inbound connection gets delayed for 2 seconds. If they're in sbl.spamhaus.org the connection gets delayed for 60 extra seconds. If they have a missing reverse DNS they get 10 seconds added. This is enough to cause a lot of spamware to give up on you, and the RFCs suggest that sending software should be willing to wait up to 5 minutes. The unconditional 2 seconds delay breaks spamware that tries to use pipelined commands. Note that nothing in the above ACL causes rejection. It just gives broken spamware a chance to fail. I also have an "acl_smtp_helo" which blocks people who HELO as my server (my server being ty-penguin.org.org or mail.ty-penguin.org.uk) or who HELO with an invalid value. check_helo: # MSA or SMTPS gets a free pass. accept condition = ${if or {{eq {$interface_port}{587}}{eq {$interface_port}{465}}}} drop condition = ${if or {\ {eq {$sender_helo_name}{[$interface_address]}}\ {eq {$sender_helo_name}{$interface_address}}\ {eq {$sender_helo_name}{ty-penguin.org.uk}}\ {eq {$sender_helo_name}{mail.ty-penguin.org.uk}}\ }{yes}{no}} message = You're not me! Are you a spammer? delay = 3s drop condition = ${if or {\ {eq {$sender_helo_name}{localhost}}\ {eq {$sender_helo_name}{127.0.0.1}}\ {eq {$sender_helo_name}{[127.0.0.1]}}\ {match {$sender_helo_name}{\N^\.\N}}\ {match {$sender_helo_name}{\N\.\.\N}}\ {match {$sender_helo_name}{\N^[^\.]+$\N}}\ }{yes}{no}} message = Invalid HELO address delay = 3s accept I think it's perfectly fair to drop stuff that has a clearly invalid HELO. I also give them a 3 second delay to slow them down a bit. In my experience, lots of spamware sends dodgy HELO lines in the hope of fooling you into thinking the mail is local. Cheers, Alun.