Scott, please reread the appeal response note more carefully. It does
not denigrate Resent-*, but acknowledges that rfc822/rfc2822-compliant
systems were not required to follow the practice. (It's marked as a
SHOULD requirement.) Consequently, a system can be compliant without
supporting Resent-*. However, *IF* a system supports that SHOULD (and
they should, of course, :-) ), then DKIM had better be able to handle it
properly
Tony Hansen
[EMAIL PROTECTED]
Scott Kitterman wrote:
> On Wednesday 12 July 2006 23:16, Tony Hansen wrote:
>> Resent-From: and Resent-Sender: would be signed only if present in the
>> header. It's perfectly legit for a forwarding system to add them (and
>> expected according to the specs), and if that forwarding server then
>> signs the message, those headers MUST be treated in the same category as
>> From: and Sender:.
>>
>> All four of these headers should be treated as: if present, it MUST be
>> signed.
>>
>
> IIRC, this issue was the matter of a recent IESG appeal:
>
> http://www.ietf.org/IESG/APPEALS/appeal2-draft-lyon-senderid.txt
> http://www.ietf.org/IESG/APPEALS/appeal-response-william-leibzon.txt
>
> Based on that, I do not believe it is correct to state that it is either
> legitimate or expected for automatic forwarders to add resent-* header
> fields.
>
> RFC 4407 got published with an IESG note because it was experimental. Here
> the bar is higher, so however this issue gets resolved, I think it important
> to not do anything that indicates resent-* header fields are to be added
> automatically.
>
> Scott K
> _______________________________________________
> 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
