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.
My feeling is that post-delivery filtering will be at most a minor use
of A-R, since servers see more of the mail stream, and so can do
better filtering than endpoints. The uses I see for A-R are for more
sophisticated filtering of multi-hop deliveries either in servers or
MUAs, e.g., my example of looking at A-R's added by forwarders, spam
forensics, tracking down errors in potentially complex networks of
hosts that do validation, and so forth. Hence I want as much data as
possible, even at the cost of making it easier for bozos to misuse.
I don't see these two as mutually exclusive. Do they have to be?
Having had discussions with people both in here and in person at various
conferences, the language has been reworked a little to allow this
possibility. Within the context of message authentication, the "trust
boundary" referenced in the draft doesn't have to be constrained to
machines bearing your domain name, although I would probably assert that
that's going to be the general case and thus some of the softer language
in the draft does make that assumption.
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.
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html