On Fri, 05 Jun 2009 18:27:06 +0100, Doug Otis
<doug(_dot_)mtview(_at_)gmail(_dot_)com>
wrote:
On Jun 5, 2009, at 6:36 AM, Charles Lindsey wrote:
No, that is NOT what section 1.6 of RFC 5451 says. It requires
removal of any pre-existing A-R header "claiming to be valid with in
its [the ADMD's] boundaries", which essentially means (AIUI) any A-R
header that might be mistaken for one that might/would/should have
been created within that same ADMD.
By selecting specific A-R headers to remove, header content might be
processed post delivery, and then appear to match against some trusted
domain.
For sure, individual recipients may wish to check signatures etc. for
themselves, espeicially if they have doubts about the policies applied by
their local assessors. If the local assessor has unnecessarily removed
sone A-R that is actually covered by the signature, then that becomes
impossible.
And if they have doubts about the policies of sone earlier mailing list
expander, they might wish to see exactly what that expander had actually
done to the message. For such forensic investigations, removing useful
information (aka "dumbing down") is always a dumb thing.
The safest solution would be to remove _all_ A-R pre-existing A-R
headers from different environments ...
But that's not what the standard says.
Note that Appendix B.6 of RFC 5451 contains an example exactly
equivalent to the one I have just given, including the retention of
A_1 (and even S_1).
IMHO, appendix B.6 is overly optimistic for today's environment.
Maybe so, but that document is a proposed standard, and unless you have
plans to get it revised, we must try and work with it as it stands.
Nothing in that example is contrary to what that standard says normatively.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html