On Jun 17, 2008, at 3:41 AM, Charles Lindsey wrote:
On Mon, 16 Jun 2008 15:51:07 +0100, Douglas Otis <dotis(_at_)mail-
abuse.org>
wrote:
Protection depends upon which ADSP assertion is made. A LOCKED
assertion will cause a message to be dismissed when ADSP compliance
is enforced. Acceptance of messages with invalid signatures from
mailing lists or those that appear to have been "converted" from a
different transport could be fairly typical when the ADSP assertion
is CLOSED, however these messages would not bypass other typical
message screenings. Scoring or annotation for CLOSED assertion
messages with invalid signatures is also likely to place these
messages into a different recognizable category that improves the
quality of the screening process.
But we are concerned with cases where the domain has NO DNS record
and hence, by definition, no ADSP assertions are available. So who
cares or knows whether the domain being spoofed was LOCKED, CLOSED
or OPEN?
When a domain represents a 'Reserved' TLD (per RFC2606) or per Frank's
http://tools.ietf.org/html/draft-ellermann-idnabis-test-tlds-04
Even so, Frank's list still needs to be extended to include names like
".local" and perhaps ".nntp" to permit address converters a safe mode
of operation. Nevertheless, these considerations are independent of
ADSP and DKIM. This is about what might be acceptable as a domain
within an email-address carried by SMTP message headers. ADSP must be
defined as pertaining to messages carried by SMTP, or its assertions
are meaningless. 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.
If the scammer writes
From: info(_at_)ebuy(_dot_)com
and verifiers allow this through because, as you seem to suggest,
that message might have come from some MS Exchange system which had
assigned info(_at_)ebuy(_dot_)com as an SMTP proxy address, and the Verifier
has no way of recognizing this situation, then the whole of ADSP
becomes pointless, and it would be a waste of time for the REAL
ebay.com to DKIM-sign anything or to publish a LOCKED ADSP record.
Perhaps @staff.example.com would be more typical, since often a
principal domain supports SMTP. Declare such messages with non-DNS
addresses will soon be considered noncompliant per a new draft
developed by an SMTP WG, since currently these messages are exchanged
without violating existing protocols. Change can occur, but it will
take effort.
The only way that ADSP can work is for Verifiers to be instructed
that 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.
To ensure ignored domains do not offer a method to spoof addresses,
defining which recognizable domains should be ignored must be
accomplished. ...
Then show us how to accomplish it.
Frank is heading in the right direction, but even this draft's list is
in need of greater accommodations when "Reserved TLDs" becomes
"Permitted non-DNS TLDs". It also seems that a draft implementing
what amounts to creating a dependence upon DNS also needs to consider
how SMTP will continue to operate for crucial systems when DNS becomes
unavailable. In this case, a means to make exceptions locally must be
possible, when host lists might be used instead.
... Again, such definitions should be done in a different draft
since this has nothing to do with DKIM or ADSP.
But if what you propose is fundamentally impossible (as appears to
be the case), then pretending that some different draft will
miraculously solve that problem and close the loophole does not seem
like a wise way to proceed.
ADSP can be defined without sub-domain flags or domain tree walking in
safe manner now. A protection gap this approach creates can be filled
by a draft fundamentally changing the permitted name space used in
SMTP message headers. It seems possible for such a draft to get
underway, based upon some positive feedback. Opening up SMTP to IPv6
creates a need for other identifiers upon which reputation can be
based. Even when signatures are utilized, a means to apply policy for
facilitating a transition seems necessary. Adopting a requirement
that eventually all DNS name space must publish an MX record could
prevent any dangerous hunting for policy or other transactions related
to validation efforts. Currently a mandate could be defined as
requiring at least MX and A records to ensure message acceptance.
Changing server discovery algorithms does not seem practical.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html