[ietf-dkim] Draft summary of SSP functionality

[Arvel Hathcock]

Ok, took the bait, couldn't resist, sorry :)

 > You don't think that a status label of "suspicious" implies a focus on
 > misbehaviors?.

I know you didn't ask me this, but (sorry), if we decide to change 
"Suspicious" to something else then we might as well go fully P.C. and 
change it to "a message of interest."  We've all seen the police on the 
news before:  "Yes, the suspect was detained for questioning... Uh, 
<looks around to see if anyone caught that>, I meant, the person of 
interest was detained..."  If anyone thinks what I've just said is silly 
then perhaps you can see why much of this dancing back and forth on 
egg-shells is just getting a bit boring.  I've got a dictionary. 
Suspicious is the right word.  I'm inclined to leave it.  But if we 
change it, please don't use "a message of interest."  I think they'll 
kill me for that in Texas.

 > Do [you] envision a reasonable scenario where a receiver has
 > adopted SSP and conforms to it, but does not have the
 > stated sender enforcement request override the reputation
 > assessment for a signer?  Note that this either implies
 > or explicitly violates the request of the SSP domain owner.

I know you didn't ask me this question either (sorry) but what I can 
easily imagine is a scenario in which a receiver has adopted SSP and 
conforms to it, but decides to set it aside in the presence of a valid 
signature from an entity that it trusts.

 > Could you provide some examples of such scenarios?

You didn't ask me, but yes, I can.

(a) My software has a global white list feature.  That white list 
contains any number of identities from which validly signed messages are 
trusted.  When encountered, no SSP.

(b) My software allows individual users to maintain their own address 
books.  The domain of any entry therein can be configured as a trusted 
identity.  When validly signed messages arrive from such identities 
bound for said users, no SSP.

(c) My software includes call outs to a certification service.  Use of 
the service is predicated upon trust in the certifier.  When validly 
signed messages arrive from identities which the certification service 
says it's in love with, no SSP.

(d) Although this isn't completely fleshed out yet I hope my software 
will someday have a transparent framework for using any domain-based 
reputation service.  Use of such services are predicated upon trust in 
the service provider.  When validly signed messages arrive, etc. etc.

Compared to many on this list, I'm a relative idiot in the software 
business.  Imagine what somebody with a real brain might be able to come 
up with.

Arvel