I think it would be better to say that the header should usually be
added by the MX for an address, since that's the only point where you
can check path authentication like SPF and Sender-ID.
Be sure to write this with "as if" in mind. In a large server farm, I
could easily imagine a setup where the border MTAs have minimal hardened
code and pass the work along to internal hosts which do the authentication
using headers added at the border that are known to be reliable.
I suppose since elsewhere in the document it says border MTAs should discard
any headers they find that they don't want to trust so it's not a big deal to
remove the restriction. My thinking here was to add an extra place where MTA
implementors are discouraged from adding the A-R header in a place that might
confuse someone downstream such as a hapless user or MUA.
I hope what you meant there is that it should strip out headers that it
can tell are lies, e.g., headers with its own name on it. The hapless
users better configure in the names of A-R headers known to be on a
reliable path, or they're going to get spoofed no matter what.
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet for
Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html