ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] The problem with the DKIM design community

2013-07-01 14:26:56
On Mon, 1 Jul 2013, Alessandro Vesely wrote:
Well, not really.  MAIL FROM: is only visible after delivery, so to
avoid dangling signatures one should store its value in some other
header field or... in the i= tag.

ITYM "only visible *before* delivery"

There's long been a standard header for that purpose, "Return-path:".
But EDSP checking in the MUA is not very useful -- if the Return-path is
disavowed, then bouncing is an even worse idea than normal.  The only
place to act is in the SMTP transaction at the border.

It does mean that if the mail passes through an SPF Sender Rewriting
Scheme forwarder, then it will end up with an unbroken but irrelevant
signature.  Even if that forwarder knows about EDSP, it can't strip the
signature because it can't know that it isn't there to serve a different
accessory protocol yet to be invented.  After all, most of the time MAIL
FROM: = From:, so the signature added for the sake of EDSP will
simultaneously be serving ADSP or DMARC.

But I don't think that's a problem.  The message will get through,
because the forwarder now owns the MAIL FROM and it's up to him whether an
EDSP check is needed.

Also, if any DKIM accessory protocol will false positive OR false negative
due to the presence of irrelevant (ie: not the d= you're looking for)
signatures, then that accessory protocol is really broken.

Of course, it's always correct for an accessory protocol to dismiss a
message as "unsigned" if the irrelevant signatures the only signatures
present.  Any other behavior would fall under "false negative due to
irrelevant signatures".

---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html