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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >>> 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
