The key words here are Verifier Acceptable. The verifier gets to specify which signatures are Verifier Acceptable, which gives it precisely the liberty you describe.
-Jim Michael Thomas wrote: > Step 9 of the SSP lookup algorithm sez: > > 9. If the value of the SSP "dkim" tag is "all", and one or more > Verifier Acceptable Third-Party Signatures are present on the > message, the message is not Suspicious and the algorithm > terminates. > > I don't see the motivation for this, and it's definitely not in the > requirements. A > receiver is always completely at liberty to whitelist, blacklist, > greylist, > pink-polka-dotted-list a third party signature regardless of what the > originating > domains says. What unique value does a signer bring to an across the > board > statement about all third party signatures? I can't think of a single > use case that I'd > alter processing based on that information. > > Mike > > > Jim Fenton wrote: >> The list has been uncharacteristically silent since I submitted an >> update to the SSP draft 10 days ago, so I thought I'd point out the new >> draft (draft-ietf-dkim-ssp-01) and a few of the highlights (more >> complete info on the changes are in section B.1). >> >> The most significant change is a new tag, called "handling", that >> represents what I called the SSP "Strong" Option in my presentation at >> IETF 69. As I mentioned at the time, we needed a better word than >> "strong", and this is what Eric and I came up with. It takes one of two >> values: "process", the default, means to do what you would normally do >> with a message that is Suspicious. "block" is a way for a domain to >> express the preference that messages violating SSP be dealt with more >> harshly, such as by deleting, bouncing, or rejecting them. >> >> Section 5, "Third-party Signatures and Mailing Lists", has been removed >> since it belongs better in the Overview document(s). Note to overview >> authors: hint, hint. >> >> Most of the other changes in the document, which are numerous, are to >> tighten up the wording rather than to introduce anything new or >> different. For example, when user-granularity SSP was in the document, >> SSP applied to an "entity" which was either a user or a domain. the >> word "domain" is sufficient, and clearer, now. >> >> Comments appreciated as always! >> >> -Jim >> >> _______________________________________________ >> NOTE WELL: This list operates according to >> http://mipassoc.org/dkim/ietf-list-rules.html >> > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
