[ietf-dkim] New Issue: ssp-requirements-01 // DKIM Strict definition needed.

[Michael Thomas]

It's my opinion that "strict" means far too many things to far too many
people. Instead of rehabilitating the term, I'd far prefer that we pick
something else and really define what it means. I'm not sure that I've
achieved that and would appreciate help, but reverting back to the
handle that nobody seems to agree on doesn't strike me as very helpful.

       Mike

Jim Fenton wrote:

>In the terminology used in ssp-requirements-01, "Strict" (as used in
>allman-dkim-ssp-02) is represented by "signing complete" plus an
>expectation that the signature wouldn't be broken, as a mailing list
>(for example) might do.  Trying to introduce "strict" here would require
>a lot of changes elsewhere in the document that refer to expectations
>separately from practices.
>
>However, my reading of 4.1 doesn't make it clear that the stronger
>expectation is being used, which I think is the source of confusion when
>comparing it with 4.2.
>
>-Jim
>
>Douglas Otis wrote:
>  
>
>>Sorry,
>>
>>This repeats a message sent earlier today with the subject:
>>ssp-requirements-01 // DKIM Strict definition needed.  There have been
>>comments that notice nothing differentiates 4.1 from 4.2.  This was
>>discussed previously but not incorporated in the revision.  This
>>definition is compatible with terms used in Eric's latest draft as well.
>>
>>2.  Definitions
>>
>>Add:
>>
>>o  DKIM Strict: the state where the domain holder believes that all
>>   legitimate mail purportedly from the domain are sent with a
>>   valid DKIM signature and that non-compliant services are avoided.
>>
>>4.1.  Scenario 1: Bigbank.example.com
>>...
>>Was:
>>,---
>>|Note that for the foreseeable future, DKIM signature breakage for
>>|unrestricted use patterns (ie with users and especially where users
>>|are members of mailing lists) will likely suffer occasional damage in
>>|transit.  While probably not a large percentage of total traffic, the
>>|kind (quality) of breakage may be significant for certain usage
>>|patterns.  As such, this scenario defines a more limited situation
>>|where the risk of a legitimate piece of mail being mislabeled as
>>|unsigned outweights the risk of illegitimate mail being delivered in
>>|the eyes of the sender.
>>'___
>>
>>Change to:
>>
>>:Note that for the foreseeable future, DKIM signature breakage for
>>:unrestricted use patterns (ie with users and especially where users
>>:are members of mailing lists) will likely suffer occasional damage in
>>:transit.  While probably not a large percentage of total traffic, the
>>:kind (quality) of breakage may be significant for certain usage
>>:patterns.  As such, this scenario defines a more limited situation
>>:where the risk of a legitimate piece of mail being mislabeled as
>>:unsigned outweights the risk of illegitimate mail being delivered in
>>:the eyes of the sender.  [Rather than indicating a DKIM Signer
>>:Complete state, DKIM Strict would be used instead.]
>>
>>-Doug
>>
>>_______________________________________________
>>NOTE WELL: This list operates according
>>tohttp://mipassoc.org/dkim/ietf-list-rules.html
>>
>>    
>>
>_______________________________________________
>NOTE WELL: This list operates according to 
>http://mipassoc.org/dkim/ietf-list-rules.html
>  
>