ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] The key record upgrade attack

2006-08-04 09:21:57

From: Stephen Farrell 
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)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?


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html