As you may have noticed, Michael, Eliot, and I have been having a
rather free and frank exchange of ideas here. After giving the smoke
a few moments to dissapate, I see that we have fundamentally different
ideas of what we're doing.
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 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.
The current draft seems designed more for the latter application, with
its language saying that you're supposed to treat the A-R headers as
trace headers and keep them all with the special case exception of
deleting A-R's from real or faked mail loops.
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.
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html