On 2/22/11 4:08 AM, Alessandro Vesely wrote: > On 22/Feb/11 00:31, Douglas Otis wrote: >> Any message containing multiple orig-date, from, sender, reply-to, >> to, cc, message-id, in-reply-to, and subject header fields will not >> produce a valid signature. See Section 5.3. > The current Section 5.3 says: > > Therefore, a verifier SHOULD NOT validate a message that is not > compliant with [RFC5322, RFC2045 and RFC2047] specifications. > > IMHO, it is somewhat vague. That SHOULD-NOT could be "promoted" to a > MUST-NOT for a finite number of specific features --to be explicitly > listed for readers' convenience. Since it is a verifier's action, > this consideration should perhaps be moved somewhere toward the end of > Section 6. Anyway, it is vital to keep such issues related to > 5322-semantics clearly separated from crypto-mechanical > signature-validity specifications. Collecting them into their own > section(s) may ease a future split. > > BTW, Section 5.3 has some other paragraphs on 7-bit encoding that may > deserve revisions, also in view of EAI. Agreed.
SHOULD NOT in 5.3 should be promoted to MUST NOT for specific features as suggested, simply to ensure security. It is wrong to describe acceptance of messages having multiple From header fields, especially when this creates a significant security exposure. DKIM does not specify how users know a message's status. Users might use something as simple as the sorting of messages based upon the From address, where they know acceptance criteria for specific domains ensures a valid DKIM signature. They might assume there is only a single From header in a message having a valid DKIM signature. EAI has also made enough progress to deserve closer review as well. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
