----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
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