----- Original Message ----- From: "Dave Crocker" <[EMAIL PROTECTED]>
> If I choose to deliver unsigned mail that purports to be from a > domain that says it signs everything, but I mark it up with flashing > lights that say "spoofed" do you want that to be a protocol violation? Yes. I am not what you mean by "But i mark it up with.." by yes, if the domain expectations for a valid transactions are broken, in order to protect his reputation inherited by a DKIM-BASE mandate, he would prerfer it to be a protocol violation. > What about my choosing to send it to > my sysadmin for special handling for spoofed mail? What about... Thats up to you and local system policy. That should take away the domain declaration for his expectatons for a valid transaction. > In other words, there are lots of things that I might reasonably > choose to do with mail that I receive that violates one or > another SSP statement. I am not sure I follow the logic, but this is all really simple. The domain told you want is expected for a valid message. It went thru all the work on signing messages for some reason that hopefully has some payoff when things go wrong with it. Isn't the essense of a security protocol? When the protocol is not followed? > It is not the publisher's right or responsibility to tell me what to do with > information. By contrast it is entirely reasonable for them to provide me with > information that I am likely to find helpful. Agree. And sure, as a receiver, you can decide to do what you want. But if we are talking about helping to stop or control abuse, then I think most receivers are very interested in technology that will help in the area. > A signer should make statements that a) the signer believes to > be important, and b) there is a good basis for believing that > evaluators will consider important. Isn't this what SSP draft, including DSAP I-D draft already does and documents? Have you looked at this documents? What is wrong with them? Do you trust the engineering done? What's missing? -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
