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