[ietf-dkim] Step 9 (was: The (really) latest SSP draft)

Michael Thomas mike at mtcc.com
Thu Sep 27 15:44:10 PDT 2007


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
>   



More information about the ietf-dkim mailing list