One additional thought on the whole double-From: argument -- if RFC language on the issue is justified at all, it really belongs in the ADSP RFC, not a core DKIM one.
A double-From: doesn't even rise to the level of theoretical threat except when dealing with ADSP (or a successor). If we, for example, invented an "LDSP" protocol to allow mipassoc.org to assert that any message bearing "List-Id: [email protected]" without a d=mipassoc.org signature is highly suspicious, then the operation of that defense would be entirely unexploitable by double-Froms. Of course, a lazy "LDSP" might be exploited with multiple List-Id: headers, and that would actually be more significant. List-Id: was invented after RFC822, so we can't claim multiple copies of it violate the protocol. To the core DKIM spec, "From:" isn't magic at all. Rather than enumerate every header that might be sensitive, we should put in a non-normative note that layered protocols should consider the issue: { Most expected applications of DKIM will involve signatures added by a sender in order to justify their use of a name in some other header of the message. For example, ADSP allows a domain to assert that their signature must be present for a message bearing one of their addresses in the From: header. It is suggested that such layered protocols include an explicit requirement to check for multiple copies of whichever header they defend. Otherwise, a situation could arise where a lazy validator approves a message based on all appropriate signatures being present for just one instance of the header, and yet a downstream entity falsely assumes a different instance was so validated. } ---- Michael Deutschmann <[email protected]> _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
