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
