(subject adjusted)
A sender using SRS would need to maintain a database of valid addresses.
However, that task can become unduly complicated if the database has to
be kept in sync across several distant hosts. A digital signature can
substantially complement the security of the necessarily-too-short hash
added to an SRS address, making it possible to avoid the database
entirely, except for address length worries. That's where EDSP can save
the day.
On Mon 01/Jul/2013 21:24:25 +0200 Michael Deutschmann wrote:
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"
It has to be in the message content for DKIM to be applicable.
There's long been a standard header for that purpose, "Return-path:".
The signature the OP posted had h=content-type:mime-version:subject:
list-unsubscribe:reply-to:to:from:date:message-id, so the sender had to
stuff it in i=.
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 is not very useful to the SMTP receiver either. The only value added
is the d= domain supplied by EDSP. SPF leaves the receiver
wondering about where the cut lies, but that's a non-actionable datum
anyway, for the time being.
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".
Yes.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html