[ietf-dkim] The key record upgrade attack

[Hallam-Baker, Phillip]

> From: Stephen Farrell [mailto:stephen.farrell at cs.tcd.ie] 

> So if a mailing list mangles a message then you'd consider 
> the message as no longer being policy-compliant? I guess 
> that's one reasonable way to look at it, but I don't believe 
> its the only reasonable way. I could equally treat this as a 
> case where the message appears to conform to the policy, but 
> fails signature checking.

A mailing list is not quite the open hole in the specification that many seem to think. 

I think it is a reasonable goal to get to the point where there are only three likely explanations for a failed message:

1) The message was damaged by a mailing list
2) The message is fake.
3) The administrator for the outgoing mail is a dufus.

Note that I don't even include the mail forwarders like PO box here. If they don't get their act together they will shut up shop. They are paid to do the job. The reason mailing lists are unlikely to be a problem is that they are often volunteer run and the incentive to upgrade is much less.

In any case where mail is being forwarded to me it is without exception because I have established that forwarding relationship.

This is something I can block very effectively in the client.


So the path processing for cases are very different here.

It is not enough to say 'we created a mess, sorting it out is someone else's implementation issue'.


> Sounds a bit like an implementation issue.

What is the point of a specification if not to provide the information the implementations need?