Eric Allman wrote:
--On October 16, 2007 10:57:04 AM -0700 Michael Thomas <mike(_at_)mtcc(_dot_)com>
wrote:
Thus, I do not believe that A-R is really for use in MUAs. It is
to pass information downstream without SMTP extensions.
I don't see how these two things follow. Just because you don't
want to show the raw auth-res (which I agree), doesn't mean that
it's not for use in MUA's. Even if you believe it needs to be tied
somehow to reputation, that doesn't mean that it has to happen
before an MUA.
True, you could combine the A-R value with reputation in the MUA, but
that implies that you're going to have some at least moderately
sophisticated code in the MUA --- sophisticated enough that it can
figure out which A-R fields are appropriate. And I believe (i.e., it
is my opinion) that in most cases combining reputation results will
come before the MUA.
Perhaps I should say "I do not believe that A-R is really for use in
basic filtering rules in MUAs, sieve scripts without special
primitives included to combine A-R with reputation information, simple
procmail scripts, or other such situations that do not involve writing
some reasonably specific code to incorporate reputation information
and which can therefore be sophisticated enough to determine whether a
particular A-R field is associated with a relevant ADMD, and where by
'reputation' I mean reputation in the broad sense, not implying use of
any particular technology, and including such related technologies as
local white lists, accreditation, etc." But that seemed a trifle
verbose, and I somehow thought the meaning of my statement was clear
enough. I guess not.
Ah, yes. That I totally agree with. That's part of why I'm so wary of
passing
cross-domain auth-res downstream is that somebody could easily get fooled
due to the limited nature of those filtering capabilities. But it's not
hard to
envision, say, a Thunderbird plugin that does those things. I think that
environment is pretty rich in comparison.
Mike
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html