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