[ietf-dkim] draft-ietf-dkim-mailinglists-02 review

[John R. Levine]

  [ aargh, Alpine has the classic Unix user interface: "if you didn't want
    me to delete all your files or, in this case, send your half written
    message, why did you push that button?" ]

>> If they say their mail is discardable, take them at their word and discard 
>> it.

> I disagree.
> 
> The ADSP=discardable deployer is not conveying apathy regarding the 
> deliverability of their mail, quite the opposite IMO.  They are saying (to 
> paraphrase) "please attempt to verify the DKIM signature on this message 
> against the key record in our DNS for this domain/subdomain, and if you 
> cannot verify the signature then please discard the message as a means of 
> protecting your subscriber from phishing attacks, otherwise please deliver 
> the message and do so knowing we put this much effort into ensuring the 
> goodness of the mail before we sent it".

This is a really good example of why ADSP isn't useful.  I believe that's 
what you mean when you set adsp=discardable, and what Paypal means, and 
what Paypal has said to networks with whom they've offered private advice 
on handling their mail, but it's not what I meant when I wrote the section 
about discardable and I don't think it's a fair reading of the RFC. 
People want to read way more into it than is actually there.

Early drafts of what turned into ADSP used the word "strict" which I 
changed to "discardable" to make it clear that if you set this flag, 
you're saying the mail is unusually unimportant, to the extent that if 
there's doubt about its legitimacy, just throw it away.

Even the early drafts said

   The entity does not expect to send messages through agents that may
   modify and re-sign messages.

The final version said

   if a message arrives without a valid Author Domain Signature due to
   modification in transit, submission via a path without access to a
   signing key, or any other reason, the domain encourages the recipient(s)
   to discard it.

I think it's a reasonable interpretation to say that if you expect your 
list software might break the signature, you're doing the sender a favor 
by pre-discarding it since that's what the recipients should do anyway.

R's,
John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2304 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mipassoc.org/pipermail/ietf-dkim/attachments/20100913/0d681dc8/attachment.bin