On Jun 5, 2007, at 2:47 PM, <Bill(_dot_)Oxley(_at_)cox(_dot_)com> <Bill(_dot_)Oxley(_at_)cox(_dot_)com>
wrote:
consider it punted
however the same tree/wildcard issue exists to get any policy
statement so lets try to think our way out of it. We have policies
we want either 1-4 or in my case 1-5 so lets get them extracted
without ddosing DNS
Agreed.
Security concerns regarding the SPF experimental draft should
preclude this mechanism from playing any role in establishing a
functional DKIM policy assertion.
A single policy record placed adjacent to the domain's MX record
could be sufficient. This would eliminate domain transversals or
wildcard search mechanisms. However, this approach creates a need to
obsolete the use of just A records as an SMTP server discovery/
confirmation method. Once an A record discovery/confirmation has
been obsoleted, then messages might not be accepted when the email-
address domain is not confirmed by the existence of an MX record.
How many SMTP servers already meet and even make this a requirement
now? The few cases where just an A record is available is likely
already problematic due to high levels of abuse. How many Fortune
1000 companies do not publish MX records?
What is _in_ the DKIM policy statement is less critical than what
other _experimental_ schemes might be expected of recipients for
determining a complete DKIM policy.
Once in place and defined, policy can then be safely extended to
authorizes other originating domains, perhaps by using various hash
prefixes. The hash prefix approach scales well and has a rather low
overhead. The initial DKIM policy record would simply be the
"default". Perhaps this could be called the DKIM-ALL policy. : )
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html