Re^2: PMiltering fun

[Tanktalus]

The mydestination setting is fine if your destination list doesn't change. But, IMO, it suffers from the data-duplicated-multiple-times syndrome. I already have this information in my DNS, duplicating it somewhere else seems like a huge waste of scarce resources (that being my ability to remember to do this should I change my network topology).

I plan on inserting a spam filter, too, but last time I tried, email crawled to a halt because my poor machine couldn't keep up with it. This is kind of the first step in reclaiming that: by eliminating over 90% of the spam based on bad domain names, I will only need to check 10%. Even that will likely bring my P3-550 to a crawling halt, so I'm going to have to set up a distributed spam check (spamd running on another machine) somehow.

Running a caching bind server on a small machine vs caching my own lookups... hmm... ;-) I suspect that for this machine, it's cheaper in both CPU and RAM to cache inside my milter.

As for a rbl, I didn't really think of trying it until this. So thanks :-) (It makes me even more glad I posted this - I never would have imagined such a useful response, but I got it anyway.)

[mr_mischief]

There are settings for Postfix to only accept mail for domains for which it is the MX record. That would solve that problem. The mydestination setting isn't duplicated data, though, because I can easily set up a non-public email domain for testing purposes. There are provisions in RFC 2821 for delivering to a machine with an A record with no MX record, too.

If you really want robust spam filtering in Perl, you could install amavisd-new as your MX-receiving SMTP server and forward mail that passes to Postfix. I recommend having a spam address and a ham address that amavis uses for Bayesian learning. Configure that anything coming from your Postfix outbound SMTP server to Amavis at those addresses gets processed accordingly, and then training your Bayesian filter is as simple as forwarding mail.

The most successful anti-spam technique I've ever found, though, is to keep track of the number of invalid recipients from particular blocks of addresses, typically /24 blocks. You can measure in percentages of overall "RCPT TO" requests that fail, or a threshold of failed receipts per hour/day. Then, you can reject mail at the SMTP level from those blocks or, like I did, reject or drop packets with iptables or ipfilter from those blocks on your MX server. The configuration for either Postfix or iptables is easy to wrap in Perl. (So are amavis, shorewall, and more, of course). Be sure to have a list of exceptions, though, because you might not want to cut yourself off from AOL, Yahoo, and other public email sites (I couldn't, using this for a commercial ISP). AOL has a list of all the ranges their outgoing email servers use, though, so they're pretty easy.

Dropping at the packet level does break a few RFCs, the one I can recall presently being the section of RFC 2821 that each domain and host that accepts or routes mail should have a reachable postmaster address despite filtering (which almost nobody follows anyway, since sending to "postmaster" then just becomes an easy way to spam). The really accepted way to do it, though, is to return a 554 policy error with text like "Your network block has been spamming this server."