ietf-mailsig
[Top] [All Lists]

Re: dkim technology?

2005-07-14 21:15:37

On Thu, 2005-07-14 at 14:15 -0500, wayne wrote:
In <2005714113127(_dot_)302394(_at_)bbprime> Dave Crocker 
<dhc(_at_)dcrocker(_dot_)net> writes:

 [...]                                                      I suspect
 that the tree-walking in the current draft will also be very unpopular
 with the DNS folks.  SPF removed the zone-cut idea in part because of
 this opposition, and the CSV's tree-walk wasn't any better accepted.

using zone-cut quite simply violates dns semantics.  zones are an 
administrative construct, not a name-space construct.

I disagree that the zone-cuts "violates DNS semantics".   Zone cuts
are already exposed for "real" DNS wildcards, for DNS dynamic updates,
for DNSSEC, and maybe for a few other things.

While the mapping of "zone file administrator" to "appropriate
administrator of email sender policies" is not perfect, I think it is
*FAR* better than doing a tree-walk.

In particular, I suspect that the admin of, say, co.uk, will not
appreciate the idea of having to deal with DKIM lookups and at the
same time, the domain owners under co.uk will not appreciate the idea
of someone outside their administrative control being able to decide
email sender policies.

Your example of a parent domain conflict suggests such TLDs will be
making policy mandates that change present behavior.  This does not seem
to be a realistic concern, however even this would not be a problem.
The goal of any domain policy is to allow policy on a domain and its
sub-domains.  If the parent domain asserts a policy that this domain and
its sub-domains send signed mail, then an exception possible would where
a specific domain with a differing direct assertion suggests otherwise.
The SSP works from the specific domain upward using a 5 level
constraint.

In general, this should be easier and faster to resolve than a zone-cut.
An attempt at a comprehensive wildcard method would be painful to
implement, and ultimately may leave domains without policy due to
resolver issues which depend upon recipient architectures.

-Doug


<Prev in Thread] Current Thread [Next in Thread>