Eric Allman wrote:
The draft has /always/ said that these header fields are to be
signed. From -03:
any header field that describes the role of the signer (for
example, the Sender or Resent-From header field if the
signature is on behalf of the corresponding address and that
address is different from the From address) MUST also be
included.
All I've done is re-word it.
We clearly have a disconnect here. When I read the previous text, I see that
it is the *signers* resposibility to figure that role based stuff and if
it can,
it MUST add those headers to h=. If it can't figure out that role, then
it's not
under any obligation to add them. Thus a receiver MUST NOT enfore that
the same way that it can enforce From (which MUST be signed regardless).
What we're morphing into here is where the signer MUST understand its
signing role for these other headers, and that gives me a great deal of
heartburn. Worse, is that a receiver would be entitled to REJECT the
signature if it thought I got my signing role wrong. That's completely
nuts. But that's the net effect of making inclusion of those MUST's.
I can't see the entire context of what you've modified, but if it still
contains
any of the paragraph you just quoted, we've got a really big problem. If
it's just the new text, my previous comments apply: making those fields
MUST INCLUDE in h= probably breaks a bunch of happily working
implementations and I really don't think the gain (if any) is worth that.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html