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
