----- Original Message ----- From: "John Levine" <[EMAIL PROTECTED]> To: <[email protected]> Cc: <[EMAIL PROTECTED]> 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
