On Saturday, July 09, 2011 07:19:17 PM Michael Deutschmann wrote:
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).
The abstract for RFC 4871 starts ...
"DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and
contents of messages by either Mail Transfer Agents (MTAs) or Mail
User Agents (MUAs). The ultimate goal of this framework is to permit
a signing domain to assert responsibility for a message, thus
protecting message signer identity and the integrity of the messages
they convey ..."
Verification of source and contents is fundamental to the DKIM requirements.
If it's not, the assertion of responsibility is meaningless (maintaining the
assertion of responsiblity even though the message has been modified in a
meaningful way is nonsense).
I wish we could have removed l= for this reason.
I think we should make it clear that singleton header fields like From (and
Subject and Date) can be added without breaking signatures unless one is
careful as a signer and/or a verifier. This is related to a core DKIM design
principle and doesn't need ADSP (or other non-standard measures) for it to be
something we should care about.
I haven't had time to carefully parse all the proposed language, so I'm not
going to comment on the specifics of the current proposals, but I think it's
just flat out wrong to claim that payload integrity is unrelated to DKIM.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html