Collection of use cases for SSP requirements

Wietse Venema wrote:

>John Levine:
>  
>
>>c) paypal-payments.com publishes that note.  I don't
want their mail
>>   whether they verify or not.
>>    
>>
>
>Scott Kitterman:
>  
>
>>>>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.
>  
>

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

>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
>_______________________________________________
>NOTE WELL: This list operates according to 
>http://
mipassoc.org/dkim/ietf-list-rules.html
>  
>

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

Michael Thomas wrote:
>  Beyond that, more information for receivers
> is better. If it's unuseful to you, don't use it. Same
goes for -base.

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