[ietf-dkim] Draft minutes...
mike at mtcc.com
Wed Jul 12 16:56:49 PDT 2006
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
Murray's? Mine doesn't by default). The change you're making here would
a compliant verifier to reject those signatures. Is it really *that*
it's me, but Resent-From and Resent-Sender seem pretty quaint and in their
> --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,
>> and Date is fine and leave the rest to the disgression of the
More information about the ietf-dkim