On Sunday 09 December 2007 21:05, John Levine wrote: > > The purpose of SSP is to detect unauthorized domain use. This can > > not be achieved if the spec assumes that a signature from just > > anybody what-so-ever is OK. > > But that's not what Dave said. He said that if there's a signature, a > receiver doesn't do SSP. It remains up to the receiver to decide what > to do with the message, including deciding what its opinion is of > the signing domain.
Right, so we don't do SSP if a signature exists. Adding signatures is trivial and so bad guys quickly add signatures (any old one will do) and SSP is obviated. That does sound like any old signature will do to obviate SSP. > To offer some concrete examples, if I get mail signed by nytimes.com > with your domain on the From: line, I'm going do deliver it no matter > what your SSP says, because I know that the Times doesn't send spam. > Even if you have a firm corporate policy that your users aren't > allowed to send mail from the Times' web site and a fierce SSP to > match, that's not my problem. > > Conversely, if I get mail signed by a sleazy domain in Nigeria that's > never sent me mail I wanted, I'm going to junk it. And what if it's signed by an unkown domain? Clearly if you have enough data and some secret sauce for reputation to understand if a signing domain is good/bad, then you'll probably let that over-ride, but reputation is outside the scope of the WG. So what about the middle option where you don't know if the signing domain is 'good' or 'bad'? If the domain has never sent you mail, how do you know it's sleazy? > Incidentally, this chronic misreading of "the signature identifies the > responsible domain" as "accept the message" (not just by one person) > tells me that we have some significant misunderstandings about what > DKIM does and doesn't do. Odd. I haven't seen anyone doing that. I've seen people accused of doing that, but not the actual doing. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
