On 10/13/10 8:04 AM, John Levine wrote: >> Subject: Buy fake watches at fakewatch.example.com! >> >> Will some clients display the second subject line? I suspect some >> will. Do we need to recommend that signers also add a protective second >> subject: to their h= value? Or do we need to require that verifiers >> make sure that any header fields that are signed and aren't supposed to >> be duplicated, aren't? I'm not sure, but right now I'm leaning toward >> the latter. > I went through pretty much the same thought process and came to the > same conclusion. > > It seems to me that there are some fairly cheap extra checks tht a > verifier can make that will defend against malformed mail that would > be likely to display confusingly in an MUA. Yes, it's technically not > DKIM's job to verifiy 5322 conformance of incoming mail, but as Barry > noted, it's not anyone else's job, either.
My inclination is that the spec should say something like: - The verifier SHOULD consider the signature invalid if a signed header field occurs an inappropriate number of times in the message header according to section 3.6 of RFC 5322. - The verifier MAY consider the signature invalid if it detects other message syntax violations of RFC 5322. - (??) The verifier SHOULD consider the signature invalid if the List-Id header field is signed and occurs more than once in violation of RFC 2919. The last provision worries me a bit because it opens the door to other specifications that define header fields. On the other hand, I can picture an attack involving insertion of a bogus List-Id header field in order to influence the handling of the message. The overall philosophy here is to strongly encourage verifiers to watch for this attack while not making current DKIM implementations obsolete, but without requiring essentially open-ended syntax checking of message by DKIM verifiers. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
