CTO, hesketh.com/inc.
Delivered May 25, 2006
at Webstock, Wellington NZ
http://www.webstock.org.nz
Permanently archived at:
http://hesketh.com/publications/webstock/2006/simplicity/
But they're not the only ones to blame:
Takeaway: idealistic blocking is somewhat risky due to the large number of legitimate, but misconfigured, mail servers and mail sources out there. Otherwise, should be able to block most spam at connect time without expense of content filters. Post-acceptance rejection ("blowback") is dangerous and stupid, an amplification of original abuse.
Sender Auth: ways to specify whether sender is allowed to send, and whether they are who they claim to be.
Reputation Services: ways to query known, trusted sources to determine reputation of sender(s).
Basic problem is that spamfighting is like fighting cancer, not like swatting flies or whacking moles; there are many different kinds of cancer and many different forms of treatment: same with spam
Gratuitous example: Chase - may send transactional mail from chase.com, bankone.com, bigfootinteractive.com, jpmchase.com, firstusa.com, alerts.chase.com, others. How do you trust this kind of mail?
March 2003: victim of massive joe job (probably ROKSO spammer Brian Westby) using forged address in our domain to send "lonely wives" solicitations.
Received hundreds of thousands of "bounces", many with headers, so we examined where the original messages came from: consumer broadband and dialup/dsl/cable.
Figured if we didn't want spam injected via those hosts bounced "back" at us by way of blowback sources, we probably didn't want it directly from them, either.
Also, many DNSBLs were being DDoS'd out of existence, so needed a way to manage our own antispam policy; earlier experiments with SpamAssassin and Vipul's Razor weren't sufficient.
Thus was born the "enemieslist".
Would you accept mail from these hosts?
We wouldn't, either. And that's where 80% of your spam comes from.
Well, they're all legitimate ISP mail servers.
The problem with DNSBLs: they only tell you where someone was spamming from, not where they will spam you from next. As number of listed hosts rises, and feed quality increases, your odds improve, but it's still not enough.
We could block 1-2-3-4.example.net, then 1-2-3-5.example.net, then... but instead we block n-n-n-n.example.net.
We can do this at connect time or soon after, depending on local policy and whether we want to gather more information before rejecting.
Building a database of naming conventions; over 15 thousand documented, describing almost 10 thousand domains in 182 countries. We add a few dozen a week.Works surprisingly well, with few false positives.
Takeaway: no longer plausible to run a mail server without easy, direct way to identify it as a legitimate source of mail.
Problem: RFCs are about as binding as W3C Recommendations; major vendors need customer pressure before they fix; smaller vendors often don't have the depth to recognize and fix their problems; what standards we have may not actually fix all the problems, anyway.
Tomorrow's session deals with the nuts and bolts of actual spam blocking, with detailed examples of some popular types of spam, spamware, and other forms of abuse (and how to fight them).
Thanks to the kind folks at Webstock for inviting me to speak, and to the folks at Signify for sponsoring me.
