On Apr 7, 2008, at 8:33 AM, Eliot Lear wrote: > Barry: >>> 3. At least one of the sub-tree mechanisms is attempting to glean >>> information from the absence of publisher action. Let me explain: >>> >> ... >> >>>> c) Checking for the presence of an A record is intended to try >>>> tell you something in the absence of an explicit action by the >>>> domain owner. That's it's flaw: It is intuiting ADSP information >>>> from non-ADSP action. >>>> >>>> While there is nothing wrong with checking the A record, it's >>>> semantics have literally nothing (directly) to do with ADSP. >>>> >> >> I agree with that assessment, but more importantly, I think the >> working group doesn't yet agree on whether he's right or not. > > As Frank points out, that's not what the draft says. The draft says > that you can pick *any* record. The purpose is simply to determine > whether the domain exists. The argument is semantically different, > particularly when you discuss this in terms of the recommended > query, an MX record. The worst you can say is that there is an > interdependency between the deployment of MX records and ADSP > records in the very same domain. The only reason you have to do the > query is because of the additional labels applied. If you want to > get away from this you need to use a new RR.
This could be generalized as a domain spoofing issue. Before SMTP receivers expend resources validating signatures, a check of the originating domain's validity eliminates the expenditures of validating signatures for domains that otherwise are determined invalid through the lack of inbound SMTP servers. Protecting resources is not a trivial matter, as DKIM demands more of receivers. Querying any record may not be conclusive. When either network providers or domains themselves inject synthesized wildcard records, sub-domains unrelated to valid message email addresses will appear to exist. To prevent this situation from being exploited, specific checks for MX or A resource records indicate at least possible support of SMTP servers by the domain. The recommendation in issue 1547 simplifies this test. Without MX resource records being found, receivers could conclude ADSP records below the '_adsp.' prefix do not exist either. While DKIM is not limited to SMTP, the purpose for ADSP seems related to the spoofing of SMTP message sources. After all, methods of message exchange involving prior arrangements are unlikely benefited by ADSP. As such, ADSP should stipulate this limitation as this would better ensure proper use. It seems some aspect of this concern appears to have been closed in issue 1551. The tracking note only indicates 'resolved' by the Philly meeting consensus. There is nothing within the minutes indicating what discussion took place or what aspect of this issue had been resolved or rejected. While MUA related protocols may be used in conjunction with SMTP, the public exchange of messages using SMTP is where ADSP offers benefit. If messages from sources other than those initially from SMTP are to be covered by ADSP, is there a list of these initial non-SMTP message sources? Such a list could permit a review of ADSP's impact on these different protocols. The introduction and even details related SMTP error codes seem to indicate ADSP is a mechanism intended to operate in conjunction with messages initially exchanged by SMTP, and then secondarily through MUA related protocols. What problem would be created by making a statement that ADSP is intended to benefit messages initially exchanged using SMTP? -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
