On Wednesday 26 July 2006 23:54, Hallam-Baker, Phillip wrote:
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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.
There is enough overlap in participation that I think this solves itself by
just moving forward.
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 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.
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
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.
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
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html