Network Working Group J. Klensin Internet-Draft December 14, 2008 Obsoletes: 5321 (if approved) Intended status: Standards Track Simple Mail Transfer Protocol draft-klensin-rfc5321-numbered-00.txt 10 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 June 17, 2009. Abstract 20 This document is a specification of the basic protocol for Internet 21 electronic mail transport. It consolidates, updates, and clarifies 22 several previous documents, making all or parts of most of them 23 obsolete. It covers the SMTP extension mechanisms and best practices 24 for the contemporary Internet, but does not provide details about 25 particular extensions. Although SMTP was designed as a mail 26 transport and delivery protocol, this specification also contains 27 information that is important to its use as a "mail submission" 28 protocol for "split-UA" (User Agent) mail reading systems and mobile 29 environments. 56 58 Internet-Draft RFC5321-Numbered Dec 2008 Table of Contents [[To be supplied or see RFC 5321]] [[Note in Draft: This special Internet-Draft version of RFC 5321 is supplied with line numbers to facilitate the possibility that the modifications to bring the document up to (full) Internet Standard may have to be done as deltas because it is unlikely the authorization for the additional rights required by RFC 5378 can be obtained from the authors of all of the text included in 5321. Should that concern be unjustified, this document will be discarded. This Internet-Draft has been paginated but is not page numbered (the page number on the last page is one of several hacks to make the automatic posting tool work), only line-numnbered, and the Table of Contents has been eliminated. The line numbering is somewhat artificial and has also been hacked to get past the automatic posting tool but, after the introductory material, reflects actual line numbers in RFC 5321.]] 222 Internet-Draft RFC5321-Numbered Dec 2008 223 224 225 1. Introduction 226 227 1.1. Transport of Electronic Mail 228 229 The objective of the Simple Mail Transfer Protocol (SMTP) is to 230 transfer mail reliably and efficiently. 231 232 SMTP is independent of the particular transmission subsystem and 233 requires only a reliable ordered data stream channel. While this 234 document specifically discusses transport over TCP, other transports 235 are possible. Appendices to RFC 821 [1] describe some of them. 236 237 An important feature of SMTP is its capability to transport mail 238 across multiple networks, usually referred to as "SMTP mail relaying" 239 (see Section 3.6). A network consists of the mutually-TCP-accessible 240 hosts on the public Internet, the mutually-TCP-accessible hosts on a 241 firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN 242 environment utilizing a non-TCP transport-level protocol. Using 243 SMTP, a process can transfer mail to another process on the same 244 network or to some other network via a relay or gateway process 245 accessible to both networks. 246 247 In this way, a mail message may pass through a number of intermediate 248 relay or gateway hosts on its path from sender to ultimate recipient. 249 The Mail eXchanger mechanisms of the domain name system (RFC 1035 250 [2], RFC 974 [12], and Section 5 of this document) are used to 251 identify the appropriate next-hop destination for a message being 252 transported. 253 254 1.2. History and Context for This Document 255 256 This document is a specification of the basic protocol for the 257 Internet electronic mail transport. It consolidates, updates and 258 clarifies, but does not add new or change existing functionality of 259 the following: 260 261 o the original SMTP (Simple Mail Transfer Protocol) specification of 262 RFC 821 [1], 263 264 o domain name system requirements and implications for mail 265 transport from RFC 1035 [2] and RFC 974 [12], 266 267 o the clarifications and applicability statements in RFC 1123 [3], 268 and 269 270 o material drawn from the SMTP Extension mechanisms in RFC 1869 271 [13]. 272 273 274 275 277 278 Internet-Draft RFC5321-Numbered Dec 2008 279 280 281 o Editorial and clarification changes to RFC 2821 [14] to bring that 282 specification to Draft Standard. 283 284 It obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821 and updatesRFC 285 1123 (replacing the mail transport materials of RFC 1123). However, 286 RFC 821 specifies some features that were not in significant use in 287 the Internet by the mid-1990s and (in appendices) some additional 288 transport models. Those sections are omitted here in the interest of 289 clarity and brevity; readers needing them should refer to RFC 821. 290 291 It also includes some additional material from RFC 1123 that required 292 amplification. This material has been identified in multiple ways, 293 mostly by tracking flaming on various lists and newsgroups and 294 problems of unusual readings or interpretations that have appeared as 295 the SMTP extensions have been deployed. Where this specification 296 moves beyond consolidation and actually differs from earlier 297 documents, it supersedes them technically as well as textually. 298 299 Although SMTP was designed as a mail transport and delivery protocol, 300 this specification also contains information that is important toits 301 use as a "mail submission" protocol, as recommended for Post Office 302 Protocol (POP) (RFC 937 [15], RFC 1939 [16]) and IMAP (RFC 3501 303 [17]). In general, the separate mail submission protocol specified 304 in RFC 4409 [18] is now preferred to direct use of SMTP; more 305 discussion of that subject appears in that document. 306 307 Section 2.3 provides definitions of terms specific to this document. 308 Except when the historical terminology is necessary for clarity, this 309 document uses the current 'client' and 'server' terminology to 310 identify the sending and receiving SMTP processes, respectively. 311 312 A companion document, RFC 5322 [4], discusses message header sections 313 and bodies and specifies formats and structures for them. 314 315 1.3. Document Conventions 316 317 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 318 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in t his 319 document are to be interpreted as described in RFC 2119 [5]. As each 320 of these terms was intentionally and carefully chosen to improve the 321 interoperability of email, each use of these terms is to be treated 322 as a conformance requirement. 323 324 Because this document has a long history and to avoid the risk of 325 various errors and of confusing readers and documents that point to 326 this one, most examples and the domain names they contain are 327 preserved from RFC 2821. Readers are cautioned that these are 328 329 330 331 333 334 Internet-Draft RFC5321-Numbered Dec 2008 335 336 337 illustrative examples that should not actually be used in either code 338 or configuration files. 339 340 2. The SMTP Model 341 342 2.1. Basic Structure 343 344 The SMTP design can be pictured as: 345 346 +----------+ +----------+ 347 +------+ | | | | 348 | User |<-->| | SMTP | | 349 +------+ | Client- |Commands/Replies| Server- | 350 +------+ | SMTP |<-------------->| SMTP | +------+ 351 | File |<-->| | and Mail | |<-->| File| 352 |System| | | | | |System| 353 +------+ +----------+ +----------+ +------+ 354 SMTP client SMTP server 355 356 When an SMTP client has a message to transmit, it establishes a two- 357 way transmission channel to an SMTP server. The responsibility of an 358 SMTP client is to transfer mail messages to one or more SMTP servers, 359 or report its failure to do so. 360 361 The means by which a mail message is presented to an SMTP client,and 362 how that client determines the identifier(s) ("names") of the 363 domain(s) to which mail messages are to be transferred, is a local 364 matter, and is not addressed by this document. In some cases, the 365 designated domain(s), or those determined by an SMTP client, will 366 identify the final destination(s) of the mail message. In other 367 cases, common with SMTP clients associated with implementations of 368 the POP (RFC 937 [15], RFC 1939 [16]) or IMAP (RFC 3501 [17]) 369 protocols, or when the SMTP client is inside an isolated transport 370 service environment, the domain determined will identify an 371 intermediate destination through which all mail messages are to be 372 relayed. SMTP clients that transfer all traffic regardless of the 373 target domains associated with the individual messages, or that do 374 not maintain queues for retrying message transmissions that initially 375 cannot be completed, may otherwise conform to this specification but 376 are not considered fully-capable. Fully-capable SMTP 377 implementations, including the relays used by these less capable 378 ones, and their destinations, are expected to support all of the 379 queuing, retrying, and alternate address functions discussed in this 380 specification. In many situations and configurations, the less- 381 capable clients discussed above SHOULD be using the message 382 submission protocol (RFC 4409 [18]) rather than SMTP. 383 384 385 386 387 389 390 Internet-Draft RFC5321-Numbered Dec 2008 391 392 393 The means by which an SMTP client, once it has determined a target 394 domain, determines the identity of an SMTP server to which a copyof 395 a message is to be transferred, and then performs that transfer, is 396 covered by this document. To effect a mail transfer to an SMTP 397 server, an SMTP client establishes a two-way transmission channelto 398 that SMTP server. An SMTP client determines the address of an 399 appropriate host running an SMTP server by resolving a destination 400 domain name to either an intermediate Mail eXchanger host or a final 401 target host. 402 403 An SMTP server may be either the ultimate destination or an 404 intermediate "relay" (that is, it may assume the role of an SMTP 405 client after receiving the message) or "gateway" (that is, it may 406 transport the message further using some protocol other than SMTP). 407 SMTP commands are generated by the SMTP client and sent to the SMTP 408 server. SMTP replies are sent from the SMTP server to the SMTP 409 client in response to the commands. 410 411 In other words, message transfer can occur in a single connection 412 between the original SMTP-sender and the final SMTP-recipient, orcan 413 occur in a series of hops through intermediary systems. In either 414 case, once the server has issued a success response at the end ofthe 415 mail data, a formal handoff of responsibility for the message occurs: 416 the protocol requires that a server MUST accept responsibility for 417 either delivering the message or properly reporting the failure to do 418 so (see Sections 6.1, 6.2, and 7.8, below). 419 420 Once the transmission channel is established and initial handshaking 421 is completed, the SMTP client normally initiates a mail transaction. 422 Such a transaction consists of a series of commands to specify the 423 originator and destination of the mail and transmission of the 424 message content (including any lines in the header section or other 425 structure) itself. When the same message is sent to multiple 426 recipients, this protocol encourages the transmission of only one 427 copy of the data for all recipients at the same destination (or 428 intermediate relay) host. 429 430 The server responds to each command with a reply; replies may 431 indicate that the command was accepted, that additional commands are 432 expected, or that a temporary or permanent error condition exists. 433 Commands specifying the sender or recipients may include server- 434 permitted SMTP service extension requests, as discussed in 435 Section 2.2. The dialog is purposely lock-step, one-at-a-time, 436 although this can be modified by mutually agreed upon extension 437 requests such as command pipelining (RFC 2920 [19]). 438 439 Once a given mail message has been transmitted, the client may either 440 request that the connection be shut down or may initiate other mail 441 442 443 445 446 Internet-Draft RFC5321-Numbered Dec 2008 447 448 449 transactions. In addition, an SMTP client may use a connection to an 450 SMTP server for ancillary services such as verification of email 451 addresses or retrieval of mailing list subscriber addresses. 452 453 As suggested above, this protocol provides mechanisms for the 454 transmission of mail. Historically, this transmission normally 455 occurred directly from the sending user's host to the receiving 456 user's host when the two hosts are connected to the same transport 457 service. When they are not connected to the same transport service, 458 transmission occurs via one or more relay SMTP servers. A very 459 common case in the Internet today involves submission of the original 460 message to an intermediate, "message submission" server, which is 461 similar to a relay but has some additional properties; such servers 462 are discussed in Section 2.3.10 and at some length in RFC 4409 [18]. 463 An intermediate host that acts as either an SMTP relay or as a 464 gateway into some other transmission environment is usually selected 465 through the use of the domain name service (DNS) Mail eXchanger 466 mechanism. 467 468 Usually, intermediate hosts are determined via the DNS MX record,not 469 by explicit "source" routing (see Section 5 and Appendix C and 470 Appendix F.2). 471 472 2.2. The Extension Model 473 474 2.2.1. Background 475 476 In an effort that started in 1990, approximately a decade after RFC 477 821 was completed, the protocol was modified with a "service 478 extensions" model that permits the client and server to agree to 479 utilize shared functionality beyond the original SMTP requirements. 480 The SMTP extension mechanism defines a means whereby an extended SMTP 481 client and server may recognize each other, and the server can inform 482 the client as to the service extensions that it supports. 483 484 Contemporary SMTP implementations MUST support the basic extension 485 mechanisms. For instance, servers MUST support the EHLO command even 486 if they do not implement any specific extensions and clients SHOULD 487 preferentially utilize EHLO rather than HELO. (However, for 488 compatibility with older conforming implementations, SMTP clients and 489 servers MUST support the original HELO mechanisms as a fallback.) 490 Unless the different characteristics of HELO must be identified for 491 interoperability purposes, this document discusses only EHLO. 492 493 SMTP is widely deployed and high-quality implementations have proven 494 to be very robust. However, the Internet community now considers 495 some services to be important that were not anticipated when the 496 protocol was first designed. If support for those services is tobe 497 498 499 501 502 Internet-Draft RFC5321-Numbered Dec 2008 503 504 505 added, it must be done in a way that permits older implementations to 506 continue working acceptably. The extension framework consists of: 507 508 o The SMTP command EHLO, superseding the earlier HELO, 509 510 o a registry of SMTP service extensions, 511 512 o additional parameters to the SMTP MAIL and RCPT commands, and 513 514 o optional replacements for commands defined in this protocol, such 515 as for DATA in non-ASCII transmissions (RFC 3030 [20]). 516 517 SMTP's strength comes primarily from its simplicity. Experience with 518 many protocols has shown that protocols with few options tend towards 519 ubiquity, whereas protocols with many options tend towards obscurity. 520 521 Each and every extension, regardless of its benefits, must be 522 carefully scrutinized with respect to its implementation, deployment, 523 and interoperability costs. In many cases, the cost of extendingthe 524 SMTP service will likely outweigh the benefit. 525 526 2.2.2. Definition and Registration of Extensions 527 528 The IANA maintains a registry of SMTP service extensions. A 529 corresponding EHLO keyword value is associated with each extension. 530 Each service extension registered with the IANA must be defined in a 531 formal Standards-Track or IESG-approved Experimental protocol 532 document. The definition must include: 533 534 o the textual name of the SMTP service extension; 535 536 o the EHLO keyword value associated with the extension; 537 538 o the syntax and possible values of parameters associated with the 539 EHLO keyword value; 540 541 o any additional SMTP verbs associated with the extension 542 (additional verbs will usually be, but are not required to be,the 543 same as the EHLO keyword value); 544 545 o any new parameters the extension associates with the MAIL or RCPT 546 verbs; 547 548 o a description of how support for the extension affects the 549 behavior of a server and client SMTP; and 558 Internet-Draft RFC5321-Numbered Dec 2008 559 560 561 o the increment by which the extension is increasing the maximum 562 length of the commands MAIL and/or RCPT, over that specified in 563 this Standard. 564 565 In addition, any EHLO keyword value starting with an upper or lower 566 case "X" refers to a local SMTP service extension used exclusively 567 through bilateral agreement. Keywords beginning with "X" MUST NOT be 568 used in a registered service extension. Conversely, keyword values 569 presented in the EHLO response that do not begin with "X" MUST 570 correspond to a Standard, Standards-Track, or IESG-approved 571 Experimental SMTP service extension registered with IANA. A 572 conforming server MUST NOT offer non-"X"-prefixed keyword values that 573 are not described in a registered extension. 574 575 Additional verbs and parameter names are bound by the same rules as 576 EHLO keywords; specifically, verbs beginning with "X" are local 577 extensions that may not be registered or standardized. Conversely, 578 verbs not beginning with "X" must always be registered. 579 580 2.2.3. Special Issues with Extensions 581 582 Extensions that change fairly basic properties of SMTP operation are 583 permitted. The text in other sections of this document must be 584 understood in that context. In particular, extensions can changethe 585 minimum limits specified in Section 4.5.3, can change the ASCII 586 character set requirement as mentioned above, or can introduce some 587 optional modes of message handling. 588 589 In particular, if an extension implies that the delivery path 590 normally supports special features of that extension, and an 591 intermediate SMTP system finds a next hop that does not support the 592 required extension, it MAY choose, based on the specific extension 593 and circumstances, to requeue the message and try later and/or try an 594 alternate MX host. If this strategy is employed, the timeout to fall 595 back to an unextended format (if one is available) SHOULD be less 596 than the normal timeout for bouncing as undeliverable (e.g., if 597 normal timeout is three days, the requeue timeout before attempting 598 to transmit the mail without the extension might be one day). 599 600 2.3. SMTP Terminology 601 602 2.3.1. Mail Objects 603 604 SMTP transports a mail object. A mail object contains an envelope 605 and content. 606 607 The SMTP envelope is sent as a series of SMTP protocol units 608 (described in Section 3). It consists of an originator address (to 609 610 611 613 614 Internet-Draft RFC5321-Numbered Dec 2008 615 616 617 which error reports should be directed), one or more recipient 618 addresses, and optional protocol extension material. Historically, 619 variations on the reverse-path (originator) address specification 620 command (MAIL) could be used to specify alternate delivery modes, 621 such as immediate display; those variations have now been deprecated 622 (see Appendix F and Appendix F.6). 623 624 The SMTP content is sent in the SMTP DATA protocol unit and has two 625 parts: the header section and the body. If the content conforms to 626 other contemporary standards, the header section consists of a 627 collection of header fields, each consisting of a header name, a 628 colon, and data, structured as in the message format specification 629 (RFC 5322 [4]); the body, if structured, is defined according to MIME 630 (RFC 2045 [21]). The content is textual in nature, expressed using 631 the US-ASCII repertoire [6]. Although SMTP extensions (such as 632 "8BITMIME", RFC 1652 [22]) may relax this restriction for the content 633 body, the content header fields are always encoded using the US-ASCII 634 repertoire. Two MIME extensions (RFC 2047 [23] and RFC 2231 [24]) 635 define an algorithm for representing header values outside the US- 636 ASCII repertoire, while still encoding them using the US-ASCII 637 repertoire. 638 639 2.3.2. Senders and Receivers 640 641 In RFC 821, the two hosts participating in an SMTP transaction were 642 described as the "SMTP-sender" and "SMTP-receiver". This document 643 has been changed to reflect current industry terminology and hence 644 refers to them as the "SMTP client" (or sometimes just "the client") 645 and "SMTP server" (or just "the server"), respectively. Since a 646 given host may act both as server and client in a relay situation, 647 "receiver" and "sender" terminology is still used where needed for 648 clarity. 649 650 2.3.3. Mail Agents and Message Stores 651 652 Additional mail system terminology became common after RFC 821 was 653 published and, where convenient, is used in this specification. In 654 particular, SMTP servers and clients provide a mail transport service 655 and therefore act as "Mail Transfer Agents" (MTAs). "Mail User 656 Agents" (MUAs or UAs) are normally thought of as the sources and 657 targets of mail. At the source, an MUA might collect mail to be 658 transmitted from a user and hand it off to an MTA; the final 659 ("delivery") MTA would be thought of as handing the mail off to an 660 MUA (or at least transferring responsibility to it, e.g., by 661 depositing the message in a "message store"). However, while these 662 terms are used with at least the appearance of great precision in 663 other environments, the implied boundaries between MUAs and MTAs 664 often do not accurately match common, and conforming, practices with 665 666 667 669 670 Internet-Draft RFC5321-Numbered Dec 2008 671 672 673 Internet mail. Hence, the reader should be cautious about inferring 674 the strong relationships and responsibilities that might be implied 675 if these terms were used elsewhere. 676 677 2.3.4. Host 678 679 For the purposes of this specification, a host is a computer system 680 attached to the Internet (or, in some cases, to a private TCP/IP 681 network) and supporting the SMTP protocol. Hosts are known by names 682 (see the next section); they SHOULD NOT be identified by numerical 683 addresses, i.e., by address literals as described in Section 4.1.2. 684 685 2.3.5. Domain Names 686 687 A domain name (or often just a "domain") consists of one or more 688 components, separated by dots if more than one appears. In the case 689 of a top-level domain used by itself in an email address, a single 690 string is used without any dots. This makes the requirement, 691 described in more detail below, that only fully-qualified domain 692 names appear in SMTP transactions on the public Internet, 693 particularly important where top-level domains are involved. These 694 components ("labels" in DNS terminology, RFC 1035 [2]) are restricted 695 for SMTP purposes to consist of a sequence of letters, digits, and 696 hyphens drawn from the ASCII character set [6]. Domain names are 697 used as names of hosts and of other entities in the domain name 698 hierarchy. For example, a domain may refer to an alias (label ofa 699 CNAME RR) or the label of Mail eXchanger records to be used to 700 deliver mail instead of representing a host name. See RFC 1035 [2] 701 and Section 5 of this specification. 702 703 The domain name, as described in this document and in RFC 1035 [2], 704 is the entire, fully-qualified name (often referred to as an "FQDN"). 705 A domain name that is not in FQDN form is no more than a local alias. 706 Local aliases MUST NOT appear in any SMTP transaction. 707 708 Only resolvable, fully-qualified domain names (FQDNs) are permitted 709 when domain names are used in SMTP. In other words, names that can 710 be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed 711 in Section 5) are permitted, as are CNAME RRs whose targets can be 712 resolved, in turn, to MX or address RRs. Local nicknames or 713 unqualified names MUST NOT be used. There are two exceptions to the 714 rule requiring FQDNs: 715 716 o The domain name given in the EHLO command MUST be either a primary 717 host name (a domain name that resolves to an address RR) or, if 718 the host has no name, an address literal, as described in 719 Section 4.1.3 and discussed further in the EHLO discussion of 720 Section 4.1.4. 721 722 723 725 726 Internet-Draft RFC5321-Numbered Dec 2008 727 728 729 o The reserved mailbox name "postmaster" may be used in a RCPT 730 command without domain qualification (see Section 4.1.1.3) and 731 MUST be accepted if so used. 732 733 2.3.6. Buffer and State Table 734 735 SMTP sessions are stateful, with both parties carefully maintaining a 736 common view of the current state. In this document, we model this 737 state by a virtual "buffer" and a "state table" on the server that 738 may be used by the client to, for example, "clear the buffer" or 739 "reset the state table", causing the information in the buffer tobe 740 discarded and the state to be returned to some previous state. 741 742 2.3.7. Commands and Replies 743 744 SMTP commands and, unless altered by a service extension, message 745 data, are transmitted from the sender to the receiver via the 746 transmission channel in "lines". 747 748 An SMTP reply is an acknowledgment (positive or negative) sent in 749 "lines" from receiver to sender via the transmission channel in 750 response to a command. The general form of a reply is a numeric 751 completion code (indicating failure or success) usually followed by a 752 text string. The codes are for use by programs and the text is 753 usually intended for human users. RFC 3463 [25], specifies further 754 structuring of the reply strings, including the use of supplemental 755 and more specific completion codes (see also RFC 5248 [26]). 756 757 2.3.8. Lines 758 759 Lines consist of zero or more data characters terminated by the 760 sequence ASCII character "CR" (hex value 0D) followed immediatelyby 761 ASCII character "LF" (hex value 0A). This termination sequence is 762 denoted as in this document. Conforming implementations MUST 763 NOT recognize or generate any other character or character sequence 764 as a line terminator. Limits MAY be imposed on line lengths by 765 servers (see Section 4). 766 767 In addition, the appearance of "bare" "CR" or "LF" characters in text 768 (i.e., either without the other) has a long history of causing 769 problems in mail implementations and applications that use the mail 770 system as a tool. SMTP client implementations MUST NOT transmit 771 these characters except when they are intended as line terminators 772 and then MUST, as indicated above, transmit them only as a 773 sequence. 774 775 776 777 778 779 781 782 Internet-Draft RFC5321-Numbered Dec 2008 783 784 785 2.3.9. Message Content and Mail Data 786 787 The terms "message content" and "mail data" are used interchangeably 788 in this document to describe the material transmitted after the DATA 789 command is accepted and before the end of data indication is 790 transmitted. Message content includes the message header sectionand 791 the possibly structured message body. The MIME specification (RFC 792 2045 [21]) provides the standard mechanisms for structured message 793 bodies. 794 795 2.3.10. Originator, Delivery, Relay, and Gateway Systems 796 797 This specification makes a distinction among four types of SMTP 798 systems, based on the role those systems play in transmitting 799 electronic mail. An "originating" system (sometimes called an SMTP 800 originator) introduces mail into the Internet or, more generally, 801 into a transport service environment. A "delivery" SMTP system is 802 one that receives mail from a transport service environment and 803 passes it to a mail user agent or deposits it in a message store that 804 a mail user agent is expected to subsequently access. A "relay" SMTP 805 system (usually referred to just as a "relay") receives mail froman 806 SMTP client and transmits it, without modification to the message 807 data other than adding trace information, to another SMTP server for 808 further relaying or for delivery. 809 810 A "gateway" SMTP system (usually referred to just as a "gateway") 811 receives mail from a client system in one transport environment and 812 transmits it to a server system in another transport environment. 813 Differences in protocols or message semantics between the transport 814 environments on either side of a gateway may require that the gateway 815 system perform transformations to the message that are not permitted 816 to SMTP relay systems. For the purposes of this specification, 817 firewalls that rewrite addresses should be considered as gateways, 818 even if SMTP is used on both sides of them (see RFC 2979 [27]). 819 820 2.3.11. Mailbox and Address 821 822 As used in this specification, an "address" is a character string 823 that identifies a user to whom mail will be sent or a location in to 824 which mail will be deposited. The term "mailbox" refers to that 825 depository. The two terms are typically used interchangeably unless 826 the distinction between the location in which mail is placed (the 827 mailbox) and a reference to it (the address) is important. An 828 address normally consists of user and domain specifications. The 829 standard mailbox naming convention is defined to be 830 "local-part@domain"; contemporary usage permits a much broader set of 831 applications than simple "user names". Consequently, and due to a 832 long history of problems when intermediate hosts have attempted to 833 834 835 837 838 Internet-Draft RFC5321-Numbered Dec 2008 839 840 841 optimize transport by modifying them, the local-part MUST be 842 interpreted and assigned semantics only by the host specified in the 843 domain part of the address. 844 845 2.4. General Syntax Principles and Transaction Model 846 847 SMTP commands and replies have a rigid syntax. All commands begin 848 with a command verb. All replies begin with a three digit numeric 849 code. In some commands and replies, arguments are required following 850 the verb or reply code. Some commands do not accept arguments (after 851 the verb), and some reply codes are followed, sometimes optionally, 852 by free form text. In both cases, where text appears, it is 853 separated from the verb or reply code by a space character. Complete 854 definitions of commands and replies appear in Section 4. 855 856 Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command 857 and extension name keywords) are not case sensitive, with the sole 858 exception in this specification of a mailbox local-part (SMTP 859 Extensions may explicitly specify case-sensitive elements). Thatis, 860 a command verb, an argument value other than a mailbox local-part, 861 and free form text MAY be encoded in upper case, lower case, or any 862 mixture of upper and lower case with no impact on its meaning. The 863 local-part of a mailbox MUST BE treated as case sensitive. 864 Therefore, SMTP implementations MUST take care to preserve the case 865 of mailbox local-parts. In particular, for some hosts, the user 866 "smith" is different from the user "Smith". However, exploiting the 867 case sensitivity of mailbox local-parts impedes interoperability and 868 is discouraged. Mailbox domains follow normal DNS rules and are 869 hence not case sensitive. 870 871 A few SMTP servers, in violation of this specification (and RFC 821) 872 require that command verbs be encoded by clients in upper case. 873 Implementations MAY wish to employ this encoding to accommodate those 874 servers. 875 876 The argument clause consists of a variable-length character string 877 ending with the end of the line, i.e., with the character sequence 878 . The receiver will take no action until this sequence is 879 received. 880 881 The syntax for each command is shown with the discussion of that 882 command. Common elements and parameters are shown in Section 4.1.2. 883 884 Commands and replies are composed of characters from the ASCII 885 character set [6]. When the transport service provides an 8-bit byte 886 (octet) transmission channel, each 7-bit character is transmitted, 887 right justified, in an octet with the high-order bit cleared to zero. 888 More specifically, the unextended SMTP service provides 7-bit 889 890 891 893 894 Internet-Draft RFC5321-Numbered Dec 2008 895 896 897 transport only. An originating SMTP client that has not successfully 898 negotiated an appropriate extension with a particular server (seethe 899 next paragraph) MUST NOT transmit messages with information in the 900 high-order bit of octets. If such messages are transmitted in 901 violation of this rule, receiving SMTP servers MAY clear the high- 902 order bit or reject the message as invalid. In general, a relay SMTP 903 SHOULD assume that the message content it has received is valid and, 904 assuming that the envelope permits doing so, relay it without 905 inspecting that content. Of course, if the content is mislabeledand 906 the data path cannot accept the actual content, this may result in 907 the ultimate delivery of a severely garbled message to the recipient. 908 Delivery SMTP systems MAY reject such messages, or return them as 909 undeliverable, rather than deliver them. In the absence of a server- 910 offered extension explicitly permitting it, a sending SMTP systemis 911 not permitted to send envelope commands in any character set other 912 than US-ASCII. Receiving systems SHOULD reject such commands, 913 normally using "500 syntax error - invalid character" replies. 914 915 8-bit message content transmission MAY be requested of the serverby 916 a client using extended SMTP facilities, notably the "8BITMIME" 917 extension, RFC 1652 [22]. 8BITMIME SHOULD be supported by SMTP 918 servers. However, it MUST NOT be construed as authorization to 919 transmit unrestricted 8-bit material, nor does 8BITMIME authorize 920 transmission of any envelope material in other than ASCII. 8BITMIME 921 MUST NOT be requested by senders for material with the high bit on 922 that is not in MIME format with an appropriate content-transfer 923 encoding; servers MAY reject such messages. 924 925 The metalinguistic notation used in this document corresponds to the 926 "Augmented BNF" used in other Internet mail system documents. The 927 reader who is not familiar with that syntax should consult the ABNF 928 specification in RFC 5234 [7]. Metalanguage terms used in running 929 text are surrounded by pointed brackets (e.g., ) for clarity. 930 The reader is cautioned that the grammar expressed in the 931 metalanguage is not comprehensive. There are many instances in w hich 932 provisions in the text constrain or otherwise modify the syntax or 933 semantics implied by the grammar. 934 935 3. The SMTP Procedures: An Overview 936 937 This section contains descriptions of the procedures used in SMTP: 938 session initiation, mail transaction, forwarding mail, verifying 939 mailbox names and expanding mailing lists, and opening and closing 940 exchanges. Comments on relaying, a note on mail domains, and a 941 discussion of changing roles are included at the end of this section. 942 Several complete scenarios are presented in Appendix D. 943 944 945 946 947 949 950 Internet-Draft RFC5321-Numbered Dec 2008 951 952 953 3.1. Session Initiation 954 955 An SMTP session is initiated when a client opens a connection to a 956 server and the server responds with an opening message. 957 958 SMTP server implementations MAY include identification of their 959 software and version information in the connection greeting reply 960 after the 220 code, a practice that permits more efficient isolation 961 and repair of any problems. Implementations MAY make provision for 962 SMTP servers to disable the software and version announcement where 963 it causes security concerns. While some systems also identify their 964 contact point for mail problems, this is not a substitute for 965 maintaining the required "postmaster" address (see Section 4). 966 967 The SMTP protocol allows a server to formally reject a mail session 968 while still allowing the initial connection as follows: a 554 969 response MAY be given in the initial connection opening message 970 instead of the 220. A server taking this approach MUST still wait 971 for the client to send a QUIT (see Section 4.1.1.10) before closing 972 the connection and SHOULD respond to any intervening commands with 973 "503 bad sequence of commands". Since an attempt to make an SMTP 974 connection to such a system is probably in error, a server returning 975 a 554 response on connection opening SHOULD provide enough 976 information in the reply text to facilitate debugging of the sending 977 system. 978 979 3.2. Client Initiation 980 981 Once the server has sent the greeting (welcoming) message and the 982 client has received it, the client normally sends the EHLO command to 983 the server, indicating the client's identity. In addition to opening 984 the session, use of EHLO indicates that the client is able to process 985 service extensions and requests that the server provide a list ofthe 986 extensions it supports. Older SMTP systems that are unable to 987 support service extensions, and contemporary clients that do not 988 require service extensions in the mail session being initiated, MAY 989 use HELO instead of EHLO. Servers MUST NOT return the extended EHLO- 990 style response to a HELO command. For a particular connection 991 attempt, if the server returns a "command not recognized" response to 992 EHLO, the client SHOULD be able to fall back and send HELO. 993 994 In the EHLO command, the host sending the command identifies itself; 995 the command may be interpreted as saying "Hello, I am " (and, 996 in the case of EHLO, "and I support service extension requests"). 997 998 999 1000 1001 1002 1003 1005 1006 Internet-Draft RFC5321-Numbered Dec 2008 1007 1008 1009 3.3. Mail Transactions 1010 1011 There are three steps to SMTP mail transactions. The transaction 1012 starts with a MAIL command that gives the sender identification. (In 1013 general, the MAIL command may be sent only when no mail transaction 1014 is in progress; see Section 4.1.4.) A series of one or more RCPT 1015 commands follows, giving the receiver information. Then, a DATA 1016 command initiates transfer of the mail data and is terminated by the 1017 "end of mail" data indicator, which also confirms the transaction. 1018 1019 The first step in the procedure is the MAIL command. 1020 1021 MAIL FROM: [SP ] 1022 1023 This command tells the SMTP-receiver that a new mail transaction is 1024 starting and to reset all its state tables and buffers, includingany 1025 recipients or mail data. The portion of the firstor 1026 only argument contains the source mailbox (between "<" and ">" 1027 brackets), which can be used to report errors (see Section 4.2 for a 1028 discussion of error reporting). If accepted, the SMTP server returns 1029 a "250 OK" reply. If the mailbox specification is not acceptablefor 1030 some reason, the server MUST return a reply indicating whether the 1031 failure is permanent (i.e., will occur again if the client tries to 1032 send the same address again) or temporary (i.e., the address might be 1033 accepted if the client tries again later). Despite the apparent 1034 scope of this requirement, there are circumstances in which the 1035 acceptability of the reverse-path may not be determined until oneor 1036 more forward-paths (in RCPT commands) can be examined. In those 1037 cases, the server MAY reasonably accept the reverse-path (with a 250 1038 reply) and then report problems after the forward-paths are received 1039 and examined. Normally, failures produce 550 or 553 replies. 1040 1041 Historically, the was permitted to contain more than 1042 just a mailbox; however, contemporary systems SHOULD NOT use source 1043 routing (see Appendix C). 1044 1045 The optional are associated with negotiated SMT P 1046 service extensions (see Section 2.2). 1047 1048 The second step in the procedure is the RCPT command. This step of 1049 the procedure can be repeated any number of times. 1050 1051 RCPT TO: [ SP ] 1052 1053 The first or only argument to this command includes a forward-path 1054 (normally a mailbox and domain, always surrounded by "<" and ">" 1055 brackets) identifying one recipient. If accepted, the SMTP server 1056 returns a "250 OK" reply and stores the forward-path. If the 1057 1058 1059 1061 1062 Internet-Draft RFC5321-Numbered Dec 2008 1063 1064 1065 recipient is known not to be a deliverable address, the SMTP server 1066 returns a 550 reply, typically with a string such as "no such user - 1067 " and the mailbox name (other circumstances and reply codes are 1068 possible). 1069 1070 The can contain more than just a mailbox. 1071 Historically, the was permitted to contain a source 1072 routing list of hosts and the destination mailbox; however, 1073 contemporary SMTP clients SHOULD NOT utilize source routes (see 1074 Appendix C). Servers MUST be prepared to encounter a list of source 1075 routes in the forward-path, but they SHOULD ignore the routes or MAY 1076 decline to support the relaying they imply. Similarly, servers MAY 1077 decline to accept mail that is destined for other hosts or systems. 1078 These restrictions make a server useless as a relay for clients that 1079 do not support full SMTP functionality. Consequently, restricted- 1080 capability clients MUST NOT assume that any SMTP server on the 1081 Internet can be used as their mail processing (relaying) site. If a 1082 RCPT command appears without a previous MAIL command, the server MUST 1083 return a 503 "Bad sequence of commands" response. The optional 1084 are associated with negotiated SMTP service 1085 extensions (see Section 2.2). 1086 1087 Since it has been a common source of errors, it is worth noting that 1088 spaces are not permitted on either side of the colon following FROM 1089 in the MAIL command or TO in the RCPT command. The syntax is exactly 1090 as given above. 1091 1092 The third step in the procedure is the DATA command (or some 1093 alternative specified in a service extension). 1094 1095 DATA 1096 1097 If accepted, the SMTP server returns a 354 Intermediate reply and 1098 considers all succeeding lines up to but not including the end of 1099 mail data indicator to be the message text. When the end of textis 1100 successfully received and stored, the SMTP-receiver sends a "250 OK" 1101 reply. 1102 1103 Since the mail data is sent on the transmission channel, the end of 1104 mail data must be indicated so that the command and reply dialog can 1105 be resumed. SMTP indicates the end of the mail data by sending a 1106 line containing only a "." (period or full stop). A transparency 1107 procedure is used to prevent this from interfering with the user's 1108 text (see Section 4.5.2). 1109 1110 The end of mail data indicator also confirms the mail transactionand 1111 tells the SMTP server to now process the stored recipients and mail 1112 1113 1114 1115 1117 1118 Internet-Draft RFC5321-Numbered Dec 2008 1119 1120 1121 data. If accepted, the SMTP server returns a "250 OK" reply. The 1122 DATA command can fail at only two points in the protocol exchange: 1123 1124 If there was no MAIL, or no RCPT, command, or all such commands were 1125 rejected, the server MAY return a "command out of sequence" (503)or 1126 "no valid recipients" (554) reply in response to the DATA command. 1127 If one of those replies (or any other 5yz reply) is received, the 1128 client MUST NOT send the message data; more generally, message data 1129 MUST NOT be sent unless a 354 reply is received. 1130 1131 If the verb is initially accepted and the 354 reply issued, the DATA 1132 command should fail only if the mail transaction was incomplete (for 1133 example, no recipients), if resources were unavailable (including, of 1134 course, the server unexpectedly becoming unavailable), or if the 1135 server determines that the message should be rejected for policy or 1136 other reasons. 1137 1138 However, in practice, some servers do not perform recipient 1139 verification until after the message text is received. These servers 1140 SHOULD treat a failure for one or more recipients as a "subsequent 1141 failure" and return a mail message as discussed in Section 6 and,in 1142 particular, in Section 6.1. Using a "550 mailbox not found" (or 1143 equivalent) reply code after the data are accepted makes it difficult 1144 or impossible for the client to determine which recipients failed. 1145 1146 When the RFC 822 format ([28], [4]) is being used, the mail data 1147 include the header fields such as those named Date, Subject, To, Cc, 1148 and From. Server SMTP systems SHOULD NOT reject messages based on 1149 perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message 1150 header section or message body. In particular, they MUST NOT reject 1151 messages in which the numbers of Resent-header fields do not match or 1152 Resent-to appears without Resent-from and/or Resent-date. 1153 1154 Mail transaction commands MUST be used in the order discussed above. 1155 1156 3.4. Forwarding for Address Correction or Updating 1157 1158 Forwarding support is most often required to consolidate and simplify 1159 addresses within, or relative to, some enterprise and less frequently 1160 to establish addresses to link a person's prior address with a 1161 current one. Silent forwarding of messages (without server 1162 notification to the sender), for security or non-disclosure purposes, 1163 is common in the contemporary Internet. 1164 1165 In both the enterprise and the "new address" cases, information 1166 hiding (and sometimes security) considerations argue against exposure 1167 of the "final" address through the SMTP protocol as a side effectof 1168 the forwarding activity. This may be especially important when the 1169 1170 1171 1173 1174 Internet-Draft RFC5321-Numbered Dec 2008 1175 1176 1177 final address may not even be reachable by the sender. Consequently, 1178 the "forwarding" mechanisms described in Section 3.2 of RFC 821, and 1179 especially the 251 (corrected destination) and 551 reply codes from 1180 RCPT must be evaluated carefully by implementers and, when they are 1181 available, by those configuring systems (see also Section 7.4). 1182 1183 In particular: 1184 1185 o Servers MAY forward messages when they are aware of an address 1186 change. When they do so, they MAY either provide address-updating 1187 information with a 251 code, or may forward "silently" and return 1188 a 250 code. However, if a 251 code is used, they MUST NOT assume 1189 that the client will actually update address information or even 1190 return that information to the user. 1191 1192 Alternately, 1193 1194 o Servers MAY reject messages or return them as non-deliverable when 1195 they cannot be delivered precisely as addressed. When they doso, 1196 they MAY either provide address-updating information with a 551 1197 code, or may reject the message as undeliverable with a 550 code 1198 and no address-specific information. However, if a 551 code is 1199 used, they MUST NOT assume that the client will actually update 1200 address information or even return that information to the user. 1201 1202 SMTP server implementations that support the 251 and/or 551 reply 1203 codes SHOULD provide configuration mechanisms so that sites that 1204 conclude that they would undesirably disclose information can disable 1205 or restrict their use. 1206 1207 3.5. Commands for Debugging Addresses 1208 1209 3.5.1. Overview 1210 1211 SMTP provides commands to verify a user name or obtain the content of 1212 a mailing list. This is done with the VRFY and EXPN commands, which 1213 have character string arguments. Implementations SHOULD support VRFY 1214 and EXPN (however, see Section 3.5.2 and Section 7.3). 1215 1216 For the VRFY command, the string is a user name or a user name and 1217 domain (see below). If a normal (i.e., 250) response is returned, 1218 the response MAY include the full name of the user and MUST include 1219 the mailbox of the user. It MUST be in either of the following 1220 forms: 1221 1222 User Name 1223 local-part@domain 1224 1225 1226 1227 1229 1230 Internet-Draft RFC5321-Numbered Dec 2008 1231 1232 1233 When a name that is the argument to VRFY could identify more thanone 1234 mailbox, the server MAY either note the ambiguity or identify the 1235 alternatives. In other words, any of the following are legitimate 1236 responses to VRFY: 1237 1238 553 User ambiguous 1239 1240 or 1241 1242 553- Ambiguous; Possibilities are 1243 553-Joe Smith 1244 553-Harry Smith 1245 553 Melvin Smith 1246 1247 or 1248 1249 553-Ambiguous; Possibilities 1250 553- 1251 553- 1252 553 1253 1254 Under normal circumstances, a client receiving a 553 reply would be 1255 expected to expose the result to the user. Use of exactly the forms 1256 given, and the "user ambiguous" or "ambiguous" keywords, possibly 1257 supplemented by extended reply codes, such as those described in RFC 1258 3463 [25], will facilitate automated translation into other languages 1259 as needed. Of course, a client that was highly automated or thatwas 1260 operating in another language than English might choose to try to 1261 translate the response to return some other indication to the user 1262 than the literal text of the reply, or to take some automated action 1263 such as consulting a directory service for additional information 1264 before reporting to the user. 1265 1266 For the EXPN command, the string identifies a mailing list, and the 1267 successful (i.e., 250) multiline response MAY include the full name 1268 of the users and MUST give the mailboxes on the mailing list. 1269 1270 In some hosts, the distinction between a mailing list and an alias 1271 for a single mailbox is a bit fuzzy, since a common data structure 1272 may hold both types of entries, and it is possible to have mailing 1273 lists containing only one mailbox. If a request is made to apply 1274 VRFY to a mailing list, a positive response MAY be given if a message 1275 so addressed would be delivered to everyone on the list, otherwise an 1276 error SHOULD be reported (e.g., "550 That is a mailing list, not a 1277 user" or "252 Unable to verify members of mailing list"). If a 1278 request is made to expand a user name, the server MAY return a 1279 1280 1281 1282 1283 1285 1286 Internet-Draft RFC5321-Numbered Dec 2008 1287 1288 1289 positive response consisting of a list containing one name, or an 1290 error MAY be reported (e.g., "550 That is a user name, not a mailing 1291 list"). 1292 1293 In the case of a successful multiline reply (normal for EXPN), 1294 exactly one mailbox is to be specified on each line of the reply. 1295 The case of an ambiguous request is discussed above. 1296 1297 "User name" is a fuzzy term and has been used deliberately. An 1298 implementation of the VRFY or EXPN commands MUST include at least 1299 recognition of local mailboxes as "user names". However, since 1300 current Internet practice often results in a single host handling 1301 mail for multiple domains, hosts, especially hosts that provide this 1302 functionality, SHOULD accept the "local-part@domain" form as a "user 1303 name"; hosts MAY also choose to recognize other strings as "user 1304 names". 1305 1306 The case of expanding a mailbox list requires a multiline reply, such 1307 as: 1308 1309 C: EXPN Example-People 1310 S: 250-Jon Postel 1311 S: 250-Fred Fonebone 1312 S: 250 Sam Q. Smith 1313 1314 or 1315 1316 C: EXPN Executive-Washroom-List 1317 S: 550 Access Denied to You. 1318 1319 The character string arguments of the VRFY and EXPN commands cannot 1320 be further restricted due to the variety of implementations of the 1321 user name and mailbox list concepts. On some systems, it may be 1322 appropriate for the argument of the EXPN command to be a file name 1323 for a file containing a mailing list, but again there are a variety 1324 of file naming conventions in the Internet. Similarly, historical 1325 variations in what is returned by these commands are such that the 1326 response SHOULD be interpreted very carefully, if at all, and SHOULD 1327 generally only be used for diagnostic purposes. 1328 1329 3.5.2. VRFY Normal Response 1330 1331 When normal (2yz or 551) responses are returned from a VRFY or EXPN 1332 request, the reply MUST include the name using a 1333 "" construction, where "domain" is a fully- 1334 qualified domain name. In circumstances exceptional enough to 1335 justify violating the intent of this specification, free-form text 1336 MAY be returned. In order to facilitate parsing by both computers 1337 1338 1339 1341 1342 Internet-Draft RFC5321-Numbered Dec 2008 1343 1344 1345 and people, addresses SHOULD appear in pointed brackets. When 1346 addresses, rather than free-form debugging information, are returned, 1347 EXPN and VRFY MUST return only valid domain addresses that are usable 1348 in SMTP RCPT commands. Consequently, if an address implies delivery 1349 to a program or other system, the mailbox name used to reach that 1350 target MUST be given. Paths (explicit source routes) MUST NOT be 1351 returned by VRFY or EXPN. 1352 1353 Server implementations SHOULD support both VRFY and EXPN. For 1354 security reasons, implementations MAY provide local installationsa 1355 way to disable either or both of these commands through configuration 1356 options or the equivalent (see Section 7.3). When these commandsare 1357 supported, they are not required to work across relays when relaying 1358 is supported. Since they were both optional in RFC 821, but VRFYwas 1359 made mandatory in RFC 1123 [3], if EXPN is supported, it MUST be 1360 listed as a service extension in an EHLO response. VRFY MAY be 1361 listed as a convenience but, since support for it is required, SMTP 1362 clients are not required to check for its presence on the extension 1363 list before using it. 1364 1365 3.5.3. Meaning of VRFY or EXPN Success Response 1366 1367 A server MUST NOT return a 250 code in response to a VRFY or EXPN 1368 command unless it has actually verified the address. In particular, 1369 a server MUST NOT return 250 if all it has done is to verify thatthe 1370 syntax given is valid. In that case, 502 (Command not implemented) 1371 or 500 (Syntax error, command unrecognized) SHOULD be returned. As 1372 stated elsewhere, implementation (in the sense of actually validating 1373 addresses and returning information) of VRFY and EXPN are strongly 1374 recommended. Hence, implementations that return 500 or 502 for VRFY 1375 are not in full compliance with this specification. 1376 1377 There may be circumstances where an address appears to be valid but 1378 cannot reasonably be verified in real time, particularly when a 1379 server is acting as a mail exchanger for another server or domain. 1380 "Apparent validity", in this case, would normally involve at leas t 1381 syntax checking and might involve verification that any domains 1382 specified were ones to which the host expected to be able to relay 1383 mail. In these situations, reply code 252 SHOULD be returned. These 1384 cases parallel the discussion of RCPT verification in Section 2.1. 1385 Similarly, the discussion in Section 3.4 applies to the use of reply 1386 codes 251 and 551 with VRFY (and EXPN) to indicate addresses thatare 1387 recognized but that would be forwarded or rejected were mail received 1388 for them. Implementations generally SHOULD be more aggressive about 1389 address verification in the case of VRFY than in the case of RCPT, 1390 even if it takes a little longer to do so. 1391 1392 1393 1394 1395 1397 1398 Internet-Draft RFC5321-Numbered Dec 2008 1399 1400 1401 3.5.4. Semantics and Applications of EXPN 1402 1403 EXPN is often very useful in debugging and understanding problems 1404 with mailing lists and multiple-target-address aliases. Some systems 1405 have attempted to use source expansion of mailing lists as a means of 1406 eliminating duplicates. The propagation of aliasing systems with 1407 mail on the Internet for hosts (typically with MX and CNAME DNS 1408 records), for mailboxes (various types of local host aliases), and in 1409 various proxying arrangements has made it nearly impossible for these 1410 strategies to work consistently, and mail systems SHOULD NOT attempt 1411 them. 1412 1413 3.6. Relaying and Mail Routing 1414 1415 3.6.1. Source Routes and Relaying 1416 1417 In general, the availability of Mail eXchanger records in the domain 1418 name system (RFC 1035 [2], RFC 974 [12]) makes the use of explicit 1419 source routes in the Internet mail system unnecessary. Many 1420 historical problems with the interpretation of explicit source routes 1421 have made their use undesirable. SMTP clients SHOULD NOT generate 1422 explicit source routes except under unusual circumstances. SMTP 1423 servers MAY decline to act as mail relays or to accept addresses that 1424 specify source routes. When route information is encountered, SMTP 1425 servers MAY ignore the route information and simply send to the final 1426 destination specified as the last element in the route and SHOULDdo 1427 so. There has been an invalid practice of using names that do not 1428 appear in the DNS as destination names, with the senders countingon 1429 the intermediate hosts specified in source routing to resolve any 1430 problems. If source routes are stripped, this practice will cause 1431 failures. This is one of several reasons why SMTP clients MUST NOT 1432 generate invalid source routes or depend on serial resolution of 1433 names. 1434 1435 When source routes are not used, the process described in RFC 821for 1436 constructing a reverse-path from the forward-path is not applicable 1437 and the reverse-path at the time of delivery will simply be the 1438 address that appeared in the MAIL command. 1439 1440 3.6.2. Mail eXchange Records and Relaying 1441 1442 A relay SMTP server is usually the target of a DNS MX record that 1443 designates it, rather than the final delivery system. The relay 1444 server may accept or reject the task of relaying the mail in the same 1445 way it accepts or rejects mail for a local user. If it accepts the 1446 task, it then becomes an SMTP client, establishes a transmission 1447 channel to the next SMTP server specified in the DNS (according to 1448 the rules in Section 5), and sends it the mail. If it declines to 1449 1450 1451 1453 1454 Internet-Draft RFC5321-Numbered Dec 2008 1455 1456 1457 relay mail to a particular address for policy reasons, a 550 response 1458 SHOULD be returned. 1459 1460 This specification does not deal with the verification of return 1461 paths for use in delivery notifications. Recent work, such as that 1462 on SPF [29] and DKIM [30] [31], has been done to provide ways to 1463 ascertain that an address is valid or belongs to the person who 1464 actually sent the message. A server MAY attempt to verify the return 1465 path before using its address for delivery notifications, but methods 1466 of doing so are not defined here nor is any particular method 1467 recommended at this time. 1468 1469 3.6.3. Message Submission Servers as Relays 1470 1471 Many mail-sending clients exist, especially in conjunction with 1472 facilities that receive mail via POP3 or IMAP, that have limited 1473 capability to support some of the requirements of this specification, 1474 such as the ability to queue messages for subsequent delivery 1475 attempts. For these clients, it is common practice to make private 1476 arrangements to send all messages to a single server for processing 1477 and subsequent distribution. SMTP, as specified here, is not ideally 1478 suited for this role. A standardized mail submission protocol has 1479 been developed that is gradually superseding practices based on SMTP 1480 (see RFC 4409 [18]). In any event, because these arrangements are 1481 private and fall outside the scope of this specification, they are 1482 not described here. 1483 1484 It is important to note that MX records can point to SMTP servers 1485 that act as gateways into other environments, not just SMTP relays 1486 and final delivery systems; see Sections 3.7 and 5. 1487 1488 If an SMTP server has accepted the task of relaying the mail and 1489 later finds that the destination is incorrect or that the mail cannot 1490 be delivered for some other reason, then it MUST construct an 1491 "undeliverable mail" notification message and send it to the 1492 originator of the undeliverable mail (as indicated by the reverse- 1493 path). Formats specified for non-delivery reports by other standards 1494 (see, for example, RFC 3461 [32] and RFC 3464 [33]) SHOULD be used if 1495 possible. 1496 1497 This notification message must be from the SMTP server at the relay 1498 host or the host that first determines that delivery cannot be 1499 accomplished. Of course, SMTP servers MUST NOT send notification 1500 messages about problems transporting notification messages. One way 1501 to prevent loops in error reporting is to specify a null reverse-path 1502 in the MAIL command of a notification message. When such a message 1503 is transmitted, the reverse-path MUST be set to null (see 1504 1505 1506 1507 1509 1510 Internet-Draft RFC5321-Numbered Dec 2008 1511 1512 1513 Section 4.5.5 for additional discussion). A MAIL command with a null 1514 reverse-path appears as follows: 1515 1516 MAIL FROM:<> 1517 1518 As discussed in Section 6.4, a relay SMTP has no need to inspect or 1519 act upon the header section or body of the message data and MUST NOT 1520 do so except to add its own "Received:" header field (Section 4.4) 1521 and, optionally, to attempt to detect looping in the mail system (see 1522 Section 6.3). Of course, this prohibition also applies to any 1523 modifications of these header fields or text (see also Section 7.9). 1524 1525 3.7. Mail Gatewaying 1526 1527 While the relay function discussed above operates within the Internet 1528 SMTP transport service environment, MX records or various forms of 1529 explicit routing may require that an intermediate SMTP server perform 1530 a translation function between one transport service and another.As 1531 discussed in Section 2.3.10, when such a system is at the boundary 1532 between two transport service environments, we refer to it as a 1533 "gateway" or "gateway SMTP". 1534 1535 Gatewaying mail between different mail environments, such as 1536 different mail formats and protocols, is complex and does not easily 1537 yield to standardization. However, some general requirements maybe 1538 given for a gateway between the Internet and another mail 1539 environment. 1540 1541 3.7.1. Header Fields in Gatewaying 1542 1543 Header fields MAY be rewritten when necessary as messages are 1544 gatewayed across mail environment boundaries. This may involve 1545 inspecting the message body or interpreting the local-part of the 1546 destination address in spite of the prohibitions in Section 6.4. 1547 1548 Other mail systems gatewayed to the Internet often use a subset of 1549 the RFC 822 header section or provide similar functionality with a 1550 different syntax, but some of these mail systems do not have an 1551 equivalent to the SMTP envelope. Therefore, when a message leaves 1552 the Internet environment, it may be necessary to fold the SMTP 1553 envelope information into the message header section. A possible 1554 solution would be to create new header fields to carry the envelope 1555 information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this 1556 would require changes in mail programs in foreign environments and 1557 might risk disclosure of private information (see Section 7.2). 1558 1559 1560 1561 1562 1563 1565 1566 Internet-Draft RFC5321-Numbered Dec 2008 1567 1568 1569 3.7.2. Received Lines in Gatewaying 1570 1571 When forwarding a message into or out of the Internet environment, a 1572 gateway MUST prepend a Received: line, but it MUST NOT alter in any 1573 way a Received: line that is already in the header section. 1574 1575 "Received:" header fields of messages originating from other 1576 environments may not conform exactly to this specification. However, 1577 the most important use of Received: lines is for debugging mail 1578 faults, and this debugging can be severely hampered by well-meaning 1579 gateways that try to "fix" a Received: line. As another consequence 1580 of trace header fields arising in non-SMTP environments, receiving 1581 systems MUST NOT reject mail based on the format of a trace header 1582 field and SHOULD be extremely robust in the light of unexpected 1583 information or formats in those header fields. 1584 1585 The gateway SHOULD indicate the environment and protocol in the "via" 1586 clauses of Received header field(s) that it supplies. 1587 1588 3.7.3. Addresses in Gatewaying 1589 1590 From the Internet side, the gateway SHOULD accept all valid address 1591 formats in SMTP commands and in the RFC 822 header section, and all 1592 valid RFC 822 messages. Addresses and header fields generated by 1593 gateways MUST conform to applicable standards (including this oneand 1594 RFC 5322 [4]). Gateways are, of course, subject to the same rules 1595 for handling source routes as those described for other SMTP systems 1596 in Section 3.3. 1597 1598 3.7.4. Other Header Fields in Gatewaying 1599 1600 The gateway MUST ensure that all header fields of a message that it 1601 forwards into the Internet mail environment meet the requirementsfor 1602 Internet mail. In particular, all addresses in "From:", "To:", 1603 "Cc:", etc., header fields MUST be transformed (if necessary) to 1604 satisfy the standard header syntax of RFC 5322 [4], MUST reference 1605 only fully-qualified domain names, and MUST be effective and useful 1606 for sending replies. The translation algorithm used to convert m ail 1607 from the Internet protocols to another environment's protocol SHOULD 1608 ensure that error messages from the foreign mail environment are 1609 delivered to the reverse-path from the SMTP envelope, not to an 1610 address in the "From:", "Sender:", or similar header fields of the 1611 message. 1612 1613 1614 1615 1616 1617 1618 1619 1621 1622 Internet-Draft RFC5321-Numbered Dec 2008 1623 1624 1625 3.7.5. Envelopes in Gatewaying 1626 1627 Similarly, when forwarding a message from another environment into 1628 the Internet, the gateway SHOULD set the envelope return path in 1629 accordance with an error message return address, if supplied by the 1630 foreign environment. If the foreign environment has no equivalent 1631 concept, the gateway must select and use a best approximation, with 1632 the message originator's address as the default of last resort. 1633 1634 3.8. Terminating Sessions and Connections 1635 1636 An SMTP connection is terminated when the client sends a QUIT 1637 command. The server responds with a positive reply code, after which 1638 it closes the connection. 1639 1640 An SMTP server MUST NOT intentionally close the connection under 1641 normal operational circumstances (see Section 7.8) except: 1642 1643 o After receiving a QUIT command and responding with a 221 reply. 1644 1645 o After detecting the need to shut down the SMTP service and 1646 returning a 421 response code. This response code can be issued 1647 after the server receives any command or, if necessary, 1648 asynchronously from command receipt (on the assumption that the 1649 client will receive it after the next command is issued). 1650 1651 o After a timeout, as specified in Section 4.5.3.2, occurs waiting 1652 for the client to send a command or data. 1653 1654 In particular, a server that closes connections in response to 1655 commands that are not understood is in violation of this 1656 specification. Servers are expected to be tolerant of unknown 1657 commands, issuing a 500 reply and awaiting further instructions from 1658 the client. 1659 1660 An SMTP server that is forcibly shut down via external means SHOULD 1661 attempt to send a line containing a 421 response code to the SMTP 1662 client before exiting. The SMTP client will normally read the 421 1663 response code after sending its next command. 1664 1665 SMTP clients that experience a connection close, reset, or other 1666 communications failure due to circumstances not under their control 1667 (in violation of the intent of this specification but sometimes 1668 unavoidable) SHOULD, to maintain the robustness of the mail system, 1669 treat the mail transaction as if a 451 response had been receivedand 1670 act accordingly. 1671 1672 1673 1674 1675 1677 1678 Internet-Draft RFC5321-Numbered Dec 2008 1679 1680 1681 3.9. Mailing Lists and Aliases 1682 1683 An SMTP-capable host SHOULD support both the alias and the list 1684 models of address expansion for multiple delivery. When a message is 1685 delivered or forwarded to each address of an expanded list form, the 1686 return address in the envelope ("MAIL FROM:") MUST be changed to be 1687 the address of a person or other entity who administers the list. 1688 However, in this case, the message header section (RFC 5322 [4]) MUST 1689 be left unchanged; in particular, the "From" field of the header 1690 section is unaffected. 1691 1692 An important mail facility is a mechanism for multi-destination 1693 delivery of a single message, by transforming (or "expanding" or 1694 "exploding") a pseudo-mailbox address into a list of destination 1695 mailbox addresses. When a message is sent to such a pseudo-mailbox 1696 (sometimes called an "exploder"), copies are forwarded or 1697 redistributed to each mailbox in the expanded list. Servers SHOULD 1698 simply utilize the addresses on the list; application of heuristics 1699 or other matching rules to eliminate some addresses, such as thatof 1700 the originator, is strongly discouraged. We classify such a pseudo- 1701 mailbox as an "alias" or a "list", depending upon the expansion 1702 rules. 1703 1704 3.9.1. Alias 1705 1706 To expand an alias, the recipient mailer simply replaces the pseudo- 1707 mailbox address in the envelope with each of the expanded addresses 1708 in turn; the rest of the envelope and the message body are left 1709 unchanged. The message is then delivered or forwarded to each 1710 expanded address. 1711 1712 3.9.2. List 1713 1714 A mailing list may be said to operate by "redistribution" rather than 1715 by "forwarding". To expand a list, the recipient mailer replacesthe 1716 pseudo-mailbox address in the envelope with each of the expanded 1717 addresses in turn. The return (backward-pointing) address in the 1718 envelope is changed so that all error messages generated by the final 1719 deliveries will be returned to a list administrator, not to the 1720 message originator, who generally has no control over the contents of 1721 the list and will typically find error messages annoying. Note that 1722 the key difference between handling aliases (Section 3.9.1) and 1723 forwarding (this subsection) is the change to the backward-pointing 1724 address in this case. When a list constrains its processing to the 1725 very limited set of modifications and actions described here, it is 1726 attempting to emulate an MTA; such lists can be treated as a 1727 continuation in email transit. 1728 1729 1730 1731 1733 1734 Internet-Draft RFC5321-Numbered Dec 2008 1735 1736 1737 There exist mailing lists that perform additional, sometimes 1738 extensive, modifications to a message and its envelope. Such mailing 1739 lists need to be viewed as full MUAs, which accept a delivery and 1740 post a new message. 1741 1742 4. The SMTP Specifications 1743 1744 4.1. SMTP Commands 1745 1746 4.1.1. Command Semantics and Syntax 1747 1748 The SMTP commands define the mail transfer or the mail system 1749 function requested by the user. SMTP commands are character strings 1750 terminated by . The commands themselves are alphabetic 1751 characters terminated by if parameters follow and 1752 otherwise. (In the interest of improved interoperability, SMTP 1753 receivers SHOULD tolerate trailing white space before the terminating 1754 .) The syntax of the local part of a mailbox MUST conform to 1755 receiver site conventions and the syntax specified in Section 4.1.2. 1756 The SMTP commands are discussed below. The SMTP replies are 1757 discussed in Section 4.2. 1758 1759 A mail transaction involves several data objects that are 1760 communicated as arguments to different commands. The reverse-path is 1761 the argument of the MAIL command, the forward-path is the argument of 1762 the RCPT command, and the mail data is the argument of the DATA 1763 command. These arguments or data objects must be transmitted and 1764 held, pending the confirmation communicated by the end of mail data 1765 indication that finalizes the transaction. The model for this is 1766 that distinct buffers are provided to hold the types of data objects; 1767 that is, there is a reverse-path buffer, a forward-path buffer, and a 1768 mail data buffer. Specific commands cause information to be appended 1769 to a specific buffer, or cause one or more buffers to be cleared. 1770 1771 Several commands (RSET, DATA, QUIT) are specified as not permitting 1772 parameters. In the absence of specific extensions offered by the 1773 server and accepted by the client, clients MUST NOT send such 1774 parameters and servers SHOULD reject commands containing them as 1775 having invalid syntax. 1776 1777 4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO) 1778 1779 These commands are used to identify the SMTP client to the SMTP 1780 server. The argument clause contains the fully-qualified domain name 1781 of the SMTP client, if one is available. In situations in which the 1782 SMTP client system does not have a meaningful domain name (e.g., when 1783 its address is dynamically allocated and no reverse mapping record is 1784 1785 1786 1787 1789 1790 Internet-Draft RFC5321-Numbered Dec 2008 1791 1792 1793 available), the client SHOULD send an address literal (see 1794 Section 4.1.3). 1795 1796 RFC 2821, and some earlier informal practices, encouraged following 1797 the literal by information that would help to identify the client 1798 system. That convention was not widely supported, and many SMTP 1799 servers considered it an error. In the interest of interoperability, 1800 it is probably wise for servers to be prepared for this string to 1801 occur, but SMTP clients SHOULD NOT send it. 1802 1803 The SMTP server identifies itself to the SMTP client in the 1804 connection greeting reply and in the response to this command. 1805 1806 A client SMTP SHOULD start an SMTP session by issuing the EHLO 1807 command. If the SMTP server supports the SMTP service extensions, it 1808 will give a successful response, a failure response, or an error 1809 response. If the SMTP server, in violation of this specification, 1810 does not support any SMTP service extensions, it will generate an 1811 error response. Older client SMTP systems MAY, as discussed above, 1812 use HELO (as specified in RFC 821) instead of EHLO, and servers MUST 1813 support the HELO command and reply properly to it. In any event,a 1814 client MUST issue HELO or EHLO before starting a mail transaction. 1815 1816 These commands, and a "250 OK" reply to one of them, confirm that 1817 both the SMTP client and the SMTP server are in the initial state, 1818 that is, there is no transaction in progress and all state tablesand 1819 buffers are cleared. 1820 1821 Syntax: 1822 1823 ehlo = "EHLO" SP ( Domain / address-literal ) CRLF 1824 1825 helo = "HELO" SP Domain CRLF 1826 1827 Normally, the response to EHLO will be a multiline reply. Each line 1828 of the response contains a keyword and, optionally, one or more 1829 parameters. Following the normal syntax for multiline replies, these 1830 keywords follow the code (250) and a hyphen for all but the last 1831 line, and the code and a space for the last line. The syntax fora 1832 positive response, using the ABNF notation and terminal symbols of 1833 RFC 5234 [7], is: 1834 1835 ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF ) 1836 / ( "250-" Domain [ SP ehlo-greet ] CRLF 1837 *( "250-" ehlo-line CRLF ) 1838 "250" SP ehlo-line CRLF ) 1839 1840 1841 1842 1843 1845 1846 Internet-Draft RFC5321-Numbered Dec 2008 1847 1848 1849 ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127) 1850 ; string of any characters other than CR or LF 1851 1852 ehlo-line = ehlo-keyword *( SP ehlo-param ) 1853 1854 ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") 1855 ; additional syntax of ehlo-params depends on 1856 ; ehlo-keyword 1857 1858 ehlo-param = 1*(%d33-126) 1859 ; any CHAR excluding and all 1860 ; control characters (US-ASCII 0-31 and 127 1861 ; inclusive) 1862 1863 Although EHLO keywords may be specified in upper, lower, or mixed 1864 case, they MUST always be recognized and processed in a case- 1865 insensitive manner. This is simply an extension of practices 1866 specified in RFC 821 and Section 2.4. 1867 1868 The EHLO response MUST contain keywords (and associated parameters if 1869 required) for all commands not listed as "required" in Section 4.5.1 1870 excepting only private-use commands as described in Section 4.1.5. 1871 Private-use commands MAY be listed. 1872 1873 4.1.1.2. MAIL (MAIL) 1874 1875 This command is used to initiate a mail transaction in which the mail 1876 data is delivered to an SMTP server that may, in turn, deliver itto 1877 one or more mailboxes or pass it on to another system (possibly using 1878 SMTP). The argument clause contains a reverse-path and may contain 1879 optional parameters. In general, the MAIL command may be sent only 1880 when no mail transaction is in progress, see Section 4.1.4. 1881 1882 The reverse-path consists of the sender mailbox. Historically, that 1883 mailbox might optionally have been preceded by a list of hosts, but 1884 that behavior is now deprecated (see Appendix C). In some types of 1885 reporting messages for which a reply is likely to cause a mail loop 1886 (for example, mail delivery and non-delivery notifications), the 1887 reverse-path may be null (see Section 3.6). 1888 1889 This command clears the reverse-path buffer, the forward-path buffer, 1890 and the mail data buffer, and it inserts the reverse-path informa tion 1891 from its argument clause into the reverse-path buffer. 1892 1893 If service extensions were negotiated, the MAIL command may also 1894 carry parameters associated with a particular service extension. 1895 1896 1897 1898 1899 1901 1902 Internet-Draft RFC5321-Numbered Dec 2008 1903 1904 1905 Syntax: 1906 1907 mail = "MAIL FROM:" Reverse-path 1908 [SP Mail-parameters] CRLF 1909 1910 4.1.1.3. RECIPIENT (RCPT) 1911 1912 This command is used to identify an individual recipient of the mail 1913 data; multiple recipients are specified by multiple uses of this 1914 command. The argument clause contains a forward-path and may contain 1915 optional parameters. 1916 1917 The forward-path normally consists of the required destination 1918 mailbox. Sending systems SHOULD NOT generate the optional list of 1919 hosts known as a source route. Receiving systems MUST recognize 1920 source route syntax but SHOULD strip off the source route 1921 specification and utilize the domain name associated with the mailbox 1922 as if the source route had not been provided. 1923 1924 Similarly, relay hosts SHOULD strip or ignore source routes, and 1925 names MUST NOT be copied into the reverse-path. When mail reaches 1926 its ultimate destination (the forward-path contains only a 1927 destination mailbox), the SMTP server inserts it into the destination 1928 mailbox in accordance with its host mail conventions. 1929 1930 This command appends its forward-path argument to the forward-path 1931 buffer; it does not change the reverse-path buffer nor the mail data 1932 buffer. 1933 1934 For example, mail received at relay host xyz.com with envelope 1935 commands 1936 1937 MAIL FROM: 1938 RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> 1939 1940 will normally be sent directly on to host d.bar.org with envelope 1941 commands 1942 1943 MAIL FROM: 1944 RCPT TO: 1945 1946 As provided in Appendix C, xyz.com MAY also choose to relay the 1947 message to hosta.int, using the envelope commands 1948 1949 MAIL FROM: 1950 RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> 1951 1952 1953 1954 1955 1957 1958 Internet-Draft RFC5321-Numbered Dec 2008 1959 1960 1961 or to jkl.org, using the envelope commands 1962 1963 MAIL FROM: 1964 RCPT TO:<@jkl.org:userc@d.bar.org> 1965 1966 Attempting to use relaying this way is now strongly discouraged. 1967 Since hosts are not required to relay mail at all, xyz.com MAY also 1968 reject the message entirely when the RCPT command is received, using 1969 a 550 code (since this is a "policy reason"). 1970 1971 If service extensions were negotiated, the RCPT command may also 1972 carry parameters associated with a particular service extension 1973 offered by the server. The client MUST NOT transmit parameters other 1974 than those associated with a service extension offered by the server 1975 in its EHLO response. 1976 1977 Syntax: 1978 1979 rcpt = "RCPT TO:" ( "" / ""/ 1980 Forward-path ) [SP Rcpt-parameters] CRLF 1981 1982 Note that, in a departure from the usual rules for 1983 local-parts, the "Postmaster" string shown above is 1984 treated as case-insensitive. 1985 1986 4.1.1.4. DATA (DATA) 1987 1988 The receiver normally sends a 354 response to DATA, and then treats 1989 the lines (strings ending in sequences, as described in 1990 Section 2.3.7) following the command as mail data from the sender. 1991 This command causes the mail data to be appended to the mail data 1992 buffer. The mail data may contain any of the 128 ASCII character 1993 codes, although experience has indicated that use of control 1994 characters other than SP, HT, CR, and LF may cause problems and 1995 SHOULD be avoided when possible. 1996 1997 The mail data are terminated by a line containing only a period, that 1998 is, the character sequence ".", where the first is 1999 actually the terminator of the previous line (see Section 4.5.2). 2000 This is the end of mail data indication. The first of this 2001 terminating sequence is also the that ends the final line of 2002 the data (message text) or, if there was no mail data, ends the DATA 2003 command itself (the "no mail data" case does not conform to this 2004 specification since it would require that neither the trace header 2005 fields required by this specification nor the message header section 2006 required by RFC 5322 [4] be transmitted). An extra MUST NOT 2007 be added, as that would cause an empty line to be added to the 2008 message. The only exception to this rule would arise if the message 2009 2010 2011 2013 2014 Internet-Draft RFC5321-Numbered Dec 2008 2015 2016 2017 body were passed to the originating SMTP-sender with a final "line" 2018 that did not end in ; in that case, the originating SMTP system 2019 MUST either reject the message as invalid or add in order to 2020 have the receiving SMTP server recognize the "end of data" condition. 2021 2022 The custom of accepting lines ending only in , as a concession to 2023 non-conforming behavior on the part of some UNIX systems, has proven 2024 to cause more interoperability problems than it solves, and SMTP 2025 server systems MUST NOT do this, even in the name of improved 2026 robustness. In particular, the sequence "." (bare line 2027 feeds, without carriage returns) MUST NOT be treated as equivalent to 2028 . as the end of mail data indication. 2029 2030 Receipt of the end of mail data indication requires the server to 2031 process the stored mail transaction information. This processing 2032 consumes the information in the reverse-path buffer, the forward-path 2033 buffer, and the mail data buffer, and on the completion of this 2034 command these buffers are cleared. If the processing is successful, 2035 the receiver MUST send an OK reply. If the processing fails, the 2036 receiver MUST send a failure reply. The SMTP model does not allow 2037 for partial failures at this point: either the message is accepted by 2038 the server for delivery and a positive response is returned or itis 2039 not accepted and a failure reply is returned. In sending a positive 2040 "250 OK" completion reply to the end of data indication, the receiver 2041 takes full responsibility for the message (see Section 6.1). Errors 2042 that are diagnosed subsequently MUST be reported in a mail message, 2043 as discussed in Section 4.4. 2044 2045 When the SMTP server accepts a message either for relaying or for 2046 final delivery, it inserts a trace record (also referred to 2047 interchangeably as a "time stamp line" or "Received" line) at thetop 2048 of the mail data. This trace record indicates the identity of the 2049 host that sent the message, the identity of the host that received 2050 the message (and is inserting this time stamp), and the date and time 2051 the message was received. Relayed messages will have multiple ti me 2052 stamp lines. Details for formation of these lines, including their 2053 syntax, is specified in Section 4.4. 2054 2055 Additional discussion about the operation of the DATA command appears 2056 in Section 3.3. 2057 2058 Syntax: 2059 2060 data = "DATA" CRLF 2061 2062 2063 2064 2065 2066 2067 2069 2070 Internet-Draft RFC5321-Numbered Dec 2008 2071 2072 2073 4.1.1.5. RESET (RSET) 2074 2075 This command specifies that the current mail transaction will be 2076 aborted. Any stored sender, recipients, and mail data MUST be 2077 discarded, and all buffers and state tables cleared. The receiver 2078 MUST send a "250 OK" reply to a RSET command with no arguments. A 2079 reset command may be issued by the client at any time. It is 2080 effectively equivalent to a NOOP (i.e., it has no effect) if issued 2081 immediately after EHLO, before EHLO is issued in the session, after 2082 an end of data indicator has been sent and acknowledged, or 2083 immediately before a QUIT. An SMTP server MUST NOT close the 2084 connection as the result of receiving a RSET; that action is reserved 2085 for QUIT (see Section 4.1.1.10). 2086 2087 Since EHLO implies some additional processing and response by the 2088 server, RSET will normally be more efficient than reissuing that 2089 command, even though the formal semantics are the same. 2090 2091 There are circumstances, contrary to the intent of this 2092 specification, in which an SMTP server may receive an indication that 2093 the underlying TCP connection has been closed or reset. To preserve 2094 the robustness of the mail system, SMTP servers SHOULD be prepared 2095 for this condition and SHOULD treat it as if a QUIT had been received 2096 before the connection disappeared. 2097 2098 Syntax: 2099 2100 rset = "RSET" CRLF 2101 2102 4.1.1.6. VERIFY (VRFY) 2103 2104 This command asks the receiver to confirm that the argument 2105 identifies a user or mailbox. If it is a user name, information is 2106 returned as specified in Section 3.5. 2107 2108 This command has no effect on the reverse-path buffer, the forward- 2109 path buffer, or the mail data buffer. 2110 2111 Syntax: 2112 2113 vrfy = "VRFY" SP String CRLF 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2125 2126 Internet-Draft RFC5321-Numbered Dec 2008 2127 2128 2129 4.1.1.7. EXPAND (EXPN) 2130 2131 This command asks the receiver to confirm that the argument 2132 identifies a mailing list, and if so, to return the membership of 2133 that list. If the command is successful, a reply is returned 2134 containing information as described in Section 3.5. This reply will 2135 have multiple lines except in the trivial case of a one-member list. 2136 2137 This command has no effect on the reverse-path buffer, the forward- 2138 path buffer, or the mail data buffer, and it may be issued at any 2139 time. 2140 2141 Syntax: 2142 2143 expn = "EXPN" SP String CRLF 2144 2145 4.1.1.8. HELP (HELP) 2146 2147 This command causes the server to send helpful information to the 2148 client. The command MAY take an argument (e.g., any command name) 2149 and return more specific information as a response. 2150 2151 This command has no effect on the reverse-path buffer, the forward- 2152 path buffer, or the mail data buffer, and it may be issued at any 2153 time. 2154 2155 SMTP servers SHOULD support HELP without arguments and MAY support it 2156 with arguments. 2157 2158 Syntax: 2159 2160 help = "HELP" [ SP String ] CRLF 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2181 2182 Internet-Draft RFC5321-Numbered Dec 2008 2183 2184 2185 4.1.1.9. NOOP (NOOP) 2186 2187 This command does not affect any parameters or previously entered 2188 commands. It specifies no action other than that the receiver send a 2189 "250 OK" reply. 2190 2191 This command has no effect on the reverse-path buffer, the forward- 2192 path buffer, or the mail data buffer, and it may be issued at any 2193 time. If a parameter string is specified, servers SHOULD ignore it. 2194 2195 Syntax: 2196 2197 noop = "NOOP" [ SP String ] CRLF 2198 2199 4.1.1.10. QUIT (QUIT) 2200 2201 This command specifies that the receiver MUST send a "221 OK" reply, 2202 and then close the transmission channel. 2203 2204 The receiver MUST NOT intentionally close the transmission channel 2205 until it receives and replies to a QUIT command (even if there was an 2206 error). The sender MUST NOT intentionally close the transmission 2207 channel until it sends a QUIT command, and it SHOULD wait until it 2208 receives the reply (even if there was an error response to a previous 2209 command). If the connection is closed prematurely due to violations 2210 of the above or system or network failure, the server MUST cancelany 2211 pending transaction, but not undo any previously completed 2212 transaction, and generally MUST act as if the command or transaction 2213 in progress had received a temporary error (i.e., a 4yz response). 2214 2215 The QUIT command may be issued at any time. Any current uncompleted 2216 mail transaction will be aborted. 2217 2218 Syntax: 2219 2220 quit = "QUIT" CRLF 2221 2222 4.1.1.11. Mail-Parameter and Rcpt-Parameter Error Responses 2223 2224 If the server SMTP does not recognize or cannot implement one or more 2225 of the parameters associated with a particular MAIL FROM or RCPT TO 2226 command, it will return code 555. 2227 2228 If, for some reason, the server is temporarily unable to accommodate 2229 one or more of the parameters associated with a MAIL FROM or RCPTTO 2230 command, and if the definition of the specific parameter does not 2231 mandate the use of another code, it should return code 455. 2232 2233 2234 2235 2237 2238 Internet-Draft RFC5321-Numbered Dec 2008 2239 2240 2241 Errors specific to particular parameters and their values will be 2242 specified in the parameter's defining RFC. 2243 2244 4.1.2. Command Argument Syntax 2245 2246 The syntax of the argument clauses of the above commands (using the 2247 syntax specified in RFC 5234 [7] where applicable) is given below. 2248 Some of the productions given below are used only in conjunction with 2249 source routes as described in Appendix C. Terminals not defined in 2250 this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined 2251 in the "core" syntax in Section 6 of RFC 5234 [7] or in the message 2252 format syntax in RFC 5322 [4]. 2253 2254 Reverse-path = Path / "<>" 2255 2256 Forward-path = Path 2257 2258 Path = "<" [ A-d-l ":" ] Mailbox ">" 2259 2260 A-d-l = At-domain *( "," At-domain ) 2261 ; Note that this form, the so-called "source 2262 ; route", MUST BE accepted, SHOULD NOT be 2263 ; generated, and SHOULD be ignored. 2264 2265 At-domain = "@" Domain 2266 2267 Mail-parameters = esmtp-param *(SP esmtp-param) 2268 2269 Rcpt-parameters = esmtp-param *(SP esmtp-param) 2270 2271 esmtp-param = esmtp-keyword ["=" esmtp-value] 2272 2273 esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") 2274 2275 esmtp-value = 1*(%d33-60 / %d62-126) 2276 ; any CHAR excluding "=", SP, and control 2277 ; characters. If this string is an email address, 2278 ; i.e., a Mailbox, then the "xtext" syntax [32] 2279 ; SHOULD be used. 2280 2281 Keyword = Ldh-str 2282 2283 Argument = Atom 2284 2285 Domain = sub-domain *("." sub-domain) 2286 2287 2288 2289 2290 2291 2293 2294 Internet-Draft RFC5321-Numbered Dec 2008 2295 2296 2297 sub-domain = Let-dig [Ldh-str] 2298 2299 Let-dig = ALPHA / DIGIT 2300 2301 Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig 2302 2303 address-literal = "[" ( IPv4-address-literal / 2304 IPv6-address-literal / 2305 General-address-literal ) "]" 2306 ; See Section 4.1.3 2307 2308 Mailbox = Local-part "@" ( Domain / address-literal ) 2309 2310 Local-part = Dot-string / Quoted-string 2311 ; MAY be case-sensitive 2312 2313 2314 Dot-string = Atom *("." Atom) 2315 2316 Atom = 1*atext 2317 2318 Quoted-string = DQUOTE *QcontentSMTP DQUOTE 2319 2320 QcontentSMTP = qtextSMTP / quoted-pairSMTP 2321 2322 quoted-pairSMTP = %d92 %d32-126 2323 ; i.e., backslash followed by any ASCII 2324 ; graphic (including itself) or SPace 2325 2326 qtextSMTP = %d32-33 / %d35-91 / %d93-126 2327 ; i.e., within a quoted string, any 2328 ; ASCII graphic or space is permitted 2329 ; without blackslash-quoting except 2330 ; double-quote and the backslash itself. 2331 2332 String = Atom / Quoted-string 2333 2334 While the above definition for Local-part is relatively permissive, 2335 for maximum interoperability, a host that expects to receive mail 2336 SHOULD avoid defining mailboxes where the Local-part requires (or 2337 uses) the Quoted-string form or where the Local-part is case- 2338 sensitive. For any purposes that require generating or comparing 2339 Local-parts (e.g., to specific mailbox names), all quoted forms MUST 2340 be treated as equivalent, and the sending system SHOULD transmit the 2341 form that uses the minimum quoting possible. 2342 2343 Systems MUST NOT define mailboxes in such a way as to require theuse 2344 in SMTP of non-ASCII characters (octets with the high order bit set 2345 2346 2347 2349 2350 Internet-Draft RFC5321-Numbered Dec 2008 2351 2352 2353 to one) or ASCII "control characters" (decimal value 0-31 and 127). 2354 These characters MUST NOT be used in MAIL or RCPT commands or other 2355 commands that require mailbox names. 2356 2357 Note that the backslash, "\", is a quote character, which is usedto 2358 indicate that the next character is to be used literally (insteadof 2359 its normal interpretation). For example, "Joe\,Smith" indicates a 2360 single nine-character user name string with the comma being the 2361 fourth character of that string. 2362 2363 To promote interoperability and consistent with long-standing 2364 guidance about conservative use of the DNS in naming and applications 2365 (e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [2]), 2366 characters outside the set of alphabetic characters, digits, and 2367 hyphen MUST NOT appear in domain name labels for SMTP clients or 2368 servers. In particular, the underscore character is not permitted. 2369 SMTP servers that receive a command in which invalid character codes 2370 have been employed, and for which there are no other reasons for 2371 rejection, MUST reject that command with a 501 response (this rule, 2372 like others, could be overridden by appropriate SMTP extensions). 2373 2374 4.1.3. Address Literals 2375 2376 Sometimes a host is not known to the domain name system and 2377 communication (and, in particular, communication to report and repair 2378 the error) is blocked. To bypass this barrier, a special literal 2379 form of the address is allowed as an alternative to a domain name. 2380 For IPv4 addresses, this form uses four small decimal integers 2381 separated by dots and enclosed by brackets such as [123.255.37.2], 2382 which indicates an (IPv4) Internet Address in sequence-of-octets 2383 form. For IPv6 and other forms of addressing that might eventually 2384 be standardized, the form consists of a standardized "tag" that 2385 identifies the address syntax, a colon, and the address itself, in a 2386 format specified as part of the relevant standards (i.e., RFC 4291 2387 [8] for IPv6). 2388 2389 Specifically: 2390 2391 IPv4-address-literal = Snum 3("." Snum) 2392 2393 IPv6-address-literal = "IPv6:" IPv6-addr 2394 2395 General-address-literal = Standardized-tag ":" 1*dcontent 2396 2397 Standardized-tag = Ldh-str 2398 ; Standardized-tag MUST be specified in a 2399 ; Standards-Track RFC and registered with IANA 2400 2401 2402 2403 2405 2406 Internet-Draft RFC5321-Numbered Dec 2008 2407 2408 2409 dcontent = %d33-90 / ; Printable US-ASCII 2410 %d94-126 ; excl. "[", "\", "]" 2411 2412 Snum = 1*3DIGIT 2413 ; representing a decimal integer 2414 ; value in the range 0 through 255 2415 2416 IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp 2417 2418 IPv6-hex = 1*4HEXDIG 2419 2420 IPv6-full = IPv6-hex 7(":" IPv6-hex) 2421 2422 IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" 2423 [IPv6-hex *5(":" IPv6-hex)] 2424 ; The "::" represents at least 2 16-bit groups of 2425 ; zeros. No more than 6 groups in addition to the 2426 ; "::" may be present. 2427 2428 IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal 2429 2430 IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::" 2431 [IPv6-hex *3(":" IPv6-hex) ":"] 2432 IPv4-address-literal 2433 ; The "::" represents at least 2 16-bit groups of 2434 ; zeros. No more than 4 groups in addition to the 2435 ; "::" and IPv4-address-literal may be present. 2436 2437 4.1.4. Order of Commands 2438 2439 There are restrictions on the order in which these commands may be 2440 used. 2441 2442 A session that will contain mail transactions MUST first be 2443 initialized by the use of the EHLO command. An SMTP server SHOULD 2444 accept commands for non-mail transactions (e.g., VRFY or EXPN) 2445 without this initialization. 2446 2447 An EHLO command MAY be issued by a client later in the session. If 2448 it is issued after the session begins and the EHLO command is 2449 acceptable to the SMTP server, the SMTP server MUST clear all buffers 2450 and reset the state exactly as if a RSET command had been issued.In 2451 other words, the sequence of RSET followed immediately by EHLO is 2452 redundant, but not harmful other than in the performance cost of 2453 executing unnecessary commands. 2454 2455 If the EHLO command is not acceptable to the SMTP server, 501, 500, 2456 502, or 550 failure replies MUST be returned as appropriate. The 2457 2458 2459 2461 2462 Internet-Draft RFC5321-Numbered Dec 2008 2463 2464 2465 SMTP server MUST stay in the same state after transmitting these 2466 replies that it was in before the EHLO was received. 2467 2468 The SMTP client MUST, if possible, ensure that the domain parameter 2469 to the EHLO command is a primary host name as specified for this 2470 command in Section 2.3.5. If this is not possible (e.g., when the 2471 client's address is dynamically assigned and the client does not have 2472 an obvious name), an address literal SHOULD be substituted for the 2473 domain name. 2474 2475 An SMTP server MAY verify that the domain name argument in the EHLO 2476 command actually corresponds to the IP address of the client. 2477 However, if the verification fails, the server MUST NOT refuse to 2478 accept a message on that basis. Information captured in the 2479 verification attempt is for logging and tracing purposes. Note that 2480 this prohibition applies to the matching of the parameter to its IP 2481 address only; see Section 7.9 for a more extensive discussion of 2482 rejecting incoming connections or mail messages. 2483 2484 The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time 2485 during a session, or without previously initializing a session. SMTP 2486 servers SHOULD process these normally (that is, not return a 503 2487 code) even if no EHLO command has yet been received; clients SHOULD 2488 open a session with EHLO before sending these commands. 2489 2490 If these rules are followed, the example in RFC 821 that shows "550 2491 access denied to you" in response to an EXPN command is incorrect 2492 unless an EHLO command precedes the EXPN or the denial of access is 2493 based on the client's IP address or other authentication or 2494 authorization-determining mechanisms. 2495 2496 The MAIL command (or the obsolete SEND, SOML, or SAML commands) 2497 begins a mail transaction. Once started, a mail transaction consists 2498 of a transaction beginning command, one or more RCPT commands, and a 2499 DATA command, in that order. A mail transaction may be aborted by 2500 the RSET, a new EHLO, or the QUIT command. There may be zero or more 2501 transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be 2502 sent if a mail transaction is already open, i.e., it should be se nt 2503 only if no mail transaction had been started in the session, or if 2504 the previous one successfully concluded with a successful DATA 2505 command, or if the previous one was aborted, e.g., with a RSET ornew 2506 EHLO. 2507 2508 If the transaction beginning command argument is not acceptable, a 2509 501 failure reply MUST be returned and the SMTP server MUST stay in 2510 the same state. If the commands in a transaction are out of order to 2511 the degree that they cannot be processed by the server, a 503 failure 2512 2513 2514 2515 2517 2518 Internet-Draft RFC5321-Numbered Dec 2008 2519 2520 2521 reply MUST be returned and the SMTP server MUST stay in the same 2522 state. 2523 2524 The last command in a session MUST be the QUIT command. The QUIT 2525 command SHOULD be used by the client SMTP to request connection 2526 closure, even when no session opening command was sent and accepted. 2527 2528 4.1.5. Private-Use Commands 2529 2530 As specified in Section 2.2.2, commands starting in "X" may be used 2531 by bilateral agreement between the client (sending) and server 2532 (receiving) SMTP agents. An SMTP server that does not recognize such 2533 a command is expected to reply with "500 Command not recognized".An 2534 extended SMTP server MAY list the feature names associated with these 2535 private commands in the response to the EHLO command. 2536 2537 Commands sent or accepted by SMTP systems that do not start with "X" 2538 MUST conform to the requirements of Section 2.2.2. 2539 2540 4.2. SMTP Replies 2541 2542 Replies to SMTP commands serve to ensure the synchronization of 2543 requests and actions in the process of mail transfer and to guarantee 2544 that the SMTP client always knows the state of the SMTP server. 2545 Every command MUST generate exactly one reply. 2546 2547 The details of the command-reply sequence are described in 2548 Section 4.3. 2549 2550 An SMTP reply consists of a three digit number (transmitted as three 2551 numeric characters) followed by some text unless specified otherwise 2552 in this document. The number is for use by automata to determine 2553 what state to enter next; the text is for the human user. The three 2554 digits contain enough encoded information that the SMTP client need 2555 not examine the text and may either discard it or pass it on to the 2556 user, as appropriate. Exceptions are as noted elsewhere in this 2557 document. In particular, the 220, 221, 251, 421, and 551 reply codes 2558 are associated with message text that must be parsed and interpreted 2559 by machines. In the general case, the text may be receiver dependent 2560 and context dependent, so there are likely to be varying texts fo r 2561 each reply code. A discussion of the theory of reply codes is given 2562 in Section 4.2.1. Formally, a reply is defined to be the sequence: a 2563 three-digit code, , one line of text, and , or a multiline 2564 reply (as defined in the same section). Since, in violation of this 2565 specification, the text is sometimes not sent, clients that do not 2566 receive it SHOULD be prepared to process the code alone (with or 2567 without a trailing space character). Only the EHLO, EXPN, and HELP 2568 commands are expected to result in multiline replies in normal 2569 2570 2571 2573 2574 Internet-Draft RFC5321-Numbered Dec 2008 2575 2576 2577 circumstances; however, multiline replies are allowed for any 2578 command. 2579 2580 In ABNF, server responses are: 2581 2582 Greeting = ( "220 " (Domain / address-literal) 2583 [ SP textstring ] CRLF ) / 2584 ( "220-" (Domain / address-literal) 2585 [ SP textstring ] CRLF 2586 *( "220-" [ textstring ] CRLF ) 2587 "220" [ SP textstring ] CRLF ) 2588 2589 textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII 2590 2591 Reply-line = *( Reply-code "-" [ textstring ] CRLF ) 2592 Reply-code [ SP textstring ] CRLF 2593 2594 Reply-code = %x32-35 %x30-35 %x30-39 2595 2596 where "Greeting" appears only in the 220 response that announces that 2597 the server is opening its part of the connection. (Other possible 2598 server responses upon connection follow the syntax of Reply-line.) 2599 2600 An SMTP server SHOULD send only the reply codes listed in this 2601 document. An SMTP server SHOULD use the text shown in the examples 2602 whenever appropriate. 2603 2604 An SMTP client MUST determine its actions only by the reply code,not 2605 by the text (except for the "change of address" 251 and 551 and, if 2606 necessary, 220, 221, and 421 replies); in the general case, any text, 2607 including no text at all (although senders SHOULD NOT send bare 2608 codes), MUST be acceptable. The space (blank) following the reply 2609 code is considered part of the text. Whenever possible, a receiver- 2610 SMTP SHOULD test the first digit (severity indication) of the reply 2611 code. 2612 2613 The list of codes that appears below MUST NOT be construed as 2614 permanent. While the addition of new codes should be a rare and 2615 significant activity, with supplemental information in the textual 2616 part of the response being preferred, new codes may be added as the 2617 result of new Standards or Standards-Track specifications. 2618 Consequently, a sender-SMTP MUST be prepared to handle codes not 2619 specified in this document and MUST do so by interpreting the fir st 2620 digit only. 2621 2622 In the absence of extensions negotiated with the client, SMTP servers 2623 MUST NOT send reply codes whose first digits are other than 2, 3,4, 2624 2625 2626 2627 2629 2630 Internet-Draft RFC5321-Numbered Dec 2008 2631 2632 2633 or 5. Clients that receive such out-of-range codes SHOULD normally 2634 treat them as fatal errors and terminate the mail transaction. 2635 2636 4.2.1. Reply Code Severities and Theory 2637 2638 The three digits of the reply each have a special significance. The 2639 first digit denotes whether the response is good, bad, or incomplete. 2640 An unsophisticated SMTP client, or one that receives an unexpected 2641 code, will be able to determine its next action (proceed as planned, 2642 redo, retrench, etc.) by examining this first digit. An SMTP client 2643 that wants to know approximately what kind of error occurred (e.g., 2644 mail system error, command syntax error) may examine the second 2645 digit. The third digit and any supplemental information that maybe 2646 present is reserved for the finest gradation of information. 2647 2648 There are four values for the first digit of the reply code: 2649 2650 2yz Positive Completion reply 2651 The requested action has been successfully completed. A new 2652 request may be initiated. 2653 2654 3yz Positive Intermediate reply 2655 The command has been accepted, but the requested action is being 2656 held in abeyance, pending receipt of further information. The 2657 SMTP client should send another command specifying this 2658 information. This reply is used in command sequence groups (i.e., 2659 in DATA). 2660 2661 4yz Transient Negative Completion reply 2662 The command was not accepted, and the requested action did not 2663 occur. However, the error condition is temporary, and the action 2664 may be requested again. The sender should return to the beginning 2665 of the command sequence (if any). It is difficult to assign a 2666 meaning to "transient" when two different sites (receiver- and 2667 sender-SMTP agents) must agree on the interpretation. Each reply 2668 in this category might have a different time value, but the SMTP 2669 client SHOULD try again. A rule of thumb to determine whethera 2670 reply fits into the 4yz or the 5yz category (see below) is that 2671 replies are 4yz if they can be successful if repeated without any 2672 change in command form or in properties of the sender or receiver 2673 (that is, the command is repeated identically and the receiver 2674 does not put up a new implementation). 2675 2676 5yz Permanent Negative Completion reply 2677 The command was not accepted and the requested action did not 2678 occur. The SMTP client SHOULD NOT repeat the exact request (in 2679 the same sequence). Even some "permanent" error conditions can be 2680 corrected, so the human user may want to direct the SMTP client to 2681 2682 2683 2685 2686 Internet-Draft RFC5321-Numbered Dec 2008 2687 2688 2689 reinitiate the command sequence by direct action at some pointin 2690 the future (e.g., after the spelling has been changed, or the user 2691 has altered the account status). 2692 2693 It is worth noting that the file transfer protocol (FTP) [34] uses a 2694 very similar code architecture and that the SMTP codes are based on 2695 the FTP model. However, SMTP uses a one-command, one-response model 2696 (while FTP is asynchronous) and FTP's 1yz codes are not part of the 2697 SMTP model. 2698 2699 The second digit encodes responses in specific categories: 2700 2701 x0z Syntax: These replies refer to syntax errors, syntactically 2702 correct commands that do not fit any functional category, and 2703 unimplemented or superfluous commands. 2704 2705 x1z Information: These are replies to requests for information, such 2706 as status or help. 2707 2708 x2z Connections: These are replies referring to the transmission 2709 channel. 2710 2711 x3z Unspecified. 2712 2713 x4z Unspecified. 2714 2715 x5z Mail system: These replies indicate the status of the receiver 2716 mail system vis-a-vis the requested transfer or other mail system 2717 action. 2718 2719 The third digit gives a finer gradation of meaning in each category 2720 specified by the second digit. The list of replies illustrates this. 2721 Each reply text is recommended rather than mandatory, and may even 2722 change according to the command with which it is associated. On the 2723 other hand, the reply codes must strictly follow the specifications 2724 in this section. Receiver implementations should not invent new 2725 codes for slightly different situations from the ones described here, 2726 but rather adapt codes already defined. 2727 2728 For example, a command such as NOOP, whose successful execution d oes 2729 not offer the SMTP client any new information, will return a 250 2730 reply. The reply is 502 when the command requests an unimplemented 2731 non-site-specific action. A refinement of that is the 504 reply for 2732 a command that is implemented, but that requests an unimplemented 2733 parameter. 2734 2735 2736 2737 2738 2739 2741 2742 Internet-Draft RFC5321-Numbered Dec 2008 2743 2744 2745 The reply text may be longer than a single line; in these cases the 2746 complete text must be marked so the SMTP client knows when it can 2747 stop reading the reply. This requires a special format to indicate a 2748 multiple line reply. 2749 2750 The format for multiline replies requires that every line, exceptthe 2751 last, begin with the reply code, followed immediately by a hyphen, 2752 "-" (also known as minus), followed by text. The last line will 2753 begin with the reply code, followed immediately by , optionally 2754 some text, and . As noted above, servers SHOULD send the 2755 if subsequent text is not sent, but clients MUST be prepared for it 2756 to be omitted. 2757 2758 For example: 2759 2760 250-First line 2761 250-Second line 2762 250-234 Text beginning with numbers 2763 250 The last line 2764 2765 In a multiline reply, the reply code on each of the lines MUST bethe 2766 same. It is reasonable for the client to rely on this, so it can 2767 make processing decisions based on the code in any line, assuming 2768 that all others will be the same. In a few cases, there is important 2769 data for the client in the reply "text". The client will be ableto 2770 identify these cases from the current context. 2771 2772 4.2.2. Reply Codes by Function Groups 2773 2774 500 Syntax error, command unrecognized (This may include errors such 2775 as command line too long) 2776 2777 501 Syntax error in parameters or arguments 2778 2779 502 Command not implemented (see Section 4.2.4) 2780 2781 503 Bad sequence of commands 2782 2783 504 Command parameter not implemented 2784 2785 2786 211 System status, or system help reply 2787 2788 214 Help message (Information on how to use the receiver or the 2789 meaning of a particular non-standard command; this reply is useful 2790 only to the human user) 2791 2792 2793 2794 2795 2797 2798 Internet-Draft RFC5321-Numbered Dec 2008 2799 2800 2801 220 Service ready 2802 2803 221 Service closing transmission channel 2804 2805 421 Service not available, closing transmission channel 2806 (This may be a reply to any command if the service knows it must 2807 shut down) 2808 2809 2810 250 Requested mail action okay, completed 2811 2812 251 User not local; will forward to (See Section 3.4) 2813 2814 252 Cannot VRFY user, but will accept message and attempt delivery 2815 (See Section 3.5.3) 2816 2817 455 Server unable to accommodate parameters 2818 2819 555 MAIL FROM/RCPT TO parameters not recognized or not implemented 2820 2821 450 Requested mail action not taken: mailbox unavailable (e.g., 2822 mailbox busy or temporarily blocked for policy reasons) 2823 2824 550 Requested action not taken: mailbox unavailable (e.g., mailbox 2825 not found, no access, or command rejected for policy reasons) 2826 2827 451 Requested action aborted: error in processing 2828 2829 551 User not local; please try (See Section 3.4) 2830 2831 452 Requested action not taken: insufficient system storage 2832 2833 552 Requested mail action aborted: exceeded storage allocation 2834 2835 553 Requested action not taken: mailbox name not allowed (e.g., 2836 mailbox syntax incorrect) 2837 2838 354 Start mail input; end with . 2839 2840 554 Transaction failed (Or, in the case of a connection-opening 2841 response, "No SMTP service here") 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2853 2854 Internet-Draft RFC5321-Numbered Dec 2008 2855 2856 2857 4.2.3. Reply Codes in Numeric Order 2858 2859 211 System status, or system help reply 2860 2861 214 Help message (Information on how to use the receiver or the 2862 meaning of a particular non-standard command; this reply is useful 2863 only to the human user) 2864 2865 220 Service ready 2866 2867 221 Service closing transmission channel 2868 2869 250 Requested mail action okay, completed 2870 2871 251 User not local; will forward to (See Section 3.4) 2872 2873 252 Cannot VRFY user, but will accept message and attempt delivery 2874 (See Section 3.5.3) 2875 2876 354 Start mail input; end with . 2877 2878 421 Service not available, closing transmission channel 2879 (This may be a reply to any command if the service knows it must 2880 shut down) 2881 2882 450 Requested mail action not taken: mailbox unavailable (e.g., 2883 mailbox busy or temporarily blocked for policy reasons) 2884 2885 451 Requested action aborted: local error in processing 2886 2887 452 Requested action not taken: insufficient system storage 2888 2889 455 Server unable to accommodate parameters 2890 2891 500 Syntax error, command unrecognized (This may include errors such 2892 as command line too long) 2893 2894 501 Syntax error in parameters or arguments 2895 2896 502 Command not implemented (see Section 4.2.4) 2897 2898 503 Bad sequence of commands 2899 2900 504 Command parameter not implemented 2901 2902 550 Requested action not taken: mailbox unavailable (e.g., mailbox 2903 not found, no access, or command rejected for policy reasons) 2904 2905 2906 2907 2909 2910 Internet-Draft RFC5321-Numbered Dec 2008 2911 2912 2913 551 User not local; please try (See Section 3.4) 2914 2915 552 Requested mail action aborted: exceeded storage allocation 2916 2917 553 Requested action not taken: mailbox name not allowed (e.g., 2918 mailbox syntax incorrect) 2919 2920 554 Transaction failed (Or, in the case of a connection-opening 2921 response, "No SMTP service here") 2922 2923 555 MAIL FROM/RCPT TO parameters not recognized or not implemented 2924 2925 4.2.4. Reply Code 502 2926 2927 Questions have been raised as to when reply code 502 (Command not 2928 implemented) SHOULD be returned in preference to other codes. 502 2929 SHOULD be used when the command is actually recognized by the SMTP 2930 server, but not implemented. If the command is not recognized, code 2931 500 SHOULD be returned. Extended SMTP systems MUST NOT list 2932 capabilities in response to EHLO for which they will return 502 (or 2933 500) replies. 2934 2935 4.2.5. Reply Codes after DATA and the Subsequent . 2936 2937 When an SMTP server returns a positive completion status (2yz code) 2938 after the DATA command is completed with ., it accepts 2939 responsibility for: 2940 2941 o delivering the message (if the recipient mailbox exists), or 2942 2943 o if attempts to deliver the message fail due to transient 2944 conditions, retrying delivery some reasonable number of times at 2945 intervals as specified in Section 4.5.4. 2946 2947 o if attempts to deliver the message fail due to permanent 2948 conditions, or if repeated attempts to deliver the message fail 2949 due to transient conditions, returning appropriate notification to 2950 the sender of the original message (using the address in the SMTP 2951 MAIL command). 2952 2953 When an SMTP server returns a temporary error status (4yz) code after 2954 the DATA command is completed with ., it MUST NOT make a 2955 subsequent attempt to deliver that message. The SMTP client reta ins 2956 responsibility for the delivery of that message and may either return 2957 it to the user or requeue it for a subsequent attempt (see 2958 Section 4.5.4.1). 2959 2960 2961 2962 2963 2965 2966 Internet-Draft RFC5321-Numbered Dec 2008 2967 2968 2969 The user who originated the message SHOULD be able to interpret the 2970 return of a transient failure status (by mail message or otherwise) 2971 as a non-delivery indication, just as a permanent failure would be 2972 interpreted. If the client SMTP successfully handles these 2973 conditions, the user will not receive such a reply. 2974 2975 When an SMTP server returns a permanent error status (5yz) code after 2976 the DATA command is completed with ., it MUST NOT make 2977 any subsequent attempt to deliver the message. As with temporary 2978 error status codes, the SMTP client retains responsibility for the 2979 message, but SHOULD not again attempt delivery to the same server 2980 without user review of the message and response and appropriate 2981 intervention. 2982 2983 4.3. Sequencing of Commands and Replies 2984 2985 4.3.1. Sequencing Overview 2986 2987 The communication between the sender and receiver is an alternating 2988 dialogue, controlled by the sender. As such, the sender issues a 2989 command and the receiver responds with a reply. Unless other 2990 arrangements are negotiated through service extensions, the sender 2991 MUST wait for this response before sending further commands. One 2992 important reply is the connection greeting. Normally, a receiver 2993 will send a 220 "Service ready" reply when the connection is 2994 completed. The sender SHOULD wait for this greeting message before 2995 sending any commands. 2996 2997 Note: all the greeting-type replies have the official name (the 2998 fully-qualified primary domain name) of the server host as the first 2999 word following the reply code. Sometimes the host will have no 3000 meaningful name. See Section 4.1.3 for a discussion of alternatives 3001 in these situations. 3002 3003 For example, 3004 3005 220 ISIF.USC.EDU Service ready 3006 3007 or 3008 3009 220 mail.example.com SuperSMTP v 6.1.2 Service ready 3010 3011 or 3012 3013 220 [10.0.0.1] Clueless host service ready 3014 3015 The table below lists alternative success and failure replies for 3016 each command. These SHOULD be strictly adhered to. A receiver MAY 3017 3018 3019 3021 3022 Internet-Draft RFC5321-Numbered Dec 2008 3023 3024 3025 substitute text in the replies, but the meanings and actions implied 3026 by the code numbers and by the specific command reply sequence MUST 3027 be preserved. 3028 3029 4.3.2. Command-Reply Sequences 3030 3031 Each command is listed with its usual possible replies. The prefixes 3032 used before the possible replies are "I" for intermediate, "S" for 3033 success, and "E" for error. Since some servers may generate other 3034 replies under special circumstances, and to allow for future 3035 extension, SMTP clients SHOULD, when possible, interpret only the 3036 first digit of the reply and MUST be prepared to deal with 3037 unrecognized reply codes by interpreting the first digit only. 3038 Unless extended using the mechanisms described in Section 2.2, SMTP 3039 servers MUST NOT transmit reply codes to an SMTP client that are 3040 other than three digits or that do not start in a digit between 2and 3041 5 inclusive. 3042 3043 These sequencing rules and, in principle, the codes themselves, can 3044 be extended or modified by SMTP extensions offered by the server and 3045 accepted (requested) by the client. However, if the target is more 3046 precise granularity in the codes, rather than codes for completely 3047 new purposes, the system described in RFC 3463 [25] SHOULD be used in 3048 preference to the invention of new codes. 3049 3050 In addition to the codes listed below, any SMTP command can return 3051 any of the following codes if the corresponding unusual circumstances 3052 are encountered: 3053 3054 500 For the "command line too long" case or if the command name was 3055 not recognized. Note that producing a "command not recognized" 3056 error in response to the required subset of these commands is a 3057 violation of this specification. Similarly, producing a "command 3058 too long" message for a command line shorter than 512 characters 3059 would violate the provisions of Section 4.5.3.1.4. 3060 3061 501 Syntax error in command or arguments. In order to provide for 3062 future extensions, commands that are specified in this document as 3063 not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 3064 message if arguments are supplied in the absence of EHLO- 3065 advertised extensions. 3066 3067 421 Service shutting down and closing transmission channel 3068 3069 3070 3071 3072 3073 3074 3075 3077 3078 Internet-Draft RFC5321-Numbered Dec 2008 3079 3080 3081 Specific sequences are: 3082 3083 CONNECTION ESTABLISHMENT 3084 3085 S: 220 3086 E: 554 3087 3088 EHLO or HELO 3089 3090 S: 250 3091 E: 504 (a conforming implementation could return this code only 3092 in fairly obscure cases), 550, 502 (permitted only with an old- 3093 style server that does not support EHLO) 3094 3095 MAIL 3096 3097 S: 250 3098 E: 552, 451, 452, 550, 553, 503, 455, 555 3099 3100 RCPT 3101 3102 S: 250, 251 (but see Section 3.4 for discussion of 251 and 551) 3103 E: 550, 551, 552, 553, 450, 451, 452, 503, 455, 555 3104 3105 DATA 3106 3107 I: 354 -> data -> S: 250 3108 3109 E: 552, 554, 451, 452 3110 3111 E: 450, 550 (rejections for policy reasons) 3112 3113 E: 503, 554 3114 3115 RSET 3116 3117 S: 250 3118 3119 VRFY 3120 3121 S: 250, 251, 252 3122 E: 550, 551, 553, 502, 504 3123 3124 EXPN 3125 3126 S: 250, 252 3127 E: 550, 500, 502, 504 3128 3129 3130 3131 3133 3134 Internet-Draft RFC5321-Numbered Dec 2008 3135 3136 3137 HELP 3138 3139 S: 211, 214 3140 E: 502, 504 3141 3142 NOOP 3143 3144 S: 250 3145 3146 QUIT 3147 3148 S: 221 3149 3150 4.4. Trace Information 3151 3152 When an SMTP server receives a message for delivery or further 3153 processing, it MUST insert trace ("time stamp" or "Received") 3154 information at the beginning of the message content, as discussedin 3155 Section 4.1.1.4. 3156 3157 This line MUST be structured as follows: 3158 3159 o The FROM clause, which MUST be supplied in an SMTP environment, 3160 SHOULD contain both (1) the name of the source host as presented 3161 in the EHLO command and (2) an address literal containing the IP 3162 address of the source, determined from the TCP connection. 3163 3164 o The ID clause MAY contain an "@" as suggested in RFC 822, but this 3165 is not required. 3166 3167 o If the FOR clause appears, it MUST contain exactly one 3168 entry, even when multiple RCPT commands have been given. Multiple 3169 s raise some security issues and have been deprecated, see 3170 Section 7.2. 3171 3172 An Internet mail program MUST NOT change or delete a Received: line 3173 that was previously added to the message header section. SMTP 3174 servers MUST prepend Received lines to messages; they MUST NOT change 3175 the order of existing lines or insert Received lines in any other 3176 location. 3177 3178 As the Internet grows, comparability of Received header fields is 3179 important for detecting problems, especially slow relays. SMTP 3180 servers that create Received header fields SHOULD use explicit 3181 offsets in the dates (e.g., -0800), rather than time zone names of 3182 any type. Local time (with an offset) SHOULD be used rather thanUT 3183 when feasible. This formulation allows slightly more information 3184 about local circumstances to be specified. If UT is needed, the 3185 3186 3187 3189 3190 Internet-Draft RFC5321-Numbered Dec 2008 3191 3192 3193 receiver need merely do some simple arithmetic to convert the values. 3194 Use of UT loses information about the time zone-location of the 3195 server. If it is desired to supply a time zone name, it SHOULD be 3196 included in a comment. 3197 3198 When the delivery SMTP server makes the "final delivery" of a 3199 message, it inserts a return-path line at the beginning of the mail 3200 data. This use of return-path is required; mail systems MUST support 3201 it. The return-path line preserves the information in the from the MAIL command. Here, final delivery means the message 3203 has left the SMTP environment. Normally, this would mean it had been 3204 delivered to the destination user or an associated mail drop, butin 3205 some cases it may be further processed and transmitted by another 3206 mail system. 3207 3208 It is possible for the mailbox in the return path to be different 3209 from the actual sender's mailbox, for example, if error responsesare 3210 to be delivered to a special error handling mailbox rather than to 3211 the message sender. When mailing lists are involved, this 3212 arrangement is common and useful as a means of directing errors to 3213 the list maintainer rather than the message originator. 3214 3215 The text above implies that the final mail data will begin with a 3216 return path line, followed by one or more time stamp lines. These 3217 lines will be followed by the rest of the mail data: first the 3218 balance of the mail header section and then the body (RFC 5322 [4]). 3219 3220 It is sometimes difficult for an SMTP server to determine whetheror 3221 not it is making final delivery since forwarding or other operations 3222 may occur after the message is accepted for delivery. Consequently, 3223 any further (forwarding, gateway, or relay) systems MAY remove the 3224 return path and rebuild the MAIL command as needed to ensure that 3225 exactly one such line appears in a delivered message. 3226 3227 A message-originating SMTP system SHOULD NOT send a message that 3228 already contains a Return-path header field. SMTP servers performing 3229 a relay function MUST NOT inspect the message data, and especiall y 3230 not to the extent needed to determine if Return-path header fields 3231 are present. SMTP servers making final delivery MAY remove Return- 3232 path header fields before adding their own. 3233 3234 The primary purpose of the Return-path is to designate the address to 3235 which messages indicating non-delivery or other mail system failures 3236 are to be sent. For this to be unambiguous, exactly one return path 3237 SHOULD be present when the message is delivered. Systems using RFC 3238 822 syntax with non-SMTP transports SHOULD designate an unambiguous 3239 address, associated with the transport envelope, to which error 3240 reports (e.g., non-delivery messages) should be sent. 3241 3242 3243 3245 3246 Internet-Draft RFC5321-Numbered Dec 2008 3247 3248 3249 Historical note: Text in RFC 822 that appears to contradict the use 3250 of the Return-path header field (or the envelope reverse-path address 3251 from the MAIL command) as the destination for error messages is not 3252 applicable on the Internet. The reverse-path address (as copied into 3253 the Return-path) MUST be used as the target of any mail containing 3254 delivery error messages. 3255 3256 In particular: 3257 o a gateway from SMTP -> elsewhere SHOULD insert a return-path 3258 header field, unless it is known that the "elsewhere" transport 3259 also uses Internet domain addresses and maintains the envelope 3260 sender address separately. 3261 3262 o a gateway from elsewhere -> SMTP SHOULD delete any return-path 3263 header field present in the message, and either copy that 3264 information to the SMTP envelope or combine it with information 3265 present in the envelope of the other transport system to construct 3266 the reverse-path argument to the MAIL command in the SMTP 3267 envelope. 3268 3269 The server must give special treatment to cases in which the 3270 processing following the end of mail data indication is only 3271 partially successful. This could happen if, after accepting several 3272 recipients and the mail data, the SMTP server finds that the mail 3273 data could be successfully delivered to some, but not all, of the 3274 recipients. In such cases, the response to the DATA command MUSTbe 3275 an OK reply. However, the SMTP server MUST compose and send an 3276 "undeliverable mail" notification message to the originator of the 3277 message. 3278 3279 A single notification listing all of the failed recipients or 3280 separate notification messages MUST be sent for each failed 3281 recipient. For economy of processing by the sender, the former 3282 SHOULD be used when possible. Note that the key difference between 3283 handling aliases (Section 3.9.1) and forwarding (this subsection)is 3284 the change to the backward-pointing address in this case. All 3285 notification messages about undeliverable mail MUST be sent usingthe 3286 MAIL command (even if they result from processing the obsolete SEND, 3287 SOML, or SAML commands) and MUST use a null return path as discussed 3288 in Section 3.6. 3289 3290 The time stamp line and the return path line are formally definedas 3291 follows (the definitions for "FWS" and "CFWS" appear in RFC 5322 3292 [4]): 3293 3294 Return-path-line = "Return-Path:" FWS Reverse-path 3295 3296 Time-stamp-line = "Received:" FWS Stamp 3297 3298 3299 3301 3302 Internet-Draft RFC5321-Numbered Dec 2008 3303 3304 3305 Stamp = From-domain By-domain Opt-info [CFWS] ";" 3306 FWS date-time 3307 ; where "date-time" is as defined in RFC 5322 [4] 3308 ; but the "obs-" forms, especially two-digit 3309 ; years, are prohibited in SMTP and MUST NOT be used. 3310 3311 From-domain = "FROM" FWS Extended-Domain 3312 3313 By-domain = CFWS "BY" FWS Extended-Domain 3314 3315 Extended-Domain = Domain / 3316 ( Domain FWS "(" TCP-info ")" ) / 3317 ( address-literal FWS "(" TCP-info ")" ) 3318 3319 TCP-info = address-literal / ( Domain FWS address-literal ) 3320 ; Information derived by server from TCP connection 3321 ; not client EHLO. 3322 3323 Opt-info = [Via] [With] [ID] [For] 3324 [Additional-Registered-Clauses] 3325 3326 Via = CFWS "VIA" FWS Link 3327 3328 With = CFWS "WITH" FWS Protocol 3329 3330 ID = CFWS "ID" FWS ( Atom / msg-id ) 3331 ; msg-id is defined in RFC 5322 [4] 3332 3333 For = CFWS "FOR" FWS ( Path / Mailbox ) 3334 3335 Additional-Registered-Clauses = CFWS Atom FWS String 3336 ; Additional standard clauses may be 3337 added in this 3338 ; location by future standards and 3339 registration with 3340 ; IANA. SMTP servers SHOULD NOT use 3341 unregistered 3342 ; names. See Section 8. 3343 3344 Link = "TCP" / Addtl-Link 3345 3346 Addtl-Link = Atom 3347 ; Additional standard names for links are 3348 ; registered with the Internet Assigned Numbers 3349 ; Authority (IANA). "Via" is primarily of value 3350 ; with non-Internet transports. SMTP servers 3351 ; SHOULD NOT use unregistered names. 3352 3353 3354 3355 3357 3358 Internet-Draft RFC5321-Numbered Dec 2008 3359 3360 3361 Protocol = "ESMTP" / "SMTP" / Attdl-Protocol 3362 3363 Attdl-Protocol = Atom 3364 ; Additional standard names for protocols are 3365 ; registered with the Internet Assigned Numbers 3366 ; Authority (IANA) in the "mail parameters" 3367 ; registry [9]. SMTP servers SHOULD NOT 3368 ; use unregistered names. 3369 3370 4.5. Additional Implementation Issues 3371 3372 4.5.1. Minimum Implementation 3373 3374 In order to make SMTP workable, the following minimum implementation 3375 MUST be provided by all receivers. The following commands MUST be 3376 supported to conform to this specification: 3377 3378 EHLO 3379 HELO 3380 MAIL 3381 RCPT 3382 DATA 3383 RSET 3384 NOOP 3385 QUIT 3386 VRFY 3387 3388 Any system that includes an SMTP server supporting mail relaying or 3389 delivery MUST support the reserved mailbox "postmaster" as a case- 3390 insensitive local name. This postmaster address is not strictly 3391 necessary if the server always returns 554 on connection opening (as 3392 described in Section 3.1). The requirement to accept mail for 3393 postmaster implies that RCPT commands that specify a mailbox for 3394 postmaster at any of the domains for which the SMTP server provides 3395 mail service, as well as the special case of "RCPT TO:" 3396 (with no domain specification), MUST be supported. 3397 3398 SMTP systems are expected to make every reasonable effort to accept 3399 mail directed to Postmaster from any other system on the Internet. 3400 In extreme cases -- such as to contain a denial of service attackor 3401 other breach of security -- an SMTP server may block mail directed to 3402 Postmaster. However, such arrangements SHOULD be narrowly tailored 3403 so as to avoid blocking messages that are not part of such attack s. 3404 3405 3406 3407 3408 3409 3410 3411 3413 3414 Internet-Draft RFC5321-Numbered Dec 2008 3415 3416 3417 4.5.2. Transparency 3418 3419 Without some provision for data transparency, the character sequence 3420 "." ends the mail text and cannot be sent by the user. 3421 In general, users are not aware of such "forbidden" sequences. To 3422 allow all user composed text to be transmitted transparently, the 3423 following procedures are used: 3424 3425 o Before sending a line of mail text, the SMTP client checks the 3426 first character of the line. If it is a period, one additional 3427 period is inserted at the beginning of the line. 3428 3429 o When a line of mail text is received by the SMTP server, it checks 3430 the line. If the line is composed of a single period, it is 3431 treated as the end of mail indicator. If the first character is a 3432 period and there are other characters on the line, the first 3433 character is deleted. 3434 3435 The mail data may contain any of the 128 ASCII characters. All 3436 characters are to be delivered to the recipient's mailbox, including 3437 spaces, vertical and horizontal tabs, and other control characters. 3438 If the transmission channel provides an 8-bit byte (octet) data 3439 stream, the 7-bit ASCII codes are transmitted, right justified, in 3440 the octets, with the high-order bits cleared to zero. See 3441 Section 3.6 for special treatment of these conditions in SMTP systems 3442 serving a relay function. 3443 3444 In some systems, it may be necessary to transform the data as it is 3445 received and stored. This may be necessary for hosts that use a 3446 different character set than ASCII as their local character set, that 3447 store data in records rather than strings, or which use special 3448 character sequences as delimiters inside mailboxes. If such 3449 transformations are necessary, they MUST be reversible, especially if 3450 they are applied to mail being relayed. 3451 3452 4.5.3. Sizes and Timeouts 3453 3454 4.5.3.1. Size Limits and Minimums 3455 3456 There are several objects that have required minimum/maximum sizes. 3457 Every implementation MUST be able to receive objects of at least 3458 these sizes. Objects larger than these sizes SHOULD be avoided when 3459 possible. However, some Internet mail constructs such as encoded 3460 X.400 addresses (RFC 2156 [35]) will often require larger objects. 3461 Clients MAY attempt to transmit these, but MUST be prepared for a 3462 server to reject them if they cannot be handled by it. To the 3463 maximum extent possible, implementation techniques that impose no 3464 limits on the length of these objects should be used. 3465 3466 3467 3469 3470 Internet-Draft RFC5321-Numbered Dec 2008 3471 3472 3473 Extensions to SMTP may involve the use of characters that occupy more 3474 than a single octet each. This section therefore specifies lengths 3475 in octets where absolute lengths, rather than character counts, are 3476 intended. 3477 3478 4.5.3.1.1. Local-part 3479 3480 The maximum total length of a user name or other local-part is 64 3481 octets. 3482 3483 4.5.3.1.2. Domain 3484 3485 The maximum total length of a domain name or number is 255 octets. 3486 3487 4.5.3.1.3. Path 3488 3489 The maximum total length of a reverse-path or forward-path is 256 3490 octets (including the punctuation and element separators). 3491 3492 4.5.3.1.4. Command Line 3493 3494 The maximum total length of a command line including the command word 3495 and the is 512 octets. SMTP extensions may be used to 3496 increase this limit. 3497 3498 4.5.3.1.5. Reply Line 3499 3500 The maximum total length of a reply line including the reply codeand 3501 the is 512 octets. More information may be conveyed through 3502 multiple-line replies. 3503 3504 4.5.3.1.6. Text Line 3505 3506 The maximum total length of a text line including the is 1000 3507 octets (not counting the leading dot duplicated for transparency). 3508 This number may be increased by the use of SMTP Service Extensions. 3509 3510 4.5.3.1.7. Message Content 3511 3512 The maximum total length of a message content (including any message 3513 header section as well as the message body) MUST BE at least 64K 3514 octets. Since the introduction of Internet Standards for multimedia 3515 mail (RFC 2045 [21]), message lengths on the Internet have grown 3516 dramatically, and message size restrictions should be avoided if at 3517 all possible. SMTP server systems that must impose restrictions 3518 SHOULD implement the "SIZE" service extension of RFC 1870 [10], and 3519 SMTP client systems that will send large messages SHOULD utilize it 3520 when possible. 3521 3522 3523 3525 3526 Internet-Draft RFC5321-Numbered Dec 2008 3527 3528 3529 4.5.3.1.8. Recipients Buffer 3530 3531 The minimum total number of recipients that MUST be buffered is 100 3532 recipients. Rejection of messages (for excessive recipients) with 3533 fewer than 100 RCPT commands is a violation of this specification. 3534 The general principle that relaying SMTP server MUST NOT, and 3535 delivery SMTP servers SHOULD NOT, perform validation tests on message 3536 header fields suggests that messages SHOULD NOT be rejected basedon 3537 the total number of recipients shown in header fields. A server that 3538 imposes a limit on the number of recipients MUST behave in an orderly 3539 fashion, such as rejecting additional addresses over its limit rather 3540 than silently discarding addresses previously accepted. A client 3541 that needs to deliver a message containing over 100 RCPT commands 3542 SHOULD be prepared to transmit in 100-recipient "chunks" if the 3543 server declines to accept more than 100 recipients in a single 3544 message. 3545 3546 4.5.3.1.9. Treatment When Limits Exceeded 3547 3548 Errors due to exceeding these limits may be reported by using the 3549 reply codes. Some examples of reply codes are: 3550 3551 500 Line too long. 3552 3553 or 3554 3555 501 Path too long 3556 3557 or 3558 3559 452 Too many recipients (see below) 3560 3561 or 3562 3563 552 Too much mail data. 3564 3565 4.5.3.1.10. Too Many Recipients Code 3566 3567 RFC 821 [1] incorrectly listed the error where an SMTP server 3568 exhausts its implementation limit on the number of RCPT commands 3569 ("too many recipients") as having reply code 552. The correct reply 3570 code for this condition is 452. Clients SHOULD treat a 552 code in 3571 this case as a temporary, rather than permanent, failure so the logic 3572 below works. 3573 3574 When a conforming SMTP server encounters this condition, it has at 3575 least 100 successful RCPT commands in its recipients buffer. If the 3576 server is able to accept the message, then at least these 100 3577 3578 3579 3581 3582 Internet-Draft RFC5321-Numbered Dec 2008 3583 3584 3585 addresses will be removed from the SMTP client's queue. When the 3586 client attempts retransmission of those addresses that received 452 3587 responses, at least 100 of these will be able to fit in the SMTP 3588 server's recipients buffer. Each retransmission attempt that is able 3589 to deliver anything will be able to dispose of at least 100 of these 3590 recipients. 3591 3592 If an SMTP server has an implementation limit on the number of RCPT 3593 commands and this limit is exhausted, it MUST use a response codeof 3594 452 (but the client SHOULD also be prepared for a 552, as noted 3595 above). If the server has a configured site-policy limitation onthe 3596 number of RCPT commands, it MAY instead use a 5yz response code. In 3597 particular, if the intent is to prohibit messages with more than a 3598 site-specified number of recipients, rather than merely limit the 3599 number of recipients in a given mail transaction, it would be 3600 reasonable to return a 503 response to any DATA command received 3601 subsequent to the 452 (or 552) code or to simply return the 503 after 3602 DATA without returning any previous negative response. 3603 3604 4.5.3.2. Timeouts 3605 3606 An SMTP client MUST provide a timeout mechanism. It MUST use per- 3607 command timeouts rather than somehow trying to time the entire mail 3608 transaction. Timeouts SHOULD be easily reconfigurable, preferably 3609 without recompiling the SMTP code. To implement this, a timer isset 3610 for each SMTP command and for each buffer of the data transfer. The 3611 latter means that the overall timeout is inherently proportional to 3612 the size of the message. 3613 3614 Based on extensive experience with busy mail-relay hosts, the minimum 3615 per-command timeout values SHOULD be as follows: 3616 3617 4.5.3.2.1. Initial 220 Message: 5 Minutes 3618 3619 An SMTP client process needs to distinguish between a failed TCP 3620 connection and a delay in receiving the initial 220 greeting message. 3621 Many SMTP servers accept a TCP connection but delay delivery of the 3622 220 message until their system load permits more mail to be 3623 processed. 3624 3625 4.5.3.2.2. MAIL Command: 5 Minutes 3626 3627 4.5.3.2.3. RCPT Command: 5 Minutes 3628 3629 A longer timeout is required if processing of mailing lists and 3630 aliases is not deferred until after the message was accepted. 3631 3632 3633 3634 3635 3637 3638 Internet-Draft RFC5321-Numbered Dec 2008 3639 3640 3641 4.5.3.2.4. DATA Initiation: 2 Minutes 3642 3643 This is while awaiting the "354 Start Input" reply to a DATA command. 3644 3645 4.5.3.2.5. Data Block: 3 Minutes 3646 3647 This is while awaiting the completion of each TCP SEND call 3648 transmitting a chunk of data. 3649 3650 4.5.3.2.6. DATA Termination: 10 Minutes. 3651 3652 This is while awaiting the "250 OK" reply. When the receiver gets 3653 the final period terminating the message data, it typically performs 3654 processing to deliver the message to a user mailbox. A spurious 3655 timeout at this point would be very wasteful and would typically 3656 result in delivery of multiple copies of the message, since it has 3657 been successfully sent and the server has accepted responsibilityfor 3658 delivery. See Section 6.1 for additional discussion. 3659 3660 4.5.3.2.7. Server Timeout: 5 Minutes. 3661 3662 An SMTP server SHOULD have a timeout of at least 5 minutes while it 3663 is awaiting the next command from the sender. 3664 3665 4.5.4. Retry Strategies 3666 3667 The common structure of a host SMTP implementation includes user 3668 mailboxes, one or more areas for queuing messages in transit, andone 3669 or more daemon processes for sending and receiving mail. The exact 3670 structure will vary depending on the needs of the users on the host 3671 and the number and size of mailing lists supported by the host. We 3672 describe several optimizations that have proved helpful, particularly 3673 for mailers supporting high traffic levels. 3674 3675 Any queuing strategy MUST include timeouts on all activities on a 3676 per-command basis. A queuing strategy MUST NOT send error messages 3677 in response to error messages under any circumstances. 3678 3679 4.5.4.1. Sending Strategy 3680 3681 The general model for an SMTP client is one or more processes that 3682 periodically attempt to transmit outgoing mail. In a typical sys tem, 3683 the program that composes a message has some method for requesting 3684 immediate attention for a new piece of outgoing mail, while mail that 3685 cannot be transmitted immediately MUST be queued and periodically 3686 retried by the sender. A mail queue entry will include not only the 3687 message itself but also the envelope information. 3688 3689 3690 3691 3693 3694 Internet-Draft RFC5321-Numbered Dec 2008 3695 3696 3697 The sender MUST delay retrying a particular destination after one 3698 attempt has failed. In general, the retry interval SHOULD be at 3699 least 30 minutes; however, more sophisticated and variable strategies 3700 will be beneficial when the SMTP client can determine the reason for 3701 non-delivery. 3702 3703 Retries continue until the message is transmitted or the sender gives 3704 up; the give-up time generally needs to be at least 4-5 days. ItMAY 3705 be appropriate to set a shorter maximum number of retries for non- 3706 delivery notifications and equivalent error messages than for 3707 standard messages. The parameters to the retry algorithm MUST be 3708 configurable. 3709 3710 A client SHOULD keep a list of hosts it cannot reach and 3711 corresponding connection timeouts, rather than just retrying queued 3712 mail items. 3713 3714 Experience suggests that failures are typically transient (the target 3715 system or its connection has crashed), favoring a policy of two 3716 connection attempts in the first hour the message is in the queue, 3717 and then backing off to one every two or three hours. 3718 3719 The SMTP client can shorten the queuing delay in cooperation withthe 3720 SMTP server. For example, if mail is received from a particular 3721 address, it is likely that mail queued for that host can now be sent. 3722 Application of this principle may, in many cases, eliminate the 3723 requirement for an explicit "send queues now" function such as ETRN, 3724 RFC 1985 [36]. 3725 3726 The strategy may be further modified as a result of multiple 3727 addresses per host (see below) to optimize delivery time versus 3728 resource usage. 3729 3730 An SMTP client may have a large queue of messages for each 3731 unavailable destination host. If all of these messages were retried 3732 in every retry cycle, there would be excessive Internet overhead and 3733 the sending system would be blocked for a long period. Note thatan 3734 SMTP client can generally determine that a delivery attempt has 3735 failed only after a timeout of several minutes, and even a one-minute 3736 timeout per connection will result in a very large delay if retri es 3737 are repeated for dozens, or even hundreds, of queued messages to the 3738 same host. 3739 3740 At the same time, SMTP clients SHOULD use great care in caching 3741 negative responses from servers. In an extreme case, if EHLO is 3742 issued multiple times during the same SMTP connection, different 3743 answers may be returned by the server. More significantly, 5yz 3744 responses to the MAIL command MUST NOT be cached. 3745 3746 3747 3749 3750 Internet-Draft RFC5321-Numbered Dec 2008 3751 3752 3753 When a mail message is to be delivered to multiple recipients, and 3754 the SMTP server to which a copy of the message is to be sent is the 3755 same for multiple recipients, then only one copy of the message 3756 SHOULD be transmitted. That is, the SMTP client SHOULD use the 3757 command sequence: MAIL, RCPT, RCPT, ..., RCPT, DATA instead of the 3758 sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there 3759 are very many addresses, a limit on the number of RCPT commands per 3760 MAIL command MAY be imposed. This efficiency feature SHOULD be 3761 implemented. 3762 3763 Similarly, to achieve timely delivery, the SMTP client MAY support 3764 multiple concurrent outgoing mail transactions. However, some limit 3765 may be appropriate to protect the host from devoting all its 3766 resources to mail. 3767 3768 4.5.4.2. Receiving Strategy 3769 3770 The SMTP server SHOULD attempt to keep a pending listen on the SMTP 3771 port (specified by IANA as port 25) at all times. This requires the 3772 support of multiple incoming TCP connections for SMTP. Some limit 3773 MAY be imposed, but servers that cannot handle more than one SMTP 3774 transaction at a time are not in conformance with the intent of this 3775 specification. 3776 3777 As discussed above, when the SMTP server receives mail from a 3778 particular host address, it could activate its own SMTP queuing 3779 mechanisms to retry any mail pending for that host address. 3780 3781 4.5.5. Messages with a Null Reverse-Path 3782 3783 There are several types of notification messages that are required by 3784 existing and proposed Standards to be sent with a null reverse-path, 3785 namely non-delivery notifications as discussed in Section 3.7, other 3786 kinds of Delivery Status Notifications (DSNs, RFC 3461 [32]), and 3787 Message Disposition Notifications (MDNs, RFC 3798 [37]). All of 3788 these kinds of messages are notifications about a previous message, 3789 and they are sent to the reverse-path of the previous mail message. 3790 (If the delivery of such a notification message fails, that usually 3791 indicates a problem with the mail system of the host to which the 3792 notification message is addressed. For this reason, at some hosts 3793 the MTA is set up to forward such failed notification messages to 3794 someone who is able to fix problems with the mail system, e.g., via 3795 the postmaster alias.) 3796 3797 All other types of messages (i.e., any message which is not required 3798 by a Standards-Track RFC to have a null reverse-path) SHOULD be sent 3799 with a valid, non-null reverse-path. 3800 3801 3802 3803 3805 3806 Internet-Draft RFC5321-Numbered Dec 2008 3807 3808 3809 Implementers of automated email processors should be careful to make 3810 sure that the various kinds of messages with a null reverse-path are 3811 handled correctly. In particular, such systems SHOULD NOT reply to 3812 messages with a null reverse-path, and they SHOULD NOT add a non-null 3813 reverse-path, or change a null reverse-path to a non-null one, to 3814 such messages when forwarding. 3815 3816 5. Address Resolution and Mail Handling 3817 3818 5.1. Locating the Target Host 3819 3820 Once an SMTP client lexically identifies a domain to which mail will 3821 be delivered for processing (as described in Sections 2.3.5 and 3.6), 3822 a DNS lookup MUST be performed to resolve the domain name (RFC 1035 3823 [2]). The names are expected to be fully-qualified domain names 3824 (FQDNs): mechanisms for inferring FQDNs from partial names or local 3825 aliases are outside of this specification. Due to a history of 3826 problems, SMTP servers used for initial submission of messages SHOULD 3827 NOT make such inferences (Message Submission Servers [18] have 3828 somewhat more flexibility) and intermediate (relay) SMTP servers MUST 3829 NOT make them. 3830 3831 The lookup first attempts to locate an MX record associated with the 3832 name. If a CNAME record is found, the resulting name is processed as 3833 if it were the initial name. If a non-existent domain error is 3834 returned, this situation MUST be reported as an error. If a 3835 temporary error is returned, the message MUST be queued and retried 3836 later (see Section 4.5.4.1). If an empty list of MXs is returned, 3837 the address is treated as if it was associated with an implicit MX 3838 RR, with a preference of 0, pointing to that host. If MX recordsare 3839 present, but none of them are usable, or the implicit MX is unusable, 3840 this situation MUST be reported as an error. 3841 3842 If one or more MX RRs are found for a given name, SMTP systems MUST 3843 NOT utilize any address RRs associated with that name unless theyare 3844 located using the MX RRs; the "implicit MX" rule above applies on ly 3845 if there are no MX records present. If MX records are present, but 3846 none of them are usable, this situation MUST be reported as an error. 3847 3848 When a domain name associated with an MX RR is looked up and the 3849 associated data field obtained, the data field of that response MUST 3850 contain a domain name. That domain name, when queried, MUST return 3851 at least one address record (e.g., A or AAAA RR) that gives the IP 3852 address of the SMTP server to which the message should be directed. 3853 Any other response, specifically including a value that will return a 3854 CNAME record when queried, lies outside the scope of this Standard. 3855 The prohibition on labels in the data that resolve to CNAMEs is 3856 discussed in more detail in RFC 2181, Section 10.3 [38]. 3857 3858 3859 3861 3862 Internet-Draft RFC5321-Numbered Dec 2008 3863 3864 3865 When the lookup succeeds, the mapping can result in a list of 3866 alternative delivery addresses rather than a single address, because 3867 of multiple MX records, multihoming, or both. To provide reliable 3868 mail transmission, the SMTP client MUST be able to try (and retry) 3869 each of the relevant addresses in this list in order, until a 3870 delivery attempt succeeds. However, there MAY also be a configurable 3871 limit on the number of alternate addresses that can be tried. Inany 3872 case, the SMTP client SHOULD try at least two addresses. 3873 3874 Two types of information are used to rank the host addresses: 3875 multiple MX records, and multihomed hosts. 3876 3877 MX records contain a preference indication that MUST be used in 3878 sorting if more than one such record appears (see below). Lower 3879 numbers are more preferred than higher ones. If there are multiple 3880 destinations with the same preference and there is no clear reason to 3881 favor one (e.g., by recognition of an easily reached address), then 3882 the sender-SMTP MUST randomize them to spread the load across 3883 multiple mail exchangers for a specific organization. 3884 3885 The destination host (perhaps taken from the preferred MX record)may 3886 be multihomed, in which case the domain name resolver will returna 3887 list of alternative IP addresses. It is the responsibility of the 3888 domain name resolver interface to have ordered this list by 3889 decreasing preference if necessary, and the SMTP sender MUST try them 3890 in the order presented. 3891 3892 Although the capability to try multiple alternative addresses is 3893 required, specific installations may want to limit or disable theuse 3894 of alternative addresses. The question of whether a sender should 3895 attempt retries using the different addresses of a multihomed host 3896 has been controversial. The main argument for using the multiple 3897 addresses is that it maximizes the probability of timely delivery, 3898 and indeed sometimes the probability of any delivery; the counter- 3899 argument is that it may result in unnecessary resource use. Note 3900 that resource use is also strongly determined by the sending strategy 3901 discussed in Section 4.5.4.1. 3902 3903 If an SMTP server receives a message with a destination for whichit 3904 is a designated Mail eXchanger, it MAY relay the message (potentially 3905 after having rewritten the MAIL FROM and/or RCPT TO addresses), make 3906 final delivery of the message, or hand it off using some mechanism 3907 outside the SMTP-provided transport environment. Of course, neither 3908 of the latter require that the list of MX records be examined 3909 further. 3910 3911 If it determines that it should relay the message without rewriting 3912 the address, it MUST sort the MX records to determine candidates for 3913 3914 3915 3917 3918 Internet-Draft RFC5321-Numbered Dec 2008 3919 3920 3921 delivery. The records are first ordered by preference, with the 3922 lowest-numbered records being most preferred. The relay host MUST 3923 then inspect the list for any of the names or addresses by which it 3924 might be known in mail transactions. If a matching record is found, 3925 all records at that preference level and higher-numbered ones MUST be 3926 discarded from consideration. If there are no records left at that 3927 point, it is an error condition, and the message MUST be returnedas 3928 undeliverable. If records do remain, they SHOULD be tried, best 3929 preference first, as described above. 3930 3931 5.2. IPv6 and MX Records 3932 3933 In the contemporary Internet, SMTP clients and servers may be hosted 3934 on IPv4 systems, IPv6 systems, or dual-stack systems that are 3935 compatible with either version of the Internet Protocol. The host 3936 domains to which MX records point may, consequently, contain "A RR"s 3937 (IPv4), "AAAA RR"s (IPv6), or any combination of them. While RFC 3938 3974 [39] discusses some operational experience in mixed 3939 environments, it was not comprehensive enough to justify 3940 standardization, and some of its recommendations appear to be 3941 inconsistent with this specification. The appropriate actions tobe 3942 taken either will depend on local circumstances, such as performance 3943 of the relevant networks and any conversions that might be necessary, 3944 or will be obvious (e.g., an IPv6-only client need not attempt to 3945 look up A RRs or attempt to reach IPv4-only servers). Designers of 3946 SMTP implementations that might run in IPv6 or dual-stack 3947 environments should study the procedures above, especially the 3948 comments about multihomed hosts, and, preferably, provide mechanisms 3949 to facilitate operational tuning and mail interoperability between 3950 IPv4 and IPv6 systems while considering local circumstances. 3951 3952 6. Problem Detection and Handling 3953 3954 6.1. Reliable Delivery and Replies by Email 3955 3956 When the receiver-SMTP accepts a piece of mail (by sending a "250OK" 3957 message in response to DATA), it is accepting responsibility for 3958 delivering or relaying the message. It must take this responsibility 3959 seriously. It MUST NOT lose the message for frivolous reasons, such 3960 as because the host later crashes or because of a predictable 3961 resource shortage. Some reasons that are not considered frivolous 3962 are discussed in the next subsection and in Section 7.8. 3963 3964 If there is a delivery failure after acceptance of a message, the 3965 receiver-SMTP MUST formulate and mail a notification message. This 3966 notification MUST be sent using a null ("<>") reverse-path in the 3967 envelope. The recipient of this notification MUST be the address 3968 from the envelope return path (or the Return-Path: line). However, 3969 3970 3971 3973 3974 Internet-Draft RFC5321-Numbered Dec 2008 3975 3976 3977 if this address is null ("<>"), the receiver-SMTP MUST NOT send a 3978 notification. Obviously, nothing in this section can or should 3979 prohibit local decisions (i.e., as part of the same system 3980 environment as the receiver-SMTP) to log or otherwise transmit 3981 information about null address events locally if that is desired.If 3982 the address is an explicit source route, it MUST be stripped downto 3983 its final hop. 3984 3985 For example, suppose that an error notification must be sent for a 3986 message that arrived with: 3987 3988 MAIL FROM:<@a,@b:user@d> 3989 3990 The notification message MUST be sent using: 3991 3992 RCPT TO: 3993 3994 Some delivery failures after the message is accepted by SMTP willbe 3995 unavoidable. For example, it may be impossible for the receiving 3996 SMTP server to validate all the delivery addresses in RCPT command(s) 3997 due to a "soft" domain system error, because the target is a mailing 3998 list (see earlier discussion of RCPT), or because the server is 3999 acting as a relay and has no immediate access to the delivering 4000 system. 4001 4002 To avoid receiving duplicate messages as the result of timeouts, a 4003 receiver-SMTP MUST seek to minimize the time required to respond to 4004 the final . end of data indicator. See RFC 1047 [40]for 4005 a discussion of this problem. 4006 4007 6.2. Unwanted, Unsolicited, and "Attack" Messages 4008 4009 Utility and predictability of the Internet mail system requires that 4010 messages that can be delivered should be delivered, regardless ofany 4011 syntax or other faults associated with those messages and regardless 4012 of their content. If they cannot be delivered, and cannot be 4013 rejected by the SMTP server during the SMTP transaction, they should 4014 be "bounced" (returned with non-delivery notification messages) as 4015 described above. In today's world, in which many SMTP server 4016 operators have discovered that the quantity of undesirable bulk email 4017 vastly exceeds the quantity of desired mail and in which accepting a 4018 message may trigger additional undesirable traffic by providing 4019 verification of the address, those principles may not be practical. 4020 4021 As discussed in Section 7.8 and Section 7.9 below, dropping mail 4022 without notification of the sender is permitted in practice. 4023 However, it is extremely dangerous and violates a long tradition and 4024 community expectations that mail is either delivered or returned.If 4025 4026 4027 4029 4030 Internet-Draft RFC5321-Numbered Dec 2008 4031 4032 4033 silent message-dropping is misused, it could easily undermine 4034 confidence in the reliability of the Internet's mail systems. So 4035 silent dropping of messages should be considered only in those cases 4036 where there is very high confidence that the messages are seriously 4037 fraudulent or otherwise inappropriate. 4038 4039 To stretch the principle of delivery if possible even further, itmay 4040 be a rational policy to not deliver mail that has an invalid return 4041 address, although the history of the network is that users are 4042 typically better served by delivering any message that can be 4043 delivered. Reliably determining that a return address is invalidcan 4044 be a difficult and time-consuming process, especially if the putative 4045 sending system is not directly accessible or does not fully and 4046 accurately support VRFY and, even if a "drop messages with invalid 4047 return addresses" policy is adopted, it SHOULD be applied only when 4048 there is near-certainty that the return addresses are, in fact, 4049 invalid. 4050 4051 Conversely, if a message is rejected because it is found to contain 4052 hostile content (a decision that is outside the scope of an SMTP 4053 server as defined in this document), rejection ("bounce") messages 4054 SHOULD NOT be sent unless the receiving site is confident that those 4055 messages will be usefully delivered. The preference and default in 4056 these cases is to avoid sending non-delivery messages when the 4057 incoming message is determined to contain hostile content. 4058 4059 6.3. Loop Detection 4060 4061 Simple counting of the number of "Received:" header fields in a 4062 message has proven to be an effective, although rarely optimal, 4063 method of detecting loops in mail systems. SMTP servers using this 4064 technique SHOULD use a large rejection threshold, normally at least 4065 100 Received entries. Whatever mechanisms are used, servers MUST 4066 contain provisions for detecting and stopping trivial loops. 4067 4068 6.4. Compensating for Irregularities 4069 4070 Unfortunately, variations, creative interpretations, and outright 4071 violations of Internet mail protocols do occur; some would suggest 4072 that they occur quite frequently. The debate as to whether a wel l- 4073 behaved SMTP receiver or relay should reject a malformed message, 4074 attempt to pass it on unchanged, or attempt to repair it to increase 4075 the odds of successful delivery (or subsequent reply) began almost 4076 with the dawn of structured network mail and shows no signs of 4077 abating. Advocates of rejection claim that attempted repairs are 4078 rarely completely adequate and that rejection of bad messages is the 4079 only way to get the offending software repaired. Advocates of 4080 "repair" or "deliver no matter what" argue that users prefer that 4081 4082 4083 4085 4086 Internet-Draft RFC5321-Numbered Dec 2008 4087 4088 4089 mail go through it if at all possible and that there are significant 4090 market pressures in that direction. In practice, these market 4091 pressures may be more important to particular vendors than strict 4092 conformance to the standards, regardless of the preference of the 4093 actual developers. 4094 4095 The problems associated with ill-formed messages were exacerbatedby 4096 the introduction of the split-UA mail reading protocols (Post Office 4097 Protocol (POP) version 2 [15], Post Office Protocol (POP) version3 4098 [16], IMAP version 2 [41], and PCMAIL [42]). These protocols 4099 encouraged the use of SMTP as a posting (message submission) 4100 protocol, and SMTP servers as relay systems for these client hosts 4101 (which are often only intermittently connected to the Internet). 4102 Historically, many of those client machines lacked some of the 4103 mechanisms and information assumed by SMTP (and indeed, by the mail 4104 format protocol, RFC 822 [28]). Some could not keep adequate track 4105 of time; others had no concept of time zones; still others could not 4106 identify their own names or addresses; and, of course, none could 4107 satisfy the assumptions that underlay RFC 822's conception of 4108 authenticated addresses. 4109 4110 In response to these weak SMTP clients, many SMTP systems now 4111 complete messages that are delivered to them in incomplete or 4112 incorrect form. This strategy is generally considered appropriate 4113 when the server can identify or authenticate the client, and there 4114 are prior agreements between them. By contrast, there is at best 4115 great concern about fixes applied by a relay or delivery SMTP server 4116 that has little or no knowledge of the user or client machine. Many 4117 of these issues are addressed by using a separate protocol, such as 4118 that defined in RFC 4409 [18], for message submission, rather than 4119 using originating SMTP servers for that purpose. 4120 4121 The following changes to a message being processed MAY be applied 4122 when necessary by an originating SMTP server, or one used as the 4123 target of SMTP as an initial posting (message submission) protocol: 4124 4125 o Addition of a message-id field when none appears 4126 4127 o Addition of a date, time, or time zone when none appears 4128 4129 o Correction of addresses to proper FQDN format 4130 4131 The less information the server has about the client, the less likely 4132 these changes are to be correct and the more caution and conservatism 4133 should be applied when considering whether or not to perform fixes 4134 and how. These changes MUST NOT be applied by an SMTP server that 4135 provides an intermediate relay function. 4136 4137 4138 4139 4141 4142 Internet-Draft RFC5321-Numbered Dec 2008 4143 4144 4145 In all cases, properly operating clients supplying correct 4146 information are preferred to corrections by the SMTP server. In all 4147 cases, documentation SHOULD be provided in trace header fields and/or 4148 header field comments for actions performed by the servers. 4149 4150 7. Security Considerations 4151 4152 7.1. Mail Security and Spoofing 4153 4154 SMTP mail is inherently insecure in that it is feasible for even 4155 fairly casual users to negotiate directly with receiving and relaying 4156 SMTP servers and create messages that will trick a naive recipient 4157 into believing that they came from somewhere else. Constructing such 4158 a message so that the "spoofed" behavior cannot be detected by an 4159 expert is somewhat more difficult, but not sufficiently so as to be a 4160 deterrent to someone who is determined and knowledgeable. 4161 Consequently, as knowledge of Internet mail increases, so does the 4162 knowledge that SMTP mail inherently cannot be authenticated, or 4163 integrity checks provided, at the transport level. Real mail 4164 security lies only in end-to-end methods involving the message 4165 bodies, such as those that use digital signatures (see RFC 1847 [43] 4166 and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [44] or Secure/ 4167 Multipurpose Internet Mail Extensions (S/MIME) in RFC 3851 [45]). 4168 4169 Various protocol extensions and configuration options that provide 4170 authentication at the transport level (e.g., from an SMTP client to 4171 an SMTP server) improve somewhat on the traditional situation 4172 described above. However, in general, they only authenticate one 4173 server to another rather than a chain of relays and servers, much 4174 less authenticating users or user machines. Consequently, unless 4175 they are accompanied by careful handoffs of responsibility in a 4176 carefully designed trust environment, they remain inherently weaker 4177 than end-to-end mechanisms that use digitally signed messages rather 4178 than depending on the integrity of the transport system. 4179 4180 Efforts to make it more difficult for users to set envelope return 4181 path and header "From" fields to point to valid addresses other than 4182 their own are largely misguided: they frustrate legitimate 4183 applications in which mail is sent by one user on behalf of another, 4184 in which error (or normal) replies should be directed to a specia l 4185 address, or in which a single message is sent to multiple recipients 4186 on different hosts. (Systems that provide convenient ways for users 4187 to alter these header fields on a per-message basis should attempt to 4188 establish a primary and permanent mailbox address for the user so 4189 that Sender header fields within the message data can be generated 4190 sensibly.) 4191 4192 4193 4194 4195 4197 4198 Internet-Draft RFC5321-Numbered Dec 2008 4199 4200 4201 This specification does not further address the authentication issues 4202 associated with SMTP other than to advocate that useful functionality 4203 not be disabled in the hope of providing some small margin of 4204 protection against a user who is trying to fake mail. 4205 4206 7.2. "Blind" Copies 4207 4208 Addresses that do not appear in the message header section may appear 4209 in the RCPT commands to an SMTP server for a number of reasons. The 4210 two most common involve the use of a mailing address as a "list 4211 exploder" (a single address that resolves into multiple addresses) 4212 and the appearance of "blind copies". Especially when more than one 4213 RCPT command is present, and in order to avoid defeating some of the 4214 purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy 4215 the full set of RCPT command arguments into the header section, 4216 either as part of trace header fields or as informational or private- 4217 extension header fields. Since this rule is often violated in 4218 practice, and cannot be enforced, sending SMTP systems that are aware 4219 of "bcc" use MAY find it helpful to send each blind copy as a 4220 separate message transaction containing only a single RCPT command. 4221 4222 There is no inherent relationship between either "reverse" (from 4223 MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP 4224 transaction ("envelope") and the addresses in the header section. 4225 Receiving systems SHOULD NOT attempt to deduce such relationshipsand 4226 use them to alter the header section of the message for delivery. 4227 The popular "Apparently-to" header field is a violation of this 4228 principle as well as a common source of unintended information 4229 disclosure and SHOULD NOT be used. 4230 4231 7.3. VRFY, EXPN, and Security 4232 4233 As discussed in Section 3.5, individual sites may want to disable 4234 either or both of VRFY or EXPN for security reasons (see below). As 4235 a corollary to the above, implementations that permit this MUST NOT 4236 appear to have verified addresses that are not, in fact, verified. 4237 If a site disables these commands for security reasons, the SMTP 4238 server MUST return a 252 response, rather than a code that could be 4239 confused with successful or unsuccessful verification. 4240 4241 Returning a 250 reply code with the address listed in the VRFY 4242 command after having checked it only for syntax violates this rule. 4243 Of course, an implementation that "supports" VRFY by always returning 4244 550 whether or not the address is valid is equally not in 4245 conformance. 4246 4247 On the public Internet, the contents of mailing lists have become 4248 popular as an address information source for so-called "spammers." 4249 4250 4251 4253 4254 Internet-Draft RFC5321-Numbered Dec 2008 4255 4256 4257 The use of EXPN to "harvest" addresses has increased as list 4258 administrators have installed protections against inappropriate uses 4259 of the lists themselves. However, VRFY and EXPN are still usefulfor 4260 authenticated users and within an administrative domain. For 4261 example, VRFY and EXPN are useful for performing internal audits of 4262 how email gets routed to check and to make sure no one is 4263 automatically forwarding sensitive mail outside the organization. 4264 Sites implementing SMTP authentication may choose to make VRFY and 4265 EXPN available only to authenticated requestors. Implementations 4266 SHOULD still provide support for EXPN, but sites SHOULD carefully 4267 evaluate the tradeoffs. 4268 4269 Whether disabling VRFY provides any real marginal security depends on 4270 a series of other conditions. In many cases, RCPT commands can be 4271 used to obtain the same information about address validity. On the 4272 other hand, especially in situations where determination of address 4273 validity for RCPT commands is deferred until after the DATA command 4274 is received, RCPT may return no information at all, while VRFY is 4275 expected to make a serious attempt to determine validity before 4276 generating a response code (see discussion above). 4277 4278 7.4. Mail Rerouting Based on the 251 and 551 Response Codes 4279 4280 Before a client uses the 251 or 551 reply codes from a RCPT command 4281 to automatically update its future behavior (e.g., updating the 4282 user's address book), it should be certain of the server's 4283 authenticity. If it does not, it may be subject to a man in the 4284 middle attack. 4285 4286 7.5. Information Disclosure in Announcements 4287 4288 There has been an ongoing debate about the tradeoffs between the 4289 debugging advantages of announcing server type and version (and, 4290 sometimes, even server domain name) in the greeting response or in 4291 response to the HELP command and the disadvantages of exposing 4292 information that might be useful in a potential hostile attack. The 4293 utility of the debugging information is beyond doubt. Those who 4294 argue for making it available point out that it is far better to 4295 actually secure an SMTP server rather than hope that trying to 4296 conceal known vulnerabilities by hiding the server's precise identity 4297 will provide more protection. Sites are encouraged to evaluate the 4298 tradeoff with that issue in mind; implementations SHOULD minimally 4299 provide for making type and version information available in someway 4300 to other network hosts. 4301 4302 4303 4304 4305 4306 4307 4309 4310 Internet-Draft RFC5321-Numbered Dec 2008 4311 4312 4313 7.6. Information Disclosure in Trace Fields 4314 4315 In some circumstances, such as when mail originates from within aLAN 4316 whose hosts are not directly on the public Internet, trace 4317 ("Received") header fields produced in conformance with this 4318 specification may disclose host names and similar information that 4319 would not normally be available. This ordinarily does not pose a 4320 problem, but sites with special concerns about name disclosure should 4321 be aware of it. Also, the optional FOR clause should be supplied 4322 with caution or not at all when multiple recipients are involved lest 4323 it inadvertently disclose the identities of "blind copy" recipients 4324 to others. 4325 4326 7.7. Information Disclosure in Message Forwarding 4327 4328 As discussed in Section 3.4, use of the 251 or 551 reply codes to 4329 identify the replacement address associated with a mailbox may 4330 inadvertently disclose sensitive information. Sites that are 4331 concerned about those issues should ensure that they select and 4332 configure servers appropriately. 4333 4334 7.8. Resistance to Attacks 4335 4336 In recent years, there has been an increase of attacks on SMTP 4337 servers, either in conjunction with attempts to discover addresses 4338 for sending unsolicited messages or simply to make the servers 4339 inaccessible to others (i.e., as an application-level denial of 4340 service attack). While the means of doing so are beyond the scope of 4341 this Standard, rational operational behavior requires that servers be 4342 permitted to detect such attacks and take action to defend 4343 themselves. For example, if a server determines that a large number 4344 of RCPT TO commands are being sent, most or all with invalid 4345 addresses, as part of such an attack, it would be reasonable for the 4346 server to close the connection after generating an appropriate number 4347 of 5yz (normally 550) replies. 4348 4349 7.9. Scope of Operation of SMTP Servers 4350 4351 It is a well-established principle that an SMTP server may refuseto 4352 accept mail for any operational or technical reason that makes sense 4353 to the site providing the server. However, cooperation among sites 4354 and installations makes the Internet possible. If sites take 4355 excessive advantage of the right to reject traffic, the ubiquity of 4356 email availability (one of the strengths of the Internet) will be 4357 threatened; considerable care should be taken and balance maintained 4358 if a site decides to be selective about the traffic it will accept 4359 and process. 4360 4361 4362 4363 4365 4366 Internet-Draft RFC5321-Numbered Dec 2008 4367 4368 4369 In recent years, use of the relay function through arbitrary sites 4370 has been used as part of hostile efforts to hide the actual origins 4371 of mail. Some sites have decided to limit the use of the relay 4372 function to known or identifiable sources, and implementations SHOULD 4373 provide the capability to perform this type of filtering. When mail 4374 is rejected for these or other policy reasons, a 550 code SHOULD be 4375 used in response to EHLO (or HELO), MAIL, or RCPT as appropriate. 4376 4377 8. IANA Considerations 4378 4379 IANA maintains three registries in support of this specification,all 4380 of which were created for RFC 2821 or earlier. This document expands 4381 the third one as specified below. The registry references listedare 4382 as of the time of publication; IANA does not guarantee the locations 4383 associated with the URLs. The registries are as follows: 4384 4385 o The first, "Simple Mail Transfer Protocol (SMTP) Service 4386 Extensions" [46], consists of SMTP service extensions with the 4387 associated keywords, and, as needed, parameters and verbs. As 4388 specified in Section 2.2.2, no entry may be made in this registry 4389 that starts in an "X". Entries may be made only for service 4390 extensions (and associated keywords, parameters, or verbs) that 4391 are defined in Standards-Track or Experimental RFCs specifically 4392 approved by the IESG for this purpose. 4393 4394 o The second registry, "Address Literal Tags" [47], consists of 4395 "tags" that identify forms of domain literals other than thosefor 4396 IPv4 addresses (specified in RFC 821 and in this document). The 4397 initial entry in that registry is for IPv6 addresses (specified in 4398 this document). Additional literal types require standardization 4399 before being used; none are anticipated at this time. 4400 4401 o The third, "Mail Transmission Types" [46], established by RFC 821 4402 and renewed by this specification, is a registry of link and 4403 protocol identifiers to be used with the "via" and "with" 4404 subclauses of the time stamp ("Received:" header field) described 4405 in Section 4.4. Link and protocol identifiers in addition to 4406 those specified in this document may be registered only by 4407 standardization or by way of an RFC-documented, IESG-approved, 4408 Experimental protocol extension. This name space is for 4409 identification and not limited in size: the IESG is encouragedto 4410 approve on the basis of clear documentation and a distinct method 4411 rather than preferences about the properties of the method itself. 4412 4413 An additional subsection has been added to the "VIA link types" 4414 and "WITH protocol types" subsections of this registry to contain 4415 registrations of "Additional-registered-clauses" as described 4416 above. The registry will contain clause names, a description,a 4417 4418 4419 4421 4422 Internet-Draft RFC5321-Numbered Dec 2008 4423 4424 4425 summary of the syntax of the associated String, and a reference. 4426 As new clauses are defined, they may, in principle, specify 4427 creation of their own registries if the Strings consist of 4428 reserved terms or keywords rather than less restricted strings. 4429 As with link and protocol identifiers, additional clauses may be 4430 registered only by standardization or by way of an RFC-documented, 4431 IESG-approved, Experimental protocol extension. The additional 4432 clause name space is for identification and is not limited in 4433 size: the IESG is encouraged to approve on the basis of clear 4434 documentation, actual use or strong signs that the clause willbe 4435 used, and a distinct requirement rather than preferences aboutthe 4436 properties of the clause itself. 4437 4438 In addition, if additional trace header fields (i.e., in additionto 4439 Return-path and Received) are ever created, those trace fields MUST 4440 be added to the IANA registry established by BCP 90 (RFC 3864) [11] 4441 for use with RFC 5322 [4]. 4442 4443 9. Acknowledgments 4444 4445 Many people contributed to the development of RFC 2821. That 4446 document should be consulted for those acknowledgments. For the 4447 present document, the editor and the community owe thanks to Dawn 4448 Mann and Tony Hansen who assisted in the very painful process of 4449 editing and converting the internal format of the document from one 4450 system to another. 4451 4452 Neither this document nor RFC 2821 would have been possible without 4453 the many contribution and insights of the late Jon Postel. Those 4454 contributions of course include the original specification of SMTP in 4455 RFC 821. A considerable quantity of text from RFC 821 still appears 4456 in this document as do several of Jon's original examples that have 4457 been updated only as needed to reflect other changes in the 4458 specification. 4459 4460 Many people made comments or suggestions on the mailing list or in 4461 notes to the author. Important corrections or clarifications were 4462 suggested by several people, including Matti Aarnio, Glenn Anders on, 4463 Derek J. Balling, Alex van den Bogaerdt, Stephane Bortzmeyer, Vint 4464 Cerf, Jutta Degener, Steve Dorner, Lisa Dusseault, Frank Ellerman, 4465 Ned Freed, Randy Gellens, Sabahattin Gucukoglu, Philip Guenther, Arnt 4466 Gulbrandsen, Eric Hall, Richard O. Hammer, Tony Hansen, Peter J. 4467 Holzer, Kari Hurtta, Bryon Roche Kain, Valdis Kletnieks, Mathias 4468 Koerber, John Leslie, Bruce Lilly, Jeff Macdonald, Mark E. Mallett, 4469 Mark Martinec, S. Moonesamy, Lyndon Nerenberg, Chris Newman, Douglas 4470 Otis, Pete Resnick, Robert A. Rosenberg, Vince Sabio, Hector Santos, 4471 David F. Skoll, Paul Smith, and Brett Watson. 4472 4473 4474 4475 4477 4478 Internet-Draft RFC5321-Numbered Dec 2008 4479 4480 4481 The efforts of the Area Directors -- Lisa Dusseault, Ted Hardie, and 4482 Chris Newman -- to get this effort restarted and keep it moving, and 4483 of an ad hoc committee with the same purpose, are gratefully 4484 acknowledged. The members of that committee were (in alphabetical 4485 order) Dave Crocker, Cyrus Daboo, Tony Finch, Ned Freed, Randall 4486 Gellens, Tony Hansen, the author, and Alexey Melnikov. Tony Hansen 4487 also acted as ad hoc chair on the mailing list reviewing this 4488 document; without his efforts, sense of balance and fairness, and 4489 patience, it clearly would not have been possible. 4490 4491 10. References 4492 4493 10.1. Normative References 4494 4495 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 4496 August 1982. 4497 4498 [2] Mockapetris, P., "Domain names - implementation and 4499 specification", STD 13, RFC 1035, November 1987. 4500 4501 [3] Braden, R., "Requirements for Internet Hosts - Application and 4502 Support", STD 3, RFC 1123, October 1989. 4503 4504 [4] Resnick, P., "Internet Message Format", RFC 5322, October 2008. 4505 4506 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4507 Levels", BCP 14, RFC 2119, March 1997. 4508 4509 [6] American National Standards Institute (formerly United States 4510 of America Standards Institute), "USA Code for Information 4511 Interchange", ANSI X3.4-1968, 1968. 4512 4513 ANSI X3.4-1968 has been replaced by newer versions with slight 4514 modifications, but the 1968 version remains definitive for the 4515 Internet. 4516 4517 [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax 4518 Specifications: ABNF", STD 68, RFC 5234, January 2008. 4519 4520 [8] Hinden, R. and S. Deering, "IP Version 6 Addressing 4521 Architecture", RFC 4291, February 2006. 4522 4523 [9] Newman, C., "ESMTP and LMTP Transmission Types Registration", 4524 RFC 3848, July 2004. 4525 4526 [10] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension 4527 for Message Size Declaration", STD 10, RFC 1870, November 1995. 4528 4529 4530 4531 4533 4534 Internet-Draft RFC5321-Numbered Dec 2008 4535 4536 4537 [11] Klyne, G., Nottingham, M., and J. Mogul, "Registration 4538 Procedures for Message Header Fields", BCP 90, RFC 3864, 4539 September 2004. 4540 4541 10.2. Informative References 4542 4543 [12] Partridge, C., "Mail routing and the domain system", RFC 974, 4544 January 1986. 4545 4546 [13] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 4547 Crocker, "SMTP Service Extensions", STD 10, RFC 1869, 4548 November 1995. 4549 4550 [14] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 4551 April 2001. 4552 4553 [15] Butler, M., Postel, J., Chase, D., Goldberger, J., and J. 4554 Reynolds, "Post Office Protocol: Version 2", RFC 937, 4555 February 1985. 4556 4557 [16] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 4558 STD 53, RFC 1939, May 1996. 4559 4560 [17] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4561 4rev1", RFC 3501, March 2003. 4562 4563 [18] Gellens, R. and J. Klensin, "Message Submission for Mail", 4564 RFC 4409, April 2006. 4565 4566 [19] Freed, N., "SMTP Service Extension for Command Pipelining", 4567 STD 60, RFC 2920, September 2000. 4568 4569 [20] Vaudreuil, G., "SMTP Service Extensions for Transmission of 4570 Large and Binary MIME Messages", RFC 3030, December 2000. 4571 4572 [21] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 4573 Extensions (MIME) Part One: Format of Internet Message Bodies", 4574 RFC 2045, November 1996. 4575 4576 [22] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 4577 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 4578 RFC 1652, July 1994. 4579 4580 [23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 4581 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 4582 November 1996. 4583 4584 4585 4586 4587 4589 4590 Internet-Draft RFC5321-Numbered Dec 2008 4591 4592 4593 [24] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word 4594 Extensions: Character Sets, Languages, and Continuations", 4595 RFC 2231, November 1997. 4596 4597 [25] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, 4598 January 2003. 4599 4600 [26] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail 4601 System Status Codes", BCP 138, RFC 5248, June 2008. 4602 4603 [27] Freed, N., "Behavior of and Requirements for Internet 4604 Firewalls", RFC 2979, October 2000. 4605 4606 [28] Crocker, D., "Standard for the format of ARPA Internet text 4607 messages", STD 11, RFC 822, August 1982. 4608 4609 [29] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for 4610 Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, 4611 April 2006. 4612 4613 [30] Fenton, J., "Analysis of Threats Motivating DomainKeys 4614 Identified Mail (DKIM)", RFC 4686, September 2006. 4615 4616 [31] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J.,and 4617 M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", 4618 RFC 4871, May 2007. 4619 4620 [32] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 4621 Extension for Delivery Status Notifications (DSNs)", RFC 3461, 4622 January 2003. 4623 4624 [33] Moore, K. and G. Vaudreuil, "An Extensible Message Format for 4625 Delivery Status Notifications", RFC 3464, January 2003. 4626 4627 [34] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, 4628 RFC 959, October 1985. 4629 4630 [35] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping 4631 between X.400 and RFC 822/MIME", RFC 2156, January 1998. 4632 4633 [36] De Winter, J., "SMTP Service Extension for Remote Message Queue 4634 Starting", RFC 1985, August 1996. 4635 4636 [37] Hansen, T. and G. Vaudreuil, "Message Disposition 4637 Notification", RFC 3798, May 2004. 4638 4639 [38] Elz, R. and R. Bush, "Clarifications to the DNS Specification", 4640 RFC 2181, July 1997. 4641 4642 4643 4645 4646 Internet-Draft RFC5321-Numbered Dec 2008 4647 4648 4649 [39] Nakamura, M. and J. Hagino, "SMTP Operational Experience in 4650 Mixed IPv4/v6 Environments", RFC 3974, January 2005. 4651 4652 [40] Partridge, C., "Duplicate messages and SMTP", RFC 1047, 4653 February 1988. 4654 4655 [41] Crispin, M., "Interactive Mail Access Protocol: Version 2", 4656 RFC 1176, August 1990. 4657 4658 [42] Lambert, M., "PCMAIL: A distributed mail system for personal 4659 computers", RFC 1056, June 1988. 4660 4661 [43] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security 4662 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 4663 RFC 1847, October 1995. 4664 4665 [44] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 4666 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 4667 4668 [45] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 4669 (S/MIME) Version 3.1 Message Specification", RFC 3851, 4670 July 2004. 4671 4672 [46] Internet Assigned Number Authority (IANA), "IANA Mail 4673 Parameters", 2007, 4674 . 4675 4676 [47] Internet Assigned Number Authority (IANA), "Address Literal 4677 Tags", 2007, 4678 . 4679 4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 84] 4701 4702 Internet-Draft RFC5321-Numbered Dec 2008 4703 4704 4705 Appendix A. TCP Transport Service 4706 4707 The TCP connection supports the transmission of 8-bit bytes. The 4708 SMTP data is 7-bit ASCII characters. Each character is transmitted 4709 as an 8-bit byte with the high-order bit cleared to zero. Service 4710 extensions may modify this rule to permit transmission of full 8-bit 4711 data bytes as part of the message body, or, if specifically designed 4712 to do so, in SMTP commands or responses. 4713 4714 Appendix B. Generating SMTP Commands from RFC 822 Header Fields 4715 4716 Some systems use an RFC 822 header section (only) in a mail 4717 submission protocol, or otherwise generate SMTP commands from RFC822 4718 header fields when such a message is handed to an MTA from a UA. 4719 While the MTA-UA protocol is a private matter, not covered by any 4720 Internet Standard, there are problems with this approach. For 4721 example, there have been repeated problems with proper handling of 4722 "bcc" copies and redistribution lists when information that 4723 conceptually belongs to the mail envelope is not separated early in 4724 processing from header field information (and kept separate). 4725 4726 It is recommended that the UA provide its initial ("submission 4727 client") MTA with an envelope separate from the message itself. 4728 However, if the envelope is not supplied, SMTP commands SHOULD be 4729 generated as follows: 4730 4731 1. Each recipient address from a TO, CC, or BCC header field SHOULD 4732 be copied to a RCPT command (generating multiple message copies 4733 if that is required for queuing or delivery). This includes any 4734 addresses listed in a RFC 822 "group". Any BCC header fields 4735 SHOULD then be removed from the header section. Once this 4736 process is completed, the remaining header fields SHOULD be 4737 checked to verify that at least one TO, CC, or BCC header field 4738 remains. If none do, then a BCC header field with no additional 4739 information SHOULD be inserted as specified in [4]. 4740 4741 2. The return address in the MAIL command SHOULD, if possible, be 4742 derived from the system's identity for the submitting (local) 4743 user, and the "From:" header field otherwise. If there is a 4744 system identity available, it SHOULD also be copied to the Sender 4745 header field if it is different from the address in the From 4746 header field. (Any Sender header field that was already there 4747 SHOULD be removed.) Systems may provide a way for submittersto 4748 override the envelope return address, but may want to restrict 4749 its use to privileged users. This will not prevent mail forgery, 4750 but may lessen its incidence; see Section 7.1. 4751 4752 4753 4754 4755 4757 4758 Internet-Draft RFC5321-Numbered Dec 2008 4759 4760 4761 When an MTA is being used in this way, it bears responsibility for 4762 ensuring that the message being transmitted is valid. The mechanisms 4763 for checking that validity, and for handling (or returning) messages 4764 that are not valid at the time of arrival, are part of the MUA-MTA 4765 interface and not covered by this specification. 4766 4767 A submission protocol based on Standard RFC 822 information alone 4768 MUST NOT be used to gateway a message from a foreign (non-SMTP) mail 4769 system into an SMTP environment. Additional information to construct 4770 an envelope must come from some source in the other environment, 4771 whether supplemental header fields or the foreign system's envelope. 4772 4773 Attempts to gateway messages using only their header "To" and "Cc" 4774 fields have repeatedly caused mail loops and other behavior adverse 4775 to the proper functioning of the Internet mail environment. These 4776 problems have been especially common when the message originates from 4777 an Internet mailing list and is distributed into the foreign 4778 environment using envelope information. When these messages are then 4779 processed by a header-section-only remailer, loops back to the 4780 Internet environment (and the mailing list) are almost inevitable. 4781 4782 Appendix C. Source Routes 4783 4784 Historically, the was a reverse source routing list of 4785 hosts and a source mailbox. The first host in the was 4786 historically the host sending the MAIL command; today, source routes 4787 SHOULD NOT appear in the reverse-path. Similarly, the 4788 may be a source routing lists of hosts and a destination mailbox. 4789 However, in general, the SHOULD contain only a mailbox 4790 and domain name, relying on the domain name system to supply routing 4791 information if required. The use of source routes is deprecated (see 4792 Appendix F.2); while servers MUST be prepared to receive and handle 4793 them as discussed in Section 3.3 and Appendix F.2, clients SHOULDNOT 4794 transmit them and this section is included in the current 4795 specification only to provide context. It has been modified somewhat 4796 from the material in RFC 821 to prevent server actions that might 4797 confuse clients or subsequent servers that do not expect a full 4798 source route implementation. 4799 4800 For relay purposes, the forward-path may be a source route of the 4801 form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST be fully- 4802 qualified domain names. This form is used to emphasize the 4803 distinction between an address and a route. The mailbox (here, JOE@ 4804 THREE) is an absolute address, and the route is information abouthow 4805 to get there. The two concepts should not be confused. 4806 4807 If source routes are used, RFC 821 and the text below should be 4808 consulted for the mechanisms for constructing and updating the 4809 4810 4811 4813 4814 Internet-Draft RFC5321-Numbered Dec 2008 4815 4816 4817 forward-path. A server that is reached by means of a source route 4818 (e.g., its domain name appears first in the list in the forward-path) 4819 MUST remove its domain name from any forward-paths in which that 4820 domain name appears before forwarding the message and MAY remove all 4821 other source routing information. The reverse-path SHOULD NOT be 4822 updated by servers conforming to this specification. 4823 4824 Notice that the forward-path and reverse-path appear in the SMTP 4825 commands and replies, but not necessarily in the message. That is, 4826 there is no need for these paths and especially this syntax to appear 4827 in the "To:" , "From:", "CC:", etc. fields of the message header 4828 section. Conversely, SMTP servers MUST NOT derive final message 4829 routing information from message header fields. 4830 4831 When the list of hosts is present despite the recommendations above, 4832 it is a "reverse" source route and indicates that the mail was 4833 relayed through each host on the list (the first host in the listwas 4834 the most recent relay). This list is used as a source route to 4835 return non-delivery notices to the sender. If, contrary to the 4836 recommendations here, a relay host adds itself to the beginning of 4837 the list, it MUST use its name as known in the transport environment 4838 to which it is relaying the mail rather than that of the transport 4839 environment from which the mail came (if they are different). Note 4840 that a situation could easily arise in which some relay hosts add 4841 their names to the reverse source route and others do not, generating 4842 discontinuities in the routing list. This is another reason why 4843 servers needing to return a message SHOULD ignore the source route 4844 entirely and simply use the domain as specified in the Mailbox. 4845 4846 Appendix D. Scenarios 4847 4848 This section presents complete scenarios of several types of SMTP 4849 sessions. In the examples, "C:" indicates what is said by the SMTP 4850 client, and "S:" indicates what is said by the SMTP server. 4851 4852 4853 4854 4855 4856 4857 4858 4859 4860 4861 4862 4863 4864 4865 4866 4867 4869 4870 Internet-Draft RFC5321-Numbered Dec 2008 4871 4872 4873 D.1. A Typical SMTP Transaction Scenario 4874 4875 This SMTP example shows mail sent by Smith at host bar.com, and to 4876 Jones, Green, and Brown at host foo.com. Here we assume that host 4877 bar.com contacts host foo.com directly. The mail is accepted for 4878 Jones and Brown. Green does not have a mailbox at host foo.com. 4879 4880 S: 220 foo.com Simple Mail Transfer Service Ready 4881 C: EHLO bar.com 4882 S: 250-foo.com greets bar.com 4883 S: 250-8BITMIME 4884 S: 250-SIZE 4885 S: 250-DSN 4886 S: 250 HELP 4887 C: MAIL FROM: 4888 S: 250 OK 4889 C: RCPT TO: 4890 S: 250 OK 4891 C: RCPT TO: 4892 S: 550 No such user here 4893 C: RCPT TO: 4894 S: 250 OK 4895 C: DATA 4896 S: 354 Start mail input; end with . 4897 C: Blah blah blah... 4898 C: ...etc. etc. etc. 4899 C: . 4900 S: 250 OK 4901 C: QUIT 4902 S: 221 foo.com Service closing transmission channel 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4913 4914 4915 4916 4917 4918 4919 4920 4921 4922 4923 4925 4926 Internet-Draft RFC5321-Numbered Dec 2008 4927 4928 4929 D.2. Aborted SMTP Transaction Scenario 4930 4931 S: 220 foo.com Simple Mail Transfer Service Ready 4932 C: EHLO bar.com 4933 S: 250-foo.com greets bar.com 4934 S: 250-8BITMIME 4935 S: 250-SIZE 4936 S: 250-DSN 4937 S: 250 HELP 4938 C: MAIL FROM: 4939 S: 250 OK 4940 C: RCPT TO: 4941 S: 250 OK 4942 C: RCPT TO: 4943 S: 550 No such user here 4944 C: RSET 4945 S: 250 OK 4946 C: QUIT 4947 S: 221 foo.com Service closing transmission channel 4948 4949 4950 4951 4952 4953 4954 4955 4956 4957 4958 4959 4960 4961 4962 4963 4964 4965 4966 4967 4968 4969 4970 4971 4972 4973 4974 4975 4976 4977 4978 4979 4981 4982 Internet-Draft RFC5321-Numbered Dec 2008 4983 4984 4985 D.3. Relayed Mail Scenario 4986 4987 Step 1 -- Source Host to Relay Host 4988 4989 The source host performs a DNS lookup on XYZ.COM (the destination 4990 address) and finds DNS MX records specifying xyz.com as the best 4991 preference and foo.com as a lower preference. It attempts to open a 4992 connection to xyz.com and fails. It then opens a connection to 4993 foo.com, with the following dialogue: 4994 4995 S: 220 foo.com Simple Mail Transfer Service Ready 4996 C: EHLO bar.com 4997 S: 250-foo.com greets bar.com 4998 S: 250-8BITMIME 4999 S: 250-SIZE 5000 S: 250-DSN 5001 S: 250 HELP 5002 C: MAIL FROM: 5003 S: 250 OK 5004 C: RCPT TO: 5005 S: 250 OK 5006 C: DATA 5007 S: 354 Start mail input; end with . 5008 C: Date: Thu, 21 May 1998 05:33:29 -0700 5009 C: From: John Q. Public 5010 C: Subject: The Next Meeting of the Board 5011 C: To: Jones@xyz.com 5012 C: 5013 C: Bill: 5014 C: The next meeting of the board of directors will be 5015 C: on Tuesday. 5016 C: John. 5017 C: . 5018 S: 250 OK 5019 C: QUIT 5020 S: 221 foo.com Service closing transmission channel 5021 5022 5023 5024 5025 5026 5027 5028 5029 5030 5031 5032 5033 5034 5035 5037 5038 Internet-Draft RFC5321-Numbered Dec 2008 5039 5040 5041 Step 2 -- Relay Host to Destination Host 5042 5043 foo.com, having received the message, now does a DNS lookup on 5044 xyz.com. It finds the same set of MX records, but cannot use theone 5045 that points to itself (or to any other host as a worse preference). 5046 It tries to open a connection to xyz.com itself and succeeds. Then 5047 we have: 5048 5049 S: 220 xyz.com Simple Mail Transfer Service Ready 5050 C: EHLO foo.com 5051 S: 250 xyz.com is on the air 5052 C: MAIL FROM: 5053 S: 250 OK 5054 C: RCPT TO: 5055 S: 250 OK 5056 C: DATA 5057 S: 354 Start mail input; end with . 5058 C: Received: from bar.com by foo.com ; Thu, 21 May 1998 5059 C: 05:33:29 -0700 5060 C: Date: Thu, 21 May 1998 05:33:22 -0700 5061 C: From: John Q. Public 5062 C: Subject: The Next Meeting of the Board 5063 C: To: Jones@xyz.com 5064 C: 5065 C: Bill: 5066 C: The next meeting of the board of directors will be 5067 C: on Tuesday. 5068 C: John. 5069 C: . 5070 S: 250 OK 5071 C: QUIT 5072 S: 221 foo.com Service closing transmission channel 5073 5074 5075 5076 5077 5078 5079 5080 5081 5082 5083 5084 5085 5086 5087 5088 5089 5090 5091 91] 5093 5094 Internet-Draft RFC5321-Numbered Dec 2008 5095 5096 5097 D.4. Verifying and Sending Scenario 5098 5099 S: 220 foo.com Simple Mail Transfer Service Ready 5100 C: EHLO bar.com 5101 S: 250-foo.com greets bar.com 5102 S: 250-8BITMIME 5103 S: 250-SIZE 5104 S: 250-DSN 5105 S: 250-VRFY 5106 S: 250 HELP 5107 C: VRFY Crispin 5108 S: 250 Mark Crispin 5109 C: MAIL FROM: 5110 S: 250 OK 5111 C: RCPT TO: 5112 S: 250 OK 5113 C: DATA 5114 S: 354 Start mail input; end with . 5115 C: Blah blah blah... 5116 C: ...etc. etc. etc. 5117 C: . 5118 S: 250 OK 5119 C: QUIT 5120 S: 221 foo.com Service closing transmission channel 5121 5122 Appendix E. Other Gateway Issues 5123 5124 In general, gateways between the Internet and other mail systems 5125 SHOULD attempt to preserve any layering semantics across the 5126 boundaries between the two mail systems involved. Gateway- 5127 translation approaches that attempt to take shortcuts by mapping 5128 (such as mapping envelope information from one system to the message 5129 header section or body of another) have generally proven to be 5130 inadequate in important ways. Systems translating between 5131 environments that do not support both envelopes and a header section 5132 and Internet mail must be written with the understanding that some 5133 information loss is almost inevitable. 5134 5135 5136 5137 5138 5139 5140 5141 5142 5143 5144 5145 5146 5147 92] 5149 5150 Internet-Draft RFC5321-Numbered Dec 2008 5151 5152 5153 Appendix F. Deprecated Features of RFC 821 5154 5155 A few features of RFC 821 have proven to be problematic and SHOULD 5156 NOT be used in Internet mail. 5157 5158 F.1. TURN 5159 5160 This command, described in RFC 821, raises important security issues 5161 since, in the absence of strong authentication of the host requesting 5162 that the client and server switch roles, it can easily be used to 5163 divert mail from its correct destination. Its use is deprecated; 5164 SMTP systems SHOULD NOT use it unless the server can authenticatethe 5165 client. 5166 5167 F.2. Source Routing 5168 5169 RFC 821 utilized the concept of explicit source routing to get mail 5170 from one host to another via a series of relays. The requirementto 5171 utilize source routes in regular mail traffic was eliminated by the 5172 introduction of the domain name system "MX" record and the last 5173 significant justification for them was eliminated by the 5174 introduction, in RFC 1123, of a clear requirement that addresses 5175 following an "@" must all be fully-qualified domain names. 5176 Consequently, the only remaining justifications for the use of source 5177 routes are support for very old SMTP clients or MUAs and in mail 5178 system debugging. They can, however, still be useful in the latter 5179 circumstance and for routing mail around serious, but temporary, 5180 problems such as problems with the relevant DNS records. 5181 5182 SMTP servers MUST continue to accept source route syntax as specified 5183 in the main body of this document and in RFC 1123. They MAY, if 5184 necessary, ignore the routes and utilize only the target domain in 5185 the address. If they do utilize the source route, the message MUST 5186 be sent to the first domain shown in the address. In particular,a 5187 server MUST NOT guess at shortcuts within the source route. 5188 5189 Clients SHOULD NOT utilize explicit source routing except under 5190 unusual circumstances, such as debugging or potentially relaying 5191 around firewall or mail system configuration errors. 5192 5193 F.3. HELO 5194 5195 As discussed in Sections 3.1 and 4.1.1, EHLO SHOULD be used rather 5196 than HELO when the server will accept the former. Servers MUST 5197 continue to accept and process HELO in order to support older 5198 clients. 5199 5200 5201 5202 5203 5205 5206 Internet-Draft RFC5321-Numbered Dec 2008 5207 5208 5209 F.4. #-literals 5210 5211 RFC 821 provided for specifying an Internet address as a decimal 5212 integer host number prefixed by a pound sign, "#". In practice, that 5213 form has been obsolete since the introduction of TCP/IP. It is 5214 deprecated and MUST NOT be used. 5215 5216 F.5. Dates and Years 5217 5218 When dates are inserted into messages by SMTP clients or servers 5219 (e.g., in trace header fields), four-digit years MUST BE used. Two- 5220 digit years are deprecated; three-digit years were never permitted in 5221 the Internet mail system. 5222 5223 F.6. Sending versus Mailing 5224 5225 In addition to specifying a mechanism for delivering messages to 5226 user's mailboxes, RFC 821 provided additional, optional, commandsto 5227 deliver messages directly to the user's terminal screen. These 5228 commands (SEND, SAML, SOML) were rarely implemented, and changes in 5229 workstation technology and the introduction of other protocols may 5230 have rendered them obsolete even where they are implemented. 5231 5232 Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers 5233 MAY implement them. If they are implemented by servers, the 5234 implementation model specified in RFC 821 MUST be used and the 5235 command names MUST be published in the response to the EHLO command. Author's Address John C. Klensin 1770 Massachusetts Ave, Suite 322 Cambridge, MA 02140 USA EMail: john+smtp@jck.com 5247 5248 5249 5250 5251 5252 5253 5254 5255 5256 5257 5258 5259 5261 5262 Internet-Draft RFC5321-Numbered Dec 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Klensin Standards Track [Page 95]