John,
You are mistake, the point is to retrieve policy data, not reputation data. In
point of fact I have already proposed the use of a URL pointer as a means to
publish reputation data. This is how secure letterhead works.
We already have policy data, and at the moment we have a heuristic hack to hunt
arround for the SSP record. The idea here is to try to meet all the issues that
have been raised:
Mail administrators
The use cases include the ability to make policy statements such as 'no
email is sent from any address in this domain. This is fully supported.
DNS mavens
Have raised concerns about the ad-hoc approach, in particular the fact
that the SSP semantics as currently defined do not align with the DNS
administration semantics. At present a delegation has very clear semantics, the
handover of control is all or nothing. The only measure of control retained by
the upper level domain is the ability to revoke the delegation at a later date.
This seems an entirely legitimate concern. I believe that the pointer scheme
addresses this concern.
Immediate deployment
The pointer scheme allows full flexibility with wildcards and is
entirely implementable with the existing DNS as deployed. Even if a new record
is cut the only parties that are required to upgrade are those parties that
decide that they need the extended wildcard specification capability.
DNSSEC deployment
No changes are required to the semantics of DNSSEC wildcards. It is not
necessary to rev the DNSSEC drafts to support this mechanism. The utility and
advantage of using DNSSEC with DKIM remains prominent. The chicken and egg
situation where DKIM is meant to provide an incentive for DNSSEC deployment but
deployment of DKIM is dependent on deployment of DNSEXT extensions (and thus in
practice DNSSEC) is avoided.
Future proofing
The pointer scheme offers clear advantages over alternatives in the
case where there are many protocol policy statements being published.
Efficiency
The algorithm always terminates in three lookups without exception.
Given that we have a clear consensus that we need a policy statement I don't
see a good reason to do a second best implementation.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of John Levine
Sent: Tuesday, July 25, 2006 6:29 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] The URL to my paper describing the
DKIM policy options
Phill's hack is indeed clever, but it seems to me egregiously
premature to propose a standard way to retrieve reputation
data that doesn't actually exist yet. We could equally well
come up with a rule to map the selector to a URL which would
work just as well albeit not as fast, again to retrieve
non-existent reputation info.
Let's finish the DKIM signature spec, then see if we can
agree to get out the smallest version of SSP on which we can
get reasonable agreement (probably two bits, one for signs
everything, the other for sends no mail), then we can return
to the grand plans.
R's,
John
_______________________________________________
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