At 17:17 08-10-2008, Michael Thomas wrote:
This sort of gets to the heart of a concern I've had for a long
time about ar. Just who exactly is the consumer of an ar header?
For me, the consumer has been either me or some automaton that
digests the ar and produces statistics, or takes some action
based on the digested bits. My assumption has always been that
ar's are protected by firewall-y-like mechanisms (eg, ingress
filtering by border mta's) and that that's good enough security.
The Authentication-results header came up during the discussion about
DomainKeys as there was a need for a mechanism to pass the results of
the verification. The results can be used by downstream filters or
MUAs which support it. It wasn't much of a security risk as the MTA
inserting that header would remove any previous occurrence of the header.
Admittedly, those are a lot of assumptions. If people are planning
on using ar for very different uses -- especially across internally
secured areas, then the current design is woefully lacking. If
they aren't then it's probably ok.
As the draft progressed, other uses were added. One of the
constraints was how to pass information without running into
deployment issues and the design reflects that.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html