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

[Steve Atkins]

On Nov 9, 2006, at 9:37 AM, Dave Crocker wrote:

>
>
> Steve Atkins wrote:
>
>> "Depending on how it's implemented by recipients there are
>> ways in which it makes it worse."
> ...
>> If (and this is where the "implemented" bit comes in) recipient ISPs
>> or MUAs annotate mail in any way that suggests that mail that is
>> validly DKIM signed and claims that no non-signed mail is ever
>> sent is, in any way at all, more trustworthy than, say, non-DKIM
>> mail or mail with no SSP constraints that will make the phish
>> more plausible than it would be in an MUA which pays no
>> attention to DKIM or SSP.
>> Lest you suggest that no ISP would ever be foolish enough to
>> do such a thing, look at Hotmails past behaviour with SenderID.
>
> I think you are exploring a realm that I class as "creative  
> misunderstanding" where the problem is with someone going  
> significantly beyond what is said or promised.  And, indeed, there  
> is a solid basis for believing that any interesting mechanism will  
> produce at least some creative misunderstanding.
>
> So, I think, a response to a concern about this needs to ask a  
> couple of basic questions:
>
> 1. For those who use the mechanism "correctly" is there substantial  
> value-add?
>
> 2. Is there something about the mechanism, or its specification,  
> that *encourages* the misunderstanding?  Answers might go as far an  
> noting common characteristics of human tendencies or as near as  
> observing particular language usage in the spec.
>
> By way of priming this line of query a bit, your noting the hotmail/ 
> sender-id example certainly seems useful to me.  More generally, we  
> have plenty of evidence that people thoroughly misunderstand what  
> signing is and is not useful for.
>
> My concern is that this line of observation quickly justifies doing  
> nothing at all.  (Since any action is subject to abuse, take no  
> action.)
>
> My own answer to question #1 is that being able to trivially,  
> accurately and reliably being able to reject a class of bogus mail  
> is rather nice.  If someone says their domain is always signed,  
> then I can choose to toss mail that I get with that domain that is  
> not signed (... ummmmm, assuming that the email service is not  
> breaking signatures very much.)

Remember that the context of the mail to which you're replying
is specifically use of SSP to reduce the problem of phishing.

In the context of phishing emails (that is emails which are
intentionally sent by a well-informed sender with the intent
of deceiving the recipient) then the size of your class of bogus
email will rapidly converge towards zero.

Broadening the scope of the discussion of "value-add" and
"creative misunderstanding" to non-phishing use cases would be
worthwhile, sure, but lets do it explicitly.

Cheers,
   Steve