I interpret this text differently. If the signer uses a signing address
that matches (for example) Resent-From, and wishes the verifier to see
that its role is as a resender, then it must sign Resent-From. But
suppose someone resends a message to a mailing list, which itself
signs. The list isn't the Resent-From address, so it is not required to
sign Resent-From (although it may, of course).
-Jim
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.
eric
--On July 12, 2006 5:27:57 PM -0700 Michael Thomas <mike(_at_)mtcc(_dot_)com>
wrote:
Eric Allman wrote:
Huh? You've got me completely confused. DKIM should /never/ add
Resent-* fields. I don't see how that is stated or implied. I
can see how you might think that it has to include them in h=
even if they didn't already exist, so I've added "if included" to
the text.
I meant added to h=. You're forcing a DKIM protocol change to
mandate that
they be present. And yes, your previous wording wasn't at all clear
about whether
they only MUST be added if they were present. And I'm not sure that
"if included"
would be right -- if they're that important, you'd want to guard
against insertions
later in malicious MTA's, right?
Resent-* may seem "quaint" to you, but they are still in-spec and
used (by me, if no one else).
The issue is whether we really need to break a bunch of DKIM
implementations over
this. It sure doesn't seem to raise to that level of urgency to me.
Mike
eric
--On July 12, 2006 4:56:49 PM -0700 Michael Thomas
<mike(_at_)mtcc(_dot_)com>
wrote:
Eric Allman wrote:
Resent-* should only be added by MUAs when someone is
re-submitting a message back into the MHS. Essentially
Resent-From subsumes the role of From when a message is
re-submitted (ditto for Resent-Sender and Sender). It's not
quite this simple, since an MUA replying to a resent message
should still reply back to the original originator, not the
resending originator, but that's the basic gist of it.
The reason I'm pushing back on this is that it's a protocol
affecting change as I don't
think that I've seen many implementations that *always* add those
fields (does
Murray's? Mine doesn't by default). The change you're making here
would cause
a compliant verifier to reject those signatures. Is it really
*that* important? Maybe
it's me, but Resent-From and Resent-Sender seem pretty quaint and
in their
dotage.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html