ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Collection of use cases for SSP requirements

2006-11-12 17:44:49
On Sun, 12 Nov 2006 12:03:07 -0800 Dave Crocker <dhc(_at_)dcrocker(_dot_)net> 
wrote:

Jim Fenton wrote:
If you go to the message that Pat Peterson wrote that started this 
thread, that is exactly what some domains would like to do.  They 
consider SSP to be helpful to counter phishing [Please, let's not 
re-open that question; it has been discussed to death] even if it is 
ineffective with look-alike domains and such.  The requirement for the 
recipient to opt-in to have unsigned messages from their domains removed 
diminishes that perceived benefit greatly.


(I mean to post a thank-you to Pat for his note.  That kind of market 
research 
is always helpful.)

Oddly, Pat's research adds an interesting challenge for the wg.  End users 
state 
end-state goals.

They are not attempting to specify a path to achieve it.  That's our job.

Oddly enough, most of the reaction to the message seemed to me to be 
focused on repudiating the end user goals that were identified.

The simple fact is that no one in this Working Group is in a position to 
forsee all the uses receivers will put SSP like information to.  The kind 
of resistance to any input or suggestion that a robust SSP is a useful 
thing is in my opinion shortsighted and foolish.

There have been proposals (most especially Hectors table) that lay out the 
possible results.  We ought to just write up the list and use that.  All 
this arguing over each possible state of policy is going to leave us with 
an incomplete protocol.

I expect that we will go around on this a few more times and end up with so 
little SSP that it has little utility.  Once it doesn't get much traction, 
the same people that are pushing to water down the protocol now will cite 
the lack of deployment of the stump of the SSP idea that's left as 
vindication of their position that SSP was useless all along.

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

<Prev in Thread] Current Thread [Next in Thread>