[ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
dotis at mail-abuse.org
Mon Apr 7 11:50:09 PDT 2008
On Apr 7, 2008, at 8:33 AM, Eliot Lear wrote:
>>> 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
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?
More information about the ietf-dkim