idnits 2.17.1 draft-viruthagiri-email-address-length-00.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 (Nov 26, 2019) is 1611 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) == Missing Reference: '3DIGIT' is mentioned on line 577, but not defined ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 1869 (Obsoleted by RFC 2821) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 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: May 26, 2020 Nov 26, 2019 6 Email Address Length 7 draft-viruthagiri-email-address-length-00 9 Abstract 11 This memo formally defines the overall email address maximum length 12 to 254 characters (octets); 14 Relaxes local-part limitation set by RFC 821/2821/5321; 16 Obsoletes domain-part limitation set by RFC 821/2821/5321; AND 18 Uses the mechanism described in RFC 1869 to define an extension with 19 keyword "EAML" to the SMTP service whereby an SMTP server can declare 20 that it is capable of handling longer email addresses. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Maximum Length . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Minimum Length . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Obsoleting domain-part limitation . . . . . . . . . . . . . . . 6 65 6. Relaxing local-part limitation . . . . . . . . . . . . . . . . 7 66 6.1. Variable Envelope Return Path (VERP) . . . . . . . . . . . 7 67 6.2. Sender Rewriting Scheme (SRS) . . . . . . . . . . . . . . . 9 68 6.3. Receiving Servers . . . . . . . . . . . . . . . . . . . . . 10 69 6.4. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 6.5. Form Inputs . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7. Framework for the Email Address Maximum Length Extension . . . 12 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Definitions 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 83 "OPTIONAL" in this document are to be interpreted as described in 84 [RFC2119]. 86 The term "character" in this document refers to an "octet character". 88 2 Background 90 [RFC3696], an informational RFC says: 92 +-------------------------------------------------------------------+ 93 |In addition to restrictions on syntax, there is a length limit on | 94 |email addresses. That limit is a maximum of 64 characters (octets) | 95 |in the "local part" (before the "@") and a maximum of 255 | 96 |characters (octets) in the domain part (after the "@") for a total | 97 |length of 320 characters. Systems that handle email should be | 98 |prepared to process addresses which are that long, even though they| 99 |are rarely encountered. | 100 +-------------------------------------------------------------------+ 102 Both [RFC821] and [RFC2821] says: 104 +-------------------------------------------------------------------+ 105 |The maximum total length of a reverse-path or forward-path is 256 | 106 |characters (including the punctuation and element separators). | 107 +-------------------------------------------------------------------+ 109 [RFC5321] updated that part with the following text: 111 +-------------------------------------------------------------------+ 112 |The maximum total length of a reverse-path or forward-path is 256 | 113 |octets (including the punctuation and element separators). | 114 +-------------------------------------------------------------------+ 116 To comply with [RFC5321] / [RFC2821] / [RFC821], John C. Klensin, the 117 author of RFC3696, filed Errata [1003] with the following text: 119 +-------------------------------------------------------------------+ 120 |In addition to restrictions on syntax, there is a length limit on | 121 |email addresses. That limit is a maximum of 64 characters (octets) | 122 |in the "local part" (before the "@") and a maximum of 255 | 123 |characters (octets) in the domain part (after the "@") for a total | 124 |length of 320 characters. However, there is a restriction in | 125 |RFC 2821 on the length of an address in MAIL and RCPT commands of | 126 |256 characters. Since addresses that do not fit in those fields are| 127 |not normally useful, the upper limit on address lengths should | 128 |normally be considered to be 256. | 129 +-------------------------------------------------------------------+ 131 There is one issue however. [RFC5321] / [RFC2821] / [RFC821] places 132 the 256 character limit on the path. A path is defined as 134 Path = "<" [ A-d-l ":" ] Mailbox ">" 136 So the forward-path will contain at least a pair of angle brackets in 137 addition to the Mailbox. This limits the Mailbox (i.e. the email 138 address) to 254 characters. 140 To correct that issue, Dominic Sayers filed Errata [1690] and updated 141 that part with the following text: 143 +-------------------------------------------------------------------+ 144 |In addition to restrictions on syntax, there is a length limit on | 145 |email addresses. That limit is a maximum of 64 characters (octets)| 146 |in the "local part" (before the "@") and a maximum of 255 | 147 |characters (octets) in the domain part (after the "@") for a total | 148 |length of 320 characters. However, there is a restriction in | 149 |RFC 2821 on the length of an address in MAIL and RCPT commands of | 150 |254 characters. Since addresses that do not fit in those fields are| 151 |not normally useful, the upper limit on address lengths should | 152 |normally be considered to be 254. | 153 +-------------------------------------------------------------------+ 155 3. Maximum Length 157 The Maximum Length for an email address is 159 +-------------------------------------------------------------------+ 160 | | 161 | 254 Characters | 162 | | 163 +-------------------------------------------------------------------+ 165 Refer Section 2 for more info. 167 This Maximum Length is a "HARD LIMIT" for end user form inputs. e.g. 168 Websites, Mobile Apps, Gaming Consoles, Smart TVs, Smart Watches, 169 Printers, DSLR cameras etc. 171 But this is a "SOFT LIMIT" for Receiving Servers. i.e. A receiving 172 server MUST support AT LEAST 254 maximum character email address. A 173 receiving server can extend this limit with the help of EAML SMTP 174 extension. EAML SMTP extension is defined in Section 7. 176 4. Minimum Length 178 The Minimum Length for an email address is 180 +-------------------------------------------------------------------+ 181 | | 182 | 5 Characters | 183 | | 184 +-------------------------------------------------------------------+ 186 The "Minimum Length" in this section applicable only to DNS-based 187 email addresses. i.e. The sender performs a DNS lookup to fetch MX 188 records before transmitting the mail. 190 The minimum length in this section applicable only to end user form 191 inputs. 193 _INFORMATIONAL_: 195 The term "email address" is a generic term. It can refer to an 196 Internet address, Intranet address, X.400 address etc. 198 Internet Address: 200 An email address on the Internet would look like a@b.c 201 e.g. john@example.com [user@domain] 203 Intranet Address: 205 An email address on the Intranet may look like a@b 206 e.g. alice@machine50 [user@host] 208 X.400 Address: 210 An X.400 address is technically referred to as an 211 Originator/Recipient (OR) address. It consists of several 212 elements, including: 214 C (Country name) 215 ADMD (Administration Management Domain, short-form A), 216 usually a public mail service provider 217 PRMD (Private Management Domain, short-form P) 218 O (Organization name) 219 OU (Organizational Unit Names), OU is equivalent to OU0, 220 can have OU1, OU2... 221 G (Given name) 222 I (Initials) 223 S (Surname) 225 e.g. G=Harald;S=Alvestrand;O=Uninett;PRMD=Uninett;A=;C=no 227 IP address Literal: 229 jsmith@[192.168.2.1] 230 jsmith@[IPv6:2001:db8::1] 232 5. Obsoleting domain-part limitation 234 [RFC821] says: 236 +-------------------------------------------------------------------+ 237 |The maximum total length of a domain name or number is 64 | 238 |characters. | 239 +-------------------------------------------------------------------+ 241 [RFC2821] updated that part with the following text: 243 +-------------------------------------------------------------------+ 244 |The maximum total length of a domain name or number is 255 | 245 |characters. | 246 +-------------------------------------------------------------------+ 248 [RFC5321] updated that part again with the following text: 250 +-------------------------------------------------------------------+ 251 |The maximum total length of a domain name or number is 255 | 252 |octets. | 253 +-------------------------------------------------------------------+ 255 Since the maximum total length of an email address is 254 characters, 256 the domain-part limitation of 255 characters is flawed and redundant. 258 It's flawed because, any such limitation should be less than overall 259 email address length. 261 i.e. domain-part length < overall email address length 263 It's redundant because, any email address that has 255 domain 264 characters already an invalid email address due to overall email 265 address length 254 characters. 267 So this document obsoletes that limitation. 269 If overall email address length can be defined as "n", then the 270 maximum total length of a domain name or number is "n-2" characters. 271 We allocated 1 character for the "@" symbol and 1 character for the 272 minimum possible local-part length. 274 6. Relaxing local-part limitation 276 [RFC821] says: 278 +-------------------------------------------------------------------+ 279 |The maximum total length of a user name is 64 characters. | 280 +-------------------------------------------------------------------+ 282 [RFC2821] updated that part with the following text: 284 +-------------------------------------------------------------------+ 285 |The maximum total length of a user name or other local-part is 64 | 286 |characters. | 287 +-------------------------------------------------------------------+ 289 [RFC5321] updated that part again with the following text: 291 +-------------------------------------------------------------------+ 292 |The maximum total length of a user name or other local-part is 64 | 293 |octets. | 294 +-------------------------------------------------------------------+ 296 This document relaxes the local-part limitation for the reasons found 297 in section 6.1 and 6.2 299 6.1. Variable Envelope Return Path (VERP) 301 Most bounce messages have historically been designed to be read by 302 human users, not automatically handled by software. They all convey 303 the same basic idea (the message from X to Y could not be delivered 304 because of reason Z) but with so many variations that it would be 305 nearly impossible to write a program to reliably interpret the 306 meaning of every bounce message. RFC 1894 (obsoleted by RFC 3464) 307 defines a standard format to fix this problem, but support for the 308 standard is far from universal. 310 [VERP] solves the bounce handling problem. 312 The hard part of bounce handling is matching up a bounce message with 313 the undeliverable address that caused the bounce. If the mailing list 314 software can see that a bounce resulted from an attempt to send a 315 message to user@example.com then it doesn't need to understand the 316 rest of the information in the bounce. It can simply count how many 317 messages were recently sent to user@example.com, and how many bounces 318 resulted, and if the proportion of bounced messages is too high, the 319 address is removed from the list. 321 While bounce message formats in general vary wildly, there is one 322 aspect of a bounce message that is highly predictable: the address to 323 which it will be sent. VERP takes full advantage of this. In a 324 mailing list that uses VERP, a different MAIL FROM address is used 325 for each recipient. 327 The mailing list manager knows that it sent a message from X (MAIL 328 FROM) to Y (RCPT TO), so if a bounce message is received at address X 329 (MAIL FROM), it can only be because address Y (RCPT TO) was 330 undeliverable, because nothing was sent from X (MAIL FROM) to any 331 other address. Thus the important information has been extracted from 332 the bounce message, without any need to understand its contents, 333 which means the person in charge of the list does not need to deal 334 with it manually. 336 Typically, an email from Alice to Bob in the above example will have 337 headers like the following: 339 +-------------------------------------------------------------------+ 340 |From: alice@example.org | 341 |To: bob@example.com | 342 |Return-Path: bounces@example.org | 343 +-------------------------------------------------------------------+ 345 A very simple VERP address for a mail to bob@example.com will be: 347 +-------------------------------------------------------------------+ 348 |MAIL FROM: | 349 +-------------------------------------------------------------------+ 351 bob is a 3 character local-part, so there won't be any issues. 353 Let's just assume a user with 62 character local-part subscribe to 354 the list. 356 A normal mail would look like this. 358 +-------------------------------------------------------------------+ 359 |From: alice@mailchimp.com | 360 |To: this-electronic-mail-address-local-part- | 361 | contains-62-characters@example.com | 362 |Return-Path: bounces@example.org | 363 +-------------------------------------------------------------------+ 365 The [VERP] address would look like: 367 +-------------------------------------------------------------------+ 368 |MAIL FROM: | 370 +-------------------------------------------------------------------+ 372 Above [VERP] address local-part contains 82 characters. If 373 example.com sticks to the RFC limit 64 characters, then the above 374 VERP address structure won't work. 376 [VERP] was introduced by Daniel J. Bernstein in 1997 and today many 377 software supports VERP. 379 To name a few, 381 AmazonSES, CiviCRM, Courier Mail Server, Discourse, exim, ezmlm, GNU 382 Mailman, Inxmail, Mercury Mail Transport System, mlmmj, Mahara, 383 Mailchimp, MediaWiki, Moodle, postfix, qmail, Sendmail, STEdb, 384 StrongMail, Sympa, Thexyz, Zimbra, Target Box, NotifyBC 386 6.2. Sender Rewriting Scheme (SRS) 388 Sender Rewriting Scheme ([SRS]) is a scheme for rewriting the 389 envelope sender address of an email message, in view of remailing it. 390 In this context, remailing is a kind of email forwarding. SRS was 391 devised in order to forward email without breaking the Sender Policy 392 Framework (SPF), back in 2003. 394 [SRS] is a form of variable envelope return path ([VERP]) inasmuch as 395 it encodes the original envelope sender in the local part of the 396 rewritten address. Consider example.com forwarding a message 397 originally destined to bob@example.com to his new address 398 400 +-------------------------------------------------------------------+ 401 |ORIGINAL | 402 |envelope sender: alice@example.org | 403 |envelope recipient: bob@example.com | 404 | | 405 |REWRITTEN | 406 |envelope sender: SRS0=HHH=TT=example.org=alice@example.com | 407 |envelope recipient: bob@example.net | 408 +-------------------------------------------------------------------+ 410 With respect to VERP, the local part (alice) is moved after her 411 domain name (example.org), further adding a prefix (SRS0), a hash 412 (HHH), and a timestamp (TT) 413 SRS provides for another prefix, SRS1, to be used for rewriting an 414 already rewritten address, in a multi-hop scenario. If example.net 415 has to forward the message in turn, it can spare adding another 416 timestamp and repeating the original local part (alice). That is, 417 each new forwarder adds just its own hash (HHH) and the domain name 418 of the preceding forwarder: 420 +-------------------------------------------------------------------+ 421 |FURTHER REWRITTEN | 422 |envelope sender: SRS1=HHH=example.com==HHH=TT=example.org | 423 | =alice@example.net | 424 |envelope recipient: bob@further.example | 425 +-------------------------------------------------------------------+ 427 SRS1 incorporates 2 domains in the local-part. So 64 characters are 428 not enough. 430 6.3. Receiving Servers 432 [RFC821], Section 4.5.3. says: 434 +-------------------------------------------------------------------+ 435 |There are several objects that have required minimum maximum | 436 |sizes. That is, every implementation must be able to receive | 437 |objects of at least these sizes, but must not send objects | 438 |larger than these sizes. | 439 +-------------------------------------------------------------------+ 441 +-------------------------------------------------------------------+ 442 | | 443 | TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION | 444 | TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH | 445 | OF THESE OBJECTS SHOULD BE USED. | 446 | | 447 +-------------------------------------------------------------------+ 449 [RFC2821], Section 4.5.3.1 says: 451 +-------------------------------------------------------------------+ 452 |There are several objects that have required minimum/maximum sizes.| 453 |Every implementation MUST be able to receive objects of at least | 454 |these sizes. Objects larger than these sizes SHOULD be avoided when| 455 |possible. However, some Internet mail constructs such as encoded | 456 |X.400 addresses will often require larger objects: clients MAY | 457 |attempt to transmit these, but MUST be prepared for a server to | 458 |reject them if they cannot be handled by it. To the maximum extent | 459 |possible, implementation techniques which impose no limits on the | 460 |length of these objects should be used. | 461 +-------------------------------------------------------------------+ 463 [RFC5321], Section 4.5.3.1 says: 465 +-------------------------------------------------------------------+ 466 |There are several objects that have required minimum/maximum sizes.| 467 |Every implementation MUST be able to receive objects of at least | 468 |these sizes. Objects larger than these sizes SHOULD be avoided when| 469 |possible. However, some Internet mail constructs such as encoded | 470 |X.400 addresses (RFC 2156) will often require larger objects. | 471 |Clients MAY attempt to transmit these, but MUST be prepared for a | 472 |server to reject them if they cannot be handled by it. To the | 473 |maximum extent possible, implementation techniques that impose no | 474 |limits on the length of these objects should be used. Extensions | 475 |to SMTP may involve the use of characters that occupy more | 476 |than a single octet each. This section therefore specifies lengths| 477 |in octets where absolute lengths, rather than character counts, are| 478 |intended. | 479 +-------------------------------------------------------------------+ 481 So the 64 character local-part limitation is a "SOFT LIMIT" for 482 receiving servers. i.e. A receiving server MUST support AT LEAST 64 483 maximum characters in the local-part. 485 A receiving server SHOULD remove the local-part 64 character 486 limitation whenever possible. 488 A receiving server can explicitly inform the client that it do not 489 perform the local-part 64 character limitation check with the help of 490 EAML SMTP extension. EAML SMTP extension is defined in Section 7. 492 6.4. Clients 494 The primary motivation for relaxing 64 character local-part 495 limitation is to have better bounce handling. Both VERP and SRS are 496 designed to handle bounces. 498 A bounce message or just "bounce" is an automated message from an 499 email system, informing the sender that the message had not been 500 delivered (or some other delivery problem occurred). The original 501 message is said to have "bounced". More formal terms for bounce 502 message include "Non-Delivery Report" or "Non-Delivery Receipt" 503 (NDR), "Delivery Status Notification" (DSN) message, or a "Non- 504 Delivery Notification" (NDN). 506 A "bounce address" is also known as MAIL FROM, Return Path, Reverse 507 Path, Envelope From, Envelope Sender etc. 509 As mentioned in [RFC2821] and [RFC5321], a client MAY attempt to 510 transmit longer email addresses, but MUST be prepared for a server to 511 reject them if they cannot be handled by it. 513 6.5. Form Inputs 515 Form Inputs (e.g. Web registration form) rarely check whether the 516 local-part contains 64 characters or not. However, there is a small 517 number of applications certainly do check the local-part character 518 limit. 520 For example, Embedded Applications (e.g. software found in a DSLR 521 camera), cannot upgrade this limit even if we completely remove that 522 limitation. (We are assuming they already force this 64 character 523 limit) 525 As mentioned in the last section, the primary motivation for relaxing 526 64 character local-part limitation is to have better bounce handling. 527 i.e. The MAIL FROM address. 529 Form inputs however, deals with the RCPT TO address. It is very rare 530 for an end user to have a genuine email address like 532 this-electronic-mail-address-local-part-contains-62- 533 characters@example.com 535 For backward-compatibility reasons, this document doesn't mandate 536 removing the local-part limitation for end user form inputs. 538 However, any kind of end user form inputs SHOULD remove the local- 539 part 64 character limitation WHENEVER POSSIBLE. 541 7. Framework for the Email Address Maximum Length Extension 543 This extension is based on the standard SMTP "Service Extensions" 544 described in [RFC1869]. 546 The following service extension is defined: 548 (1) The name of the SMTP service extension is "Email Address Maximum 549 Length"; 551 (2) The EHLO keyword value associated with this extension is "EAML"; 553 (3) One OPTIONAL parameter is allowed with this EHLO keyword value, 554 a decimal number indicating the maximum email address length in 555 octets that the server will accept. 557 (4) [RFC822] / [RFC2822] / [RFC5322] header field data is still 558 acceptable to 1000, 998+EOL, where EOL in the SMTP protocol are 559 the control codes, , carriage return, linefeed. In order 560 to avoid hitting that limit and give some room for header keys, 561 EAML parameter value MUST NOT be greater than 900. i.e. 900 562 octets is the maximum allowed email address length. 564 (5) The parameter value SHOULD be from 254-900 (inclusive). 566 S: 220 smtp.example.com ESMTP Ready 567 C: EHLO bob.example.org 568 S: 250-smtp.example.com 569 S: 250-EXPN 570 S: 250-EAML 500 571 S: 250-PIPELINING 572 S: 250 HELP 574 (6) The syntax of the parameter is as follows, using the ABNF 575 notation of [RFC5322] / [RFC2822] / [RFC822]: 577 eaml-param ::= [3DIGIT] 579 (7) If the parameter is omitted or the parameter value is 0-253 580 (inclusive) or the value is greater than 900, then the value 581 MUST be treated as 254. 583 (8) Servers offering this extension MUST remove the 64 characters 584 local-part limit. That effectively means, maximum characters 585 allowed in local-part is n-2. Where n is the EAML parameter 586 value. 588 (9) Servers offering this extension MUST remove the 255 characters 589 domain-part limit. That effectively means, maximum characters 590 allowed in domain-part is n-2. Where n is the EAML parameter 591 value. 593 (10) The parameter value is OPTIONAL. 595 S: 220 smtp.example.com ESMTP Ready 596 C: EHLO bob.example.org 597 S: 250-smtp.example.com 598 S: 250-EXPN 599 S: 250-EAML 600 S: 250-PIPELINING 601 S: 250 HELP 603 (11) The parameter omitted EAML keyword says: 605 [*] No local-part limitation. 606 [*] No domain-part limitation. 607 [*] 254 maximum characters 609 (12) No additional SMTP verbs are defined by this extension. 611 8. IANA Considerations 613 IANA is hereby requested to register the EAML extension. 615 9. Security Considerations 617 This RFC does not discuss security issues and is not believed to 618 raise any security issues not already endemic in electronic mail and 619 present in fully conforming implementations of SMTP. 621 10. References 623 10.1. Normative References 625 [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 626 821, DOI 10.17487/RFC0821, August 1982, . 629 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 630 2821, DOI 10.17487/RFC2821, April 2001, . 633 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 634 DOI 10.17487/RFC5321, October 2008, . 637 [RFC822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET 638 TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, 639 August 1982, . 641 [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, DOI 642 10.17487/RFC2822, April 2001, . 645 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 646 10.17487/RFC5322, October 2008, . 649 [RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 650 Crocker, "SMTP Service Extensions", STD 11, RFC 1869, DOI 651 10.17487/RFC1869, November 1995, . 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, DOI 656 10.17487/RFC2119, March 1997, . 659 10.2. Informative References 661 [RFC3696] Klensin, J., "Application Techniques for Checking and 662 Transformation of Names", RFC 3696, DOI 10.17487/RFC3696, 663 February 2004, . 665 [1003] Klensin, J., "Errata 1003", July 2005, . 668 [1690] Sayers, D., "Errata 1690", April 2010, . 671 [VERP] Bernstein, D., "Variable Envelope Return Paths", February 672 1997, . 674 [SRS] Shevek, "The Sender Rewriting Scheme", June 2004, 675 . 677 Authors' Addresses 679 Viruthagiri Thirumavalavan 680 Dombox, Inc. 682 EMail: giri@dombox.org