mon petit blogue sans importance...

fight the spam...

i usually get a fair amount of spam, and lately it was about 50-100/day. About 2/3s of which is caught by Thunderbird's spam filter, which at least doesn't have many false positives, but that still leaves a lot of crap in my inbox. Yesterday i put in some changes in my postfix setup, and i'm down to less than 10 (judging from the only 2 spams i got overnight)... very cool. See below for the changes i did.

I lost track of the different websites i looked at to get my hints, apart from the postfix documentation, but here's what i did.

I created /etc/postfix/header_checks with this in it:

/^Content-Type: multipart\/report; report-type=delivery-status\;/  REJECT no third-party DSNs

/^Content-Type: message\/delivery-status; /     REJECT no third-party DSNs

That's because i was getting a lot of bounce backs from other systems. What was happening is that someone was using a subdomain of mine and using it, with all sorts of names, as a From for the spam they're sending. That's probably because i had enabled SPF for my main domain, and tried to on my subdomain, but that one was an ALIAS in DNS, and you can't have a TXT field in DNS for an ALIAS entry, as the good guys at Easydns helped me figure out. So i now changed it to a HOST entry, and SPF should now work for it. In the meantime, it means a lot of email servers were sending me bounces for spam i didn't send... that's a 'third-party bounce': the email wasn't sent by my server, but the bounce comes back to it. Almost all third party bounces are from spam, because if your server sends the email to a non-existent username, or to a mailbox that's full, the receiving server will tell you right away when your server connects to it to try to deliver the mail. Those bounces will still be caught properly. The third-party bounces you get aren't technically spam - if you start flagging them in your filter, you'll miss real bounces. But they're annoying and i was getting a lot of them (hopefully that'll die down now that SPF is in effect for the subdomain, though). To put that policy into effect, you put this into effect, you put this into /etc/postfix/main.cf:

header_checks = regexp:/etc/postfix/header_checks

The other part of this is more checks on incoming mail right at the point where the remote server is connecting to mine and trying to deliver mail. One thing to do is to rely on something like Spamhaus, which maintains lists of IPs which are known to be relaying lots of spam (most are either open relays,or zombies), and reject the mail before the remote server even tries to deliver it, which saves processing and bandwidth. Then, a few rules can be applied at this stage as well: are both the sender and receiver addresses valid emails at fully qualified domain names? Is the recipient a valid local destination? (of course, the mail server would figure this out, but normally it doesn't look that up right at this stage, it might wait until after the mail is actually delivered), etc.

By doing all this at the stage where the remote announced it's sending you mail, from who and to whom, but before it started sending the body, you're saving precious bandwith and processing time. To put that into effect, here's the magical stuff, still in /etc/postfix/main.cf:

 smtpd_recipient_restrictions =
  
        reject_non_fqdn_recipient
  
        reject_non_fqdn_sender
  
        permit_mynetworks
  
        reject_unknown_sender_domain
  
        reject_unknown_recipient_domain
  
        reject_rbl_client zen.spamhaus.org
  
        reject_unlisted_recipient
  
        reject_unauth_destination

There's tons more stuff to do potentially: i still haven't installed something like spamassassin, and lots of cool filters can be done outside of Postfix. One i saw that's pretty neat: a greylist policy. The first part is that for a new remote server, you respond with 'try again later', which means a remote mail server will just have to wait and re-try. Most spam is sent from zombies, and those aren't compliant mail servers ('MTA's), so they don't actually retry. If they do, they might well have been tagged in the meantime as a spamming MTA by spamhaus, and they second try will be met with strict refusal to accept mail. The second part is that those spam agents will frequently try to deliver many spam messages to your server in a short amount of time, some to valid addresses, some to invalid ones. The greylisting agent on your server will hold your incoming mail for about 60 seconds and store which IP it came from, as well as the sender and destination. If it sees a pattern that's spam-like, it will just reject all of them, and will start rejecting all mail from that IP, or from a combination of that IP and that sender. It's very powerful, and from what i read works very well. But for now, my current improvements seem to be enough.

I really, really hate spammers. 

by wiswaud on 30 October 2007
Tags: english, geeky, linux, spam sucks