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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Jul 2006 20:54:46 -0700

> [mailto:[email-masked]] On Behalf Of Scott Kitterman

> It might be useful (later, after the requirements discussion 
> is complete) to explore the feasibility of a common policy 
> record for the two for future revisions.  The risk associated 
> with complexity and the possibility of contradictory policy 
> statements may make the associated up front pain worthwhile.
> 
> I would imagine that 'the market' is looking for simplicity 
> in a holistic approach.  The more that these technologies can 
> be effectively integrated, the better off the average mail 
> admin will be.

The question in my mind is who builds a road towards whom.

One way forward is to start with SPF and have a statement 'there is a DKIM record'.

Pro: Already some base
Con: The decision to use a raw unprefixed TXT record does not play 
	nice with other systems.
Con: SPF politics.
Con: Leaves a standard track WG dependent on an RFC parked at experimental

Another is to make the dkim policy language powerful enough to support the statement 'there is also an SPF record'

Pro: Least work for us
Pro: Aligns with standards
Pro: Uses a prefixed record
Con: Lose the SPF base

A third option is to introduce a super-policy record that lists the authentication mechanisms in use

Pro: Is clean
Pro: Puts DKIM, SMIME, PGP, SPF on equal footing
Con: Yet another policy descriptor

One other factor that I have been looking into, it seems to me that super wildcards play nicely with legacy systems. IE if there is a legacy resolver that comes across a domain that uses super wildcards the system is most likely to produce the intended semantics. So super wildcards could be phased in.

In the first phase policy lookups would first try the superwildcard algorithm, then revert to the heuristic. In the second phase the heuristic would be phased out and only super wildcard records looked for.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 27 Jul 2006 12:04:23 -0400

> The question in my mind is who builds a road towards whom.
There is enough overlap in participation that I think this solves itself by 
just moving forward.

> Con: Leaves a standard track WG dependent on an RFC parked at experimental
Another PRO is that since the envelope comes first, by the time the receiver 
goes to DATA, the record will already be in the local cache if Mail From == 
From.  As I understand it, that's roughly 80% of the time, so as an 
optimization, it's non-trivial.

If one defines a modifier for the SPF record that gives a pointer to the DKIM 
policy/practice statement, but it's not the only way to discover it, then 
this can be utilized by the receiver without becoming dependent on an 
experimental RFC.  If pieces of RFC 4408 are needed, they can be copied into 
a new document that updates 4408 to avoid the dependency.

> Pro: Uses a prefixed record
Yes, but even if you leverage the SPF record format and location, you've 
already lost the base since records would have to be modified to support any 
option we pick.  

The other CON is that SPF can be done before DATA, so a DKIM policy record 
announcing SPF support is out of sequence for SMTP.

> Con: Yet another policy descriptor
Yes, but we are going to need some method of combining these different 
technologies.  I would prefer to see at least the protocol aspects of that 
standardized.  That gives us some hope for interoperability as the synergies 
between these approaches are developed.

Another CON - Probably out of scope for this group and I don't think it can 
wait for the time needed to spin up another WG.

Scott K