Network Working Group F. Martin, Ed.
Internet-Draft LinkedIn
Updates: 5321 (if approved) A. Peterson, Ed.
Intended status: Standards Track Message Systems
Expires: May 18, 2014 November 14, 2013
SMTP target host selection in Mixed IPv4/IPv6 environments
draft-martin-smtp-target-host-selection-ipv4-ipv6-00
Abstract
The Simple Mail Transfer Protocol (SMTP) is defined in [RFC5321].
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 [RFC5321] to provide a standard way of
selecting the target host in mixed environements.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 18, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Martin & Peterson Expires May 18, 2014 [Page 1]
Internet-Draft SMTP host selection with IPv4/v6 November 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Locating the target host . . . . . . . . . . . . . . . . . . 3
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 4
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 4
A.1. Target list . . . . . . . . . . . . . . . . . . . . . . . 4
A.1.1. Example 1: dual stacked servers . . . . . . . . . . . 5
A.1.2. Example 2: single stacked servers . . . . . . . . . . 5
A.1.3. Example 3: single and dual stacked servers . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Target host selection is discussed in [RFC5321] section 5 and some
operational experience is described in [RFC3974]. 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.
1.1. Requirements Language
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 [RFC2119].
1.2. Rationale
Martin & Peterson Expires May 18, 2014 [Page 2]
Internet-Draft SMTP host selection with IPv4/v6 November 2013
[RFC5321] 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).
2. Locating the target host
This part applies if one or more MX Resource Records (RR) [RFC1035]
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.
The sender-SMTP server first tries all the IP addresses (IPv4 and
IPv6) with higher preference (lower number) before the IP addresses
with lower preference (higher number). The sender-SMTP server tries
all the addresses up to a limit before deciding if the message is
deliverable or not. The sender-SMTP server tries at least two
addresses in each IP familly it is enabled (2 IPv4 addresses if IPv4
capable and 2 IPv6 addresses if IPv6 capable).
For the same MX RR preference, when there is more than one IP address
(IPv4/IPv6) to be tried, the sender-SMTP SHOULD maintain an internal
sub preference list based on the rate of successful delivery of
messages and based on the speed of such delivery. If such internal
sub preference list is not established or cannot be established then
the sender-SMTP tries randomly any address within the same
preference. Using this method the sender-SMTP will not prefer IP
addresses it cannot connect to, or IP addresses with more rejection
or latency. In some ways, this strategy is similar to the Happy
Eveballs [RFC6555] strategy where web browsers initiate parralel
connections to web servers using IPv4 and IPv6 and select the
connection with better response. It is however not similar, because
Martin & Peterson Expires May 18, 2014 [Page 3]
Internet-Draft SMTP host selection with IPv4/v6 November 2013
the sender-SMTP does 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.
3. Acknowledgements
Thanks to Murray Kucheraway for guidance in getting this draft out.
4. IANA Considerations
This section has no action requested of IANA.
[RFC Editor: Please remove this section before publication.]
5. Security Considerations
Rogue sender-SMTP do not follow MX RR preferences, this existed over
IPv4 and common defense can be used over IPv6
6. References
6.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012.
6.2. Informative References
[RFC3974] Nakamura, M. and J. Hagino, "SMTP Operational Experience
in Mixed IPv4/v6 Environments", RFC 3974, January 2005.
Appendix A. Examples
A.1. Target list
Martin & Peterson Expires May 18, 2014 [Page 4]
Internet-Draft SMTP host selection with IPv4/v6 November 2013
A.1.1. Example 1: dual stacked servers
For example, a site with dual stacked servers may have the following
DNS definitions:
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN AAAA 2001:db8:ffff::1
IN A 192.0.2.1
mx10.example.org. IN AAAA 2001:db8:ffff::2
IN A 192.0.2.2
The ordered preference list will look initially:
1 2001:db8:ffff::1
1 192.0.2.1
10 2001:db8:ffff::2
10 192.0.2.2
A.1.2. Example 2: single stacked servers
For example, a site with single stacked servers may have the
following DNS definitions:
example.org. IN MX 1 mx1-6.example.org.
IN MX 1 mx1.example.org
IN MX 10 mx10-6.example.org.
IN MX 10 mx10.example.org
mx1-6.example.org. IN AAAA 2001:db8:ffff::1
mx1.example.org. IN A 192.0.2.1
mx10-6.example.org. IN AAAA 2001:db8:ffff::2
mx10.example.org IN A 192.0.2.2
The ordered preference list will look initially:
1 2001:db8:ffff::1
1 192.0.2.1
10 2001:db8:ffff::2
10 192.0.2.2
A.1.3. Example 3: single and dual stacked servers
For example, a site with a mix of single and dual stacked servers may
have the following DNS definitions:
Martin & Peterson Expires May 18, 2014 [Page 5]
Internet-Draft SMTP host selection with IPv4/v6 November 2013
example.org. IN MX 1 mx1.example.org.
IN MX 1 mx1-6.example.org
IN MX 1 mx2.example.org
IN MX 10 mx10.example.org.
mx1.example.org. IN A 192.0.2.1
mx1-6.example.org. IN AAAA 2001:db8:ffff::1
mx2.example.org. IN A 192.0.2.2
mx10.example.org. IN AAAA 2001:db8:ffff::2
mx10.example.org IN A 192.0.2.3
The ordered preference list will look initially:
1 192.0.2.1
1 2001:db8:ffff::1
1 192.0.2.2
10 2001:db8:ffff::2
10 192.0.2.3
Authors' Addresses
Franck Martin (editor)
LinkedIn
Mountain View, CA
US
Email: fmartin@linkedin.com
Alec Peterson (editor)
Message Systems
Columbia, MD
US
Email: alec@messagesystems.com
Martin & Peterson Expires May 18, 2014 [Page 6]