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: <Bill(_dot_)Oxley(_at_)cox(_dot_)com>
To: <hsantos(_at_)santronics(_dot_)com>; <dcrocker(_at_)bbiw(_dot_)net>;
<ietf-dkim(_at_)mipassoc(_dot_)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
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Sunday, August 06, 2006 12:01 AM
To: dcrocker(_at_)bbiw(_dot_)net; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy
----- 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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html