[ietf-dkim] The URL to my paper describing the DKIM policy options

[Hallam-Baker, Phillip]

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.org 
> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of John Levine
> Sent: Tuesday, July 25, 2006 6:29 PM
> To: ietf-dkim at mipassoc.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
> 
>