On Jun 8, 2009, at 3:24 AM, Charles Lindsey wrote:
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:
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