idnits 2.17.1 draft-viruthagiri-email-address-length-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Dec 04, 2019) is 1604 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Viruthagiri Thirumavalavan 3 Intended Status: Proposed Standard Dombox, Inc. 4 Expires: Jun 04, 2020 Dec 04, 2019 6 SMTP Extension for Longer Email Address 7 draft-viruthagiri-email-address-length-01 9 Abstract 11 This memo defines an SMTP extension with keyword "EAML" whereby an 12 SMTP server can declare that it is capable of handling longer email 13 addresses without any local-part or domain-part restriction set by 14 RFC 5321. 16 EAML stands for "Email Address Maximum Length". 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Relaxing the local-part limitation . . . . . . . . . . . . . . 4 59 4. Relaxing the domain-part limitation . . . . . . . . . . . . . . 5 60 5. Framework for the EAML Extension . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 66 Appendix A. Variable Envelope Return Path (VERP) . . . . . . . . . 8 67 Appendix B. Sender Rewriting Scheme (SRS) . . . . . . . . . . . . 10 68 Appendix C. Email Address Types . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Definitions 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 75 "OPTIONAL" in this document are to be interpreted as described in 76 [RFC2119]. 78 The term "character" in this document refers to an "octet character". 80 2 Background 82 [RFC5321], Section 4.5.3.1.3 says: 84 +-------------------------------------------------------------------+ 85 | | 86 | The maximum total length of a reverse-path or forward-path is | 87 | 256 octets (including the punctuation and element separators). | 88 | | 89 +-------------------------------------------------------------------+ 91 [RFC5321], Section 4.1.2 defines the path as: 93 +-------------------------------------------------------------------+ 94 | | 95 | Path = "<" [ A-d-l ":" ] Mailbox ">" | 96 | | 97 +-------------------------------------------------------------------+ 99 So the path will contain at least a pair of angle brackets in 100 addition to the Mailbox. This limits the Mailbox (i.e. the email 101 address) to 254 characters. 103 [RFC5321], Section 4.5.3.1 says: 105 +-------------------------------------------------------------------+ 106 | | 107 | To the maximum extent possible, implementation techniques that | 108 | impose no limits on the length of these objects should be used. | 109 | | 110 +-------------------------------------------------------------------+ 112 From a receiving server perspective, 254 maximum characters 113 limitation is a "SOFT LIMIT" as per RFC 5321. i.e. A receiving server 114 MUST support AT LEAST 254 maximum character email address. 116 While 254 characters is enough for RCPT TO email addresses, it's not 117 enough for MAIL FROM addresses due to the widespread usage of 118 Variable Envelope Return Path (VERP). 120 Bulk mailing systems use VERP for automatic bounce handling. For 121 example, an end user subscribes to a list with 254 character email 122 address which is a valid email address, but the rewritten VERP 123 address would go beyond 254 characters. 125 In most cases, VERP addresses would not go beyond 254 characters. 126 However local-part of VERP addresses would easily go beyond 64 127 characters. So this memo's primary concern is local-part 64 character 128 limitation. 130 There is no standard way for a client to know whether a receiving 131 server sticks to the 64 characters local-part limit or not. 133 Also there is no standard way for a client to know whether a 134 receiving server supports email addresses that go beyond 254 135 characters. e.g. Gmail supports 900 character email addresses. 137 To address such issues, this memo defines an SMTP extension with 138 keyword "EAML". The framework is defined in Section 5. 140 3. Relaxing the local-part limitation 142 [RFC5321], Section 4.5.3.1.1 says: 144 +-------------------------------------------------------------------+ 145 | | 146 | The maximum total length of a user name or other local-part | 147 | is 64 octets. | 148 | | 149 +-------------------------------------------------------------------+ 151 Variable Envelope Return Path (VERP) and Sender Rewriting Scheme 152 (SRS) are the two perfect examples where 64 character local-part 153 limit actually causes issues. VERP and SRS are explained in Appendix 154 A. and Appendix B. respectively. 156 Both VERP and SRS are designed to handle bounces. So the primary 157 motivation for relaxing 64 character local-part limitation is to have 158 better bounce handling. 160 A bounce message or just "bounce" is an automated message from an 161 email system, informing the sender that the message had not been 162 delivered (or some other delivery problem occurred). The original 163 message is said to have "bounced". More formal terms for bounce 164 message include "Non-Delivery Report" or "Non-Delivery Receipt" 165 (NDR), "Delivery Status Notification" (DSN) message, or a "Non- 166 Delivery Notification" (NDN). 168 A "bounce address" is also known as MAIL FROM, Return Path, Reverse 169 Path, Envelope From, Envelope Sender etc. 171 This memo relaxes the local-part limitation explicitly with the help 172 of EAML extension. 174 If overall email address length can be defined as "n", then the 175 maximum total length of local-part is "n-2" characters. We allocated 176 1 character for the "@" symbol and 1 character for the minimum 177 possible domain-part length. Note: We are using user@host address 178 type for calculating this number. Refer Appendix C. for more info. 180 4. Relaxing the domain-part limitation 182 [RFC5321], Section 4.5.3.1.2 says: 184 +-------------------------------------------------------------------+ 185 | | 186 | The maximum total length of a domain name or number is 255 | 187 | octets. | 188 | | 189 +-------------------------------------------------------------------+ 191 Since the maximum total length of an email address is 254 characters, 192 the domain-part limitation of 255 characters is flawed and redundant. 194 It's flawed because, any such limitation should be less than overall 195 email address length. 197 i.e. domain-part length < overall email address length 199 It's redundant because, any email address that has 255 domain 200 characters already an invalid email address due to overall email 201 address length 254 characters. [We are assuming the server sticks to 202 the default limit] 204 This memo relaxes the domain-part limitation explicitly with the help 205 of EAML extension. 207 If overall email address length can be defined as "n", then the 208 maximum total length of a domain name is "n-2" characters. We 209 allocated 1 character for the "@" symbol and 1 character for the 210 minimum possible local-part length. 212 Just to be clear, 214 [RFC1034], Section 3.5 says, A domain label must be 63 characters or 215 less. For example, www.example.com contains 3 labels. i.e. www, 216 example and com. 218 This memo relaxes only the domain-part soft limitation set by 219 [RFC5321]. Not the domain label hard limitation set by [RFC1034]. 221 5. Framework for the EAML Extension 223 The following service extension is defined: 225 (1) The name of the SMTP service extension is "Email Address Maximum 226 Length"; 228 (2) The EHLO keyword value associated with this extension is "EAML"; 230 (3) One OPTIONAL parameter is allowed with this EHLO keyword value, 231 a three digit decimal number indicating the maximum email 232 address length in octets that the server will accept. 234 (4) [RFC5322] header field data is still acceptable to 1000 235 characters. i.e. 998+EOL. where EOL refers to the control codes 236 . Carriage Return and Line Feed. In order to avoid 237 hitting that limit and give some room for header keys, EAML 238 parameter value MUST NOT be greater than 900. i.e. 900 octets is 239 the maximum allowed email address length. 241 (5) The parameter value SHOULD be from 254-900 (inclusive). 243 S: 220 smtp.example.com ESMTP Ready 244 C: EHLO bob.example.org 245 S: 250-smtp.example.com 246 S: 250-EXPN 247 S: 250-EAML 500 248 S: 250-PIPELINING 249 S: 250 HELP 251 (6) The syntax of the parameter is as follows, using the ABNF 252 notation of [RFC5322]: 254 eaml-param ::= [ 3DIGIT ] 256 (7) If the parameter is omitted or the parameter value is 0-253 257 (inclusive) or the value is greater than 900, then the value 258 MUST be treated as 254. 260 (8) Servers offering this extension MUST remove the 64 characters 261 local-part limit. That effectively means, maximum characters 262 allowed in local-part is n-2. Where n is the EAML parameter 263 value. 265 (9) Servers offering this extension MUST remove the 255 characters 266 domain-part limit. That effectively means, maximum characters 267 allowed in domain-part is n-2. Where n is the EAML parameter 268 value. 270 (10) The parameter value is OPTIONAL. 272 S: 220 smtp.example.com ESMTP Ready 273 C: EHLO bob.example.org 274 S: 250-smtp.example.com 275 S: 250-EXPN 276 S: 250-EAML 277 S: 250-PIPELINING 278 S: 250 HELP 280 (11) The parameter omitted EAML keyword says: 282 [*] No local-part limitation. 283 [*] No domain-part limitation. 284 [*] 254 maximum characters 286 (12) No additional SMTP verbs are defined by this extension. 288 6. IANA Considerations 290 IANA is hereby requested to register the EAML extension. 292 7. Security Considerations 294 This RFC does not discuss security issues and is not believed to 295 raise any security issues not already endemic in electronic mail and 296 present in fully conforming implementations of SMTP. 298 8. References 300 8.1. Normative References 302 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 303 DOI 10.17487/RFC5321, October 2008, . 306 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 307 10.17487/RFC5322, October 2008, . 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, DOI 312 10.17487/RFC2119, March 1997, . 315 8.2. Informative References 317 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 318 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 319 . 321 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 322 for Delivery Status Notifications", RFC 3464, DOI 323 10.17487/RFC3464, January 2003, . 326 [VERWIKI] Wikipedia, "Variable envelope return path", December 2019, 327 . 330 [SRSWIKI] Wikipedia, "Sender Rewriting Scheme", December 2019, 331 . 334 [VERP] Bernstein, D., "Variable Envelope Return Paths", February 335 1997, . 337 [SRS] Shevek, "The Sender Rewriting Scheme", June 2004, 338 . 340 Appendix A. Variable Envelope Return Path (VERP) 342 Most bounce messages have historically been designed to be read by 343 human users, not automatically handled by software. They all convey 344 the same basic idea (the message from X to Y could not be delivered 345 because of reason Z) but with so many variations that it would be 346 nearly impossible to write a program to reliably interpret the 347 meaning of every bounce message. [RFC3464] defines a standard format 348 to fix this problem, but support for the standard is far from 349 universal. 351 VERP solves the bounce handling problem. 353 The hard part of bounce handling is matching up a bounce message with 354 the undeliverable address that caused the bounce. If the mailing list 355 software can see that a bounce resulted from an attempt to send a 356 message to user@example.com then it doesn't need to understand the 357 rest of the information in the bounce. It can simply count how many 358 messages were recently sent to user@example.com, and how many bounces 359 resulted, and if the proportion of bounced messages is too high, the 360 address is removed from the list. 362 While bounce message formats in general vary wildly, there is one 363 aspect of a bounce message that is highly predictable: the address to 364 which it will be sent. VERP takes full advantage of this. In a 365 mailing list that uses VERP, a different MAIL FROM address is used 366 for each recipient. 368 The mailing list manager knows that it sent a message from X to Y, so 369 if a bounce message is received at address X, it can only be because 370 address Y was undeliverable, because nothing was sent from X to any 371 other address. Thus the important information has been extracted from 372 the bounce message, without any need to understand its contents, 373 which means the person in charge of the list does not need to deal 374 with it manually. 376 Typically, an email from Alice to Bob in the above example will have 377 headers like the following: 379 +-------------------------------------------------------------------+ 380 | | 381 | From: alice@example.org | 382 | To: bob@example.com | 383 | Return-Path: bounces@example.org | 384 | | 385 +-------------------------------------------------------------------+ 387 A very simple VERP address for a mail to bob@example.com will be: 389 +-------------------------------------------------------------------+ 390 | | 391 | MAIL FROM: | 392 | | 393 +-------------------------------------------------------------------+ 395 bob is a 3 character local-part, so there won't be any issues. 397 Let's just assume a user with 62 character local-part subscribe to 398 the list. 400 A normal mail would look like this. 402 +-------------------------------------------------------------------+ 403 | | 404 | From: alice@mailchimp.com | 405 | To: this-electronic-mail-address-local-part- | 406 | contains-62-characters@example.com | 407 | Return-Path: bounces@example.org | 408 | | 409 +-------------------------------------------------------------------+ 411 The [VERP] address would look like: 413 +-------------------------------------------------------------------+ 414 | | 415 | MAIL FROM: | 417 | | 418 +-------------------------------------------------------------------+ 420 Above VERP address local-part contains 82 characters. If example.com 421 sticks to the RFC 5321 local-part limit 64 characters, then the above 422 VERP address structure won't work. 424 [VERP] was introduced by Daniel J. Bernstein in 1997 and today many 425 software supports VERP. 427 To name a few, 429 AmazonSES, CiviCRM, Courier Mail Server, Discourse, exim, ezmlm, GNU 430 Mailman, Inxmail, Mercury Mail Transport System, mlmmj, Mahara, 431 Mailchimp, MediaWiki, Moodle, postfix, qmail, Sendmail, STEdb, 432 StrongMail, Sympa, Thexyz, Zimbra, Target Box, NotifyBC. 434 See Wikipedia's page [VERWIKI] to learn more about VERP. 436 Appendix B. Sender Rewriting Scheme (SRS) 438 Sender Rewriting Scheme ([SRS]) is a scheme for rewriting the 439 envelope sender address of an email message, in view of remailing it. 440 In this context, remailing is a kind of email forwarding. SRS was 441 devised in order to forward email without breaking the Sender Policy 442 Framework (SPF), back in 2003. 444 [SRS] is a form of variable envelope return path ([VERP]) inasmuch as 445 it encodes the original envelope sender in the local part of the 446 rewritten address. Consider example.com forwarding a message 447 originally destined to bob@example.com to his new address 448 449 +-------------------------------------------------------------------+ 450 | | 451 | ORIGINAL | 452 | envelope sender: alice@example.org | 453 | envelope recipient: bob@example.com | 454 | | 455 | REWRITTEN | 456 | envelope sender: SRS0=HHH=TT=example.org=alice@example.com | 457 | envelope recipient: bob@example.net | 458 | | 459 +-------------------------------------------------------------------+ 461 With respect to VERP, the local part (alice) is moved after her 462 domain name (example.org), further adding a prefix (SRS0), a hash 463 (HHH), and a timestamp (TT) 465 SRS provides for another prefix, SRS1, to be used for rewriting an 466 already rewritten address, in a multi-hop scenario. If example.net 467 has to forward the message in turn, it can spare adding another 468 timestamp and repeating the original local part (alice). That is, 469 each new forwarder adds just its own hash (HHH) and the domain name 470 of the preceding forwarder: 472 +-------------------------------------------------------------------+ 473 | | 474 | FURTHER REWRITTEN | 475 | envelope sender: SRS1=HHH=example.com==HHH=TT=example.org | 476 | =alice@example.net | 477 | envelope recipient: bob@further.example | 478 | | 479 +-------------------------------------------------------------------+ 481 SRS1 incorporates 2 domains in the local-part. So 64 characters are 482 not enough. 484 See Wikipedia's page [SRSWIKI] to learn more about SRS. 486 Appendix C. Email Address Types 488 _INFORMATIONAL_: 490 The term "email address" is a generic term. It can refer to an 491 Internet address, Intranet address, X.400 address etc. 493 Internet Address: 495 An email address on the Internet would look like a@b.c 496 e.g. john@example.com [user@domain] 498 Intranet Address: 500 An email address on the Intranet may look like a@b 501 e.g. alice@machine50 [user@host] 503 X.400 Address: 505 An X.400 address is technically referred to as an 506 Originator/Recipient (OR) address. It consists of several 507 elements, including: 509 C (Country name) 510 ADMD (Administration Management Domain, short-form A), 511 usually a public mail service provider 512 PRMD (Private Management Domain, short-form P) 513 O (Organization name) 514 OU (Organizational Unit Names), OU is equivalent to OU0, 515 can have OU1, OU2... 516 G (Given name) 517 I (Initials) 518 S (Surname) 520 e.g. G=Harald;S=Alvestrand;O=Uninett;PRMD=Uninett;A=;C=no 522 IP address Literal: 524 jsmith@[192.168.2.1] 525 jsmith@[IPv6:2001:db8::1] 527 Authors' Addresses 529 Viruthagiri Thirumavalavan 530 Dombox, Inc. 532 EMail: giri@dombox.org