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

From: Scott Kitterman <[email-masked]>
Date: Thu, 09 Nov 2006 8:09 -0500

On 9 Nov 2006 07:24:20 -0000 John Levine <[email-masked]> wrote:
>>> a) paypal.com publishes that note.  So far so good.
>>>
>>> b) mismanaged-isp.com publishes that note, and blames you when their
>>>    users' poorly formatted mail disappears.  Not so good.
>>>
>>> c) paypal-payments.com publishes that note.  I don't want their mail
>>>    whether they verify or not.
>
>>A is good.  
>
>Agreed.
>
>>B is not your fault.  No matter what you do, poorly configured senders 
will 
>>blame you.  They do it now, so this is no different than today.
>
>Except that for those of us who want to make our users happy rather
>than score points, we'll need to ignore the SSP from these guys.  So
>if we need to do that, perhaps we should ignore SSP altogether and
>pick up the relatively small set of A's some other way, as Steve A.
>suggested.

People will do it wrong is an arguement that applies equally well to 
DK/DKIM signing.  In my testing of signing, I've had a message bounced back 
to me because it had an invalid signature.  As I understand it, this was 
wrong for a number of reasons:

 - The test flag was set.
 - Invalid signatures aren't supposed to be treated any differently than no 
signature.
 - The message was sent via a known failure mode (a mailing list).

Additionally, but unrelated to DKIM, the bounce was sent to the 2822.From 
and not the 2821.Mail From.

So, people are already twisting -base in ways it wasn't meant to be 
twisted.  Does that make it valueless? 

>>C is not the problem SSP is meant to solve.
>
>Well, OK.  In one sentence, what IS problem that SSP is meant to
>solve?  It would be helpful if your answer kept in mind that receivers
>have no inherent interest in senders' policy.  It's only useful if it
>helps their own systems work better.

We've had this conversation before...

SSP can solve or substantially help exact domain forgery.  Some of us think that's useful, 
some don't.

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

---

From: [email-masked] (Wietse Venema)
Date: Thu, 9 Nov 2006 09:11:21 -0500 (EST)

> >>C is not the problem SSP is meant to solve.
...
> SSP can solve or substantially help exact domain forgery.  Some
> of us think that's useful, some don't.

It's certainly useful for the bad guys behind paypal-payments.com
etc. After all, their own SSP record says their mail is authentic.

SSP helps the bad buys to create an *illegitimate* sense of security
from a *legitimate* DKIM-base result.

I find that very, very, embarassing.

SSP does not help customers to find out if paypal-payments.com is
their paypal bank.  For that, DKIM-base results need to be used in
a more appropriate manner. We had lengthy discussions on that
already here, and they are already archived for eternity.

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Thu, 09 Nov 2006 07:52:03 -0800

>I find that very, very, embarassing.

Only if you're dumb enough to think that SSP or DKIM-base solves the
lookalike domain problem. Beyond that, more information for receivers
is better. If it's unuseful to you, don't use it. Same goes for -base.
   
       Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 09 Nov 2006 08:05:00 -0800

Michael Thomas wrote:
>  Beyond that, more information for receivers

I suspect your view is widely held.  I suspect it also is incorrect.

One likelihood of the view is that there will be masses of different kinds of 
information.  I think it reasonable to assume that only a small fraction will 
actually be useful.

An implied premise of your view is that there is essentially no cost in dealing 
with a mass of un-useful information.  Yet it is clear that each bit carries costs.

It carries costs in creation.  It carries costs in processing.  And it carries 
costs in setting expectations that won't be met.

In the aggregate, these can combine into something that is very expensive and -- 
worse -- lessens the overall credibility of the underlying mechanism.

I characterize the view you state as: "default to include as much as you can and 
worry about utility later".

My own experience with Internet-scale mechanisms is that the view needs to be: 
"default to exclude anything that does not have a compelling use case and strong 
indication of community need/desire."

d/

ps. Let me stress that even if I've distorted what you actually meant, I think 
that my note does respond to a view that is widely held.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html