Squawks of the Parrot

As a compromise my procmail config discards messages with extremely high scores (>100) rather than quarantining it.

I can everything that gets a score >= 12. I used to go through the log once in a while but never found a false positive sent to /dev/null.

Also, why leave this to SpamAssassin and not just do it directly in procmail? (procmail can score conditions, too -- and you get any number of them per mail.)

I've long had a procmail rule that checks messages for attachments and simply throws away anything with an attached .EXE, .SCR, .PIF, .LNK and how they're all called. I can count the number of worms that got through ever since on the fingers of one hand.

These galactically idiotic virus detection notification mails drive me up the walls, though. They've grown to become a serious portion of the "general junk" mailtraffic -- I'm starting to think every virus scanner author who even puts this option in his software, at least if he doesn't give users a huge flashing warning about the caveats when they enable it, needs a session of parking lot therapy. If they make it the default they need to be shot for not knowing what the heck they're even doing.

Sorry for the hard feelings -- I'm not usually that negative, but this issue seriously gets my goat.

*grumble*

To balance the negativity a bit -- SPF is the single most elegant solution to any problem as intractable as spam seemed to be that I've seen in a long time. The simplicity is astonishing, and gets even more so considering how exceedingly effective it is. There are caveats of course (can't ever have the cake and eat it, can we?), but it had been a long time since I felt this sense of "whoa (i mean, whoa) -- someone seriously knew what they were doing here".

SPF gives me that annoying sense of "whoa (i mean, whoa) -- someone seriously does not know what they are doing here" -- another bogus "solution" to spam.

I'm not naive. I have always been looking at solutions from the attacker's perspective; it's the (real) Murphy's Law that anything that can possibly happen will happen. I am impressed with SPF preciesly because as much as I try, I fail to see how spammers can "dodge the change" with anything less than huge effort.

You need to control some part of the DNS infrastructure in any case; you need valid DNS records or you can try to spoof them. Valid DNS records will end up on blacklists quickly; spoofing will require true cracking attacks against part of the infrastructure containing the victim mail server. If that's the server itself, well, shucks. If you don't actually touch the mail server, but manage to DNS traffic from outside the network it's in, well that's just one more reason to tighten up DNS. And whenever DNS tightens up for any reason, it will also strengthen SPF.

Please point out if there's any attack vector I missed.

OK, so first we need to get every single domain name to upgrade to use SPF (which is impossible). But even if we do that, spammers will have no trouble finding domain names that have an open SPF policy (corp-too-lazy-to-get-a-vpn dot com), cheap sources of new domain names (e.g. foo.easydns.net), purchasing time on legitimately-used domains (corruptible-isp dot net), or even starting new legitimately-used domains as cover (hottermail dot com).

(Note: the spam solution here didn't like the original content of this post and made me change "." to "dot".)

While SPF doesn't solve the spam problem, it does take care of some of the sub-problems. If nothing else, SPF will take care of joe-jobs (where someone sends out mail with someone else's from address) done on domains that exist. Even if it never does anything else, cutting down on the avalanche of bounce messages and flames that come when someone uses your e-mail address in spam will be a welcome thing. (Only if your domain has SPF set up right, and some receivers use SPF, but hell, if only MSN, AOL, Yahoo, Hotmail, and Earthlink check SPF and reject mail that fails it'll cut down on a lot of that)

Yeah, it's only a partial solution, but you take what you can and work to make it better as you go.

(And the anti-spam filters don't like domains with multiple dashes, as they're bogus and/or webspam so often I just unconditionally reject 'em)

Aaron: good points. I was stuck in the technical domain. What they confirm me in, though, is that this time spammers are actually being forced to adapt to constraints beyond just the software they use -- every other antispam measure so far has only required more carefully crafting the mail headers, which is no issue at all.

Spam is only going to stop when the cost to spam becomes higher than the potential revenue; as cheap as email (any email, incl illegitimate) currently is, the ratio is astronomically in favour of spammers. So we need every measure we can get that raises the barrier for entry and also every measure we can get that raises the spammer upkeep cost.

I'm sure I'm not telling you any news.

The point is: SPF does do that. Only a bit, maybe, but it does. It's the first antispam measure I've seen proposed which goes beyond swatting at flies already buzzing around your mail server.

Anyone impressed with SPF and other "great" solutions should really really really pay attention to what people such as Wietse Venema, D J Bernstein and Eric Allman has to say about it. Or at least anyone who has spent some in a competent ISP abuse department.

I must say the thing that disturbs me most about SPF is that it is marketed as a spam stopper, which it isn't. Not at all.

Spam isn't sent with false from-headers due to some fundamental necessity necessity, that's only the current state of affaris and it will change radically the second SPF or anything else is implemented. Spammers will either target domains with unpublished SPF records, or more likely, just use valid from-domains -- either the actual domain of the network where the slave is situated or just buy domains in bulk and publish SPF records for them.

(If they didn't their "customers" would take their business to someone who did! Always keep in mind that someone out there is *paying* them to abuse your mailbox!)

Remember SPF is all about the SMTP handshake, not the actual header contents. It's not like it's an audit trail anyway. We're talking about a business that's a) illegal in many countries/states, b) breaking every possible ISP AUP, c) already abusing viruses, break-ins and open proxies/relays as much as possible. Do you *really* think a minor SMTP tweak would disturb their business much??

Apart from that it doesn't work it has some technical drawbacks too:

1. To be successful, it requires that most of the world uses this scheme. We're talking a world where Blaster could roam free, and which it will take 10 years something to stop setting up open relays. Also, see next point.

2. It completely breaks forwarding e-mail, which is crucial for many people. It also makes it more difficult to send e-mail since you need to queue it on different servers depending on the from-address. SPF offers a theoretical solution to this as well, which so far is vaporware. Not one implementation exist.

3. There is nothing to judge yet. Only proof-of-concept code exist. No one has allocated SPF DNS records yet, let alone using them. TXT records are used in interim, which breaks completely with people using them for other purposes.