ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] NEW ISSUE: Limit the application of SSP to unsigned messages

2007-12-10 06:11:03
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.

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.

But it is a problem and here its Time's problem because it has to address people like yourself who A) may be ignorant of DKIM/SSP or B) ignorant of SSP or C) plays by its own rules.

When Time did its email verification, if its going to be signing mail as a 3rd party, it should of included a check to Arvel's SSP to check to see if this is a restricted high-value consideration.

One simple DNS check would of tell them that a subscribing address is not allowed to be used at a Times web site. It helps protect you, them and the responsible original domain, all parties.

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 like others pointed out, there is this vast middle world that didn't make it into your limited, subjective A/R database system yet which no one disagrees or doesn't know is a natural part of a Local Policy considerations.

This is all a prime example of how out of scope A/R considerations continues to muddy the water and abuses the SSP WG progress.


--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

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

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