fl!ptop's Journal: Musings from a Spam Warrior

I have been aggressively fighting spam for about 6 years now, employing several techniques I've found work best. I thought that maybe I would share my thoughts and observations here on /. with others who are interested in doing what they can to thwart this menace to the Internet.

I started doing this because the amount of spam I was receiving was getting out of hand, on the order of 600-1000 spam messages per day. I administer about 50 different domains and have several email addresses that are widely published, which means I'm a big target to harvesters. Using my techniques I've successfully reduced the amount of spam I receive to around 10 per day.

I use sendmail, and the techniques I use to fight spam from within sendmail are:

• BAD_RCPT_THROTTLE - currently set to 1
• greet-pause - currently set to 5000ms
• require_rdns
• Spamcop

Any incoming message that passes these tests is then handled by SpamAssassin.

Now I know that blocking based on bad RDNS is considered taboo by many email administrator purists out there, since there's nothing in the RFC that requires a connecting machine have proper RDNS info. However, I block approximately 1,000,000 spam messages per month using this one rule, and have few false positives. If you do use the RDNS hack, I recommend you diligently read your server log summaries every day (which I do, even while on vacation), and contact the administrators of domains with machines that are missing this info. In almost all cases where I've done that, they're more than happy to add the RDNS info to their zone files. And, in a few cases, they were alerted to activity by their customers that violated their Terms of Service. Meaning, their customer wasn't allowed to use a machine on their network to send email, they were supposed to use the ISP's downstream SMTP server.

Occasionally, you'll find something funny using the require_dns hack. Just this morning, I saw this entry in my log summary:

ruleset=check_relay, arg1=[128.220.161.143], arg2=128.220.161.143, relay=smtp.jphnshopkins.edu [128.220.161.143] (may be forged), reject=451 4.1.8 Possibly forged hostname for 128.220.161.143: 24 Time(s)

I realized this was an obvious typo, and called Alan Shackelford, who's listed as the Administrative Contact for the domain johnshopkins.edu. He was appreciative of me pointing out the error, and even called me back to let me know he had fixed the PTR record and it had a 1 hour TTL.

Another thing to consider if you're thinking of employing the require_rdns hack - let your customers know what you're doing. That way, when an irate customer of theirs calls to say, "I can't email you at all, everyone else has no problems receiving my messages but everything I send you bounces back!" your customer will know what's going on. Instruct them to contact you right away so you can fix the problem. All of my customers appreciate the low amount of spam they receive a lot, and are willing to put up with the occasional false positive. I've found that setting up another email address (like gmail or yahoo), one that's not published or used for anything else (and that's not on your server), and telling the customer to instruct their customer to send a blank email to it can help troubleshoot delivery problems related to using the require_rdns hack.

I also am a paying member of Spamcop, and I report spam to them every day. This helps get hacked boxes that are part of spambot networks blacklisted more quickly.

In addition to these techniques, I have my own customized sendmail access file where I put domains that send nothing but spam. Particularly nefarious domains will get added to my firewall, where I'll just drop connections entirely. Sometime in the future I'll post my access file and firewall rules.