[ietf-dkim] Issue #1520: limiting SSP to statements that inform recipient about (potential) signer actions

Dave Crocker dhc at dcrocker.net
Thu Dec 13 07:01:56 PST 2007



Jim Fenton wrote:
> Dave Crocker wrote:
>> 1.  We seem to be seeing inconsistency between whether SSP is
>> providing information about potential signers, versus whether it is
>> directing the behavior of receivers.  ("providing guidance" is giving
>> direction.)
> SSP is clearly providing information about the use of DKIM by domains. 
> It is also allowing those domains to express their preference about the
> handling of mail that purports to come from them.  The intent in this
> latter regard is that domains are encouraged to do as requested by the
> alleged originating domain, but that they are compliant with the
> specification even if they choose not to do so.

Jim, you might want to review various postings about this.  Please note 
postings from your colleagues who seem to disagree with your position, since 
they are claiming that SSP is merely providing information and they take 
exception to characterizations that it seeks to direct actions.  ("Expressing 
preference about the handling" sounds nicely distant, but it is seeking to 
direct actions.)


>> 2. RFC 2597 specifies actions relative to packets that are from the
>> specifier of the actions.  SSP is about messages that the specifier
>> has not issued.
> 
> True, but I consider that just a characteristic of the different use
> cases between SSP and Diffserv.

Please point to the relevant diffserv text, so we can compare the details.


>> 3. RFC 2597 has been at Proposed Standard for 8 years.  Can you point
>> to some deployment discussion, so that we can see how broadly it has
>> been deployed and how well it works?
> 
> The point is that RFC 2597 is an IETF standards-track document,

Sorry I wasn't clear.  I was not trying to ask about legal precedents.  I was 
trying to ask about demonstrated success scenarios.

Lots of IETF protocols fail.  Although the fact that the IETF has put 
something forward might be interesting, but it does not prove anything about 
utility.


  and an
> example of a protocol which seeks to direct the behavior of receivers
> (to use your terminology).  It does this with considerably more forceful
> language than the SSP draft currently uses.

When you point to the relevant language, we can evaluate just how similar its 
assumption, models, and directives are.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


More information about the ietf-dkim mailing list