If you (or Hector, or whoever) have suggested changes for ssp-02 please
raise an issue, including suggested new text and we can process that.
Thanks,
Stephen.
Charles Lindsey wrote:
On Fri, 08 Feb 2008 19:15:15 -0000, Eric Allman <eric+dkim(_at_)sendmail(_dot_)org>
wrote:
Hector,
You say some things about the Evaluator that lead me to believe that
you've got a different idea of what it should be than I do. You say:
So to me the idea of an Evaluator would be first a fundamental
protocol consistency Evaluator that would be part of the DKIM/SSP
framework across all supportive/compliant systems. It would be
100% independent from any subjective or heuristics or reputation
analysis or any one group detecting their questionable inherent
policies or implementations methods.
This is the inverse of the model in my head, where the Evaluator is
completely /dependent/ on "subjective or heuristics or reputation
analysis" --- it is, in short, how the receiver decides how to process
the message. Indeed, the point of introducing the concept is an
attempt to make explicit what is out of scope for normative definition
in the SSP spec.
I think Hector's model (AIUI) is nearer what I want.
Call it a "DKIM Evaluator". Its function is to examine all the available
signatures (including the precise forms of their tags), to compare them
with the various From, Sender, Whatever-Else headers that one would
expect to be matched by those signatures, and to report where that
matching is deficient having regard to the SSP policies and their
severities appropriate to those headers.
Armed with this "DKIM evaluation report", the verifier now knows how the
sender(s) would like their messages to be treated. On top of this, the
verifier can also consider other evidence in its possession, its
clients' preferences and its own internal policies and then proceed as
it sees fit. But that process should be called the "Local Evaluator",
and should not be described in the SSP document beyond a mention that it
will likely exists. But the "DKIM evaluator" can and should be fully
described.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html