]> LinkedIn

Mountain View CA US fmartin@linkedin.com

Message Systems

Columbia MD US alec@messagesystems.com

apparea Network Working Group SMTP IPv4 IPv6 MX The Simple Mail Transfer Protocol (SMTP) is defined in . Section 5 of that document describes the process of host selection. While locating the target host in IPv4 is well defined, this process is unclear for sytems in IPv4 and IPv6 environemts. This specification extends to provide a standard way of selecting the target host in mixed environements.

Target host selection is discussed in section 5 and some operational experience is described in . However the process is unclear when selecting the target host in a mixed environment. Several widely deployed open source MTA do not make this selection the same and sometimes do not find all the hosts. This specification addresses the issue of host selection in mixed environments.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

section 5.2 specifically discusses SMTP implementations taking into account 'local circumstances' when deciding which network addresses to use. However, neither it nor [RFC3974] explore what 'local circumstances' should be evaluated or how they should be evaluated. The result has thus far been an inconsistent set of SMTP client implementations. Providing a guideline for how SMTP client implementations should handle various dual-stack situations will improve the stability of the network while we operate in a dual- stack mode (which will likely be for an extended period of time).

This part applies if one or more MX Resource Records (RR) are found for a given name and if the sender-SMTP server is IPV4 and/or IPv6 capable. When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name. That domain name is queried for A RR if the sender-SMTP is IPv4 capable and is queried for AAAA RR if the sender-SMTP is IPv6 capable. A list of IPv4 and IPv6 addresses of the SMTP servers to which the message should be directed is therefore built. When there are more than one MX RR associated to the given domain, the above process is done for each MX RR. An ordered list of IPv4 and IPv6 addresses is then established using the MX RR preference. Lower numbers are more preferred than higher ones. For the same MX RR preference, when there is more than one IP address (IPv4/IPv6) to be tried, the sender-SMTP SHOULD sort this list either following the application configuration, recognition of an easily reached or well performing address, or the operating system's address selection or when there is no clear reason to favor one, then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific domain name. Most sender-SMTP limit the number of IP addresses that will be tried for each MX record. For the same MX RR preference, the sender-SMTP SHOULD ensure that at least two IP addresses of the other address family are tried before that limit. If the sender-SMTP orders the IP list for the same MX RR preference based on some reacheability criteria, it will not prefer IP addresses for instance it cannot connect to, or IP addresses with more rejection or latency. In some ways, this strategy is similar to the Happy Eveballs strategy where web browsers initiate parralel connections to web servers using IPv4 and IPv6 and select the better connection. It is however not similar, because the sender-SMTP MUST NOT try to establish a connection to all the MX RR in parralel but remembers for a period of time which connection, for IP addresses with same MX RR preference, had better response. Network paths and servers are constantly breaking and being repaired. Thus, implementations MUST occasionally age out their IPv6 or IPv4 preferences. It is RECOMMENDED that this information be aged out several times before the maximum retry time of a message while also following the DNS TTL of the MX RR.

Thanks to Murray Kucheraway for guidance in getting this draft out.

This section has no action requested of IANA. [RFC Editor: Please remove this section before publication.]

Rogue sender-SMTP do not follow MX RR preferences, this existed over IPv4 and common defense can be used over IPv6

&RFC1035; &RFC2119; &RFC3552; &RFC5321; &RFC6555; &RFC6724; &RFC3974;

For example, a site with dual stacked servers may have the following DNS definitions:

The ordered preference list will look initially:

For example, a site with single stacked servers may have the following DNS definitions:

The ordered preference list will look initially:

For example, a site with a mix of single and dual stacked servers may have the following DNS definitions:

The ordered preference list will look initially:

For example, a SMTP-server that prefers IPv6 over IPv4 as per default address preference is trying to send a message to example.org with the following configuration:

The sender-SMTP would prefer mail1 (preference 10) and then mail2 (preference 20). An SMTP-server implementation that does not implement this specification and has a 6 address limit per MX record and default address preference, would attempt to connect to the 6 IPv6 addresses belonging to mail1. If the IPv6 path is broken, these connection attempts would all fail (after a timeout), as would the connection attempt to mail2's IPv6 address. Finally, after those connection timeouts, the IPv4 address for mail2 would succeed. In contrast, an SMTP-server which is following the normative procedure above would succeed in connecting to mail1 if the IPv4 path is working but the IPv6 path is broken. This SMTP-server implementation would attempt to connect to the four IPv6 addresses belonging to mail1 and then to the IPv4 addresses belonging to mail2 -- resulting in mail delivery to mail1 (which is preferable for the receiving domain) and faster mail delivery. Following the procedure above with a 6 address limit per MX record and default address preference, the connections attempted would be: