SMTP IPv6 to IPv4 Fallback: An Applicability Statement

SMTP IPv6 to IPv4 Fallback: An Applicability Statement LinkedIn

Mountain View CA US fmartin@linkedin.com

Message Systems

Columbia MD US alec@messagesystems.com

apparea Network Working Group SMTP IPv4 IPv6 MX This Applicability Statement describes how Mail Transfer Agents (MTAs) can be encouraged to fall back to IPv4 when a message is refused over IPv6.

The Simple Mail Transfer Protocol (SMTP) is defined in . Section 5 of that document describes the process of host selection. SMTP clients in well known Mail Transfer Agent (MTA) software will retry a message using a different Mail Exchanger (MX) or network address if the message is temporarily rejected. This document describes under which circumstances well known and widely deployed open source MTAs (and others) can be made to retry over IPv4 when an initial connection to IPv6 results in a temporary rejection. Furthermore, the purpose of this document is to record that behaviour and encourage its further adoption while at the same time providing for the future a well defined mechanism via a service extension with cooperating SMTP clients. This behavior could be useful in, for instance, enforcing higher requirements for Simple Mail Transfer Protocol (SMTP) sessions over IPv6 than what exists on IPv4 without simply rejecting the message outright.

IPv6 brings more IP addresses, which means building an IP-based reputation system using IPv6 addresses could be difficult to achieve. Moving from an IP based reputation system to a domain based reputation system is expected to be easier. However, it requires that all SMTP servers participate. IPv4 address space is well known and many tools have been built to handle unwanted emails from certain IPv4 addresses. There is not yet such expertise on IPv6 nor tools. However, labels, like domain names are more stable, unlike the more dynamic nature of IP address allocation, and provide a relatively better chain to associate an email to its author, provided such labels can be authentified. Such labels allow better reporting of unwanted emails to the system administrators of mail servers in these domains. As IPv6 is still relatively nascent, there is a chance to mandate use of the Sender Policy Framework (SPF, ) or DomainKeys Identified Mail (DKIM, ) or similar domain-based authentication mechanisms for messages sent over IPv6 and, if these fail, to do retries over IPv4.

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.

To move from IP based reputation to a domain based reputation system for email, a receiver-SMTP could, for example, require that messages pass SPF or DKIM. This section does not discuss the merit of such policy but proposes mechanisms for any policy to get the sender-SMTP to fall back to IPv4 from an IPv6 connection.

The receiver-SMTP MAY addvertise a service extension IPV6-IPV4-FALLBACK, which the sender-SMTP replies by IPV6-IPV4-FALLBACK if capable In this condition for each message not acceptable due to policy where a retry over IPv4 is requested, the sender-SMTP server MUST reply by the reply code 456, where the sender-SMTP requeues the message for immediate retry by selecting a receiver, according to Section 5 of , that is at an IPv4 address.. If there is no IPv4 address to be tried, the sender-SMTP SHOULD fail the message. If the receiver-SMTP implements enhanced status codes, The SMTP enhanced status code SHOULD be 4.4.8.

Example status message The SMTP status code 456 is introduced in this document, and has a very specific meaning associated to the service extension. The SMTP enhanced status code is also introduced in this document, but like all enhanced status codes, they are usually not interpreted by the SMTP client, but for the bounce processor as to provide more meaningful reports to the mail administrator.

The receiver-SMTP server MUST have MX RR pointing to single stack hostnames and for same MX RR preference MUST have a MX RR pointing to an hostname with an A RR and a MX RR pointing to an hostname with an AAAA RR. No hostname pointed by a MX RR have a A RR and an AAAA RR.

For example: When a receiver-SMTP makes a policy decision not to accept a message over IPv6, it rejects the message with a 451 code if done at connection time and 421 code if done later and terminates the connection so the sender-SMTP requeues the message for immediate retry by selecting a receiver, according to Section 5 of , that is at an IPv4 address.. If the receiver-SMTP implements enhanced status codes, The SMTP enhanced status code SHOULD be 4.4.8. The rejection at connection time MAY be issued only when it has been demonstrated that a majority of messages would not pass the policy and that the sender-SMTP is not capable of the service extension IPV6-IPV4-FALLBACK. The rejection at connection time SHOULD be for a limited time to give a chance for later messages to be re-evaluted against the policy. 456 is not used here, as it is a new SMTP status code introduced for clients that understand the service extension IPV6-IPV4-FALLBACK. It is not sure that sender-SMTP without this service extension would behave as expected with a new SMTP status code. Research presented in annexes has shown that common MTA exhibit this behavior.

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

This section describes actions requested of IANA.

IANA is requested to add the following to the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry: Enumerated Status Codes Code: X.4.8 Summary: retry on IPv4 Associated basic status code: 421,451,456 Description: the mail system will not accept this message over IPv6 because it lacks some requirments described in the full text of the rejection, however the sending mail system can retry immediately to submit the message over IPv4 only.

IANA is requested to add the following to the Simple Mail Transfer Protocol (SMTP) Service Extensions Registry: Textual name: Capable to retry the message over IPv4 from IPv6 if requested EHLO Keyword: IPV6-IPV4-FALLBACK There is no parameters associated with the extension SMTP verb: IPV6-IPV4-FALLBACK Description: When the server indicates the service extension and the client indicates via the SMTP verb that it supports such extension, if the server rejects the message with the status code 456, the client will requeue the message to be delivered over IPv4. This extension does not increase the length of the MAIL and RCPT commands

