[ietf-dkim] Draft minutes...

[Jim Fenton]

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.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.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
>