On Jun 11, 2007, at 10:07 PM, Jim Fenton wrote:
(3) Upward query vs. wildcard publication. 27 messages in
discussion from 15 people. Most of the discussion was a rehash of
the idea of associating semantics with DNS zone-cuts, which we had
already discussed and rejected. I have also been trying to get an
opinion from DNSOP on the idea of a one-level upward search (which
I think solves 90% of the problem), but haven't gotten any response.
Issue#3: +1 - Define an upward query based approach to finding SSP
statements
Issue#3: -1 - Define a wildcard based approach to finding SSP
statements
+1
Rationale: Required to support TXT RR (what I think is what we'll
end up with). Even with a new RR, it avoids the need to publish an
additional new-RR record to go with every other label in the zone
to deal with the characteristics of DNS wildcarding.
Jim,
Your conclusions seem correct, however they exclude the possibility
of first checking the existence of MX or A records. Checking the
existence of MX or A records is an alternative to domain transversal
of the use of wildcards. The DKIM policy is limited and unable to
indicate whether a domain is bogus anyway. This means recipients
will be unable to differentiate between broken signatures and bogus
domains. Checking the existence of MX or A records ensures bogus
domains are avoided.
For many years at least, DKIM policy will be present within a small
percentage of domains sending email. What this means for recipients,
is that most domain transversals will either begin or end at the TLD
without any benefit. This will also cause SLDs to experience a high
amount of unanswered transactions. The desire to use a wildcard or
domain transversals is to detect bogus domains. Checking the
existence of MX or A records provides a much safer, more effective,
and simpler method. Every valid email-address domain MUST publish
either an MX or A record. A request for ANY record at the email-
address domain is likely to return the desired information within a
single DNS transaction.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html