idnits 2.17.1 draft-martin-smtp-ipv6-to-ipv4-fallback-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5321, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5321, updated by this document, for RFC5378 checks: 2005-07-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 15, 2014) is 3634 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5226' is defined on line 239, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4408 (Obsoleted by RFC 7208) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Martin, Ed. 3 Internet-Draft LinkedIn 4 Updates: 5321 (if approved) A. Peterson, Ed. 5 Intended status: Standards Track Message Systems 6 Expires: November 16, 2014 May 15, 2014 8 SMTP IPv6 to IPv4 Fallback: An Applicability Statement 9 draft-martin-smtp-ipv6-to-ipv4-fallback-01 11 Abstract 13 This Applicability Statement describes how Mail Transfer Agents 14 (MTAs) can be encouraged to fall back to IPv4 when a message is 15 refused over IPv6. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 16, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Moving from IP Reputation to Domain Based Reputation . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 54 3. Indicating the sender-SMTP server to fall back to IPv4 . . . 3 55 3.1. Using 421 SMTP Error code . . . . . . . . . . . . . . . . 3 56 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 5.1. SMTP Enhanced Status Codes Registry update . . . . . . . 4 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 7.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Appendix A. Examples and research . . . . . . . . . . . . . . . 6 64 A.1. SMTP fall back from IPv6 to IPv4 . . . . . . . . . . . . 6 65 A.2. Common Open Source MTA Design . . . . . . . . . . . . . . 7 66 A.2.1. MX RR configuration . . . . . . . . . . . . . . . . . 8 67 A.2.2. Rejecting Messages for Immediate Retry on IPv4 . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 The Simple Mail Transfer Protocol (SMTP) is defined in [RFC5321]. 73 Section 5 of that document describes the process of host selection. 74 SMTP clients in well known Mail Transfer Agent (MTA) software will 75 retry a message using a different Mail Exchanger (MX) or network 76 address if the message is temporarily rejected. This document 77 describes under which circumstances well known and widely deployed 78 open source MTAs (and others) can be made to retry over IPv4 when an 79 initial connection to IPv6 results in a temporary rejection. This 80 behavior could be useful in, for instance, enforcing higher 81 requirements for Simple Mail Transfer Protocol (SMTP) sessions over 82 IPv6 than what exists on IPv4 without simply rejecting the message 83 outright. 85 1.1. Moving from IP Reputation to Domain Based Reputation 87 IPv6 brings more IP addresses, which means building an IP-based 88 reputation system using IPv6 addresses could be difficult to achieve. 89 Moving from an IP based reputation system to a domain based 90 reputation system is expected to be easier. However, it requires 91 that all SMTP servers participate. 93 IPv4 address space is well known and many tools have been built to 94 handle unwanted emails from certain IPv4 addresses. There is not yet 95 such expertise on IPv6 nor tools. However, labels, like domain names 96 are more stable, unlike the more dynamic nature of IP address 97 allocation, and provide a relatively better chain to associate an 98 email to its author, provided such labels can be authentified. Such 99 labels allow better reporting of unwanted emails to the system 100 administrators of mail servers in these domains. 102 As IPv6 is still relatively nascent, there is a chance to mandate use 103 of the Sender Policy Framework (SPF, [RFC4408]) or DomainKeys 104 Identified Mail (DKIM, [RFC6376]) or similar domain-based 105 authentication mechanisms for messages sent over IPv6 and, if these 106 fail, to do retries over IPv4. 108 2. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 3. Indicating the sender-SMTP server to fall back to IPv4 116 To move from IP based reputation to a domain based reputation system 117 for email, a receiver-SMTP could, for example, require that messages 118 pass SPF [RFC6652] or DKIM [RFC6376]. This section does not discuss 119 the merit of such policy but proposes mechanisms for any policy to 120 get the sender-SMTP to fall back to IPv4 from an IPv6 connection. 122 3.1. Using 421 SMTP Error code 124 The receiver-SMTP server MUST have at least one MX RR of the highest 125 priority pointing to a single stack hostname with only an A RR 126 record. 128 For example: 130 example.org. IN MX 1 mx1.example.org. 131 IN MX 1 mx2.example.org 132 mx1.example.org. IN A 192.0.2.1 133 mx2.example.org. IN AAAA 2001:db8:ffff::2 134 mx2.example.org. IN A 192.0.2.2 136 If the sender-SMTP decides to select first the MX with an hostname 137 having an AAAA RR, and the receiver-SMTP makes a policy decision not 138 to accept a message over IPv6, the receiver-SMTP MUST reject the 139 message with a 451 code if done at connection time and 421 code if 140 done later and MUST terminates the connection immediately after so 141 the sender-SMTP requeues the message for immediate retry by selecting 142 the next receiver in priority order, according to Section 5 of 143 [RFC5321]. Because the highest priority MX points to an hostname 144 with only an A RR, the next connection will be over IPv4... 146 As per Section 4.2.3 of [RFC5321] the 421 error code means "Service 147 not available, closing transmission channel". As such the sender- 148 SMTP usually immediately retries the message on next available MX. 150 If the receiver-SMTP implements enhanced status codes [RFC5248], The 151 SMTP enhanced status code SHOULD be 4.4.8. 153 The rejection at connection time MAY be issued only when it has been 154 demonstrated that a majority of messages would not pass the policy. 156 The rejection at connection time SHOULD be for a limited time to give 157 a chance for later messages to be re-evaluted against the policy. 159 Research presented in annexes has shown that common MTA exhibit this 160 behavior. 162 4. Acknowledgements 164 Thanks to Murray Kucheraway for guidance in getting this draft out. 166 5. IANA Considerations 168 This section describes actions requested of IANA. 170 5.1. SMTP Enhanced Status Codes Registry update 172 IANA is requested to add the following to the Simple Mail Transfer 173 Protocol (SMTP) Enhanced Status Codes Registry: 175 o Enumerated Status Codes 177 o Code: X.4.8 179 o Summary: retry on IPv4 181 o Associated basic status code: 421,451 182 o Description: the mail system will not accept this message over 183 IPv6 because it lacks some requirments described in the full text 184 of the rejection, however the sending mail system can retry 185 immediately to submit the message over IPv4 only. 187 6. Security Considerations 189 SMTP clients might not not fall back to IPv4 when requested (by not 190 implementing this proposal) and keep retrying on IPv6. MTA 191 administrators ought to monitor for such servers, and could whitelist 192 them to accept messages over IPv6 or take other action as 193 appropriate. 195 Messages may start to queue on the sender-SMTP side and the mail 196 administrator may not notice them or take appropriate action in time. 198 If the policy is not explained clearly the mail administrator may not 199 know what is required to pass the policy. 201 If the policy is to cumbersome and is not based on widely adopted 202 standards and recommendations, the mail administrator may decide not 203 to jump through hoops to get the email delivered. 205 Some SMTP clients may fail completely when the MX points to an 206 hostname with only an AAAA RR, therefore it is preferred that any 207 hostname with an AAAA record be dual stacked, ie. have an A RR too. 209 7. References 211 7.1. Normative References 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, March 1997. 216 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 217 for Authorizing Use of Domains in E-Mail, Version 1", RFC 218 4408, April 2006. 220 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 221 Mail System Status Codes", BCP 138, RFC 5248, June 2008. 223 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 224 October 2008. 226 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 227 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 228 September 2011. 230 [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) 231 Authentication Failure Reporting Using the Abuse Reporting 232 Format", RFC 6652, June 2012. 234 7.2. Informative References 236 [RFC3974] Nakamura, M. and J. Hagino, "SMTP Operational Experience 237 in Mixed IPv4/v6 Environments", RFC 3974, January 2005. 239 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 240 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 241 May 2008. 243 Appendix A. Examples and research 245 A.1. SMTP fall back from IPv6 to IPv4 247 The sender-SMTP server opens a connection to the receiver-SMTP 248 example.org over IPv6, the message is refused because no domain 249 authentication can be performed therefore the sender-SMTP retries 250 immediately using IPv4. "S" indicates text sent by a server, and "C" 251 indicates text sent by a client. Line terminations are omitted in 252 this illustration. 254 S: 220 ipv6.example.com Simple Mail Transfer Service Ready 255 C: EHLO example.org 256 S: 250-ipv6.example.com greets example.org over IPv6 257 S: 250-8BITMIME 258 S: 250-SIZE 259 S: 250-DSN 260 S: 250 HELP 261 C: MAIL FROM: 262 S: 250 OK 263 C: RCPT TO: 264 S: 250 OK 265 C: DATA 266 S: 354 Start mail input; end with . 267 C: [message body] 268 C: . 269 S: 421 4.4.8 message with no SPF or DKIM and over IPv6 270 S: 272 S: 220 ipv4.example.com Simple Mail Transfer Service Ready 273 C: EHLO example.org 274 S: 250-ipv4.example.com greets example.org over IPv4 275 S: 250-8BITMIME 276 S: 250-SIZE 277 S: 250-DSN 278 S: 250 HELP 279 C: MAIL FROM: 280 S: 250 OK 281 C: RCPT TO: 282 S: 250 OK 283 C: DATA 284 S: 354 Start mail input; end with . 285 C: [message body] 286 C: . 287 S: 250 OK 288 C: QUIT 289 S: 221 foo.com Service closing transmission channel 291 A.2. Common Open Source MTA Design 293 This secton discusses current implementations in common open source 294 MTAs. 296 SMTP clients only interpret SMTP status codes, but the use of SMTP 297 enhanced status codes can be used to better monitor and act on the 298 reason of the temporary failure. 300 For instance, at the end of DATA, if the message was sent over IPv6, 301 the SMTP server can evalute whether the message passes SPF or DKIM 302 and reject the message using 421 if neither pass. If one passes, 303 then an authenticated domain name is available and domain reputation 304 rules can be applied. The IPv6 address of the SMTP client can be 305 noted, and futher connections over IPv6 can be temporarily failed 306 using the 451 status code for some period of time period so as to 307 minimize resources to evaluate each message after the end of DATA. 308 On the other hand, if a message coming from an IPv6 address does not 309 pass SPF or DKIM, it is unlikely that this state would quickly change 310 for the next message coming from the same network address. 312 For proprietary mail systems or large mailbox providers, they all do 313 a form of domain authentication, either SPF or DKIM, so the above may 314 not apply to them. Not all are yet enabled to send email over IPv6. 316 Some observations: 318 o When presented with a permanent failure code (5yz) during 319 connection establishment, MTA clients will declare the message non 320 deliverable and will not retry it on a different MX. Some clients 321 do retry however. 323 o When an SMTP server rejects during the connection phase using the 324 code 451 and disconnects, the SMTP client will typically retry the 325 message immediately on a different MX. 327 o When an SMTP server rejects after the DATA phase using a 421 SMTP 328 reply code followed by a disconnect, the SMTP client will retry 329 the message immediately on a different MX. 331 MX RR configuration and the proper rejection need both to be properly 332 defined. 334 A.2.1. MX RR configuration 336 When a message is temporarily refused, using a 400-series SMTP error 337 code, the strategy for the SMTP client is sometimes to retry 338 immediately to a different MTA, as defined by the target selection 339 process defined in [RFC5321]. 341 When the new MX refers to a dual-stacked machine (see [RFC3974]), 342 some MTA software will not pick up all of the A or AAAA RRs (Resource 343 Records), but will instead select only the RRs matching the address 344 family preferred by the local TCP/IP implementation. Thus, MX RRs 345 MUST have at least one record of the highest priority pointing to a 346 single-stack machine with an A RR only. 348 For instance, the following configuration is desired: 350 example.org. IN MX 10 mx1.example.org. 351 IN MX 10 mx2.example.org. 352 mx1.example.org. IN A 192.0.2.1 353 mx2.example.org. IN A 192.0.2.2 354 mx2.example.org. IN AAAA 2001:db8:ffff::2 356 In this configuration, the SMTP client see two MXes at the same 357 preference, and will automatically pick one and try the other one if 358 the message is properly temp-failed. Therefore, in the above 359 example, if the first connection was over IPv6 and the message 360 temporarly refused and the session disconnected, the next connection 361 will be over IPv4. 363 A.2.2. Rejecting Messages for Immediate Retry on IPv4 365 Here is an example of an initial message sent over IPv6. The SMTP 366 client then retries immediately on the next MX record, here an IPv4 367 address. "S" indicates text sent by a server, and "C" indicates text 368 sent by a client. Line terminations are omitted in this 369 illustration. 371 C: 372 S: 220 example.net Simple Mail Transfer Service Ready 373 C: EHLO example.com 374 S: 250-example.net greets example.com over IPv6 375 S: 250-8BITMIME 376 S: 250-SIZE 377 S: 250-DSN 378 S: 250 HELP 379 C: MAIL FROM: 380 S: 250 OK 381 C: RCPT TO: 382 S: 250 OK 383 C: DATA 384 S: 354 Start mail input; end with . 385 C: 386 C: . 387 S: 421 4.4.8 SPF and/or DKIM required on IPv6; try elsewhere 388 C: QUIT 389 S: 221 foo.com Service closing transmission channel 391 Where the client is known to not use DKIM and/or SPF, the server may 392 terminate the connection immediately: 394 C: 395 S: 451 4.4.8 Come back on IPv4 as I told you before 397 Authors' Addresses 399 Franck Martin (editor) 400 LinkedIn 401 Mountain View, CA 402 US 404 Email: fmartin@linkedin.com 406 Alec Peterson (editor) 407 Message Systems 408 Columbia, MD 409 US 411 Email: alec@messagesystems.com