[ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8
Stephen Farrell
stephen.farrell at cs.tcd.ie
Mon Feb 11 05:13:49 PST 2008
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.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.
>
More information about the ietf-dkim
mailing list