SMTP clients might not not fall back to IPv4 when requested (by not implementing this proposal) and keep retrying on IPv6. MTA administrators ought to monitor for such servers, and could whitelist them to accept messages over IPv6 or take other action as appropriate. Messages may start to queue on the sender-SMTP side and the mail administrator may not notice it or take appropriate action in time. If the policy is not explained clearly the mail administrator may not know what is required to pass the policy. If the policy is to cumbersome and is not based on widely adopted standards and recommendations, the mail administrator may decide not to jump through hoops to get the email delivered. The fall back mechanism without service extension may create unecessary burden for the sender as well as the receiver.

&RFC2119; &RFC5248; &RFC5321; &RFC6376; &RFC6652; &RFC4408; &RFC3974; &RFC5226;

The sender-SMTP server opens a connection to the receiver-SMTP example.org over IPv6, the message is refused because no domain authentication can be performed therefore the sender-SMTP retries immediately using IPv4. "S" indicates text sent by a server, and "C" indicates text sent by a client. Line terminations are omitted in this illustration. S: 250 OK C: RCPT TO: S: 250 OK C: DATA S: 354 Start mail input; end with . C: [message body] C: . S: 421 4.4.8 message with no SPF or DKIM and over IPv6 S: S: 220 ipv4.example.com Simple Mail Transfer Service Ready C: EHLO example.org S: 250-ipv4.example.com greets example.org over IPv4 S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250 HELP C: MAIL FROM: S: 250 OK C: RCPT TO: S: 250 OK C: DATA S: 354 Start mail input; end with . C: [message body] C: . S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel ]]>

The sender-SMTP server opens a connection to example.com over IPv6, the message is refused because no domain authentication can be performed therefore the sender-SMTP retries immediately using IPv4. "S" indicates text sent by a server, and "C" indicates text sent by a client. Line terminations are omitted in this illustration. S: 250 OK C: RCPT TO: S: 250 OK C: DATA S: 354 Start mail input; end with . C: [message body] C: . S: 456 4.4.8 message with no SPF or DKIM and over IPv6 C: QUIT S: 221 foo.com Service closing transmission channel Message is then retried immediately over IPv4 ]]>

This secton discusses current implementations in common open source MTAs. SMTP clients only interpret SMTP status codes, but the use of SMTP enhanced status codes can be used to better monitor and act on the reason of the temporary failure. For instance, at the end of DATA, if the message was sent over IPv6, the SMTP server can evalute whether the message passes SPF or DKIM and reject the message using 421 if neither pass. If one passes, then an authenticated domain name is available and domain reputation rules can be applied. The IPv6 address of the SMTP client can be noted, and futher connections over IPv6 can be temporarily failed using the 451 status code for some period of time period so as to minimize resources to evaluate each message after the end of DATA. On the other hand, if a message coming from an IPv6 address does not pass SPF or DKIM, it is unlikely that this state would quickly change for the next message coming from the same network address. For proprietary mail systems or large mailbox providers, they all do a form of domain authentication, either SPF or DKIM, so the above may not apply to them. Not all are yet enabled to send email over IPv6. Some observations: When presented with a permanent failure code (5yz) during connection establishment, MTA clients will declare the message non deliverable and will not retry it on a different MX. Some clients do retry however. When an SMTP server rejects during the connection phase using the code 451 and disconnects, the SMTP client will typically retry the message immediately on a different MX. When an SMTP server rejects after the DATA phase using a 421 SMTP reply code followed by a disconnect, the SMTP client will retry the message immediately on a different MX. MX RR configuration and the proper rejection need both to be properly defined.

When a message is temporarily refused, using a 400-series SMTP error code, the strategy for the SMTP client is sometimes to retry immediately to a different MTA, as defined by the target selection process defined in . When the new MX refers to a dual-stacked machine (see ), some MTA software will not pick up all of the A or AAAA RRs (Resource Records), but will instead select only the RRs matching the address family preferred by the local TCP/IP implementation. Thus, MX RRs MUST NOT refer to dual-stacked machines.

For instance, the following configuration is desired: In this configuration, the SMTP client see two MXes at the same preference, and will automatically pick one and try the other one if the message is properly temp-failed. Therefore, in the above example, if the first connection was over IPv6 and the message temporarly refused and the session disconnected, the next connection will be over IPv4.

Here is an example of an initial message sent over IPv6. The SMTP client then retries immediately on the next MX record, here an IPv4 address. "S" indicates text sent by a server, and "C" indicates text sent by a client. Line terminations are omitted in this illustration. S: 220 example.net Simple Mail Transfer Service Ready C: EHLO example.com S: 250-example.net greets example.com over IPv6 S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250 HELP C: MAIL FROM: S: 250 OK C: RCPT TO: S: 250 OK C: DATA S: 354 Start mail input; end with . C: C: . S: 421 4.4.8 SPF and/or DKIM required on IPv6; try elsewhere C: QUIT S: 221 foo.com Service closing transmission channel ]]>

Where the client is known to not use DKIM and/or SPF, the server may terminate the connection immediately: S: 451 4.4.8 Come back on IPv4 as I told you before ]]>