taint.org: Justin Mason’s Weblog

There’s a common misconception about spam, email, and email authentication; Matt Cutts has been the most recent promulgator, asking ‘Where’s my authenticated email?’, in which various members of the comment thread consider this as an anti-spam question.

Here’s the thing — email these days is authenticated. If you send a mail from GMail, it’ll be authenticated using both SPF and DomainKeys. However, this alone will not help in the fight against spam.

Put simply — knowing that a mail was sent by ‘jm3485 at massiveisp.net’, is not much better than knowing that it was sent by IP address 192.122.3.45, unless you know that you can trust ‘jm3485 at massiveisp.net’, too. Spammers can (and do) authenticate themselves.

Authentication is just a step along the road to reputation and accreditation, as Eric Allman notes:

Reputation is a critical part of an overall anti-spam, anti-phishing system but is intentionally outside the purview of the DKIM base specification because how you do reputation is fundamentally orthogonal to how you do authentication.

Conceptually, once you have established an identity of an accountable entity associated with a message you can start to apply a new class of identity-based algorithms, notably reputation. … In the longer term reputation is likely to be based on community collaboration or third party accreditation.

As he says, in the long term, several vendors (such as Return Path and Habeas) are planning to act as accreditation bureaus and reputation databases, undoubtedly using these standards as a basis. Doubtless Spamhaus have similar plans, although they’ve not mentioned it.

But there’s no need to wait — in the short term, users of SpamAssassin and similar anti-spam systems can run their own personal accreditation list, by whitelisting frequent correspondents based on their DomainKeys/DKIM/SPF records, using whitelist_from_spf, whitelist_from_dkim, and whitelist_from_dk.

Hopefully more ISPs and companies will deploy outbound SPF, DK and DKIM as time goes on, making this easier. All three technologies are useful for this purpose (although I prefer DKIM, if pushed to it ;).

It’s worth noting that the upcoming SpamAssassin 3.2.0 can be set up to run these checks upfront, “short-circuiting” mail from known-good sources with valid SPF/DK/DKIM records, so that it isn’t put through the lengthy scanning process.

That’s not to say Matt doesn’t have a point, though. There are questions about deployment — why can’t I already run “apt-get install postfix-dkim-outbound-signer” to get all my outbound mail transparently signed using DKIM signatures? Why isn’t DKIM signing commonplace by now?

Tags: accreditation, anti-spam, authentication, dkim, domainkeys, email, habeas, reputation, return-path, smtp, spam, spamhaus, spf

The combined DKIM standard, mixing Yahoo!’s DomainKeys and Cisco’s IIM, has been submitted to the IETF as a candidate spec by the MASS ‘pre-working group effort’. I like the idea behind both (a few years back, I, a few other SpamAssassin developers, and several others came up with the roots of a message-signature anti-forgery scheme we called ‘porkhash’, but never really went anywhere with it), so I’m glad to see this one progressing nicely.

Seeing as I never seem to write much about anti-spam here any more, I might as well remedy that now with some comments on the new DKIM draft. ;)

It’s a very good synthesis of the two previous drafts, DomainKeys and IIM, more DK-ish, but taking the nice features from IIM.

The ‘h=’ tag is now listed as REQUIRED. This specifies the list of headers that are to be signed. If I recall correctly, this was added in IIM, modifies the behaviour of DK, and is a good feature — it protects against in-transit corruption by, (a) specifying an order of the headers, to protect against MTAs that reorder them; and (b) allowing sites to protect the ‘important’ headers (From, To, Subject etc.) and ignore possible additions by MTAs down the line (scanner additions, mailing list munging and additions, and so on).

A list of recommended headers to sign is included, with From as a MUST and Subject, Date, Content-Type and Content-Transfer-Encoding as a SHOULD.

Forwarding is, of course, just fine. This one doesn’t suffer from the SPF failure mode, whereby a forwarder will break a signature if it doesn’t rewrite the SMTP MAIL FROM sender address. (Of course, it now has its own new failure modes — the message must be forwarded in a nearly-pristine state.)

The message length to sign can be specified with ‘l=’. This may be useful to protect against the issue where mailing list managers add a footer to a signed message. It recommends that verifiers remove text after the ‘l’ length, if it appears, since that offers a way for spammers to reuse existing signatures. I still have to think about this, but I suspect SpamAssassin could give points for additional text beyond the ‘l=’ point that doesn’t match mailing list footer profiles.

The IIM HTTP-based public-key infrastructure is gone; it’s all DNS, as it was in DK.

The ‘z=’ field, which contains copies of the original headers, is a great feature for filters — we can now pragmatically detect ‘acceptable’ header rewriting if necessary, and handle recovery at the receiver end.

Multiple signatures, unfortunately, couldn’t be supported. I can see why, though, it’s a very hard problem.

The ‘Security Considerations’ section is excellent — 9.1.2 uses a very clever HTML attack.

Looks like development of DKIM-Milter, and an associated library, libdkim, are underway.

Given all that, it looks good. It’s not clear how much we can do with DK, and now DKIM, in SpamAssassin, however — it’s very important in these schemes that the message be entirely unmunged, and in most SpamAssassin installs, the filter doesn’t get to see the message until after the delivering MTA, or the MDA (Message Delivery Agent), has performed some rewriting. This would cause FPs if we’re not very, very careful.

I hope though, that we can find a useful way to trust DKIM results. It appears likely that they’d make an excellent way to provide trustworthy whitelisting — ‘whitelist_from_dkim’ rules, similarly to our new whitelist_from_spf support. (In fact, we could probably just merge both into some new ‘whitelist_from_authenticated’ setting.)

Tags: course, dkim, domainkeys, failure, iim, list, message, mtas, subject, the