[ietf-dkim] Draft minutes...

[Eric Allman]

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