SM wrote:
I'd like to have some consensus discussion around ways to verify that an
MTA supports this draft. You mentioned alternatives including digital
signatures and interrogating the MTA, but dismissed those alternatives.
It's a really important question and one the IESG will latch onto!
It's a question of detecting forged signatures, yes, but it's also a
question of supporting auto-configuration -- the current draft makes
email configuration harder, and it's hard enough already.
One of the purposes of this draft is to convey the results of various
message authentication checks being applied. Adding
auto-configuration would require changes to existing MUAs. If that's
a requirement, then it would better to devise other mechanisms or
adopt existing sender-to-recipient authentication mechanisms which
are path agnostic. I won't suggest such a requirement because of
deployment constraints.
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.
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.
But this all gets back to who the ar consumers are, what their
characteristics are, and what assumptions if any we can make about
them.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html