ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Draft summary of SSP functionality

2007-12-06 00:42:29
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


_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html