Bill, Actually, IMV, the POLICY is the easiest part because that is already define by the potential DKIM-BASE may exhibit.
It will be the engineering to get it done properly that may ultimately tell us of the feasbiliity of it all which I am 100% capability of accepting way away or another. No, I don't think it is hardr at all. The possible policies are fixed. Where did that come from anyway? "I sign all mail" That isn't in SSP DRAFT, in fact the SSP says for the o= tag: o= Outbound signing policy for the entity (plain-text; OPTIONAL, default is "~"). Possible values are as follows: ~ The entity signs some but not all email. - All mail from the entity is signed; unsigned email MUST NOT be accepted, but email signed with a Verifier Acceptable Third Party Signature SHOULD be accepted. ! All mail from the entity is signed; Third-Party signatures SHOULD NOT be accepted . This entity never sends email. The "." policy can be used to "short circuit" searches from subdomains; for example, the "ad.jp" domain might use this. If an initial policy search receives this policy then the email SHOULD NOT be accepted; if found while searching parent domains then the search should terminate as though no policy record was found. ^ Repeat query at user level. This value MUST NOT be used in user-level policy records. A Verifier MUST look up the selector for "<user>._policy" where <user> is the local-part of the Originator Address (i.e., the portion of the address before the "@" character). These is the SEMANTICS people should be debating. Once you think about the engineering to statisfy these requirement, including problems from a security standpoint, the loopholes, etc, then you see my position better and why DSAP was done. There is alot of time being wasted here by people who saying they don't understand and then suggest it is the status quo, therefore lets water it down without thinking about the security implications which are pretty major. No, it is extremely simple yet powerful concept. The issue? It is feasible. Can it work? What will it take to work? Is there a revamp and/or migration issue here? etc. No, the policies are simple. In short, watering it down make be as bad as having nothing at all. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <ietf-dkim@mipassoc.org> Sent: Sunday, August 06, 2006 12:23 AM Subject: RE: [ietf-dkim] "I sign everything" is not a useful policy Hector, The engineering part is easy, what is extremely difficult is the policy. After spending a long period of time debating what the word UNIQUE means in a policy document that has some similarities to email, I want to get it right the first time. Make sure the rules are simple. Ensure there is agreement. Make sure a clean unambiguous meaning is set to every possibility. Its harder than it looks. Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hector Santos Sent: Sunday, August 06, 2006 12:01 AM To: [EMAIL PROTECTED]; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy ----- 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 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html