(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
