ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Draft minutes...

2006-07-13 11:42:34
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
        tony(_at_)att(_dot_)com

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