Network Working Group S. Moonesamy Internet Draft October 8, 2011 Obsoletes: 3974 (if approved) Intended status: Informational Expires: April 10, 2012 SMTP in an IPv4/IPv6 dual stack Environment draft-moonesamy-smtp-ipv6-00.txt Abstract This memo discusses about SMTP in an IPv4/IPv6 dual stack environment. It documents the algorithm initially specified in RFC 3974 which is used in several SMTP implementations. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 10, 2012 Copyright Notice Copyright (c) 2011 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 S. Moonesamy Expires April 2011 [Page 1] Internet Draft SMTP and IPv6 October 8, 2011 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. S. Moonesamy Expires April 2011 [Page 2] Internet Draft SMTP and IPv6 October 8, 2011 1. Introduction This memo discusses about SMTP in an IPv4/IPv6 dual stack environment. It contains a specific interpretation, initially specified in RFC 3974, of the applicability of the MX processing algorithm in RFC 5321, Section 5, to dual-stack environments. Implementers are cautioned that they must reference RFC 5321 for the full algorithm; in case of ambiguity, RFC 5321 is authoritative. This memo obsoletes RFC 3974 [RFC3974]. 2. SMTP Sender Algorithm in a Dual-Stack Environment The algorithm for a dual-stack SMTP sender is basically the same as that for an IPv4-only SMTP client, but it now includes AAAA lookups of DNS MX records for SMTP-over-IPv6 relaying. IPv4/IPv6 dual stack destinations should be treated just like multihomed destinations, as described in RFC 5321 [RFC5321], Section 5. Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in RFC 5321 Sections 2.3.5 and 3.6), a DNS lookup must be performed to resolve the domain name (RFC 1035 [RFC1035]). The names are expected to be fully-qualified domain names (FQDNs): mechanisms for inferring FQDNs from partial names or local aliases are outside of this specification. (1) As specified in RFC 5321, the lookup first attempts to locate an MX RR associated with the name. If a CNAME record is found, the resulting name is processed as if it were the initial name. If a non-existent domain error is returned, this situation must be reported as an error. If a temporary error is returned, the message must be queued and retried later (see RFC 5321 Section 4.5.4.1). If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. If MX RRs are present, but none of them are usable, or the implicit MX RR is unusable, this situation must be reported as an error. (2) Compare each host name in MX RR with the names of the sending host. If there is match, drop MX RRs which have an equal or larger value than the lowest-preference matching MX RR (including itself). If multiple MX RRs remain, sort the MX RRs in ascending order based on their preference values. Loop over steps (3) to (9) on each host name in MX RR in a sequence. If no MX RRs remain, the SMTP client must be the primary MX host. Other routing rules should be applied. Finish. (3) If the sending MTA has IPv4 capability, lookup the A RR. S. Moonesamy Expires April 2011 [Page 3] Internet Draft SMTP and IPv6 October 8, 2011 Keep the resulting addresses until step (5). (4) If the sending MTA has IPv6 capability, lookup the AAAA RRs. (5) If there is no A or AAAA RR present, try the next MX RR (go to step (3)). Note that the next MX RR could have the same preference. NOTE: If one or more address RRs are found, an implementation may sort addresses RRs based on the implementation's preference of A or AAAA RR. To encourage the transition from IPv4 to IPv6, AAAA RRs may take precedence. The sorting may only reorder address RRs from MX RRs of the same preference. (6) For each of the addresses, loop over steps (7) to (9). (7) An SMTP session is initiated with the SMTP client opening a connection to the SMTP server as specified in RFC 5321 Section 3.1. The SMTP client needs to adhere to the timeouts specified in RFC 5321 Section 4.5.3.2 and the sending strategy defined in RFC 5321 Section 4.5.4.1. If successful, go to step (9). (8) If unsuccessful and there is another available address, try the next available address. Go to step (7). If all addresses are not reachable and if a list of MX RRs is being traversed, try the next MX RR (go to step (3)). If there is no list of MX RRs, or if the end of the list of MX RRs has been reached, raise a temporary email delivery failure. Finish. (9) Attempt to deliver the email over the connection established, as specified in RFC 5321. If a transient failure condition is reported, try the next MX RR (go to step (3)). If an error condition is reported, raise a permanent email delivery error, and do not try further MX RR. Finish. If successful, SMTP delivery has succeeded. Finish. 3. Security Considerations Section 7 of RFC 5321 discusses about the security considerations for SMTP implementations should provide the capability for filtering in an IPv6 environment similar to what is currently available in an IPv4 environment. 4. IANA Considerations S. Moonesamy Expires April 2011 [Page 4] Internet Draft SMTP and IPv6 October 8, 2011 This document does not require the IANA to take any action. 5. Acknowledgements This document borrows text from RFC 3974 which was written by Motonori Nakamura and Jun-ichiro itojun Hagino. Here is a list of people who contributed to RFC 3974: Gregory Neil Shapiro, Arnt Gulbrandsen, Mohsen Souissi, JJ Behrens, John C Klensin, Michael A. Patton, Robert Elz, Dean Strik, Pekka Savola, and Rob Austein. Some of the text in this document was copied from RFC 5321. 6. References 6.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. 6.1. Informative References [RFC3974] Nakamura, M. and Hagino, J., "SMTP Operational Experience in Mixed IPv4/v6 Environments", RFC 3974, January 2005. Author's Address S. Moonesamy 76, Ylang Ylang Avenue Quatre Bornes Mauritius Email: sm+ietf@elandsys.com S. Moonesamy Expires April 2011 [Page 5]