On 15/Oct/10 18:59, Jim Fenton wrote: > On 10/15/10 2:12 AM, Alessandro Vesely wrote: >> Fuzziness stems from the fact that a signature on a given message may >> either verify or not depending on how meticulously the verifier >> interprets that "SHOULD". The "MUST" immediately following it is >> deceptive because it conveys the false impression that a signature is >> REQUIRED to fail in case a particular header field is added after signing. >> >> Because of the SHOULD, existing verifiers can still be considered >> compliant. Thus, it may still make sense for a signer to still put >> "h=from:from". Why did Jim remove that advice? > > I wanted it to be clear that it's the verifier's job to detect the > duplication, not the signer's job to work around the problem. Recall > that SHOULD means, roughly "Do it unless you have a valid reason not to, > and have considered the implications."
The implications are that instead of having a signature that is either valid or not we'll have signatures that verify according to a variable percentage of existing verifiers, as it is for virus detection. Why not mandate to fail verification if the signed body contains a virus? To clarify, I'm not against changing DKIM. However, if we do, we better integrate the change in the original design. First of all, it should be in section 5.4. Second, it has to be an explicit list of header fields, rather than generic references to RFC 5322, RFC 2919, etcetera. Third, the spec should state that any repetition of such fields in the h tag, e.g. h=from:to:from:to, has to be regarded as a backward compatible guard, and new implementations must discard duplicated names retaining their first occurrence only. Then, it can derive the implication that signers cannot produce a valid signature of a message whose header actually contains multiple instances of any listed field... Lots of work and some semantic change... > Besides, as Mark Delany said yesterday, having to do > > h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id > > "strikes me as an ugly hack." But then the whole DKIM-Signature is an ugly hack :-) >> MUAs often disallow writing a "From" with multiple mailboxes, thus a >> sender may happen to end up with two "From" fields after hacking in an >> attempt to recognize authorship to a second mailbox. > > Are you saying that there are MUAs that disallow a From: with multiple > addresses, but support the addition of multiple From: header fields? If > so, I hope it's not a popular MUA that's doing this. One can always find ways or extensions to add /any/ header field more easily than for modifying existing ones. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html