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