In section 5.2 it says:
5.2. Trusting The Header
Rather than the coding rigor of doing a digital signature on the con-
tent of this header, it may be sufficient to establish a maximum SMTP
path length between the addition of the header and final delivery.
This sentence contains an incomplete phrase at the beginning and doesn't
parse properly. It should be reworded.
The path length is defined as the count of Received headers above the
Authentication-Results header. If more than that maximum path length
is traversed between insertion of the header and delivery, the value
of the header should no longer be trusted to be valid.
This doesn't follow. If I have a message that is verified at an MTA,
then forwarded through one or more accounts, why does that invalidate
that verification process.
Also be aware that some MTAs or gateways reorder headers, and the
location of the Received: headers vis-a-vis the A-R header cannot be
relied on.
This requires a configurable MUA setting to define this maximum path
length. The setting would need to take into account possible addi-
tional hops should the final delivery server be unavailable.
Although this approach likely bears a much shorter time to implement,
it is a less general solution than the proposed one and would proba-
bly require additional user education above the norm and thus lead to
more confusion on deployment. The MUA SHOULD trust this header if it
is trusting such headers and the path length after the addition of
the header is less than three.
I don't think this suggestion is viable and should probably be removed.
Discussion?
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html