On Jun 5, 2007, at 10:19 AM, Hallam-Baker, Phillip wrote:
We already know how to wildcard NOMAIL. If we find that only 5% of
domains actually need to wildcard a DKIM policy for domains that do
not exist then we simply direct people to the existing solutions
for declaring NOMAIL (MXdot, SenderID/SPF) that work with wildcard.
Neither MX dot or SPF represents a safe solution!!!! All unused sub-
domains would be included in an assertion that implies "Don't bother
processing a signature or mail from these domains, they're bogus."
This means a 5% estimate is off by a large margin!
At that point we can solve 95% of all problems today with no
infrastructure changes with the TXT/XPTR/TXT search, and the
coverage will reach 100% in the future as infrastructure is upgraded.
The XPTR solution requires a wildcard RR be published at _every_ DNS
node. There was little interest within the DNS WG to automate this
construct. This will also have a significant impact upon the size of
a typical DNS zone and all the related caching. It would be highly
prudent to seek advice from the DNS WG on this matter.
We don't need to propose any thrashing about the DNS tree of the
type that rightly upsets DNS folk. We set a clean precedent for the
future. We get the benefit of an improved admin model. We build out
infrastructure that is DNSSEC friendly.
Changes to infrastructure is not needed when the SMTP service and
policy are anchored to the MX record. Email represents a rather
unique problem as it pushes a vast amount of information without
prior arrangement. It is not clear there are other protocols that
benefit from introducing of a new type of DNS wildcard. In each
case, there are likely other solutions that impose less risk as most
other protocols pull information.
As email is rather unique, it might be possible to establish an
interim solution for email where policy is anchored to an A record.
However, the adoption timeframe will be long, where obsoleting the
use of A records as an alternative to MX records should also be
possible when a little pressure is applied. Less is more with
respect to security.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html