Murray S. Kucherawy wrote:
John Levine wrote:
They seem to be saying (and I'm sure they'll correct me if I'm
misinterpreting them) that the only use, or at least the most
significant use, of the A-R header is to do filtering in MUAs beyond
what the server did. Since the users who run those MUAs tend not to
know much about mail, we need to make the design as resistant as
possible to misuse, even at the cost of making it impossible to use
A-R for other things.
My own view is that MUAs can adapt to making use of this header (or
its successors, such as an ESMTP and/or IMAP extension) to acquire
border MTA authentication results and use that information to indicate
to the user, either graphically or by actual message action (e.g.
procmail), which messages could be trusted with respect to their
authenticity and which could not. In that sense I suppose I fall in
the camp of "filtering beyond what the server did" if forced to come
up with a simple definition. At least, that was my initial intent,
but I'm of course happy to entertain other possible uses of this idea.
I don't see much point in getting hung up on what the consumer of AR
is, be it an MUA, MTA, MDA or something else entirely. AR is a way
to project -- unauthenticated -- the results from some verifier downstream
to something that will make use of it.
I think it's a very reasonable question to ask why we need this, and what
it's purpose is because surely as it hits the larger community we'll be
asked
those questions in spades. Let me say what I use it for right now:
1) Forensics for DKIM
2) Naive annotation for Thunderbird and a few other MUA's
The first is primarily because I'm a developer, so that's a corner case IMO
and not all that compelling from a standards standpoint. The second is
seemingly more compelling, but I'll say that until it's a standard
feature in
MUA's it's still a geeky tool -- and extremely error prone -- especially if
John gets his way with cross domain AR's hanging around. What I don't
use it for is for something like spamassassin and I wonder if it really will
be used that way because SA is usually co-located at the border anyway
and can probably get the verification results directly without having to go
through some header that it would need to parse again.
Are there other use cases?
Mike points out that we have no requirements document. So what is
everyone else expecting to use A-R for? I don't think this is a big
enough project to be worth a full blown separate requirements doc, but
it would be nice if we could at least have general agreement on what
we're trying to do.
I concur. I don't think some kind of formal specification of the
problem we're trying to solve is really necessary.
I don't think we need anything formal, but I do think we need to agree on
what problem we're solving. And maybe a charter for why we're doing this at
all.
Mike
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html