On 14/Oct/10 20:40, Barry Leiba wrote:
6.1.1 Validate the Message Syntax
The verifier SHOULD meticulously validate the format of the message
being verified against the requirements specified in [RFC5322],
[RFC2045], and [RFC2047]. In particular, limitations on the number of
occurrences of particular header fields specified in [RFC5322] section
3.6 SHOULD be verified. Messages found to be in violation of these
checks MUST return a PERMFAIL (message syntax error) verification result.
-1
If we go for changing the protocol in order to avoid the exploit, we
should explicitly enumerate the header fields whose duplication
verifiers MUST check. "SHOULD meticulously validate" + "MUST return
PERMFAIL" make for a fuzzy protocol.
I think this is clear in Jim's text, and not contradictory or fuzzy at
all. They SHOULD check. If they check and the message violates the
checks, they MUST return a PERMFAIL. Where's the contradiction or
confusion?
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?
The spec should also state whether duplicated fields invalidate a
signature even when they are duly signed.
It does. A message that has two "From" lines, for example, is in
violation of RFC 5322. It makes no difference whether it's signed or
not. RFC 5322 (and the other specs) doesn't know about the signature
and doesn't care, and anything that checks compliance with it doesn't
care either.
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. The reason why
such a message may be questioned is not relevant to the signature
validation algorithm. Contrast that with
Signatures MAY be considered invalid if the verification time
at the verifier is past the expiration date.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html