----- Original Message -----
From: "John Levine" <johnl(_at_)iecc(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Cc: <ietf-dkim(_at_)kitterman(_dot_)com>
Sent: Friday, July 28, 2006 12:22 AM
Subject: Re: [ietf-dkim] SSP complications, wa The URL to my paper ...
Yes. What I want as a small domain owner is the ability to publish a
policy record that say that for mail sent (for some definition of sent
that
we will probably have to argue about later) from my domain, the domain(s)
authorized to sign are ...
Once again I ask: what possible use could a recipient make of this
assertion?
I believe you are asking the wrong question. It is the verifier who will
make use the policy declaration. The verifier will make an assertion to
verify the signing declaration. If it fails, there is strong evidenc that
this is a violation of the policy hence an immediate classification for
rejection. If it passes, the verifier can accept it or pass it on to
another layer of subjective reputation stuff that really have nothing to do
with following a strong protocol.
Of course, verifiers will have the ultimate say with the help of local
policy administration decisions on what or how these checks will be done.
If your ISP signs your mail and, for whatever reason, the recipient likes
the ISP's domain, they'll accept your mail. If not, they'll filter or
reject it. How would an SSP assertion change that?
Again, wrong question. I think you are mixing Reputation, Certification
ideas and it really doesn't apply. SSP has nothing to do with whether the
verifier likes or doesn't like your ISP domain
Reputation, Certification, etc is really whole different level of subjective
mail interpretation considerations and if I read the charter right, it is
out of scope and it can only serve to complicate discussions about SSP.
SSP or DSAP are about protecting the DKIM-BASE signing process from abuse.
It has nothing to do certification or reputation.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html