[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