On Apr 19, 2008, at 11:36 AM, Charles Lindsey wrote:
On Thu, 17 Apr 2008 17:55:52 +0100, Douglas Otis <dotis(_at_)mail-
abuse.org>
wrote:
A proprietary scheme is not recommended, but it is not be
unthinkable open source schemes might offer similar features, and
perhaps overcome some of DNS's security issues as well. Discussing
naming service agility in the abstract is difficult. However, it
is rather clear ADSP has stipulated DNS and its heuristics. ADSP
should declare theextent of the policy and stipulate this policy
_only_ relates to email-addresses suitable for SMTP and DNS.
DNS yes, but why SMTP? SMTP is not the problem. It is DNS that is
(possibly) a problem. DKIM already relies on DNS, so I see no reason
why ADSP should differ.
The current ADSP algorithm establishes DKIM signing compliance by
qualifying From header email-address domains. This qualification
process ensures NXDOMAIN are not returned in response some DNS
transaction at the domain.
A) With a negative result, an NXDOMAIN response MUST return an error
(likely resulting in the rejection of the message).
B) With a positive result, not finding an NXDOMAIN implies a valid
domain without policy when policy records are not found below this or
the parent's domain at "_adsp._domainkey."
Item A and B are about qualifying the From email-address domain
signing compliance. Although DNS is being used for DKIM and ADSP,
without knowing the protocol used to exchange messages using RFC2822
From header email-addresses, it could prove incorrect to assume DNS
will always publish resource records for all email-address domains.
Names might be placed in specific TLDs to signal the use of resolving
services other than DNS. A strategy adopting specific TLDs that
ensure non-overlapping name space still runs afoul of ADSP's negative
existence check based upon its assumption that _all_ domains are found
in DNS.
Item B fails to properly qualify the From email-address domain
whenever wildcards are used by some entity related to the domain or
network service. Wildcards are used for purposes other than SMTP.
The overwhelming majority of messages carried by SMTP both abuse
recipients and those spoofed as message sources. In general, DKIM is
not the only SMTP extension adding a separate policy. Both DKIM and
ADSP must consider the amount of undesired traffic the schemes will
direct to otherwise innocent third-party victims. The issues with
item A and B are mitigated by _positively_ confirming existence of the
domain's _service_ before assuming policy might exist. For ADSP, a
positive check is made by verifying SMTP discovery resource records.
Placing a requirement that MX records are always published in
conjunction with ADSP records thereby allows absence of a likely
cached MX record to terminate any further policy related
transactions. This provision offers valuable protection from this
scheme increasing the level of undesired traffic seen by innocent
victims of SMTP related abuse.
It would be utterly stupid if someone invented a naming space with
the same syntax as domain names but using something other than DNS,
and then let those names wander around freely on the internet. At
the very least, any such scheme MUST use some TLD(s) distinct from
any that is approved for DNS usage by ICANN.
How does ADSP recognize distinctly different TLDs and unknown
protocols? Why not extend this logic to SMTP as well? Such as:
ADSP compliance requires RFC2822 From email-addresses be deliverable
using SMTP (which also uses DNS). Checks for ADSP compliance fail
when SMTP delivery can not be assured. ADSP SMTP/DNS compliance
failures MUST be handled in accordance local policies.
It seems rather bizarre to qualify email-address domain's signing
policies by ignoring the protocol expected to accept the signed From
email-address. What harm is there in stating ADSP compliance is based
upon SMTP deliverability?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html