On Jun 18, 2008, at 2:43 AM, Charles Lindsey wrote:
On Tue, 17 Jun 2008 23:51:24 +0100, Douglas Otis <dotis(_at_)mail-
abuse.org> wrote:
On Jun 17, 2008, at 3:41 AM, Charles Lindsey wrote:
Sure, I am happy for our draft to omit the existence test in the
case of some class of non-TLD domains, and we can discuss what to
include in that class (the consensus now is to "modiffy" the present
wording, anyway). But it only partially solve the problem, because
scammers will still attempt to use non-existent domains ending
in .com and the like.
With urgency being expressed by the chairs, it does not appear there
is time to resolve which non-DNS domains should or should not be
ignored. Clearly this is work independent of ADSP anyway.
ADSP must be defined as pertaining to messages carried by SMTP, or
its assertions are meaningless.
And that is a departure from your pevious stance, since if ADSP
pertains to messages "carried" by SMTP, then it pertains to messages
arriving at a Verifier via SMTP (whether or not they were originally
created in an SMTP environment).
Going back perhaps a year or more, you'll find statements about a need
to include scope parameters to permit ADSP a means to extend beyond
SMTP. Without such a parameter, ADSP must be defined as _only_
pertaining to SMTP messages transmitted by the domain. Even so, ADSP
will not prevent other providers from bridging non-SMTP protocols and
services into SMTP with unsigned messages purporting to be from a
domain now publishing ADSP records. A CLOSED ADSP record may cause
receivers to look for evidence as to why the message is not
complaint. When a LOCKED ADSP record is used, the domain is
indicating they do not wish to benefit from the availability of such
services, since such messages from mailing lists or NNTP feeds are
likely to be dismissed.
... ADSP might wish to indicate a need to adopt addressing
conventions defined in a separate draft intended to place
limitations upon addresses found in headers carried by SMTP. This
effort would be for the general good by reducing the level of fraud.
But ADSP needs to stand or fall on the basis of its own draft, and
not to be dependent for its success upon some mythical future draft.
SMTP proponents need to be cautious in how their drafts might be
utilized. For example, DNS servers that have not provided reputation
services in years, and that return no records, now see a growing level
of worthless queries now running at ~4 mb/s. Adding forward domain
receiver transactions to an evaluation process may increase the level
of such activity. When a concerted attack occurs beyond the steady
drum beat, network expenditures quickly go into the millions. This is
not a trivial concern.
Perhaps @staff.example.com would be more typical, since often a
principal domain supports SMTP.
Sure, it would be more typical of "normal" usage, but scammers are
not "normal" users :-) .
Agreed. Nor can ADSP define a principal domain either. Use of an
NXDOMAIN results as header acceptance requirements represent a
fundamental change in how SMTP operates. Any strategy that first
checks for the existence of MX records can limit the consequences of
any additional transactions to domains clearly indicating support of
SMTP. It truly seems an MX acceptance strategy is needed to combat
rising levels of malevolent and perhaps even malignant abuse. There
is little reason to be optimistic, but that may change.
The only way that ADSP can work is for Verifiers to be
instructedthat anything that _looks_ like an SMTP message (in
fact, anything that complies with RFC 2822) is to be treated as if
every non-existent domain was LOCKED. Which is exactly what our
drafts and the current WG consensus seems to be saying.
Agreed. But this would be a change to SMTP, and is not limited to
domains currently considering DKIM and ADSP, which takes this well
beyond the DKIM WG.
On the contrary, ADSP is alrerady a change to SMTP, since it is
encouraging (to say the least) sites (i.e. verifiers) to drop, or at
least to interfere with, what are currently perfectly normal SMTP
messages.
Agreed. This is likely why the WG ADSP (ASP) draft avoided even
mentioning SMTP. : (
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html