On Apr 8, 2008, at 9:37 AM, Hector Santos wrote:
Douglas Otis wrote:
Standardizing on AAAA fallback when MX resource record do not exist
will require those using IPv6-only hostnames to publish bogus MX
resource records as a means to avoid undesired traffic SMTP now
generates. Standardization on AAAA fallback is likely to attract
this undesired traffic and further abuse of SMTP. The undesired
traffic can be substantial, depending upon the nature of the
spoofed email, where creating bogus MX resource records in response
should not be seen as beneficial. This effort will increase the
DNS zone sizes. Instances of IPv6 only SMTP lacking MX records and
receiving public SMTP traffic is sure to represent a small minority
of the number of hostnames in IPv6 address space.
Given a MX mandate for security purposes, I have the following
questions:
(1) WHERE is the MX mandate best apply?
Use of MX records would not change. MX or A records would be used
whenever an outbound SMTP client is attempting to discover the public
SMTP server for a specific domain. By purposely prohibiting MX fall-
back to AAAA records, hostnames only having IPv6 addresses will not
automatically assumed to be a possible SMTP server. The assumption of
AAAA records representing possible inbound SMTP servers for the domain
represented by the hostname enables source domain exploits already
common for IPv4.
Outbound SMTP clients discovering SMTP servers for an email address
should quit when MX or A resource records are not published for the
email address domain. Inbound SMTP servers might rely upon the
necessity of MX or A resource records to confirm validity of MailFrom
email addresses, hopefully before message data has been accepted.
Prohibition of AAAA MX fall-back would inhibit undesired traffic
created by bad-actors spoofing source domains by exploiting existing
hostname records.
To ensure uniform configurations between IPv4 and IPv6 clients, A
record fall-back should also be deprecated, but this would need to be
done in a separate draft. RFC 2821bis would be would be making an
unsafe architectural choice by standardizing AAAA fall-back when MX
resource records are not found. A luxury of not needing MX records is
becoming expensive due to rampant SMTP abuse.
Hostnames seen on the Internet within IPv4 address space often
represent substantial systems, although a small number of these hosts
act as inbound SMTP servers. IPv6 is likely to expose a wider range
of devices to the Internet with an even smaller percentage acting as
inbound SMTP servers. In addition, many of these servers may be
embedded with less resources compared to systems currently found
within IPv4 address space. Abuse currently endemic for A resource
records may prove devastating for embedded servers directly connected
to the Internet as promised by IPv6.
2) WHEN is the MX best utilized?
(A) Before the PAYLOAD is transmitted?
(B) After the PAYLOAD is transmitted but not accepted yet. (DATA)
(C) After the PAYLOAD is accepted with a 250 response
(D) Only when NECESSARY
Of course, if your answer to 1.A, then it best utilized at 2.A.
But I am afraid you and others are going to have a vastly different
views about where MX is used and when it is applied. Regardless of
WHERE, most will have no real choice when it can be applied. For
many, 2.C is their only option. In fact, I think we might find many
here say 2.D is the really the only choice since MX is only
important come response time.
What this means is that MANY of the concerns regarding IMPLICIT MX
and bounce attacks can be resolved or drastically minimized by
mandating a 2.A or 2.B SMTP level design.
This approach would help address the general concern of source domain
spoofing. This would also minimize the number of domain nodes that
might need to publish SMTP related policy as well.
Of course, that is not practical.
What is not practical? Checking the reverse DNS zone is becoming less
and less practical. IPv6 seems sure to defeat this strategy.
Acceptance of a draft that details steps for a transition to MX only
SMTP discovery would help bring about a smoother introduction of
IPv6. Changes will need to be adopted as a means to minimize
disruptions an MX only discovery paradigm change might cause. Some
may adopt rote publishing of MX and address records. Others may not
default MailFroms to the local-host domain.
-Doug