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