On Jun 8, 2009, at 3:24 AM, Charles Lindsey wrote: > On Fri, 05 Jun 2009 18:27:06 +0100, Doug Otis <doug.mtv...@gmail.com> > wrote: > >> On Jun 5, 2009, at 6:36 AM, Charles Lindsey wrote: >> >> 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 some A-R that is actually covered by the > signature, then that becomes impossible.
The use of the DKIM l=, z= and x= features provide a means for recipients to separately evaluate DKIM signatures without reliance on intermediary assessors. In addition, the A-R header does not capture the IP address when assessing path registration protocols, which means that safe recipient reassessment might only be possible in the case of DKIM or reverse DNS. > 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. Removal of foreign A-R headers provides better security. Since A-R header fails to capture source IP addresses for path registration schemes, the forensic value of this header is very limited, to the point of being dangerous. Reliance upon the A-R header offers providers permission to modify messages. Some providers offer their services free, however there remains a profit motive where their security may overlook embedded iFRAMEs referencing malware injected into one of their third-party ad servers. A-R header may indicate to recipients that the message originated from Big-Bank, but ads might appear from a different entity. In this case, the goal of DKIM is has been lost. Unfortunately, the introduction of ads is fairly common, and the authserv-ids may not offer a means to consolidate or identify who is being trusted. There are significant risks and problems created when dealing with A-R headers. DKIM without A-R headers does not invite questionable practices likely to create many duped victims. An appearance of a message being from someone trusted can be worse than a message with an unknown status when the content source is in doubt. >> 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. Wrong. See RFC 5451 section 5, complete removal is suggested for maximum security. It also suggests: "A more robust border MTA could allow a specific list of authenticating MTAs whose information should be let in, removing all others." >>> 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. No. Nor does the RFC warn of encoded headers or header reordering. Headers may be altered during handling. In addition, the "Trust Environment" can use any type of token, and not just those derived from a host name. The lack of uniformity or standardized means of ensuring uniqueness means little should be assumed regarding any A-R header not generated by the receiving MTA. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html