[Top] [All Lists]

Re: current usage of AAAA implicit MX?

2008-04-08 14:35:42

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.