Jim Fenton wrote:
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.
We're not communicating. What might a receiver do differently with a third
party signature with and without the "all"? I can't think of anything.
Also: there are two orthogonal things going on with "all": the general
proposition
from the originator that they sign everything, and this third party
signature thing.
At the very least, they should be decoupled.
Mike
-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