On Thursday 13 July 2006 14:29, Tony Hansen wrote: > 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 >
The appeal had multiple points. One of which was that resent-* header fields were for information only and should not be automatically acted on: > 2. Use Resent-* headers for automatic action, which is incompatible > with RFC2822 > Ref: http://www.ietf.org/rfc/rfc2822.txt (section 3.6.6): > | Resent fields are > | strictly informational. They MUST NOT be used in the normal > | processing of replies or other such automatic actions on messages. > I take "automatic action" to include rejection and bouncing of messages > and draft-lyon-senderid-core-01 recommends when PRA address derived from > Resent- header is not authorized based on corresponding SPF record check, > then message is to be rejected by mail system in automated manner. If the fields MUST NOT be used in processing on the receive side, what's the point in signing them? While signing them surely doesn't hurt, I can't see how it should be required. So, getting a back to your original point: > 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. I think this is incorrect. Resent-* are fundamentally different than From:/Sender:. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
