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: ietf-dkim(_at_)mipassoc(_dot_)org"
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 <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html