looking at the new DKIM draft
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
