ietf-dkim
[Top] [All Lists]

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

2006-11-09 11:08:32

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

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

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