[ietf-dkim] Draft minutes...

[Michael Thomas]

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

>
> eric
>
>
> --On July 12, 2006 4:44:57 PM -0700 Michael Thomas <mike at mtcc.com> wrote:
>
>> Eric Allman wrote:
>>
>>> For the same reason From: has to be signed --- they represent the
>>> [fill in blank with your favorite word: author, originator,
>>> whatever]  of the message.  I suppose we can legitimately ask why
>>> From: MUST be  signed though.  In terms of interoperability it is
>>> not required, but  in terms of being useful it seems like it is.
>>
>>
>>
>>    I'm unclear on Resent-From and Resent-Sender: can they be added
>> in transit?
>>    If so, the MUST as worded below will guarantee the signature
>> won't be valid
>>    after somebody adds those headers.
>>
>>    I guess if you're going to make these MUST requirements why
>> Sender or
>>    ListID aren't MUST's too. Frankly I think the wording with From,
>> Subject
>>    and Date is fine and leave the rest to the disgression of the
>> signer.
>