[mail-vet-discuss] Discussion of auth-header draft (fwd)
mike at mtcc.com
Wed Oct 8 17:17:27 PDT 2008
>>> 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
More information about the mail-vet-discuss