[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Scott
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
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