CircleID

This doesn't mean that the essential concept of DomainKeys is broken, rather that more work is needed to account for problems like the one described here.

I agree. I originally wrote this piece for an IBM/Lotus Notes/Domino user audience and, clearly, there are issues that need to be addressed to make DomainKeys viable for such users.

I suspect the issue is more widespread however (incorporating many other sites relying on other popular proprietary email software which implements an SMTP MTA) and this, while not defeating the DomainKeys concept, may make widespread adoption problematic.

Ultimately it boils down to RFC compliance issues and these are often matters of some debate if not controversy.

If simple things like using EHLO, not HELO and offering a valid primary domain name as the EHLO phrase are so often flouted, how much more difficult will it be to encourage even a significant minority of email administrators to implement software that does not rewrite or reorder headers?

1. DomainKeys does not rely on headers being in a particular order.

2. DomainKeys lets the sender specify which headers to include in the calculation. So ones that are a problem can be left out.

3. DKeys also does a canonicalization of the data, to eliminate variances from transit. Alas, defining the right algorithm for this turns out to be very difficult.

I concur with Yakov.  If there is an issue with Domino, there is an issue with Domino. 
Anything responsible that can be done to reduce unsolicited email at the server level is going to have some hiccups due to the variety of SMTP handlers that are out there.
It is a feature, not a bug ;).

One issue is - when is Domino actually changing the headers? A normal domainkeys scenerio would be that cryptographic authentication would occur at receipt by the mailserver, before any headers were altered.

Also, there are plenty of good reasons why IBM might want to change Domino's behavior. Just because a mail server (MTA) is RFC compliant doesn't mean that it will support all of the functionality that its user's desire. I have no doubt that if DomainKeys were to become popular, all the major MTAs would support it, regardless of 2821 and 2822.

The biggest barrier to adoption of useful anti-spam technology has been the efforts of a few diehards in the IETF to demand compliance with every previous mail standard, regardless of sense or utility. Standards need to evolve to face unforseen challenges. RFCs are not some sort of revealed truth.

Perhaps my mistake was in the title of this piece.

DomainKeys is not broken - indeed the theoretical concept is well founded. However there exist many practical obstacles to widespread adoption, one of which I have illustrated.

The issue here is not that of "demanding compliance with every previous mail standard, regardless of sense or utility". It may be that such compliance, while widely ignored by user organisations and software suppliers, is actually needed. Specifically, if all MTA software really did what the standards appear to suggest (prepending all new headers and not rewriting old ones), the problem would be less severe.

As to the issue of canonicalization - DomainKeys does indeed implement this and mandates two algorithms, "simple" and "nofws". Both of these would be broken by the sample headers in this article because neither anticipates reordering of headers or semantic changes to existing headers such as changing charset=US-ASCII to charset="US-ASCII".

Other changes are routinely made to messages in transit by all sorts of different software, for example automatic conversion between MIME types (8 bit MIME to quoted printable and so on).

While the issue may be easily addressed in open source MTA software, the widespread use particularly by corporate users of proprietary software cannot be ignored and modifying the behaviour of these systems will only happen when their suppliers (Microsoft, IBM and so on) sign up to DomainKeys. It seems that at least Microsoft is unlikely to do so because it is still pursuing Sender ID as its preferred sender verification solution.

Hmm.  Re-arranging of the headers is taken care of by the "h=received:message-id:..." part of line -2.  The whitespace changes are taken care of by the 'nofws' canonicalization.  Thus, the only legitimate complaint in the article is that
Content-Type: text/plain; charset=US-ASCII
is changed to
Content-Type: text/plain; charset="US-ASCII"

Does Lotus Domino enable forwarding? If not, this change affects exactly 0 people. If so, the change only affects those that use Lotus Domino as the border MTA and forward the mail to a DomainKey aware MTA. Sounds pretty unlikely to me.

As for Microsoft, CERN (the creators of the WWW), has released a DomainKey library for MS Exchange 2003.  http://mmmservices.web.cern.ch/mmmservices/Antispam/DomainKeysLibrary.aspx