[ietf-dkim] draft-ietf-dkim-mailinglists-02 review
John R. Levine
johnl at iecc.com
Mon Sep 13 18:18:41 PDT 2010
[ 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2304 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mipassoc.org/pipermail/ietf-dkim/attachments/20100913/0d681dc8/attachment.bin
More information about the ietf-dkim