On May 24, 2008, at 2:51 PM, Frank Ellermann wrote:
John Levine wrote:
The question is whether ADSP should define what domain existence
means, or defer to other definitions.
Saying what result NXDOMAIN means can't be seriously wrong.
RFC 4408 uses "rcode 3", not "NXDOMAIN". If you like that better it
is okay, as defined in RFC 1035. So let's add RFC 1035 to the
normative references, and be done with it.
Nobody wanted to "redefine" NXDOMAIN, this is just a name for "rcode
3" in a header file.
Adopt the language found in RFC2821, or perhaps reference the relevant
section. To offer a strategy for minimizing undesired traffic that
might occur when dealing with spoofed domains while verifying DKIM and
ADSP, emphasis should be placed on checking MX records first. MX
first is currently defined in RFC2821 for discovering SMTP servers.
Inventing our own definition is, as I think I've said in other
messages, a rather severe case of mission creep.
Doug's proposal wrt q=mx would be mission creep, the stuff that
didn't make it into 2821bis, and ADSP isn't the place to try it
again, his proposal needs its own RFC.
This is to verify the Author Domain offers records required to support
SMTP. The first record sought by RFC2821 is the MX record. The otis-
dkim-adsp-02 draft includes notes to indicate how ADSP discovery
_might_ change whenever SMTP mandates MX records for the acceptance of
public message exchanges. This change would minimize possibly
dangerous levels of undesired traffic directed against non-SMTP
domains due to email-address spoofing. Even if that change is never
needed, this draft clearly stipulates the ADSP related domain has
adopted DKIM for SMTP.
Why is defining the protocol adopting DKIM in the practice assertion
mission creep? Defining the protocol adopting DKIM is absolutely
essential, but this is not done in Jim's or John's drafts. Not
defining the protocol might prove disruptive when a domain's ADSP
assertions are applied against protocols that have as yet not adopted
DKIM for what might become a range of messaging protocols. It is far
too early to make assumptions about which protocols will or will not
implement DKIM. Since declaring the protocol has been excluded from
the ADSP record, it is essential and necessary to define the
_specific_ public messaging protocol in the draft itself. That is not
mission creep, that is a must.
If the q=mx recipe could be confused with more ambitious concepts
let's use another example, or no example at all:
Implementors are supposed to know how this works, and if they don't
know it they can read RFC 1035.
Typically ADSP records will not be discovered for many years and
perhaps decades to come. Discovering whether an Author Domain exists
offers less value than knowing whether resource records essential for
SMTP exist. Even more importantly, when limited to domains publishing
SMTP discovery records, the number of domains needing to publish ADSP
records is significantly reduced.
Such testing is not mission creep. The test is simply based upon SMTP
being the focus of ADSP assertions. Although DKIM can be used by many
different protocols, what other public message exchange protocol is to
be assessed by ADSP assertions? Not indicating the public exchange
protocol being protected by ADSP would be remiss.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html