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

From: Scott Kitterman <[email-masked]>
Date: Sun, 12 Nov 2006 19:28 -0500

On Sun, 12 Nov 2006 12:03:07 -0800 Dave Crocker <[email-masked]> 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

---

From: John Levine <[email-masked]>
Date: 13 Nov 2006 01:39:40 -0000

> 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.

Quite right.  That's why I find it baffling that people are rushing to
standardize untried paper designs rather than doing experiments and
getting experience with running code.

One of the reasons that we got dkim-base done fairly quickly and
without major roadblocks is that we had a field-tested DK design to
start from.  For SSP, all of us, whether we think it'll be essential
or we think it'll be worse than useless, are just guessing.

R's,
John

---

From: wayne <[email-masked]>
Date: Sun, 12 Nov 2006 22:57:23 -0600

> getting experience with running code.

SSP has been in Domainkeys for a long time now.  Surely there is as
much experience with it as with the underlying fingerprinting code.

-wayne

---

From: John Levine <[email-masked]>
Date: 13 Nov 2006 07:14:48 -0000

>much experience with it as with the underlying fingerprinting code.

Interesting point.  The policy record has certainly been in DK for a
while, but I haven't heard of anyone actually using it other than the
test bits.

Perhaps someone from Yahoo or Gmail can report on their experience?

R's,
John

---

From: John Levine <[email-masked]>
Date: 13 Nov 2006 07:14:48 -0000

R's,
John

---

From: wayne <[email-masked]>
Date: Mon, 13 Nov 2006 15:51:17 -0600

> while, but I haven't heard of anyone actually using it other than the

Well, yeah, but most email that I see with DomainKeys signatures are
marked as being "testing" only too.  Again, how is SSP any different?

-wayne

---

From: John Levine <[email-masked]>
Date: 14 Nov 2006 06:13:37 -0000

>marked as being "testing" only too.  Again, how is SSP any different?

Because people actually are verifying DK signatures, but I don't know
of anyone throwing away mail, or even treating mail any differently at
all based on the SSP-ish bits.

R's,
John