On Jun 5, 2008, at 4:30 PM, Frank Ellermann wrote:
Douglas Otis wrote:
Agreed. However, ADSP must limit the scope of the practice.
Okay, so apparently we agree that noting say "gbl" addresses as
"nomailfqdn" and then reject or even discard them is a bad idea.
(I'm not sure if "gbl" is the correct example, please correct me if
it's beside your point.)
Sorry, the term "gbl" eludes me. A scheme that refuses messages based
upon NXDOMAIN or the lack of SMTP discovery records would be a bad
idea without also incorporating a domain specific mitigation
strategy. A mitigation strategy could be to make exceptions for non-
SMTP domains. Exceptions would be made by transports and MUAs
accepting messages from non-SMTP transports. These exceptions would
likely represent fairly simple and small domain or address list.
However we're here deep in "receiver policy" territory again, as
nice as an X.400 address might be, I don't wish to get it in my
inbox, because I'd have no clue how to reply - without reading old
Mixer RFCs, which would be cheating, not what an ordinary user does.
Mailbox addresses must conform to the syntax specified by RFC2822.
Exceptions could be based upon specific domains that might be assigned
by X.400 rather than DNS, for example. An ability to make exceptions
is needed for users making use of non-SMTP transport and non-DNS name
space.
To take something less exotic, IIRC the drafts don't discuss domain
literals at the moment. For an "nxdomain" check this could be
addressed by stating "n/a".
Unless messages from "n/a" domains are not accepted, ADSP would be
unable to prevent sub-domain abuse. When ADSP adds an absence
validation requirement, then messages handled by MS Exchange may be
disrupted. Nevertheless, it should be a small matter to impose an
exception for their own domains, provided of course the transport
supports a means to make these exceptions.
For John's more elaborated "nomailfqdn" check it could be either
solved as "a domain literal is *of course* no FQDN", or by saying "a
domain literal *of course* is an A or AAAA".
John's draft offers a mode that provides fewer benefits where SMTP
support is not confirmed by the added overhead, nor is the transport
specified.
The otis-dkim-adsp draft leaves out AAAA records. Mandating presence
of either an MX or A record at this time should not be disruptive,
however the AAAA record exclusion affords IPv6 hosts greater
protection from SMTP related undesired traffic. Once again, the AAAA
record exclusion also requires a means to make an exception for
crucial systems.
Our bad actor tracking system observes millions of new IP addresses
becoming briefly active every hour. These addresses then go dormant
for very long periods of time. With hundreds of millions of addresses
within their control, about 40 million bad actor controlled sources
make SMTP transactions within any given hour. A mandate to publish MX
records can reduce the level of undesired and potentially dangerous
levels of traffic imposed on non-SMTP domains when spoofed as an email
source. By having vast numbers of Bots, both spam and malware quickly
become a unique product generated for each receiver. A strategy that
depends upon content filtering is doomed. However, source validation
and behaviour tracking remains viable.
Even here, ADSP is making a tragic mistake. Binding the local-part to
the Author Key domain disallows opaque local-part identifiers that
might track access accounts rather than users by name. It is not
practical for DKIM signatures to link local-parts with each user.
Ascribing the signer as an identity that includes the local-part
parameter unfortunately prevents a practical use of DKIM for tracking
intra-domain abuse without needlessly violating user privacy or
freedom. The work-around requires multiple signatures be applied
whenever DKIM affirms on whose behalf the message was signed when the
identifier does not match the From header.
I'd prefer "no FQDN" and let the receiver decide what to do with it,
because the technical details of which A or AAAA are plausible
public addresses (not 127.0.0.1 etc.) are no topic for ADSP. But
maybe it is as simple as two normative references, and after all it
still boils down to "let the receiver decide".
The Internet and SMTP is under siege. If DKIM is to have merit, it
should be part of a comprehensive strategy. With DKIM, both receivers
and senders should be be able block bad actors infiltrating domains
using standardized conventions. At every level of security, simple
standardized message passing is needed. SMTP and similar approaches
must be employed in a secure fashion. These solutions likely
represent a critical aspect for future designs.
A message transport should verify support of the transport protocol by
purported originators before proceeding with a large number of
transactions. A means to make exceptions is also essential, since DNS
failure must be tolerated for crucial systems. The ability to make
exceptions also supports a mix of non-SMTP traffic within SMTP as well.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html