diff options
| author | fukachan <fukachan> | 2001-07-14 04:35:12 +0000 |
|---|---|---|
| committer | fukachan <fukachan> | 2001-07-14 04:35:12 +0000 |
| commit | 3eabb3821f867c6b51d84a2a2066f67ed1cb07c4 (patch) | |
| tree | cde45b297561d07e2d6770c3ccc2d74e207daeab /Documentation | |
| parent | 077a433ea6a398464142f5a91297a03091360437 (diff) | |
| download | fml8-3eabb3821f867c6b51d84a2a2066f67ed1cb07c4.tar.gz fml8-3eabb3821f867c6b51d84a2a2066f67ed1cb07c4.tar.bz2 fml8-3eabb3821f867c6b51d84a2a2066f67ed1cb07c4.zip | |
nuke old I-D
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/en/I-D/draft-ietf-drums-smtpupd-06.txt | 4053 | ||||
| -rw-r--r-- | Documentation/en/I-D/draft-ietf-drums-smtpupd-07.txt | 4053 | ||||
| -rw-r--r-- | Documentation/en/I-D/draft-ietf-drums-smtpupd-08.txt | 3574 | ||||
| -rw-r--r-- | Documentation/en/I-D/draft-ietf-drums-smtpupd-09.txt | 3734 | ||||
| -rw-r--r-- | Documentation/en/I-D/draft-ietf-drums-smtpupd-10.txt | 3796 | ||||
| -rw-r--r-- | Documentation/en/I-D/draft-ietf-drums-smtpupd-11.txt | 4018 | ||||
| -rw-r--r-- | Documentation/en/I-D/draft-ietf-drums-smtpupd-12.txt | 4076 | ||||
| -rw-r--r-- | Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-00.txt | 354 | ||||
| -rw-r--r-- | Documentation/en/I-D/draft-varshavchik-verp-smtpext-01.txt | 538 | ||||
| -rw-r--r-- | Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-00.txt | 679 | ||||
| -rw-r--r-- | Documentation/en/I-D/draft-ward-esmtp-slide-03.txt | 563 |
11 files changed, 0 insertions, 29438 deletions
diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-06.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-06.txt deleted file mode 100644 index 80b62634..00000000 --- a/Documentation/en/I-D/draft-ietf-drums-smtpupd-06.txt +++ /dev/null @@ -1,4053 +0,0 @@ - -INTERNET-DRAFT John C. Klensin, Editor -Expires in six months Dawn P. Mann, Co-Editor - July 30, 1997 - - - Simple Mail Transfer Protocol - - draft-ietf-drums-smtpupd-06.txt - - Status of this Memo - -This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by -other documents at any time. It is not appropriate to use -Internet-Drafts as reference material or to cite them other than as a -"working draft" or "work in progress". - -To learn the current status of any Internet-Draft, please check the -1id-abstracts.txt listing contained in the Internet-Drafts Shadow -Directories on ds.internic.net (US East Coast), nic.nordu.net -(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). - -If consensus is reached on this document, it will be forwarded to the -IESG with the recommendation that it be processed onto the Standards -track. - -[[Sections marked with doubled brackets (e.g., "<<") are explicit -placeholders or known major loose ends. The marking ## is a note in -the draft to recheck a section number and should be ignored.]] - -[[As discussed in the WG, most of the syntax and examples have not -been changed from 821 -- those changes are a last- step item, after -the ABNF document completely stabilizes and differences with 822bis -have been resolved. Similarly, the numbers of appendices will be -rationalized (and Appendix X removed) before the document is -submitted to the IESG. Please check appendix X.2 for additional -problems of which the editor is already painfully aware before -complaining about things that are missing.]] - - - TABLE OF CONTENTS - 0. ABSTRACT - - 1. INTRODUCTION - - 2. THE SMTP MODEL - - 2.1 Basic structure - 2.2 The extension model - 2.3 Other terminology - 2.4 Syntax Principles - - - 3. THE SMTP PROCEDURES: AN OVERVIEW - - 3.1 Session initiation - 3.2 Client initiation - 3.3 Mail transactions - 3.4 Forwarding for Address Correction or Updating - 3.5 Commands for Debugging Addresses - 3.6 Domains - 3.7 Relaying - 3.8 Mail Gatewaying - 3.9 Terminating sessions and connections - 3.10 Mailing lists and Aliases - - - 4. THE SMTP SPECIFICATIONS - - 4.1. SMTP Commands - 4.1.1. Command Semantics and Syntax - 4.1.2. Lower-level Syntax - 4.1.3. Address literals - 4.1.4. Order of commands - 4.1.5. Private-use commands - 4.2. SMTP Replies - 4.2.1. Reply Code Severities and Theory - 4.2.2. Reply Codes by Function Group - 4.2.3. Reply Codes in Numeric Order - 4.2.4. Reply code 502 - 4.2.5 Reply codes after DATA and the subsequent CRLF.CRLF. - 4.3. Sequencing of Commands and Replies - 4.4 Trace information - 4.5. Details - 4.5.1. Minimum Implementation - 4.5.2. Transparency - 4.5.3. Sizes and Timeouts - 4.5.4 SMTP Queuing Strategies - - 5. Address resolution and mail handling - - 6. Problem detection and handling - 6.1 Reliable delivery and replies by email - 6.2 Loop detection - 6.3 Compensating for irregularities - - 7. Security Considerations - 7.1 Mail security and spoofing - 7.2 "Blind" copies - 7.3 VRFY, EXPN, and security - 7.4 Information disclosure - 7.5 Scope of operation of SMTP servers - - 8. IANA Considerations - - 9. References - - 10. Editor's addresses - - 11. Acknowledgments - - APPENDIX A: TCP - APPENDIX B: Generating SMTP commands from RFC 822 headers - APPENDIX C: Source routes - APPENDIX F: Scenarios - APPENDIX G: Other gateway issues. - APPENDIX I: Deprecated features of RFC 821 - APPENDIX X: Change summary and Loose ends (temporary) - - - - - -0. Abstract - -This document is a self-contained specification of the basic protocol -for the Internet electronic mail transport, consolidating and -updating - - * the original SMTP specification of RFC 821 [RFC-821], - * Domain name system requirements and implications for mail - transport from RFC 1035 [RFC-DNS] and RFC 974 [RFC974], - * the clarifications and applicability statements in - RFC 1123 [RFC-1123], and - * material drawn from the SMTP Extension mechanisms [SMTPEXT]. - -It replaces RFC 821, RFC 974, and the mail transport materials of RFC -1123. However, RFC 821 specifies some features that are not in -significant use in the Internet of the mid-1990s and (in appendices) -some additional transport models. Those sections are omitted here in -the interest of clarity and brevity; readers needing them should -refer to RFC 821. - -It also includes some additional material from RFC 1123 that required -amplification. This material has been identified in multiple ways, -mostly by tracking flaming on the header-people list [HEADER-PEOPLE] -and problems of unusual readings or interpretations that have turned -up as the SMTP extensions have been deployed. Where this -specification moves beyond consolidation and actually differs from -earlier documents, it supersedes them technically as well as -textually. - -Although SMTP was designed as a mail transport and delivery protocol, -this specification also contains information that is important to its -use as a 'mail posting' protocol, as recommended for POP [RFC-POP2, -RFC-POP3] and IMAP [RFC-IMAP4]. - -Section ##2.3 provides definitions of terms specific to this -document. Except when the historical terminology is necessary for -clarity, this document uses the current 'client' and 'server' -terminology to identify the sending and receiving SMTP processes, -respectively. - -A companion document discusses message bodies and formats RFC 822, -MIME, and their relationship - [MSGFMT]. - -1. INTRODUCTION - -The objective of the Simple Mail Transfer Protocol (SMTP) is to -transfer mail reliably and efficiently. - -SMTP is independent of the particular transmission subsystem and -requires only a reliable ordered data stream channel. While this -document specifically discusses transport over TCP, other transports -are possible. Appendices to RFC 821 describe some of them. - -An important feature of SMTP is its capability to transport mail -across transport service environments, usually referred to as "mail -gatewaying" (see section 3.8). A transport service environment might -consist of the mutually-TCP-accessible hosts on the public Internet, -a firewall-isolated private TCP/IP LAN, or a LAN or WAN environment -utilizing an entirely different transport-level protocol. It is -important to realize that "transport systems" are one-to-one with -usual definitions of "networks". A process can communicate directly -with another process, and transport mail using this protocol, through -any mutually known transport layer. Conversely, mail can be relayed -(actually gatewayed) between hosts on different transport systems by -a host on both transport systems. The Mail eXchanger mechanisms of -the domain name system [RFC-DNS, and section ##5 of this document] -usually permit relaying and gatewaying to occur invisibly to the user. - - -2. THE SMTP MODEL - -2.1 Basic structure - -The SMTP design is based on the following model of communication: as -the result of a user mail request (or transfer from a mail user agent -(see section ##2.3)), the SMTP client establishes a two-way -transmission channel to an SMTP server. A fully-capable SMTP client -determines the address of an appropriate host running an SMTP server -by resolving the domain name given in the SMTP request to either an -intermediate mail exchanger host or a final target host. In other -cases, common with clients associated with implementations of the POP -[RFC-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the -client is inside an isolated transport service environment, the SMTP -client may send all of its traffic to a single SMTP server which, in -turn, relays the mail to final (or other intermediate) destinations. -The relay and those destinations are expected to support all of the -queuing, retrying, and alternate address functions discussed in this -specification. - -The SMTP server may be either the ultimate destination or an -intermediate "relay" (i.e., may assume the role of an SMTP client -after receiving the message). SMTP commands are generated by the -SMTP client and sent to the SMTP server. SMTP replies are sent from -the SMTP server to the SMTP client in response to the commands. - -Once the transmission channel is established and initial handshaking -completed, the SMTP client normally initiates a mail transaction. -Such a transaction consists of a series of commands to specify the -originator and destination of the mail and transmission of the -message content (including any headers or other structure) itself. -When the same message is sent to multiple recipients, this protocol -encourages the transmission of only one copy of the data for all -recipients at the same destination (or intermediate relay) host. - -The server responds to each command with a reply; replies may -indicate that the command was accepted, that additional commands are -expected, or that a temporary or permanent error condition exists. -Commands specifying the sender or recipients may include -server-permitted SMTP service extension requests as discussed in -section ##2.2. The dialog is purposely lock-step, one-at-a-time, -although this can be modified by mutually-agreed extension requests -(e.g., [RFC-Pipeline]). - -Once a given mail message has been transmitted, the client may either -request that the connection be shut down or may initiate other mail -transactions. - - ------------------------------------------------------------- - - - +----------+ +----------+ - +------+ | | | | - | User |<-->| | SMTP | | - +------+ | Sender- |Commands/Replies| Receiver-| - +------+ | SMTP |<-------------->| SMTP | +------+ - | File |<-->| | and Mail | |<-->| File | - |System| | | | | |System| - +------+ +----------+ +----------+ +------+ - - - SMTP client SMTP server - - Model for SMTP Use - - Figure 1 - - ------------------------------------------------------------- - -In addition, an SMTP client may use a connection to an SMTP server -for ancillary services such as verification of email addresses or -retrieval of mailing list subscriber addresses. - -As suggested above, this protocol provides mechanisms for the -transmission of mail. This transmission normally occurs directly -from the sending user's host to the receiving user's host when the -two hosts are connected to the same transport service. When they are -not connected to the same transport service, transmission occurs via -one or more relay SMTP servers. An intermediate host that acts -as either an SMTP relay or as a gateway into some other transmission -environment may also be selected through the use of the domain name -service (DNS) Mail eXchanger mechanism. - -To provide relay capability, the SMTP server is supplied with the -name of the ultimate destination host as well as the destination -mailbox name. Usually, intermediate hosts are determined via the DNS -MX record, not by explicit "source" routing (see Appendices ##C and -##I). - - - -2.2 The Extension Model - -2.2.1 Background - -In an effort that started in 1990, approximately a decade after RFC -821 was completed, the protocol was modified with a "service -extensions" model permitting the client and server to agree to -utilize shared functionality beyond the original SMTP requirements. -Contemporary SMTP implementations MUST support the basic extension -mechanisms (see below for details), i.e., servers MUST support the -EHLO command even if they do not implement any specific extensions -and clients MUST preferentially utilize EHLO rather than HELO. -(However, for compatibility with older conforming implementations, -SMTP clients and servers MUST support the original HELO mechanisms as -a fallback.) Unless the different characteristics of HELO must be -identified for interoperability purposes, this document discusses -only EHLO. - -SMTP is widely and deployed and high-quality implementations have -proven to be very robust., However, the Internet community now -considers some services to be important that were not anticipated -when the protocol was first designed. If support for those services -is to be added, it must be done in a way that permits older -implementations to continue working acceptably. - -In an effort that started in 1990, approximately a decade after RFC -821 was completed, the protocol was modified with a "service -extensions" model permitting the client and server to agree to -utilize shared functionality beyond the original SMTP requirements. -The SMTP extension mechanism defines a means whereby an extended SMTP -client and server may recognize each other, and the server can inform -the client as to the service extensions that it supports. - -The extension framework consists of: - - (1) The SMTP command EHLO, superseding the earlier HELO, - - (2) a registry of SMTP service extensions, - - (3) additional parameters to the SMTP MAIL FROM and RCPT TO - commands, and - - (4) optional replacements for verbs defined in this protocol, - such as for DATA (e.g., see [RFC-BDAT]). - -SMTP's strength comes primarily from its simplicity. Experience with -many protocols has shown that: - - -- protocols with few options tend towards ubiquity, whereas - -- protocols with many options tend towards obscurity. - -Each and every extension, regardless of its benefits, must be -carefully scrutinized with respect to its implementation, deployment, -and interoperability costs. In many cases, the cost of extending the -SMTP service will likely outweigh the benefit. - -Contemporary SMTP implementations MUST support the basic extension -mechanism (see below for details), i.e., servers MUST support the -EHLO command even if they do not implement any specific extensions -and clients MUST preferentially utilize EHLO rather than HELO. - - - - - -2.2.2 Definition and Registration of Extensions - -The IANA maintains a registry of SMTP service extensions. A -corresponding EHLO keyword value is associated with each extension . -Each service extension registered with the IANA must be defined in -aformal standards-track or IESG-approved experimental protocol -document. The definition must include: - - (1) the textual name of the SMTP service extension; - - (2) the EHLO keyword value associated with the extension; - - (3) the syntax and possible values of parameters associated with - the EHLO keyword value; - - (4) any additional SMTP verbs associated with the extension - (additional verbs will usually be, but are not required - to be, the same as the EHLO keyword value); - - (5) any new parameters the extension associates with the - MAIL FROM or RCPT TO verbs; - - (6) a description of how support for the extension affects the - behavior of a server and client SMTP; and, - - (7) the increment by which the extension is increasing the - maximum length of the commands MAIL FROM and/or RCPT TO, over - that specified in RFC 821. - -In addition, any EHLO keyword value starting with an upper or lower -case "X" refers to a local SMTP service extension used exclusively -through bilateral agreement. Keywords beginning with "X" may not be -used in a registered service extension. Conversely, keyword values -presented in the EHLO response that do not begin with "X" must -correspond to a standard, standards-track, or IESG-approved -experimental SMTP service extension registered with IANA. A -conforming server MUST NOT offer non-"X"-prefixed keyword values that -are not described in a registered extension. - -Additional verbs and parameter names are bound by the same rules as -EHLO keywords; specifically, verbs beginning with "X" are local -extensions that may not be registered or standardized. Conversely, -verbs not beginning with "X" must always be registered. - - -2.3 Terminology - -Most of the terminology in this document is common in the Internet at -the time of its writing. However, the following terms and concepts -are used in special ways here, or represent differences in -terminology between RFC 821 and this document, and should be -understood before reading further. These definitions are normative, -i.e., they contain specifications to which SMTP implementations are -required to conform. - -2.3.1 Mail objects - -SMTP transports a mail object containing an envelope and content. - - (1) The SMTP envelope is straightforward, and is sent as a - series of SMTP protocol units (described in section ##3): it - consists of an originator address (to which error reports - should be directed); a delivery mode (e.g., deliver to - recipient mailboxes); one or more recipient addresses; and - optional protocol extension material. - - (2) The SMTP content is sent in the SMTP DATA protocol unit and - has two parts: the headers and the body. The headers form a - collection of field/value pairs structured as described in - [MSGFMT]; the body, if structured, is defined according to - MIME [RFC-MIME]. The content is textual in nature, expressed - using the US ASCII repertoire[1]. Although extensions (such as - MIME) may relax this restriction for the content body, the - content headers are always encoded using the US ASCII - repertoire. The algorithm defined in [RFC-INTLHDR] is used to - represent header values outside the US ASCII repertoire, while - still encoding them using the US ASCII repertoire. - -2.3.2. Senders and receivers - -In RFC 821, the two hosts participating in an SMTP transaction were -described as the "SMTP-sender" and "SMTP-receiver". This document -has been changed to reflect current industry terminology and hence -refers to them as the "SMTP client" (or sometimes just "the client") -and "SMTP server" (or just "the server"), respectively. Since a -given host may act both as server and client in a relay situation, -"receiver" and "sender" terminology is still used where needed for -clarity. - -2.3.3. Mail agents - -Additional mail system terminology became common after RFC 821 was -published and, where convenient, is used in this specification. In -particular, SMTP servers and clients provide a mail transport service -and therefore act as Mail Transfer Agents (MTAs). Mail User Agents -(MUAs or UAs) are normally thought of as the sources and targets of -mail. At the source, an MUA might collect mail to be transmitted -from a user and hand it off to an MTA; the final ("delivery") MTA -would be thought of as handing the mail off to an MUA (or at least -transferring responsibility to it). However, while these terms are -used with at least the appearance of great precision in other -environments, the implied boundaries between MUAs and MTAs often do -not accurately match common, and conforming, practices with Internet -mail. Hence, the reader should be cautious about inferring the -strong relationships and responsibilities that might be implied if -these terms were used elsewhere. - -2.3.4 host - -For the purposes of this specification, a host is a computer system -attached to the Internet (or, in some cases, to a private TCP/IP -network) and supporting the SMTP protocol. Hosts are known by names -(see "domain"); identifying them by numerical address is discouraged. - -2.3.5 domain - -The name of a host (often referred to as a "fully-qualified domain -name" or "FQDN"), or some entry in the domain name hierarchy, usually -referred to as a "subdomain", that may contain many hosts. A domain, -or domain name, may also refer to an alias (label of a CNAME RR) or -name the label of Mail eXchanger records to be used to deliver mail. -See [RFC-DNS] and section ##5. - -The domain name, as described in this document and in [RFC-DNS], is -the entire, fully-qualified name, and an apparent host name that is -not in FQDN form is no more than a local alias. Local aliases MUST -NOT appear in any SMTP transaction. - - -In other works, if ab.cd.ef is the fully-qualified name of a host (or -label for an MX record), then it is obviously a "domain". However, -"cd.ef" may be only a domain name; it is possible for it to not refer -to any host. - -2.3.6 buffer and state table - -SMTP sessions are stateful, with both parties carefully maintaining a -common view of the current state. In this document we model this -state by a virtual "buffer" and a "state table" on the server which -may be used by the client to, for example, "clear the buffer" or -"reset the state table," causing the information in the buffer to be -discarded and the state to be returned to some previous state - -2.3.7 lines - -SMTP commands and, unless altered by a service extension, message -data, are transmitted in "lines". Lines consist of zero or more data -characters terminated by the ASCII sequence "CR" followed immediately -by "LF". Conforming implementations MUST NOT recognize or generate -any other character or character sequence as a line terminator. - -2.3.8 Gateway, relay, originator, and delivery system - -This specification makes a distinction among four types of SMTP -systems, based on the role those systems play in transmitting -electronic mail. An "originating" system (sometimes called an SMTP -originator) introduces mail into the Internet or, more generally, -into a transport service environment. A "delivery" SMTP system is one -that receives mail from a transport service environment and hands it -to a mail user agent or deposits it in a maildrop which a mail user -agent is expected to subsequently access. A "relay" SMTP system -(usually referred to just as a "relay") receives mail from an SMTP -client and transmits it, without modification to the message data -other than adding trace information, to another SMTP server for -further relaying or for delivery. - -A "gateway" SMTP system (usually referred to just as a "gateway") -receives mail from a client system in one transport environment and -transmits it to a server system in another transport environment. -Differences in protocols or message semantics between the transport -environments on either side of a gateway may require that the gateway -system perform transformations to the message that are not permitted -to SMTP relay systems. - - -2.3.9 Message content and message body - -The terms "message content" and "mail data" are used interchangably -in this document to describe the material transmitted after the DATA -command is accepted and before the end of data indication is -transmitted. Message content includes message headers and the -possibly-structured message body. The MIME specification [RFC-MIME] -provides the Standard mechanisms for structured message bodies See -##2.3.1. - -2.3.10 mailbox and address - -As used in this specification, an "address" is a character string -that identifies a user to whom mail will be sent or a location into -which mail will be deposited. The term "mailbox" refers to that -depository. The two terms are typically used interchangeably unless -the distinction between the location in which mail is placed (the -mailbox) and a reference to it (the address) is important. An -address normally consists of user and domain specifications. The -standard mailbox naming convention is defined to be -"local-part@domain": contemporary usage permits a much broader set of -applications than simple "user names" and, consequently, the -local-part is interpreted and assigned semantics only by the host -specified in the domain part of the address. - - -2.3.11. reply - -An SMTP reply is an acknowledgment (positive or negative) sent from -receiver to sender via the transmission channel in response to a -command. The general form of a reply is a numeric completion code -(indicating failure or success) followed by a text string. The codes -are for use by programs and the text is usually intended for human -users. - - - -2.4 Syntax Principles - - -2.4.1 General syntax and transaction model - -The mail commands and replies have a rigid syntax. Replies also have -a numeric code. Complete lists of commands and replies appear in -Section ##4 "The SMTP Specification". - -Commands and replies are not case sensitive. That is, a command or -reply word MAY be upper case, lower case, or any mixture of upper and -lower case. Note that this is NOT true of mailbox user names. For -some hosts the user name is case sensitive (this practice impedes -interoperability and is discouraged), therefore, SMTP implementations -MUST take care to preserve the case of user names as they appear in -mailbox arguments. Domain names are not case sensitive. - -Commands and replies are composed of characters from the ASCII -character set [1]. When the transport service provides an 8-bit byte -(octet) transmission channel, each 7-bit character is transmitted -right justified in an octet with the high order bit cleared to zero. -More specifically, the unextended SMTP service provides seven bit -transport only. Originating SMTP clients MUST NOT transmit messages -with information in the high-order bit of octets. If such messages -are transmitted in violation of this rule, receiving SMTP servers MAY -clear the high-order bit or reject the message as invalid. In -general, a relay SMTP SHOULD assume that the message content it has -received is valid and, assuming that the envelope permits doing so, -relay it without inspecting that content. Of course, if the content -is mislabelled and the data path cannot accept the actual content, -this may result in ultimate delivery of a severely garbled message to -the recipient. Delivery SMTP systems MAY reject ("bounce") such -messages rather than deliver them. No sending SMTP system is -permitted to send envelope commands in any character set other than -US-ASCII; receiving systems SHOULD reject such commands, normally -using "500 syntax error - invalid character" replies. - -Eight-bit message content transmission MAY be requested of the server -by a client using extended SMTP facilities, notably the "8BITMIME" -extension [8BITMIME]. 8BITMIME SHOULD be supported by SMTP servers. -However, it MUST not be construed as authorization to transmit -unrestricted eight bit material. 8BITMIME MUST NOT be requested by -senders for material with the high bit on that is not in MIME format -with an appropriate content-transfer encoding and servers MAY reject -such messages. - -The metalinguistic notation used in this document corresponds to the -"Augmented BNF" used in other Internet mail system documents. The -reader who is not familiar with that syntax should consult [ABNF]. -Metalanguage terms used in running text and examples are surrounded -by pointed brackets (e.g., <CRLF>) for clarity. - - -2.4.2 Command and reply syntax - -The commands consist of a command code followed by an argument field. -Command codes are four alphabetic characters and are case insensitive. - -This also applies to any symbols representing parameter values, such -as "TO" or "to" for the forward-path. Command codes and the argument -fields are separated by one or more spaces. However, case is -important in the local-part within the reverse-path and forward-path -arguments. In particular, in some hosts the user "smith" is -different from the user "Smith". - -A few SMTP receiver systems, in violation of this specification (and -RFC 821) require that a particular case be transmitted by clients. -Implementations MAY wish to make provision to accommodate those -systems. - -The argument field consists of a variable length character string -ending with the character sequence <CRLF>. The receiver will take no -action until this sequence is received. - -The syntax for each command is shown with the discussion of that -command. Common elements and parameters are shown in section ##4.1.2. - - - -3. THE SMTP PROCEDURES: AN OVERVIEW - -This section contains descriptions of the procedures used in SMTP: -session initiation, the mail transaction, forwarding mail, verifying -mailbox names and expanding mailing lists, and the opening and -closing exchanges. Comments on relaying, a note on mail domains, and -a discussion of changing roles are included at the end of this -section. Examples of partial command and reply sequences are used -throughout; several complete scenarios are presented in Appendix ##F. - - -3.1 Session initiation - -An SMTP session is initiated when a client opens a connection to -a server and the server responds with an opening message. - -SMTP server implementations MAY include identification of their -software and version information in the connection greeting reply -after the 220 code (see section ##7.4), a practice that permits more -efficient isolation and repair of any problems. Implementations MAY -make provision for SMTP servers to disable the software and version -announcement where it causes security concerns. While some systems -also identify their contact point for mail problems, this is not a -substitute for maintaining the required "postmaster" address (see -[MSGFMT]). - -The SMTP protocol allows a server to formally reject a transaction - while still allowing the initial connection as follows: a 554 -response MAY be given in the initial connection opening message -instead of the 220. A server taking this approach MUST still wait -for the client to send a QUIT (see section ##4.1.1.10) before closing -the connection and SHOULD respond to any intervening commands with -"503 bad sequence of commands". Since an attempt to make an SMTP -connection to such a system is probably in error, a server returning a -554 response on connection opening SHOULD provide enough information -in the reply text to facilitate debugging of the sending system. - -Once the server has sent the welcoming message and the client has -received it, the client then sends the EHLO command to the server, -indicating the client’s identity. In addition to opening the -session, use of EHLO indicates that the client is able to process -service extensions and requests that the server provide a list of the -extensions it supports. Older SMTP systems, unable to support -service extensions, MAY use HELO instead of EHLO. Servers SHOULD NOT -return the extended EHLO-style response to a HELO command. - -In the EHLO command the host sending the command identifies itself; -the command may be interpreted as saying "Hello, I am <domain>" (and, -in the case of EHLO, "and I support service extension requests"). - - ------------------------------------------------------------- - | - | Example of Connection Opening - | - | S: 220 UNIX.BBN.COM SMTP Ready - trashmail 1.99.a - | C: EHLO ISIF.ISI.EDU - | S: 250-UNIX.BBN.COM - | S: 250 EXPN - | - | Example 1 | - ------------------------------------------------------------- - - ------------------------------------------------------------- - | - | Example of Connection Closing - | - | S: QUIT - | R: 221 UNIX.BBN.COM Service closing transmission channel - | - | Example 2 - | - ------------------------------------------------------------- - - -3.3. Mail Transactions - -There are three steps to SMTP mail transactions. The transaction -starts with a MAIL command which gives the sender identification. A -series of one or more RCPT commands follows giving the receiver -information. Then a DATA command initiates transfer of the mail data -and is terminated by the "end of mail" data indicator, which also -confirms the transaction. - - The first step in the procedure is the MAIL command. - - MAIL <SP> FROM:<reverse-path> [<SP> <mail-parameters>] <CRLF> - - This command tells the SMTP-receiver that a new mail transaction - is starting and to reset all its state tables and buffers, - including any recipients or mail data. The <reverse-path> contains - the source mailbox, which can be used to report errors (see - section ##4.2 for a discussion of error reporting). If accepted, - the SMTP server returns a 250 OK reply. If the mailbox - specification is not acceptable for some reason, the server MUST - return a reply indicating whether the failure is permanent (i.e., - will occur again if the client tries to send the same address - again) or temporary (i.e., the address might be accepted if the - client tries again later). See section ##4.2.1. Normally, - failures produce 550 or 553 replies. - - Historically, the <reverse-path> can contain more than just a - mailbox, however, contemporary systems SHOULD NOT use source - routing (see Appendix ##C). - - The optional <mail-parameters> are associated with negotiated SMTP - service extensions (see section ##2.2). - - The second step in the procedure is the RCPT command. - - RCPT <SP> TO:<forward-path> [<SP> <rcpt-parameters>] <CRLF> - - This command gives a forward-path (normally a mailbox and domain) - identifying one recipient. If accepted, the SMTP server returns a - 250 OK reply and stores the forward-path. If the recipient is - known not to be a deliverable address, the SMTP server returns a - 550 reply, typically with a string such as "no such user - " and - the mailbox name (other circumstances and reply codes are - possible). This step of the procedure can be repeated any number - of times. The <forward-path> can contain more than just a - mailbox. Historically, the <forward-path> can be a source routing - list of hosts and the destination mailbox, however, contemporary - SMTP clients SHOULD NOT utilize source routes (see Appendix ##C). - Servers MUST be prepared to encounter a list of source routes in - the forward path, but SHOULD ignore the routes or MAY decline to - support the relaying they imply. Similarly, servers MAY decline - to accept mail that is destined for other hosts or systems. These - restrictions make a server useless as a relay for clients that do - not support full SMTP functionality. Consequently, - restricted-capability clients MUST NOT assume that any SMTP server - on the Internet can be used as their mail processing (relaying) - site. If RCPT TO appears without a previous MAIL FROM, the server - MUST return a 503 "Bad sequence of commands" response. The - optional <mail-parameters> are associated with negotiated SMTP - service extensions (see section ##2.2). - - The third step in the procedure is the DATA command (or some - alternative specified in a service extension). - - DATA <CRLF> - - If accepted, the SMTP server returns a 354 Intermediate reply and - considers all succeeding lines up to but not including the end of - mail data indicator to be the message text. When the end of text - is received and stored the SMTP-receiver sends a 250 OK reply. - - Since the mail data is sent on the transmission channel, the end - of mail data indicator must be indicated so that the command and - reply dialog can be resumed. SMTP indicates the end of the mail - data by sending a line containing only a "." (period or full - stop). A transparency procedure is used to prevent this from - interfering with the user's text (see Section ##4.5.2). - - The end of mail data indicator also confirms the mail transaction - and tells the SMTP server to now process the stored recipients and - mail data. If accepted, the SMTP server returns a 250 OK reply. - The DATA command can fail in only two ways: - - o If there was no MAIL FROM, or no RCPT TO, command, or all - such commands were rejected, the server MAY return a "command - out of sequence" (503) reply. If that reply is received, - the client MUST NOT send the message data; more generally, - message data MUST NOT be sent unless a 354 reply is received. - - o If the verb is initially accepted and the 354 reply issued, - the DATA command should fail only if the mail transaction was - incomplete (for example, no recipients), or if resources were - unavailable. However, in practice, some servers do not - perform recipient verification until after the message text - is received. These servers SHOULD treat a failure for one or - more recipients as a "subsequent failure" and return a mail - message as discussed in section ##6. Using a "550 mailbox - not found" (or equivalent) reply code after the data are - accepted makes it difficult or impossible for the client to - determine which recipients failed. - -When RFC 822 format is being used, the mail data include the memo -header items such as Date, Subject, To, Cc, From [MSGFMT]. Server -SMTP systems SHOULD NOT reject messages based on perceived defects in -the RFC 822 or MIME [RFC-MIME] message header or message body. In -particular, they MUST NOT reject messages in which the numbers of -Resent- fields do not match or Resent-to appears without Resent-from -and/or Resent-date. - - -Mail transaction commands MUST be used in the order discussed above. -Example 3 (below) illustrates the use of these commands in a mail -transaction. - - - ------------------------------------------------------------- - | - | Example of the SMTP Mail Transaction Procedure - | - | This SMTP example shows mail sent by Smith at host Alpha.foo, - | to Jones, Green, and Brown at host Beta.org. Here we assume - | that host Alpha contacts host Beta directly. - | - | C: MAIL FROM:<Smith@Alpha.foo - | S: 250 OK - | - | C: RCPT TO:<Jones@Beta.org - | S: 250 OK - | - | C: RCPT TO:<Green@Beta.org - | S: 550 No such user here - | - | C: RCPT TO:<Brown@Beta.org - | S: 250 OK - | - | C: DATA - | S: 354 Start mail input; end with <CRLF>.<CRLF> - | C: Blah blah blah...<CRLF> - | C: ...etc. etc. etc. - | C: <CRLF>.<CRLF> - | S: 250 OK - | - | The mail has now been accepted for Jones and Brown. Green did - | not have a mailbox at domain Beta.org - | - | Example 3 - | - ------------------------------------------------------------- - - - -3.4. Forwarding for Address Correction or Updating - -Forwarding support is most often required to consolidate and simplify -addresses within, or relative to, some enterprise and less frequently -to establish addresses to link a person’s prior address with a -current one.. Silent forwarding of messages (without server -notification to the sender), for security or non-disclosure purposes, -is common in the contemporary Internet. - -In both the enterprise and the "new address" cases, information -hiding (and sometimes security) considerations argue against exposure -of the "final" address through the SMTP protocol as a side-effectof -the forwarding activity. This may be especially important when the -final address may not even be reachable by the sender. Consequently, -the "forwarding" mechanisms described in section 3.2 of RFC 821, and -especially the 251 (corrected destination) reply code from RCPT TO -are deprecated: Servers SHOULD NOT provide that service or return -that code. - - - -3.5. Commands for Debugging Addresses - -3.5.1 Overview - -SMTP provides commands to verify a user name or expand a mailing -list. This is done with the VRFY and EXPN commands, which have -character string arguments. Implementations MUST support VRFY and -SHOULD support EXPN (however, see section ##3.5.2 and ##7.3). - -For the VRFY command, the string is a user name or a user name and -domain (see below). The response MAYinclude the full name of the user -and MUST include the mailbox of the user, e.g., it MUST be in either - User Name <mailbox@domain> -or - mailbox@domain -form. - - -When a name that is the argument to VRFY could identify more than one -mailbox, the server MAY either note the ambiguity or identify the -alternatives. In other words, either of the following are legitimate -response to VRFY: - - 553 User ambiguous - or - 553- Ambiguous; Possibilities are - 553-Joe Smith <jsmith@somedomain> - 553-Harry Smith <hsmith@somedomain> - 553 Melvin Smith <dweep@somedomain> - or - 553-Ambiguous; Possibilities - 553- <jsmith@somedomain> - 553- <hsmith@somedomain> - 553 <dweep@somedomain> - -Under normal circumstances, a client receiving a 553 reply would be -expected to expose the result to the user. Use of exactly the forms -given, and the "user ambiguous" or "ambiguous" keywords, possibly -supplemented by extended reply codes as described in [RFC-REPLY], -will facilitate automated translation into other languages as needed. -Of course, a client that was highly automated or that was operating -in another language than English, might choose to try to translate -the response, to return some other indication to the user than the -literal text of the reply, or to take some automated action such as -consulting a directory service for additional information before -reporting to the user. - -For the EXPN command, the string identifies a mailing list, and the -multiline response MAY include the full name of the users and MUST -give the mailboxes on the mailing list. - -In some hosts the distinction between a mailing list and an alias for -a single mailbox is a bit fuzzy, since a common data structure may -hold both types of entries, and it is possible to have mailing lists -of one mailbox. If a request is made to verify a mailing list, a -positive response can be given if a message so addressed would be -delivered to everyone on the list, otherwise an error should be -reported (e.g., "550 That is a mailing list, not a user"). If a -request is made to expand a user name, the server MAY return a -positive response consisting of a list containing one name, or an -error MAY be reported (e.g., "550 That is a user name, not a mailing -list"). - -In the case of a multiline reply (normal for EXPN) exactly one -mailbox is to be specified on each line of the reply. The case of an -ambiguous request is discussed above. - -"User name" is a fuzzy term and has been used deliberately. An -implementation of the VRFY or EXPN commands MUST include at least -recognition of local mailboxes as "user names". However, since -current Internet practice often results in a single host handling -mail for multiple domains, hosts, especially hosts that provide this -functionality, SHOULD accept the "user@domain" form as a "user name"; -hosts MAY also choose to recognize other strings as "user names". - - - -The case of verifying a user name is straightforward as shown in -example 4. - - - ----------------------------------------------------------------- - | - | Example of Verifying a User Name - | - | Either - | - | C: VRFY Smith - | S: 250 Fred Smith <Smith@F.ISI.EDU > - | - | Or - | - | C: VRFY Jones - | S: 550 String does not match anything. - | - | Or - | - | C: VRFY Jones - | S: 551 User not local; please try <Jones@ ISIQ.ISI.EDU> - | - | Or - | - | C: VRFY Gourzenkyinplatz - | S: 553 User ambiguous. - | - | Or - | - | C: VRFY fizzle - | S: 252-Cannot VRFY fizzle, but will accept message and - | S: 252 attempt delivery - | - | Example 4 - | - ----------------------------------------------------------------- - - The case of expanding a mailbox list requires a multiline reply - as shown in example 5. - - ------------------------------------------------------------- - | - | Example of Expanding a Mailing List - | - | Either - | - | C: EXPN Example-People - | S: 250-Jon Postel <Postel@isi.edu - | S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu> - | S: 250-Sam Q. Smith <SQSmith@specific.generic.com>> - | S: 250-Quincy Smith <Q-Smith@VAXA.EDU - | S: 250-<joe@totalitarian.org> - | S: 250 <xyz@dominance.universal.int> - | - | Or - | - | C EXPN Executive-Washroom-List - | S: 550 Access Denied to You. - | - | Example 5 - | - ------------------------------------------------------------- - - The character string arguments of the VRFY and EXPN commands - cannot be further restricted due to the variety of - implementations of the user name and mailbox list concepts. On - some systems it may be appropriate for the argument of the EXPN - command to be a file name for a file containing a mailing list, - but again there are a variety of file naming conventions in the - Internet. - - -3.5.2 VRFY normal response. - -When normal (2yz or 551) responses are returned from a VRFY or EXPN -request, the reply should normally include the mailbox name, e.g., -"<foo@bar>" (where "bar" is a fully qualified domain name) must -appear in the syntax. In exceptional circumstances, free-form text -MAY be returned. In order to facilitate parsing by both computers -and people, addresses SHOULD appear in pointed brackets. EXPN and -VRFY MUST return only valid domain addresses that are usable in SMTP -RCPT commands. Consequently, if an address implies delivery to a -program or other system, the mailbox name used to reach that target -MUST be given. Paths (explicit source routes) MUST NOT be returned by -VRFY or EXPN. - - -Server implementations MUST support VRFY and SHOULD support EXPN. -For security reasons, implementations MAY provide local installations -a way to disable either or both of these commands through -configuration options or the equivalent. When these commands are -supported, they are not required to work across relays when relaying -is supported. Since they were both optional in RFC 821, they MUST, -if supported, be listed in the response to EHLO if service extensions -are supported. - - -3.5.3 Meaning of VRFY or EXPN success response. - -A server MUST NOT return a 220 code in response to a VRFY or EXPN -command unless it has actually verified the address. In particular, -a server MUST NOT return 220 if all it has done is to verify that the -syntax given is valid. In that case, 502 (Command not implemented) -or 500 (Syntax error, command unrecognized) SHOULD be returned. As -stated elsewhere, implementation of VRFY is required and EXPN is -strongly recommended. Hence, except as provided in section ##7.3, -implementations that return 500 or 502 for VRFY are not in compliance -with this specification. - -There may be circumstances where an address appears to be valid but -cannot reasonably be verified in real time, particularly when a -server is acting as a mail exchanger for another server or domain. -"Apparent validity" in this case would normally involve at least -syntax checking and might involve verification that any domains -specified were ones to which the host expected to be able to relay -mail. In these situations, reply code 252 SHOULD BE returned. These -cases parallel the discussion of RCPT verification discussed in -section ##2.1 Implementations generally SHOULD be more aggressive -about address verification in the case of VRFY than in the case of -RCPT, even if it takes a little longer to do so. - - -3.5.4. Semantics and applications of EXPN. - -EXPN is often very useful in debugging and understanding problems -with mailing lists and multiple-target-address aliases. Some systems -have attempted to use source expansion of mailing lists as a means of -eliminating duplicates. The propagation of aliasing systems with -mail on the Internet--both for hosts (typically with MX and CNAME DNS -records) and for mailboxes (various types of local host aliases)--has -made it nearly impossible for these strategies to work, and mail -systems SHOULD NOT attempt them. - - - -3.6. Domains - - -Only resolvable, fully-qualified, domain names (FQDNs) are permitted -when domain names are used in SMTP. In other words, names that can -be resolved to MX RRs or A RRs (as discussed in section ##5) are -permitted, as are CNAME RRs whose targets can be resolved, in turn, -to MX or A RRs. Local nicknames or unqualified names MUST NOT be -used. There are two exceptions to this rule: (i) The domain name -given in the EHLO command MUST BE either a primary host name (a -domain name that resolves to an A RR) or, if the host has no name, an -address literal as described in section ##4.1.1.1 and (ii) The -reserved mailbox name "postmaster" may be used in a RCPT TO command -without domain qualification (see section ##4.1.1.3). - - - -3.7. RELAYING - -In general, the availability of Mail eXchanger records in the domain -name system [RFC-DNS] makes the use of explicit source routes in the -Internet mail system unnecessary. Many historical problems with -their interpretation have made their use undesirable. SMTP clients -SHOULD NOT generate explicit source routes except under unusual -circumstances. SMTP servers MAY decline to act as mail relays or to -accept addresses that specify source routes. They are also permitted -to ignore the route information and simply send to the final -destination specified as the last element in the route . There has -been an invalid practice of using names that do not appear in the DNS -as destination names, with the senders counting on the intermediate -hosts specified in source routing to resolve any problems. If source -routes are stripped, this practice will cause failures -- one of -several reasons why SMTP clients MUST NOT generate invalid source -routes or depend on serial resolution of names. - -When source routes are not used, the process described in RFC 821 for -constructing a reverse-path from the forward-path is not applicable -and the reverse-path at the time of delivery will simply be the -address that appeared in the MAIL command. - -A relay SMTP server is usually the target of a DNS MX record that -designates it, rather than the final delivery system. The relay -server may accept or reject the task of relaying the mail in the same -way it accepts or rejects mail for a local user. If it accepts the -task, it then becomes an SMTP client, establishes a transmission -channel to the next SMTP server specified in the DNS (according to -the rules in section ##5), and sends it the mail. - -If an SMTP server has accepted the task of relaying the mail and -later finds that the destination is incorrect or that the mail cannot -be delivered for some other reason, then it MUST construct an -"undeliverable mail" notification message and send it to the -originator of the undeliverable mail (as indicated by the -reverse-path). Formats specified for non-delivery reports by other -standards SHOULD be used if possible. - -This notification message must be from the SMTP server at the relay -host or the host that first determines that delivery cannot be -accomplished. Of course, SMTP servers MUST NOT send notification -messages about problems transporting notification messages. One way -to prevent loops in error reporting is to specify a null reverse-path -in the MAIL command of a notification message. When such a message -is transmitted the reverse-path MUST beset to null. A MAIL command -with a null reverse-path appears as follows: - - MAIL FROM:<> - -An undeliverable mail notification message is shown in example 6. -This notification is in response to a message originated by JOE at -xyz.somecollege.edu and sent to a user on HOSTY.org - - ------------------------------------------------------------- - | - | Example Undeliverable Mail Notification Message - | - | C: MAIL FROM:<> - | S: 250 ok - | C: RCPT TO:< JOE@xyz.somecollege.edu> - | S: 250 ok - | C: DATA - | S: 354 send the mail data, end with . - | C: Date: 23 Oct 81 11:22:33 - | C: From: SMTP@HOSTY.org - | C: To: JOE@xyz.somecollege.edu - | C: Subject: Mail System Problem - | C: -<<replace with NOTARY format >> - | C: . - | S: 250 ok - | - | Example 6 - | - -As discussed in section ##2.4.1, a relay SMTP has no need to inspect -or act upon the headers or body of the message data and MUST NOT do -so. - - - - -3.8 Mail Gatewaying - -While the relay function discussed above operates within the Internet -SMTP transport service environment, MX records or various forms of -explicit routing may require that an intermediate SMTP server perform -a translation function between one transport service and another. As -discussed in section ##2.3.8, when such a system is at the boundary -between two transport service environments, we refer to it as a -"gateway" or "gateway SMTP". - -Gatewaying mail between different mail environments, i.e., different -mail formats and protocols, is complex and does not easily yield to -standardization. However, some general requirements may be given for -a gateway between the Internet and another mail environment. - - -3.8.1 Header fields MAY be rewritten when necessary as messages are -gatewayed across mail environment boundaries. - -This may involve inspecting the message body or interpreting the -local-part of the destination address in spite of the prohibitions in -section ##2.4.1 - -Other mail systems gatewayed to the Internet often use a subset of -RFC-822 headers or provide similar functionality with a different -syntax, but some of these mail systems do not have an equivalent to -the SMTP envelope. Therefore, when a message leaves the Internet -environment, it may be necessary to fold the SMTP envelope -information into the message header. A possible solution would be to -create new header fields to carry the envelope information (e.g., -"X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would require -changes in mail programs in foreign environments. - - -3.8.2 When forwarding a message into or out of the Internet -environment, a gateway MUST prepend a Received: line, but it MUST NOT -alter in any way a Received: line that is already in the header. - -Received: fields of messages originating from other environments may -not conform exactly to this specification. However, the most -important use of Received: lines is for debugging mail faults, and -this debugging can be severely hampered by well-meaning gateways that -try to "fix" a Received: line. As another consequence of trace -fields arising in non-SMTP environments, receiving systems MUST NOT -reject mail based on the format of a trace field and SHOULD be -extremely robust in the light of unexpected information or formats in -those fields. - -The gateway SHOULD indicate the environment and protocol in the "via" -clauses of Received field(s) that it supplies. - - -3.8.3 From the Internet side, the gateway SHOULD accept all valid -address formats in SMTP commands and in RFC-822 headers, and all -valid RFC-822 messages. Gateways are, of course, subject to the same -rules for handling source routes as those described for other SMTP -systems in section ##3.3. - - -3.8.4 The gateway MUST ensure that all header fields of a message -that it forwards into the Internet meet the requirements for Internet -mail. In particular, all addresses in "From:", "To:", "Cc:", etc., -fields MUSTbe transformed (if necessary) to satisfy RFC-822 syntax, -MUST reference only fully-qualified domain names, and MUSTbe -effective and useful for sending replies. 3.8.5 The translation -algorithm used to convert mail from the Internet protocols to another -environment's protocol SHOULD ensure that error messages from the -foreign mail environment are delivered to the return path from the -SMTP envelope, not to the sender listed in the "From:" field (or -other fields) of the RFC-822 message. - -3.8.6 Similarly, when forwarding a message from another environment -into the Internet, the gateway SHOULD set the envelope return path in -accordance with an error message return address, if supplied by the -foreign environment. If the foreign environment has no equivalent -concept, the gateway must select and use a best approximation, with -the message originator’s address as the default of last resort. - - - -3.9. Terminating Sessions and Connections - -An SMTP connection is terminated when the client sends a QUIT -command. The server responds with a positive reply code, after which -it closes the connection. - -An SMTP server MUST NOT intentionally close the connection except: - - o After receiving a QUIT command and responding with a 221 reply. - - o After detecting the need to shutdown the SMTP service and - returning a message with a 451 response code. This response - code can be issued after the server receives any command or, if - necessary, asynchronously from command receipt (on the - assumption that the client will receive it after the next - command is issued). - -In particular, a server that closes connections in response to -commands that are not understood is in violation of this -specification. Servers are expected to be tolerant of unknown -commands, issuing a 500 reply and awaiting further instructions from -the client. - -An SMTP server which is forcibly shut down via external means SHOULD -attempt to send a line containing 451 response code to the SMTP -client before exiting. The SMTP client will normally read the 451 -response code after sending its next command. - -SMTP clients that experience a connection close, reset, or other -communications failure due to circumstances not under their control -(in violation of the intent of this specification but sometimes -unavoidable) should, to maintain the robustness of the mail system, -treat the mail transaction as if a 451 response had been received and -act accordingly. - - - - - -3.10 Mailing Lists and Aliases - -An SMTP-capable host SHOULD support both the alias and the list form -of address expansion for multiple delivery. When a message is -delivered or forwarded to each address of an expanded list form, the -return address in the envelope ("MAIL FROM:") MUST be changed to be -the address of a person or other entity who administers the list but -the message header MUST be left unchanged; in particular, the "From" -field of the message is unaffected. - -An important mail facility is a mechanism for multi-destination -delivery of a single message, by transforming or "expanding" a -pseudo-mailbox address into a list of destination mailbox addresses. -When a message is sent to such a pseudo-mailbox (sometimes called an -"exploder"), copies are forwarded or redistributed to each mailbox in -the expanded list. We classify such a pseudo-mailbox as an "alias" -or a "list", depending upon the expansion rules. - - -3.10.1 Alias - -To expand an alias, the recipient mailer simply replaces the -pseudo-mailbox address in the envelope with each of the expanded -addresses in turn; the rest of the envelope and the message body are -left unchanged. The message is then delivered or forwarded to each -expanded address. - - -3.10.11 List - -A mailing list may be said to operate by "redistribution" rather than -by "forwarding". To expand a list, the recipient mailer replaces the -pseudo-mailbox address in the envelope with each of the expanded -addresses in turn. The return address in the envelope is changed so -that all error messages generated by the final deliveries will be -returned to a list administrator, not to the message originator, who -generally has no control over the contents of the list and will -typically find error messages annoying. - - - - -4. THE SMTP SPECIFICATIONS - -4.1. SMTP COMMANDS - -4.1.1. COMMAND SEMANTICS AND SYNTAX - -The SMTP commands define the mail transfer or the mail system -function requested by the user. SMTP commands are character strings -terminated by <CRLF>. The command codes themselves are alphabetic -characters terminated by <SP> if parameters follow and <CRLF> -otherwise. The syntax of the local part of a mailbox must conform to -receiver site conventions and the syntax specified in section -##4.1.2. The SMTP commands are discussed below. The SMTP replies -are discussed in Section ##4.2. - -A mail transaction involves several data objects which are -communicated as arguments to different commands. The reverse-path is -the argument of the MAIL command, the forward-path is the argument of -the RCPT command, and the mail data is the argument of the DATA -command. These arguments or data objects must be transmitted and -held pending the confirmation communicated by the end of mail data -indication which finalizes the transaction. The model for this is -that distinct buffers are provided to hold the types of data objects, -that is, there is a reverse-path buffer, a forward-path buffer, and a -mail data buffer. Specific commands cause information to be appended -to a specific buffer, or cause one or more buffers to be cleared. - - -4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) - -These commands are used to identify the SMTP client to the SMTP -server. The argument field contains the fully-qualified domain name -of the SMTP client if one is available. In situations in which the -SMTP client system does not have a meaningful domain name (e.g., when -its address is dynamically allocated and no reverse mapping record is -available), the client should send an address literal (see section -##4.1.3), optionally followed by information that will help to -identify the client system. - -The SMTP server identifies itself to the SMTP client in the -connection greeting reply and in the response to this command. - -A client SMTP SHOULD start an SMTP session by issuing the EHLO -command. If the SMTP server supports the SMTP service extensions it -will give a successful response, a failure response, or an error -response. If the SMTP server, in violation of this specification, -does not support any SMTP service extensions it will generate an -error response. Older client SMTP systems MAY, as discussed above, -use HELO (as specified in RFC 821) instead of EHLO and servers MUST -support the HELO command and reply properly to it. - -These commands, and a "250 OK" reply to one of them, confirm that -both the SMTP client and the SMTP server are in the initial state, -that is, there is no transaction in progress and all state tables and -buffers are cleared. - -Normally, the response to EHLO will be a multiline reply. Each line -of the response contains a keyword and, optionally, one or more -parameters. The syntax for a positive response, using the ABNF -notation and low-level terminals of [ABNF], is: - - ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF - / ( "250-" domain [ SP greeting ] CR LF - *( "250-" ehlo-line CR LF ) - "250" SP ehlo-line CR LF ) - - greeting ::= 1*<any character other than CR or LF> - - ehlo-line ::= ehlo-keyword *( SP ehlo-param ) - - ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") - - ; syntax and values depend on ehlo-keyword - ehlo-param ::= 1*<any CHAR excluding SP and all - control characters (US ASCII 0-31 - inclusive)> - -[[xxx ALPHA ::= <any one of the 52 alphabetic characters - (A through Z in upper case, and, - a through z in lower case)> - DIGIT ::= <any one of the 10 numeric characters - (0 through 9)> - - CR ::= <the carriage-return character - (ASCII decimal code 13)> - LF ::= <the line-feed character - (ASCII decimal code 10)> - SP ::= <the space character - (ASCII decimal code 32)> /xxx]] - -Although EHLO keywords may be specified in upper, lower, or mixed -case, they must always be recognized and processed in a -case-insensitive manner. This is simply an extension of practices -specified in RFC 821 and section ##2.4.1. - - -4.1.1.2 MAIL (MAIL) - -This command is used to initiate a mail transaction in which the mail -data is delivered to one or more mailboxes. The argument field -contains a reverse-path. - -The reverse-path consists of the sender mailbox or a list of hosts as -described in Appendix C. In some types of reporting messages for -which a reply is likely to cause a mail loop (for example, mail -delivery and nondelivery notifications), the reverse-path may be null -(see section ##3.7). - -This command clears the reverse-path buffer, the forward-path buffer, -and the mail data buffer; and inserts the reverse-path information -from this command into the reverse-path buffer. - -If service extensions were negotiated, the MAIL command may also -carry parameters associated with a particular service extension. - -Syntax: "MAIL FROM:" Reverse-path [ SP Mail-parameters ] - or - "MAIL FROM:<>" - - -4.1.1.3 RECIPIENT (RCPT) - -This command is used to identify an individual recipient of the mail -data; multiple recipients are specified by multiple use of this -command. - -The forward-path normally consists of the required destination -mailbox(es). Sending systems SHOULD not generate the optimal list of -hosts known as a source route. Receiving systems MUST recognize -source route syntax but SHOULD strip off the source route -specification and utilize the domain name associated with the mailbox -as if the source route had not been provided. - -Similarly, relay hosts SHOULD strip or ignore source routes, and -names MUST NOT be copied into the reverse-path. When mail reaches its -ultimate destination (the forward-path contains only a destination -mailbox), the SMTP server inserts it into the destination mailbox in -accordance with its host mail conventions. - - -For example, mail received at relay host A with envelope commands - - MAIL FROM:<USERX@Y.foo.org - RCPT TO:<@HOSTA.INT,@HOSTB.INT:USERC@D.bar.org> - -will normally be sent directly on to host D.bar.org with envelope -commands - - MAIL FROM:<USERX@foo.org> - RCPT TO:<USERC@D.bar.org> - -as provided in Appendix C, HostA MAY also choose to relay the message -to HostB, using the envelope commands - - MAIL FROM:<USERX@HOSTY.ARPA> - RCPT TO:<@HOSTB.int:USERC@D. BAR.ORG> - -Of course, since hosts are not required to relay mail at all, HostA -may also reject the message entirely when the RCPT TO command is -received, using a 550 code (since this is a "policy reason"). - -If service extensions were negotiated, the RCPT TO command may also -carry parameters associated with a particular service extension -offered by the server. The client MUST NOT transmit parameters other -than those associated with a service extension offered by the server -in its EHLO response. - -Syntax: "RCPT TO:" Forward-path [ SP Rcpt-parameters ] - or - "RCPT TO:<Postmaster>" [ SP Rcpt-parameters ] - - -4.1.1.4 DATA (DATA) - -The receiver treats the lines (strings ending in CRLF sequences, see -section ##2.3.7) following the command as mail data from the sender. -This command causes the mail data to be appended to the mail data -buffer. The mail data may contain any of the 128 ASCII character -codes, although experience has indicated that use of control -characters other than SP, HT, CR, and LF may cause problems and -should be avoided when possible. - -The mail data is terminated by a line containing only a period, that -is, the character sequence "<CRLF>.<CRLF>" (see Section ##4.5.2 on -Transparency). This is the end of mail data indication. Note that -the first <CRLF> of this terminating sequence is also the <CRLF> that -ends the final line of the data (message text) or, if there was no -data, ends the DATA command itself. An extra <CRLF> MUST NOT be -added, as that would cause an empty line to be added to the message. -The only exception to this rule would arise if the message body were -passed to the originating SMTP-sender with a final "line" that did -not end in <CRLF>; in that case, the originating SMTP system MUST -either reject the message as invalid or add <CRLF> in order to have -the receiving SMTP server recognize the "end of data" condition. - -The custom of accepting lines ending only in <LF>, as a concession to -non-conforming behavior on the part of some UNIX systems, has proven -to cause more interoperability problems than it solves, and SMTP -server systems MUST NOT do this, even in the name of improved -robustness. In particular, the sequence "<LF>.<LF>" (bare line -feeds, without carriage returns) MUST NOT be treated as equivalent to -<CRLF>.<CRLF> as the end of mail data indication. - -Receipt of the end of mail data indication requires the server to -process the stored mail transaction information. This processing -consumes the information in the reverse-path buffer, the forward-path -buffer, and the mail data buffer, and on the completion of this -command these buffers are cleared. If the processing is successful -the receiver must send an OK reply. If the processing fails the -receiver must send a failure reply. The SMTP model does not allow for -partial failures at this point: either the message is accepted by the -server for delivery and a positive response is returned or it is not -accepted and a failure reply is returned. Errors that are diagnosed -subsequently MUST be reported in a mail message, as discussed in -section ##4.4 In sending a positive completion reply to the end of -data indication, the receiver takes full responsibility for the -message (see section ##6.1). - -When the SMTP server accepts a message either for relaying or for -final delivery, it inserts a trace record (also referred to -interchangeably as a "time stamp line" or "Received" line) at the top -of the mail data. This trace record indicates the identity of the -host that sent the message, the identity of the host that received -the message (and is inserting this time stamp), and the date and time -the message was received. Relayed messages will have multiple time -stamp lines. Details for formation of these lines, including their -syntax, is specified in section ##4.4. - - -4.1.1.5 RESET (RSET) - -This command specifies that the current mail transaction will be -aborted. Any stored sender, recipients, and mail data MUST be -discarded, and all buffers and state tables cleared. The receiver -MUST send a "250 OK" reply. A reset command may be issued by the -client at any time. It is effectively equivalent to a NOOP if issued -immediately after EHLO, or before either of those commands are -issued. In other situations, it restores the state to that -immediately after the most recent EHLO. An SMTP server MUST NOT -close the connection as the result of receiving a RSET; that action -is reserved for QUIT (see section ##4.1.1.10, below). - -Since EHLO imply some additional processing and response by the -server, RSET will normally be more efficient than reissuing those -commands, even though the formal semantics are the same. - -There are circumstances, contrary to the intent of this -specification, in which an SMTP server may receive an indication that -the underlying TCP connection has been closed or reset. To preserve -the robustness of the mail system, SMTP servers should be prepared -for this condition and should treat it as if a RSET, followed by a -QUIT, had been received before the connection disappeared. - -4.1.1.6 VERIFY (VRFY) - -This command asks the receiver to confirm that the argument -identifies a user or mailbox. If it is a user name, information is -returned as specified in section ##3.5. - -This command has no effect on the reverse-path buffer, the -forward-path buffer, or the mail data buffer. - -Syntax: "VRFY" SP String - -4.1.1.7 EXPAND (EXPN) - -This command asks the receiver to confirm that the argument -identifies a mailing list, and if so, to return the membership of -that list. If the command is successful, a multiline reply is -returned containing information as described in section ##3.5. - -This command has no effect on the reverse-path buffer, the -forward-path buffer, or the mail data buffer. - -Syntax: "EXPN" SP String - -4.1.1.8 HELP (HELP) - -This command causes the server to send helpful information to the -client. The command MAY take an argument (e.g., any command name) -and return more specific information as a response. - -This command has no effect on the reverse-path buffer, the -forward-path buffer, or the mail data buffer. - -SMTP servers SHOULD support HELP without arguments and MAY support it -with arguments. - -Syntax: "HELP" [ SP String ] - - -4.1.1.9 NOOP (NOOP) - -This command does not affect any parameters or previously entered -commands. It specifies no action other than that the receiver send -an OK reply. - -This command has no effect on the reverse-path buffer, the -forward-path buffer, or the mail data buffer. - -Syntax: "NOOP" [SP String] - -4.1.1.10 QUIT (QUIT) - -This command specifies that the receiver must send an OK reply, and -then close the transmission channel. - -The receiver MUST NOT intentionally close the transmission channel -until it receives and replies to a QUIT command (even if there was an -error). The sender MUST NOT intentionally close the transmission -channel until it sends a QUIT command and receives the reply (even if -there was an error response to a previous command). If the -connection is closed prematurely due to violations of the above or -system or network failure, the server MUST act as if a RSET command -had been received (canceling any pending transaction, but not undoing -any previously completed transaction) and the client MUST act as if -the command or transaction in progress had received a temporary error -(4xx). - -Syntax: "QUIT" - - -4.1.2. LOWER-LEVEL SYNTAX - -The syntax of the argument fields of the above commands (using the -syntax specified in [ABNF] where applicable) is given below. Some of -the productions given below are used only in conjunction with source -routes as described in Appendix C. - - Reverse-path ::= Path - - Forward-path ::= Path - - Path ::= "<" [ A-d-l ":" ] <mailbox> ">" - - A-d-l ::= At-domain *( "," A-d-l ) - - At-domain ::= "@" Domain - - Mail-parameters ::= *( SP Keyword "=" Argument ) - - Rcpt-parameters ::= *( SP Keyword "=" Argument ) - - Keyword ::= String <<>>??? - Argument ::= String <<>>??? - - Domain ::= sub-domain 1*("." sub-domain) | address-literal - - sub-domain ::= let-dig *(ldh-str) - address-literal ::= "[" IPv4-address-literal | - IPv6-address-literal | General-address-literal "]" - IPv4-address-literal ::= snum 3("." snum) - IPv6-address-literal ::= "IPv6" SP <<what did we finally decide on?>> - General-address-literal ::= Standardized-tag SP String - Standardized-tag ::= String (Specified in a standards-track RFC - and registered with IANA) - snum = one, two, or three digits representing a decimal - integer value in the range 0 through 255 - let-dig = Alpha / Digit - ldh-str = *( Alpha / Digit / "-" ) let-dig - -<< Placeholder: the following are not right, and the "alpha" one -<<may need separate rules for case-sensitive and case-insensitive. -<<Waiting for ABNF to stabilize. >> - - Alpha = ASCII character in the range A-Z or a-z. As specified in - the domain name system definition [RFC-DNS], case is not - significant in domain strings. - Digit = 0 - 9 - - Mailbox ::= Local-part "@" Domain - - Local-part ::= Dot-string | Quoted-string - -While the above definition for Local-part is relatively permissive, -for maximum interoperability, a host that expects to receive mail -SHOULD avoid defining mailboxes where the Local-part requires (or -uses) the Quoted-string form or where the Local-part is -case-sensitive. For any purposes that require generating or -comparing Local-parts (e.g., to specific mailbox names), all quoted -forms MUST be treated as equivalent and the sending system SHOULD -transmit the form that uses the minimum quoting possible. - -Systems MUST NOT define mailboxes in such a way as to require the use -of non-ASCII characters (octets with the high order bit set to one) -or ASCII "control characters" (decimal value 0-31 and 127). These -characters MUST NOT be used in MAIL FROM or RCPT TO commands or other -commands that require mailbox names. - - -<<?>> <string> ::= <char> | <char> <string> - -<<?>> <quoted-string> ::= """ <qtext> """ - -<<?>> <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext> - - <char> ::= <c> | "\" <x> - - <number> ::= <d> | <d> <number> - - <CRLF> ::= <CR> <LF> - - <CR> ::= the carriage return character (ASCII code 13) - - <LF> ::= the line feed character (ASCII code 10) - - <SP> ::= the space character (ASCII code 32) - - <a> ::= any one of the 52 alphabetic characters A through Z - in upper case and a through z in lower case - - <c> ::= any one of the 128 ASCII characters, but not any - <special> or <SP> - - <d> ::= any one of the ten digits 0 through 9 - - <q> ::= any one of the 128 ASCII characters except <CR>, - <LF>, quote ("), or backslash (\) - - <x> ::= any one of the 128 ASCII characters (no exceptions) - - <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." - | "," | ";" | ":" | "@" """ | the control - characters (ASCII codes 0 through 31 inclusive and - 127) - -Note that the backslash, "\", is a quote character, which is used to -indicate that the next character is to be used literally (instead of -its normal interpretation). For example, "Joe\,Smith" indicates a -single nine character user field with the comma being the fourth -character of the field. - -Characters outside the set of alphas, digits, and hyphen MUST NOT -appear in domain names. In particular, the underscore character is -not permitted. - - - -4.1.3. Address literals - -Sometimes a host is not known to the domain name system and -communication (and, in particular, communication to report and repair -the error) is blocked. To bypass this barrier a special literal form -of the address is allowed as an alternative to a domain name. For -IPv4 addresses, this form uses four or more small decimal integers -separated by dots and enclosed by brackets, e.g., [123.255.37.2], -which indicates an (IPv4) Internet Address in sequence-of-octets -form. For IPv6 and other forms of addressing that might eventually -be standardized, the form consists of a standardized "tag" that -identifies the address syntax, a space, and the address itself, in a -format specified elsewhere. (where?)<<IPv6 reference?? >> - - - -4.1.4. Order of commands - -There are restrictions on the order in which these commands may be -used. - -A session that will contain mail transactions MUST first be -initialized by the use of the EHLO command. An SMTP server SHOULD -accept commands for non-mail transactions (e.g., VRFY or EXPN) -without this initialization. - -An EHLO command MAY be issued by a client later in the session. If -it is issued after the session begins, the SMTP server MUST clear all -buffers and reset the state exactly as if a RSET command had been -issued. In other words, the sequence of RSET followed immediately by -EHLO is redundant, but not harmful other than in the performance cost -of executing unnecessary commands. - -If the EHLO command is not acceptable to the SMTP server, 501, 500, -or 502 failure replies MUST be returned as appropriate. The SMTP -server must stay in the same state after transmitting these replies -that it was in before the EHLO was received. - -The SMTP client MUST ensure that the domain parameter to the EHLO -command is a valid principal host name (not a CNAME or MX name) for -its host. If this is not possible (e.g., when the client's address -is dynamically assigned and the client does not have an obvious -name), an address literal SHOULD be substituted for the domain name -and supplemental information provided that will assist in identifying -the client. - -An SMTP server MAY verify that the domain name parameter in the EHLO -command actually corresponds to the IP address of the client. -However, the server MUST NOT refuse to accept a message if the -verification fails -- the information about verification failure is -for logging and tracing only. - -The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time -during a session, or without previously initializing a session. SMTP -servers SHOULD process these normally (i.e., not return a 503 code) -even if no EHLO command has yet been received; clients SHOULD open a -session with EHLO before sending these commands. - -If these rules are followed, the example in RFC 821 that shows "550 -access denied to you" in response to an EXPN command is incorrect -unless an EHLO command precedes the EXPN or the denial of access is -based on the client's IP address. - -The MAIL command (or the obsolete SEND, SOML, or SAML commands) -begins a mail transaction. Once started, a mail transaction consists -of a transaction beginning commands, one or more RCPT commands, and a -DATA command, in that order. A mail transaction may be aborted by -the RSET (or a new EHLO) command. There may be zero or more -transactions in a session. - -If the transaction beginning command argument is not acceptable, a -501 failure reply MUST be returned and the SMTP server must stay in -the same state. If the commands in a transaction are out of order to -the degree that they cannot be processed by the server, a 503 failure -reply MUST be returned and the SMTP server must stay in the same -state. - -The last command in a session must be the QUIT command. The QUIT -command cannot be used at any other time in a session, but SHOULD be -used by the client SMTP to request connection closure, even when no -session opening command was sent and accepted. - - - -4.1.5 Private-use commands - -As specified in section 2.2.2, commands starting in "X" may be used -by bilateral agreement between the client (sending) and server -(receiving) SMTPs. An SMTP server that does not recognize such a -command is expected to reply with "500 Command not recognized". An -extended SMTP server MAY list the feature names associated with these -private commands in the response to the EHLO command. - -Commands sent or accepted by SMTP systems that do not start with "X" -MUST conform to the requirements of section ##2.2.2, above. - - - -4.2. SMTP REPLIES - -Replies to SMTP commands serve to ensure the synchronization of -requests and actions in the process of mail transfer and to guarantee -that the SMTP client always knows the state of the SMTP server. -Every command must generate exactly one reply. - -The details of the command-reply sequence are described in Section -##4.3 on Sequencing. - -An SMTP reply consists of a three digit number (transmitted as three -alphanumeric characters) followed by some text. The number is for -use by automata to determine what state to enter next; the text is -for the human user. The three digits contain enough encoded -information that the SMTP client need not examine the text and may -either discard it or pass it on to the user, as appropriate. -Exceptions are as noted elsewhere in this document. In particular, -the 220, 221, 251, 421, and 551 reply codes are associated with -message text that must be parsed and interpreted by machines. In the -general case, the text may be receiver dependent and context -dependent, so there are likely to be varying texts for each reply -code. A discussion of the theory of reply codes is given insection -##4.2.1. Formally, a reply is defined to be the sequence: a -three-digit code, SP, one line of text, and CRLF, or a multiline -reply (as defined insection ##4.2.1). Only the EXPN and HELP -commands are expected to result in multiline replies in normal -circumstances, however, multiline replies are allowed for any command. - -An SMTP server SHOULD send only the reply codes listed in this -document. An SMTP server SHOULD use the text shown in the examples -whenever appropriate. - -A client SMTP MUST determine its actions only by the reply code, not -by the text (except for 251 and 551 and, if necessary, 220, 221, and -421 replies); in the general case, any text, including no text at all -(although senders SHOULD NOT send bare codes), MUSTbe acceptable. -The space (blank) following the reply code is considered part of the -text. Whenever possible, a sender-SMTP SHOULD test the first digit -(severity indication) of the reply code. - -The list of codes that appears below must not be construed as -permanent. While the addition of new codes should be a rare and -significant activity, with supplemental information in the textual -part of the response being preferred, new codes may be added as the -result of new Standards or Standards-track specifications. -Consequently, a sender-SMTP MUST be prepared to handle codes not -specified in this document and MUST do so by interpreting the first -digit only. - - - -4.2.1. REPLY CODE SEVERITIES AND THEORY - - -The three digits of the reply each have a special significance. The -first digit denotes whether the response is good, bad or incomplete. -An unsophisticated SMTP client, or one that receives an unexpected -code, will be able to determine its next action (proceed as planned, -redo, retrench, etc.) by examining this first digit. An SMTP client -that wants to know approximately what kind of error occurred (e.g., -mail system error, command syntax error) may examine the second -digit. The third digit and any supplemental information that may be -present is reserved for the finest gradation of information. - -There are five values for the first digit of the reply code: - - 1yz Positive Preliminary reply - - The command has been accepted, but the requested action - is being held in abeyance, pending confirmation of the - information in this reply. The SMTP client should send - another command specifying whether to continue or abort - the action. - - [Note: unextended SMTP does not have any commands that allow - this type of reply, and so does not have continue or abort - commands.] - - 2yz Positive Completion reply - - The requested action has been successfully completed. A new - request may be initiated. - - 3yz Positive Intermediate reply - - The command has been accepted, but the requested action is being - held in abeyance, pending receipt of further information. The - SMTP client should send another command specifying this - information. This reply is used in command sequence groups - (i.e., in DATA). - - 4yz Transient Negative Completion reply - - The command was not accepted, and the requested action did not - occur. However, the error condition is temporary and the action - may be requested again. The sender should return to the - beginning of the command sequence (if any). It is difficult to - assign a meaning to "transient" when two different sites - (receiver- and sender- SMTPs) must agree on the interpretation. - Each reply in this category might have a different time value, - but the SMTP client is encouraged to try again. A rule of thumb - to determine whether a reply fits into the 4yz or the 5yz - category (see below) is that replies are 4yz if they can be - repeated without any change in command form or in properties of - the sender or receiver. (E.g., the command is repeated - identically and the receiver does not put up a new - implementation.) - - 5yz Permanent Negative Completion reply - - The command was not accepted and the requested action did not - occur. The SMTP client is discouraged from repeating the exact - request (in the same sequence). Even some "permanent" error - conditions can be corrected, so the human user may want to - direct the SMTP client to reinitiate the command sequence by - direct action at some point in the future (e.g., after the - spelling has been changed, or the user has altered the account - status). - -The second digit encodes responses in specific categories: - - x0z Syntax -- These replies refer to syntax errors, - syntactically correct commands that don't fit any - functional category, and unimplemented or superfluous - commands. - - x1z Information -- These are replies to requests for - information, such as status or help. - - x2z Connections -- These are replies referring to the - transmission channel. - - x3z Unspecified as yet. - - x4z Unspecified as yet. - - x5z Mail system -- These replies indicate the status of - the receiver mail system vis-a-vis the requested - transfer or other mail system action. - -The third digit gives a finer gradation of meaning in each category -specified by the second digit. The list of replies illustrates this. -Each reply text is recommended rather than mandatory, and may even -change according to the command with which it is associated. On the -other hand, the reply codes must strictly follow the specifications -in this section. Receiver implementations should not invent new -codes for slightly different situations from the ones described here, -but rather adapt codes already defined. - -For example, a command such as NOOP, whose successful execution does -not offer the SMTP client any new information, will return a 250 -reply. The reply is 502 when the command requests an unimplemented -non-site-specific action. A refinement of that is the 504 reply for -a command that is implemented, but that requests an unimplemented -parameter. - -The reply text may be longer than a single line; in these cases the -complete text must be marked so the SMTP client knows when it can -stop reading the reply. This requires a special format to indicate a -multiple line reply. - -The format for multiline replies requires that every line, except the -last, begin with the reply code, followed immediately by a hyphen, -"-" (also known as minus), followed by text. The last line will -begin with the reply code, followed immediately by <SP>, optionally -some text, and <CRLF>. As noted above, clients SHOULD send the <SP> -if subsequent text is not sent, but servers MUST be prepared for it -to be omitted. - - For example: - 123-First line - 123-Second line - 123-234 text beginning with numbers - 123 The last line - -In many cases the SMTP client then simply needs to search for the -reply code followed by <SP> at the beginning of a line, and ignore -all preceding lines. In a few cases, there is important data for the -sender in the reply "text". The sender will be able to identify -these cases from the current context. - - -4.2.2. REPLY CODES BY FUNCTION GROUPS - - 500 Syntax error, command unrecognized - [This may include errors such as command line too long] - 501 Syntax error in parameters or arguments - 502 Command not implemented (see section ##4.2.3) - 503 Bad sequence of commands - 504 Command parameter not implemented - - 211 System status, or system help reply - 214 Help message - [Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user] - - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 421 <domain> Service not available, - closing transmission channel - [This may be a reply to any command if the service knows it - must shut down] - - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - [See section ##3.4] - 252 Cannot VRFY user, but will accept message and attempt - delivery - [See section ##3.5.3] - 450 Requested mail action not taken: mailbox unavailable - [E.g., mailbox busy] - 550 Requested action not taken: mailbox unavailable - [E.g., mailbox not found, no access, or command rejected - for policy reasons] - 451 Requested action aborted: error in processing - 551 User not local; please try <forward-path> - [See section ##3.4] - 452 Requested action not taken: insufficient system storage - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - [E.g., mailbox syntax incorrect] - 354 Start mail input; end with <CRLF>.<CRLF> - 554 Transaction failed [Or, in the case of a connection-opening - response, "No SMTP service here"] - - -4.2.3. NUMERIC ORDER LIST OF REPLY CODES - - 211 System status, or system help reply - 214 Help message - [Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user] - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - [See section ##3.4] - 252 Cannot VRFY user, but will accept message and attempt - delivery - [See section ##3.5.3] - - 354 Start mail input; end with <CRLF>.<CRLF> - - 421 <domain> Service not available, - closing transmission channel - [This may be a reply to any command if the service knows it - must shut down] - 450 Requested mail action not taken: mailbox unavailable - [E.g., mailbox busy] - 451 Requested action aborted: local error in processing - 452 Requested action not taken: insufficient system storage - - 500 Syntax error, command unrecognized - [This may include errors such as command line too long] - 501 Syntax error in parameters or arguments - 502 Command not implemented - 503 Bad sequence of commands - 504 Command parameter not implemented - 550 Requested action not taken: mailbox unavailable - [E.g., mailbox not found, no access, or command rejected - for policy reasons] - 551 User not local; please try <forward-path> - [See section ##3.4] - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - [E.g., mailbox syntax incorrect] - 554 Transaction failed [Or, in the case of a connection-opening - response, "No SMTP service here"] - - -4.2.4. Reply code 502 - -Questions have been raised as to when reply code 502 (Command not -implemented) should be returned in preference to other codes. 502 -SHOULD be used when the command is actually recognized by the SMTP -server, but not implemented. If the command is not recognized, code -500 SHOULD be returned. Extended SMTP systems MUST NOT list -capabilities in response to EHLO for which they will return 502 (or -500) replies. - - -4.2.5 Reply codes after DATA and the subsequent <CRLF>.<CRLF>. - -When an SMTP server returns a positive completion status (2yz code) -after the DATA command is completed with <CRLF>.<CRLF>, it accepts -responsibility for: - - o delivering the message (if the recipient mailbox exists), or - - o if attempts to deliver the message fail due to transient - conditions, retrying delivery some reasonable number of times - at intervals as specified in section ##4.2.6. - - o if attempts to deliver the message fail due to permanent - conditions, or if repeated attempts to deliver the message fail - due to transient conditions, returning appropriate notification to - the sender of the original message (using the address in the SMTP - MAIL FROM command). - - -When an SMTP server returns a transient error completion status (4yz) -code after the DATA command is completed with <CRLF>.<CRLF>, it MUST -NOT make any further attempt to deliver that message. The SMTP -client retains responsibility for delivery of that message and may -either return it to the user or requeue it for a subsequent attempt -(see section ##4.5.4.1). The sending user should be able to -interpret the return of a transient or permanent failure status as a -non-delivery indication. - - - -4.3. SEQUENCING OF COMMANDS AND REPLIES - -4.3.1 Sequencing overview - -The communication between the sender and receiver is an alternating -dialogue, controlled by the sender. As such, the sender issues a -command and the receiver responds with a reply. Unless other -arrangements are negotiated through service extensions, the sender -must wait for this response before sending further commands. - -One important reply is the connection greeting. Normally, a receiver -will send a 220 "Service ready" reply when the connection is -completed. The sender should wait for this greeting message before -sending any commands. - -Note: all the greeting-type replies have the official name (i.e., the -fully-qualified primary domain name) of the server host as the first -word following the reply code. Sometimes the host will have no -meaningful name. See ##4.1.3 for a discussion of alternatives in -these situations. - - For example, - - 220 ISIF.USC.EDU Service ready - or - - 220 LOSER.BOGUS.COM Trashmail v 6.1.2 Service ready - -The table below lists alternative success and failure replies for -each command. These SHOULD be strictly adhered to; a receiver may -substitute text in the replies, but the meaning and action implied by -the code numbers and by the specific command reply sequence cannot be -altered. - -4.3.2 Command-Reply Sequences - -Each command is listed with its usual possible replies. The prefixes -used before the possible replies are "P" for preliminary (not used in -SMTP), "I" for intermediate, "S" for success, "F" for failure, and -"E" for error. The 421 reply (service not available, closing -transmission channel) may be given to any command if the SMTP -receiver knows it must shut down. Since some servers may generate -other replies under special circumstances, and to allow for future -extension, SMTP clients SHOULD, when possible, interpret only the -first digit of the reply and MUST be prepared to deal with -unrecognized reply codes by interpreting the first digit only. SMTP -servers MUST NOT transmit reply codes to an SMTP client that are -other than three digits or that do not start in a digit between 2 and -5 inclusive. - - CONNECTION ESTABLISHMENT - S: 220 - F: 421, 554 - EHLO (or HELO) - S: 250 - E: 500*, 501, 504, 421, 550 - MAIL - S: 250 - F: 552, 451, 452 - E: 500*, 501, 421, 550, 553 - RCPT - S: 250, 251 (but see section ##3.4 for discussion of 251) - F: 550, 551, 552, 553, 450, 451, 452 - E: 500*, 501, 503, 421, 550 - DATA - I: 354 -> data -> S: 250 - F: 552, 554, 451, 452 - F: 451, 554 - E: 500*, 501, 503, 421 - RSET - S: 250 - E: 500*, 501, 504, 421 - SEND - S: 250 - F: 552, 451, 452 - E: 500, 501, 502, 421 - SOML - S: 250 - F: 552, 451, 452 - E: 500, 501, 502, 421 - SAML - S: 250 - F: 552, 451, 452 - E: 500, 501, 502, 421 - VRFY - S: 250, 251, 252 - F: 550, 551, 553 - E: 500*, 501, 502, 504, 421 - EXPN - S: 250, 252 - F: 550 - E: 500, 501, 502, 504, 421 - HELP - S: 211, 214 - E: 500, 501, 502, 504, 421 - NOOP - S: 250 - E: 500*, 421 - QUIT - S: 221 - E: 500* - TURN - S: 250 - F: 502 - E: 500, 503 - - * Since support of this command is required, returning - this reply code as part of an "unrecognized command" - status places an implementation out of conformance with - this specification. - - - -4.4 Trace information - -When an SMTP server receives a message for delivery or further -processing, it MUST insert trace ("time stamp" or "Received") -information at the beginning of the message content, as discussed -under the DATA command in section ##4.1.1.4. - -This line must be structured as follows: - - * The FROM field SHOULD contain both (1) the name of the - source host as presented in the EHLO command and (2) an - address literal containing the IP address of the source, - determined from the TCP connection. - - * The ID field MAY contain an "@" as suggested in RFC-822, - but this is not required. - - * The FOR field MAY contain a list of <path> entries when - multiple RCPT commands have been given. - -An Internet mail program MUST NOT change a Received: line that was -previously added to the message header. SMTP servers MUST prepend -Received lines to messages; they MUST NOT change the order of -existing lines or insert Received lines in any other location. - -As the Internet grows, comparability of Received fields is important -for detecting problems, especially slow relays. SMTP servers that -create Received fields SHOULD use explicit offsets in the dates -(e.g., -0800), rather than time zone names of any type. Local time -(with an offset) is preferred to UT when feasible. If a time zone -name is used, it should be included in a comment. - -When the delivery SMTP server makes the "final delivery" of a -message, it inserts a return-path line at the beginning of the mail -data. This use of return-path is required; mail systems MUST support -it. The return-path line preserves the information in the -<reverse-path> from the MAIL command. Here, final delivery means the -message has left the SMTP world. Normally, this would mean it had -been delivered to the destination user or an associated mail drop, -but in some cases it may be further processed and transmitted by -another mail system. - -It is possible for the mailbox in the return path to be different -from the actual sender's mailbox, for example, if error responses are -to be delivered a special error handling mailbox rather than to the -message sender. When mailing lists are involved, this arrangement is -common and useful as a means of directing errors to the list -maintainer rather than the message originator. - -The text above implies that the final mail data will begin with a -return path line, followed by one or more time stamp lines. These -lines will be followed by the mail data headers and body [RFC822]. - -It is sometimes difficult for an SMTP server to determine whether or -not it is making final delivery since forwarding or other operations -may occur after the message is accepted for delivery. Consequently, -any further (forwarding, gateway, or relay) systems MAY remove the -return path and rebuild the MAIL FROM command as needed to ensure -that exactly one such line appears in a delivered message. - -A message-originating SMTP system SHOULD NOT send a message that -already contains a Return-path header. SMTP servers performing a -relay function MUST NOT inspect the message data, and especially not -to the extent needed to determine if Return-path headers are present. -SMTP servers making final delivery MAY remove Return-path headers -before adding their own. - -The primary purpose of the Return-path is to designate the address to -which messages indicating non-delivery or other mail system failures -are to be sent. For this to be unambigious, exactly one return path -should be present when the message is delivered. Systems using RFC -822 syntax with non-SMTP transports SHOULD designate an unambiguous -address, associated with the transport envelope, to which error -reports (e.g., non-delivery messages) should be sent. - - Historical note: Text in RFC 822 that appears to contradict the - use of Return-path (or the envelope MAIL FROM address) as the - destination for error messages is not applicable on the Internet. - The MAIL FROM address (as copied into the Return-path) MUST be - used as the target of any mail containing delivery error messages. - << Probably should take this out if [MSGFMT] adequately - clarifies that point --Ed.>> - -In particular, - -(i) a gateway from SMTP->elsewhere SHOULD insert a return-path -header, unless it is known that the "elsewhere" transport also uses -Internet domain addresses and maintains the envelope sender address -separately. - -(ii) a gateway from elsewhere->SMTP SHOULD delete any -return-path header present in the message, and either copy -that information to the SMTP envelope or combine it with -information present in the envelope of the other transport -system to construct the MAIL FROM part of the SMTP envelope. - - - -The server must give special treatment to cases in which the -processing following the end of mail data indication is only -partially successful. This could happen if, after accepting several -recipients and the mail data, the SMTP server finds that the mail -data could be successfully delivered to some, but not all, of the -recipients. In such cases, the response to the DATA command must be -an OK reply. However, the SMTP server must compose and send an -"undeliverable mail" notification message to the originator of the -message. A single notification listing all of the failed recipients -or separate notification messages must be sent for each failed -recipient. For economy of processing by the sender, the former is -preferred when possible. All undeliverable mail notification -messages are sent using the MAIL command (even if they result from -processing the obsolete SEND, SOML, or SAML commands) and use a null -return path as discussed in section ##3.7. - - <<The following section is incomplete in this draft >>> - -The time stamp line and the return path line are formally defined as -follows: - -<return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF> - -<time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF> - -<stamp> ::= <from-domain> <by-domain> <opt-info> ";" - <daytime> - -<from-domain> ::= "FROM" <SP> <domain> <SP> - -<by-domain> ::= "BY" <SP> <domain> <SP> - -<opt-info> ::= [<via>] [<with>] [<id>] [<for>] - -<via> ::= "VIA" <SP> <link> <SP> - -<with> ::= "WITH" <SP> <protocol> <SP> - -<id> ::= "ID" <SP> <string> <SP> - -<for> ::= "FOR" <SP> <path> <SP> - -<< FOR and <link> need to be nailed down.>> - - <link> ::= The standard names for links are registered with - the Internet Assigned Numbers Authority (IANA). - - <protocol> ::= The standard names for protocols are - registered with the Internet Assigned Numbers Authority - (IANA). - - <daytime> ::= <SP> <date> <SP> <time> - - Date ::= Dd SP Mon SP YYYY - - Note that the earlier form, which permits two-digit years, has - been deprecated. SMTP systems MUST use four-digit years. - - <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone> - - Dd ::= the one or two decimal integer day of the month in - the range 1 to 31. - - Mon ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | - "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" - - YYYY ::= the four decimal integer year in the range 0000 to - 9999. - - <hh> ::= the two decimal integer hour of the day in the - range 00 to 24. - - <mm> ::= the two decimal integer minute of the hour in the - range 00 to 59. - - <ss> ::= the two decimal integer second of the minute in the - range 00 to 59. - - <zone> ::= A four digit, signed time zone offset, such as -0600 for - US Eastern Standard Time. This may be supplemented by a - time zone name in parentheses, e.g., "-0800 (PDT)". See - ##___ for additional discussion. - - Note that there is no default; time zone information - is required and MUST be supplied. - - - - -------------------------------------------------------------- -| -| Example of Return Path and Received Time Stamps -| -| Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA> -| Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 -0800 -| Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 -0800 -| Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 -0800 -| Date: 27 Oct 81 15:01:01 -0800 (PST) -| From: JOE@ABC.ARPA -| Subject: Improved Mailing System Installed -| To: SAM@JKL.ARPA -| -| This is to inform you that ... -| -| Example 8 -| -------------------------------------------------------------- - - - - - -4.5. DETAILS - -4.5.1. MINIMUM IMPLEMENTATION - -In order to make SMTP workable, the following minimum -implementation is required for all receivers: - - COMMANDS -- HELO - VRFY - MAIL - RCPT - DATA - RSET - NOOP - QUIT - -Any system that includes an SMTP server supporting mail relaying -or delivery, i.e., the RCPT command, MUST support the reserved -mailbox "postmaster" as a case-insensitive local name. This -postmaster address is not strictly necessary if the server always -returns 554 on connection opening (as described in section ##3.1). The -requirement to accept mail for postmaster implies that RCPT TO -commands which specify a mailbox for postmaster at any of the domains -for which the SMTP server provides mail service, as well as the -special case of "RCPT TO:<Postmaster>" (with no domain specification), -MUST be supported. - -EHLO SHOULD be supported if possible. - - - -4.5.2. TRANSPARENCY - -Without some provision for data transparency, the character -sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent -by the user. In general, users are not aware of such -"forbidden" sequences. To allow all user composed text to be -transmitted transparently, the following procedures are used. - - 1. Before sending a line of mail text, the SMTP client checks - the first character of the line. If it is a period, one - additional period is inserted at the beginning of the line. - - 2. When a line of mail text is received by the SMTP server, - it checks the line. If the line is composed of a single period, - it is treated as the end of mail indicator. If the first - character is a period and there are other characters on the line, - the first character is deleted. - -The mail data may contain any of the 128 ASCII characters. All -characters are to be delivered to the recipient's mailbox, including -format effectors and other control characters. If the transmission -channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII -codes are transmitted right justified in the octets, with the high -order bits cleared to zero. See ##3.7 for special treatment of these -conditions in SMTP systems serving a relay function. - -In some systems it may be necessary to transform the data as it is -received and stored. This may be necessary for hosts that use a -different character set than ASCII as their local character set or -store data in records rather than strings. If such transformationss -are necessary, they must be reversible -- especially if such -transformationss are applied to mail being relayed. - - -4.5.3. SIZES AND TIMEOUTS - -There are several objects that have required minimum/maximum sizes. -Every implementation must be able to receive objects of at least -these sizes. Objects larger than these sizes SHOULD be avoided when -possible. However, some Internet mail constructs, e.g., encoded -X.400 addresses [RFC-X400] will often require larger objects: clients -MAY attempt to transmit these, but MUST be prepared for a server to -reject them if they cannot be handled by it. - - -**************************************************** -* * -* TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * -* TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * -* OF THESE OBJECTS SHOULD BE USED. * -* * -**************************************************** - -local-part - - The maximum total length of a user name or other local-part - -is 64 characters. - -domain - - The maximum total length of a domain name or number is 255 - characters. - -path - - The maximum total length of a reverse-path or - forward-path is 256 characters (including the punctuation - and element separators). - -command line - - The maximum total length of a command line including the - command word and the <CRLF> is 512 characters. - -reply line - - The maximum total length of a reply line including the reply code - and the <CRLF> is 512 characters. More information may be - conveyed through multiple-line replies. - - -text line - - The maximum total length of a text line including the <CRLF> is - 1000 characters (not counting the leading dot duplicated for - transparency). This number may be increased by the use of SMTP - Service Extensions. - -message content - - The maximum total length of a message content (including any - message headers as well as the message body) MUST BE at least 64K - octets. Since the introduction of multimedia mail [RFC-MIME], - message lengths on the Internet have grown dramatically, and - message size restrictions should be avoided if at all possible. - SMTP server systems that must impose restrictions SHOULD implement - the "SIZE" service extension ([RFC-SIZE]), and SMTP client systems - that will send large messages SHOULD utilize it when possible. - -recipients buffer - - The minimum total number of recipients that must be buffered is - 100 recipients. Rejection of messages (for excessive recipients) - with fewer than 100 RCPT TO commands is a violation of this - specification. The general principle that relaying SMTP servers - MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation - tests on message headers suggests that rejecting a message based - on the total number of recipients shown in header fields is to be - discouraged. A server which imposes a limit on the number of - recipients MUST behave in an orderly fashion, e.g., reject - additional addresses over its limit rather than silently - discarding addresses previously accepted. A client that needs to - deliver a message containing over 100 RCPT TO commands SHOULD be - prepared to transmit in 100-recipient "chunks" if the server - declines to accept more than 100 recipients in a single message. - - -**************************************************** -* * -* TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * -* TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * -* OF THESE OBJECTS SHOULD BE USED. * -* * -**************************************************** - -Errors due to exceeding these limits may be reported by using the -reply codes, for example: - -500 Line too long. - -501 Path too long - -552 Too many recipients. - -<< Note in draft: Should this be 452?>> - -552 Too much mail data. - - -An SMTP client MUST provide a timeout mechanism. It MUST use -per-command timeouts rather than somehow trying to time the entire -mail transaction. Timeouts SHOULD be easily reconfigurable, -preferably without recompiling the SMTP code. To implement this, a -timer is set for each SMTP command and for each buffer of the data -transfer. The latter means that the overall timeout is inherently -proportional to the size of the message. - -Based on extensive experience with busy mail-relay hosts, the minimum -per-command timeout values SHOULD be as follows: - -o Initial 220 Message: 5 minutes - - An SMTP client process needs to distinguish between a failed TCP - connection and a delay in receiving the initial 220 greeting - message. Many SMTP servers accept a TCP connection but delay - delivery of the 220 message until their system load permits more - mail to be processed. - -o MAIL Command: 5 minutes - - -o RCPT Command: 5 minutes - - A longer timeout is required if processing of mailing lists and - aliases is not deferred until after the message was accepted. - -o DATA Initiation: 2 minutes - - This is while awaiting the "354 Start Input" reply to a - DATA command. - -o Data Block: 3 minutes - - This is while awaiting the completion of each TCP SEND call - transmitting a chunk of data. - -o DATA Termination: 10 minutes. - - This is while awaiting the "250 OK" reply. When the receiver - gets the final period terminating the message data, it typically - performs processing to deliver the message to a user mailbox. A - spurious timeout at this point would be very wasteful and would - typically result in delivery of multiple copies of the message, - since it has been successfully sent and the server has accepted - responsibility for delivery. See section ##6.1 for additional - discussion. - -An SMTP server SHOULD have a timeout of at least 5 minutes while it -is awaiting the next command from the sender. - - -4.5.4 Queuing Strategies - -The common structure of a host SMTP implementation includes user -mailboxes, one or more areas for queueing messages in transit, and -one or more daemon processes for sending and receiving mail. The -exact structure will vary depending on the needs of the users on the -host and the number and size of mailing lists supported by the host. -We describe several optimizations that have proved helpful, -particularly for mailers supporting high traffic levels. - -Any queueing strategy MUST include: - -o Timeouts on all activities on a per-command basis. - -o Never sending error messages in response to error messages. - - -4.5.4.1 Sending Strategy - -The general model for an SMTP client is one or more processes that -periodically attempt to transmit outgoing mail. In a typical system, -the program that composes a message has some method for requesting -immediate attention for a new piece of outgoing mail, while mail that -cannot be transmitted immediately MUST be queued and periodically -retried by the sender. A mail queue entry will include not only the -message itself but also the envelope information. - -The sender MUST delay retrying a particular destination after one -attempt has failed. In general, the retry interval SHOULD be at -least 30 minutes; however, more sophisticated and variable strategies -will be beneficial when the SMTP client can determine the reason for -non- delivery. - -Retries continue until the message is transmitted or the sender gives -up; the give-up time generally needs to be at least 4-5 days. The -parameters to the retry algorithm MUST be configurable. - -A client SHOULD keep a list of hosts it cannot reach and -corresponding connection timeouts, rather than just retrying queued -mail items. - - -Experience suggests that failures are typically transient (the target -system or its connection has crashed), favoring a policy of two -connection attempts in the first hour the message is in the queue, -and then backing off to one every two or three hours. - -The SMTP client can shorten the queuing delay in cooperation with the -SMTP server. For example, if mail is received from a particular -address, it is likely that mail queued for that host can now be sent. -Application of this principle may, in many cases, eliminate the -requirement for an explicit "send queues now" function such as that -discussed in [RFC-ETRN]. - -The strategy may be further modified as a result of multiple -addresses per host (see below) to optimize delivery time vs. -resource usage. - -An SMTP client may have a large queue of messages for each -unavailable destination host. If all of these messages were retried -in every retry cycle, there would be excessive Internet overhead and -the sending system would be blocked for a long period. Note that an -SMTP client can generally determine that a delivery attempt has -failed only after a timeout of several minutes and even a one-minute -timeout per connection will result in a very large delay if retries -are repeated for dozens, or even hundreds, of queued messages to the -same host. - -At the same time, SMTP clients should use great care in caching -negative responses from servers. In an extreme case, if EHLO is -issued multiple times during the same SMTP connection, different -answers may be returned by the server. More significantly, 5yz -responses to MAIL FROM MUST NOT be cached. - -When the same message will be delivered to several users on the same -host, only one copy of the message SHOULD be transmitted. That is, -the SMTP client SHOULD use the command sequence: RCPT, RCPT,... RCPT, -DATA instead of the sequence: RCPT, DATA, ..., RCPT, DATA, ... RCPT, -DATA. Implementation of this efficiency feature is strongly -encouraged. - -Similarly, to achieve timely delivery, the SMTP client MAY support -multiple concurrent outgoing mail transactions. However, some limit -may be appropriate to protect the host from devoting all its -resources to mail. - -4.5.4.2 Receiving strategy - -The SMTP server SHOULD attempt to keep a pending listen on the SMTP -port at all times. This requires the support of multiple incoming -TCP connections for SMTP. Some limit MAY be imposed. - -As discussed above, when the SMTP server receives mail from a -particular host address, it could notify the SMTP client to retry any -mail pending for that host address. - - - -5. Address resolution and mail handling - -Once an SMTP client lexically identifies a domain to which mail will -be delivered for processing (as described in sections ##3.6 and -##3.7), a DNS lookup is performed to resolve the domain name (see -[RFC-DNS]). The lookup first attempts to locate an MX record -associated with the name. If a CNAME record is found instead, the -resulting name is processed as if it were the initial name. If no MX -records are found, but an A RR is found, the A RR is treated as if it -was associated with an implicit MX RR, with a preference of 0, -pointing to that host. If one or more MX RRs are found for a given -name, SMTP systems MUST NOT utilize an A RRs associated with that -name unless they are located using the MX RRs; i.e., the "implicit -MX" rule above applies only if there are no MX records present. If -MX records are present, but none of them are usable, this situation -MUST be reported as an error. - -When the lookup succeeds, the mapping can result in a list of -alternative delivery addresses rather than a single address, because -of (a) multiple MX records, (b) multihoming, or both. To provide -reliable mail transmission, the SMTP client MUST be able to try (and -retry) each of the relevant addresses in this list in order, until a -delivery attempt succeeds. However, there MAY also be a configurable -limit on the number of alternate addresses that can be tried. In any -case, a host SHOULD try at least two addresses. - -The following information is used to rank the host addresses: - - (1) Multiple MX Records -- these contain a preference indication - that should be used in sorting (see below). Lower numbers are - more preferred than higher ones. If there are multiple - destinations with the same preference and there is no clear - reason to favor one (e.g., by recognition of an easily-reached - address), then the sender-SMTP SHOULD pick one at random to - spread the load across multiple mail exchangers for a specific - organization. - - (2) Multihomed host -- The destination host (perhaps taken from the - preferred MX record) may be multihomed, in which case the domain - name resolver will return a list of alternative IP addresses. It - is the responsibility of the domain name resolver interface to - have ordered this list by decreasing preference if necessary, and - SMTP MUST try them in the order presented. - - Although the capability to try multiple alternative addresses is - required, specific installations may want to limit or disable the - use of alternative addresses. The question of whether a sender - should attempt retries using the different addresses of a - multihomed host has been controversial. The main argument for - using the multiple addresses is that it maximizes the probability - of timely delivery, and indeed sometimes the probability of any - delivery; the counterargument is that it may result in - unnecessary resource use. - - Note that resource use is also strongly determined by the sending - strategy discussed in Section #4.5.4.1. - -If a host receives a message with a destination for which it is a -designated Mail eXchanger, it MAY relay the message (potentially -after having rewritten the addresses), make final delivery of the -message, or hand it off using some mechanism outside the -SMTP-provided transport environment. - -If it determines that it should relay the message without rewriting -the address, it must sort the MX records to determine candidates for -delivery. The records are first ordered by preference, with the -lowest-numbered records being most preferred. The relay host must -then inspect the list for any of the names or addresses by which it -might be known in mail transactions. If a matching record is found, -all records at that preference level and higher-numbered ones MUST BE -discarded from consideration. If there are no records left at that -point, it is an error condition, and the message must be returned as -undeliverable. If records do remain, they should be tried, best -preference first, as described above. - - -6. Problem detection and handling - -6.1 Reliable delivery and replies by email - -When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" -message in response to DATA), it is accepting responsibility for -delivering or relaying the message. It must take this responsibility -seriously, i.e., it MUST NOT lose the message for frivolous reasons, -e.g., because the host later crashes or because of a predictable -resource shortage. - -If there is a delivery failure after acceptance of a message, the -receiver-SMTP MUST formulate and mail a notification message. This -notification MUST be sent using a null ("<>") reverse path in the -envelope. The recipient of this notification SHOULD be the address -from the envelope return path (or the Return-Path: line). However, -if this address is null ("<>"), the receiver-SMTP MUST NOT send a -notification. If the address is an explicit source route, it MUST be -stripped down to its final hop. - -DISCUSSION: - For example, suppose that an error notification must be - sent for a message that arrived with: - MAIL FROM:<@a,@b:user@d> - The notification message should be sent using: - RCPT TO:<user@d> - -Some delivery failures after the message is accepted by SMTP will be -unavoidable. For example, it may be impossible for the receiving -SMTP server to validate all the delivery addresses in RCPT command(s) -due to a "soft" domain system error, because the target is a mailing -list (see earlier discussion of RCPT), or because the server is -acting as a relay and has no immediate access to the delivering -system. - -To avoid receiving duplicate messages as the result of timeouts, a -receiver-SMTP MUST seek to minimize the time required to respond to -the final <CRLF>.<CRLF> end of data indicator. See RFC-1047 -[RFC1047] for a discussion of this problem. - - -6.2 Loop detection - -Simple counting of the number of Received lines in a message has -proven to be an effective, although rarely optimal, method of -detecting loops in mail systems. SMTP servers using this technique -should use a large rejection threshold, normally at least 100 -Received entries. Whatever mechanisms are used, servers MUST contain -provisions for detecting and stopping trivial loops. - - -6.3 Compensating for irregularities - -Unfortunately, variations, creative interpretations, and outright -violations of Internet mail protocols do occur; some would suggest -that they occur quite frequently. The debate as to whether a -well-behaved SMTP receiver or relay should reject a malformed -message, attempt to pass it on unchanged, or attempt to repair it to -increase the odds of successful delivery (or subsequent reply) began -almost with the dawn of structured network mail and shows no signs of -abating. Advocates of rejection claim that attempted repairs are -rarely completely adequate and that rejection of bad messages is the -only way to get the offending software repaired. Advocates of -"repair" or "deliver no matter what" argue that users prefer that -mail go through it if at all possible and that there are significant -market pressures in that direction. In practice, these market -pressures may be more important to particular vendors than strict -conformance to the standards, regardless of the preference of the -actual developers. - -The problems associated with ill-formed messages were exacerbated by -the introduction of the split-UA mail reading protocols [RFC-POP2, -RFC-POP3, RFC-IMAP2, RFC-PCMAIL These protocols have encouraged the -use of SMTP as a posting protocol, and SMTP servers as relay systems -for these client hosts (which are often only intermittently connected -to the Internet). Historically, many of those client machines lacked -some of the mechanisms and information assumed by SMTP (and indeed, -by the mail format protocol [RFC-822]). Some could not keep adequate -track of time; others had no concept of time zones; still others -could not identify their own names or addresses; and, of course, none -could satisfy the assumptions that underlay RFC-822's conception of -authenticated addresses. - -In response to these weak SMTP clients, many SMTP systems now -complete messages that are delivered to them in incomplete or -incorrect form. This strategy is generally considered appropriate -when the server can identify or authenticate the client, and there -are prior agreements between them. By contrast, there is at best -great concern about fixes applied by a relay or delivery SMTP server -that has little or no knowledge of the user or client machine. - -The following changes to a message being processed MAY be applied by -an originating SMTP server, or one used as the target of SMTP as an -initial posting protocol, when necessary. The less information the -server has about the client, the less likely these changes are to be -correct and the more caution and conservatism should be applied when -considering whether or not to perform fixes and how. These changes -MUST NOT be applied by an SMTP server that provides an intermediate -relay function. - - - Addition of a message-id field when none appears - - - Addition of a date, time or time zone when none appears - - - Correction of addresses to proper FQDN format - -In all cases, properly-operating clients supplying correct -information are preferred to corrections by the SMTP server. In all -cases, documentation of actions performed by the servers (in trace -fields and/or header comments) is strongly encouraged. - - -7. Security Considerations - -7.1 Mail security and spoofing - -SMTP mail is inherently insecure in that it is feasible for even -fairly casual users to negotiate directly with receiving and relaying -SMTP servers and create messages that will trick a naive recipient -into believing that they came from somewhere else. Constructing such -a message so that the "spoofed" behavior cannot be detected by an -expert is somewhat more difficult, but not sufficiently so as to be a -deterrent to someone who is determined and knowledgeable. -Consequently, as knowledge of Internet mail increases, so does the -knowledge that SMTP mail inherently cannot be authenticated, or -integrity checks provided, at the transport level. - -Real mail security lies only in end-to-end methods involving the -message bodies, e.g., those that can be provided in the MOSS -framework [RFC-MOSS]. - -Efforts to make it more difficult for users to set envelope MAIL FROM -and header "From" fields to point to valid addresses other than their -own are largely misguided: they frustrate legitimate applications in -which mail is sent by one user on behalf of another or in which error -(or normal) replies should be directed to a special address. (Systems -that provide convenient ways for users to alter these fields on a -per-message basis should attempt to establish a primary and permanent -mailbox address for the user so that Sender fields within the message -data can be generated sensibly.) - - -This specification does not further address the authentication issues -associated with SMTP other than to advocate that useful functionality -not be disabled in the hope of providing some small margin of -protection against an ignorant user who is trying to fake mail. - - - -7.2 "Blind" copies. - -Addresses that do not appear in the message headers may appear in the -RCPT TO commands to an SMTP server for a number of reasons. The two -most common involve the use of a mailing address as a "list exploder" --- a single address that resolves into multiple addresses -- and the -appearance of "blind copies". In order to avoid defeating some of -the purpose of these mechanisms, SMTP clients and servers SHOULD NOT -copy the full set of RCPT TO command arguments into the headers, even -as informational or private-extension headers. Since this rule is -often violated in practice, and cannot be enforced, sending SMTP -systems that are aware of "bcc" use MAY find it helpful to send each -blind copy as a separate message transaction containing only a single -RCPT TO command. - -There is no inherent relationship between either "reverse" (MAIL -FROM, SAML FROM, etc.) or "forward" (RCPT TO) addresses in the SMTP -transaction ("envelope") and the addresses in the headers. Receiving -systems SHOULD NOT attempt to deduce such relationships and use them -to alter the headers of the message for delivery. The popular -"Apparently-to" header is a violation of this principle and SHOULD -NOT be used. - - -7.3 VRFY, EXPN, and security. - -As discussed in section ##3.5, individual sites may want to disable -one or both VRFY or EXPN for security reasons. As a corollary to the -above, implementations that permit this MUST NOT appear to have -verified addresses that are not, in fact, verified. If a site -disables these commands for security reasons, the SMTP server MUST -return a 252 response, rather than a code that could be confused with -successful or unsuccessful verification. - -Returning a 250 reply code with the address listed in the VRFY -command after having checked it only for syntax violates this rule. -Of course, an implementation that "supports" VRFY by always returning -550 whether or not the address is valid is equally not in conformance. - -Within the last four years, the contents of mailing lists have become -popular as an address information source for so-called "spammers." -The use of EXPN to "harvest" addresses has increased as list -administrators have installed protections against inappropriate uses -of the lists themselves. Implementations SHOULD still provide -support for EXPN, but sites should carefully evaluate the tradeoffs.. -As authentication mechanisms are introduced into SMTP, some sites may -choose to make EXPN available only to authenticated requestors. - - -7.4. Information Disclosure - -There has been an ongoing debate about the tradeoffs between the -debugging advantages of announcing server type and version (and, -sometimes, even server domain name) in the greeting response or in -response to the HELP command and the disadvantages of exposing useful -information to potential hostile attack. The utility of the -debugging information is beyond doubt. Those who argue for making it -available point out that it is far better to actually secure an SMTP -server rather than hope that trying to conceal known vunerabilities -by hiding the server's precise identity will provide more protection. -Sites are encouraged to evaluate the tradeoff with that issue in -mind; implementations are strongly encouraged to minimally provide -for making type and version information available in some way to -other network hosts. - - -7.5. Scope of operation of SMTP servers - -It is a well-established principle that an SMTP server may refuse to -accept mail for any operational or technical reason that makes sense -to the site providing the server. However, cooperation among sites -and installations makes the Internet possible.. If sites take -excessive advantage of the right to reject traffic, the ubiquity of -email availability (one of the strengths of the Internet) will be -threatened; considerable care should be taken and balance maintained -if a site decides to be selective about the traffic it will accept -and process. - -In recent years, use of the relay function through arbitrary sites -has been used as part of hostile efforts to hide the actual origins -of mail. Some sites have decided to limit the use of the relay -function to known or identifiable sources, and implementations SHOULD -provide the capability to perform this type of filtering. When mail -is rejected for these or other policy reasons, a 550 code should be -used in response to EHLO, MAIL FROM, or RCPT TO as appropriate. - - -8. IANA Considerations - -IANA is [[requested]] to set up two registries. The first consists -of SMTP service extensions with the associated keywords, and, as -needed, parameters and verbs. As specified in section ##2.2.2, no -entry may be made in this registry that starts in an "X". Entries -may be made only for service extensions (and associated keywords, -parameters, or verbs) that are defined in standards-track or -experimental RFCs specifically approved by IESG for this purpose. - -The second registry consists of "tags" that identify forms of domain -literals other than those for IPv4 addresses (specified in RFC 821 -and in this document) and IPv6 addresses (specified in this -document). Additional literal types require standardization before -being used; none are anticipated at this time. - - -9. REFERENCES - -[1] ASCII - - ASCII, "USA Code for Information Interchange", United States of - America Standards Institute (now American National Standards - Institute), X3.4, 1968. ANSI X3.4-1968 has been replaced by - newer versions with slight modifications, but the 1968 - version remains definitive for the Internet. - -[RFC822] - Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", RFC 822, Department of Electrical Engineering, - University of Delaware, August 1982. - -[3] TCP - Postel, J., ed., "Transmission Control Protocol - DARPA Internet - Program Protocol Specification", RFC 793, USC/Information Sciences - Institute, NTIS AD Number A111091, September 1981. - -[HEADER-PEOPLE] - -[RFC-DNS] P. Mockapetris, "Domain names - implementation and - specification", RFC 1035 and P. Mockapetris, "Domain names - - concepts and facilities", RFC 1034. (STD 13) - -[RFC974] C. Partridge, "Mail routing and the domain system", RFC - 974, 01/01/1986 - -[RFC1047] C. Partridge, "Duplicate messages and SMTP", RFC 1047, - 02/01/1988. - -[RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension - for Message Size Declaration", RFC 1870, 11/06/1995. (STD 10) - -[RFC-MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message - Bodies", RFC 2045, 12/02/1996. - -[RFC-INTLHDR] K. Moore, "MIME (Multipurpose Internet Mail Extensions) - Part Three: Message Header Extensions for Non-ASCII Text", - RFC 2047, 12/02/1996. - -[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, - "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, - 07/18/1994. - -[SMTPEX] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. - Crocker, "SMTP Service Extensions", RFC-1869, 11/06/1995. - -[RFC-1123] R. Braden, "Requirements for Internet hosts - - application and support", 10/01/1989 - -[RFC-MOSS] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object - Security Services", RFC 1848, 10/03/1995. - -[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J. - Reynolds, "Post Office Protocol - version 2", RFC 937, - 02/01/1985 - -[RFC-IMAP2] M. Crispin, "Interactive Mail Access Protocol - Version - 2", RFC 1176, 08/20/1990. - -[RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for - personal computers", RFC 1056, 06/01/1988. - -[RFC-POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3", - RFC 1930, 5/14/96 (Std 53). - -[RFC-IMAP4] M. Crispin, "Internet Message Access Protocol - - Version 4", RFC 2060, 12/04/1996. - -[RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / - ISO 10021 and RFC 822", RFC 1327, 05/18/1992. - -[RFC-ETRN] J. De Winter, "SMTP Service Extension for Remote - Message Queue Starting", RFC 1985, 08/14/1996. - -[RFC-BDAT] G. Vaudreuil, "SMTP Service Extensions for - Transmission of Large and Binary MIME Messages", RFC 1830, - 08/16/1995. - -[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension - for Command Pipelining", RFC 1854, 10/04/1995. - -[RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery - Status Notifications", RFC 1891, 01/15/1996. - -[RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message - Format for Delivery Status Notifications", RFC 1894, - 01/15/1996. - -[RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes", - RFC 1893, 01/15/1996. - -[ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", - (in progress -- draft-ietf-drums-abnf-03.txt) - -[MSGFMT] P. Resnick, Work in progress, - draft-ietf-drums-msg-fmt-02.txt, June 1997. - - -9. Editor's Addresses - - John C. Klensin - MCI Communications - 800 Boylston St., 7th floor - Boston, MA 02199 - USA - Email: Klensin@mci.net - Phone: +1 617 960 1011 - Fax: +1 617 960 1009 - -Dawn P. Mann -Microsoft Corporation -1 Microsoft Way -Redmond, WA 98052-6399 -USA - Email: dawnm@microsoft.com - Tel: +1 425 936 5475 - - - -10. Acknowledgments - -<<>>to be supplied>> - - - -APPENDIX A - -TCP Transport service - -The Transmission Control Protocol [3] is used in the Internet, and in -any network following the Internet standards for internetwork protocols. - -Connection Establishment - - The SMTP transmission channel is a TCP connection established - between the sender process port U and the receiver process port - L. This single full duplex connection is used as the - transmission channel. This protocol is assigned the service - port 25 (31 octal), that is L=25. - -Data Transfer - - The TCP connection supports the transmission of 8-bit bytes. - The SMTP data is 7-bit ASCII characters. Each character is - transmitted as an 8-bit byte with the high-order bit cleared to - zero. Service extensions may modify this rule to permit - transmission of full 8-bit data bytes as part of the message - body, but not in SMTP commands or responses. - - - -APPENDIX B - -Generating SMTP commands from RFC 822 headers - -Some systems use RFC 822 headers (only) in a mail submission -protocol, or otherwise generate SMTP commands from RFC 822 headers -when such a message is handed to an MTA from a UA. While the MTA-UA -protocol is a private matter, not covered by any Internet Standard, -there are problems with this approach. For example, there have been -repeated problems with proper handling of "bcc" copies and -redistribution lists when information that conceptually belongs to a -mail envelopes is not separated early in processing from header -information (and kept separate). - -It is recommended that the UA provide its initial MTA with an -envelope separate from the message itself. However, if the envelope -is not supplied, SMTP commands should be generated as follows: - -(i) each recipient address from a TO, CC, or BCC header field -should be copied to a RCPT command (generating multiple message -copies if that is required for queuing or delivery). This includes -any addresses listed in a RFC 822 "group". Any BCC fields should -then be removed from the headers. Once this process is completed, -the remaining headers should be checked to verify that at least one -To:, Cc:, or Bcc: header remains. If none do, then a bcc: header -with no additional information SHOULD be inserted as specified in -[MSGFMT]. - -(ii) the return address in the MAIL command should, if possible, be -derived from the system's identity for the submitting (local) user. -And the From header field otherwise. If there is a system identity -available, it should also be copied to the Sender header field if it -is different from the address in the From header field. (Any Sender -field that was already there should be removed.) Systems may provide -a way for submitters to override the envelope return address, but may -want to restrict its use to privileged users. (This will not prevent -mail forgery, but may lessen its incidence -- see section 7.1.) - -When an MTA is being used in this way, it bears responsibility for -ensuring that the message being transmitted is valid. The mechanisms -for checking that validity, and for handling (or returning) messages -that are not valid at the time of arrival, are part of the MUA-MTA -interface and not covered by this specification. - -A submission protocol based on Standard RFC 822 information alone -MUST NOT be used to gateway a message from a foreign (non-SMTP) mail -system into an SMTP environment. Additional information to construct -an envelope must come from some source in the other environment, -whether supplemental headers or the foreign system's envelope. - -Attempts to gateway messages using only their header "to" and "cc" -fields, have repeatedly caused mail loops and other behavior adverse -to the proper functioning of the Internet mail environment. These -problems have been especially common when the message originates from -an Internet mailing list and is distributed into the foreign -environment using envelope information. When these messages are then -processed by a header-only remailer, loops back to the Internet -environment (and the mailing list) are almost inevitable. - - -APPENDIX C - -Source routes. - -The <reverse-path> is a reverse source routing list of hosts and a -source mailbox. The first host in the <reverse-path> should be the -host sending the MAIL FROM command. Similarly, the <forward-path> -may be a source routing lists of hosts and a destination mailbox. -However, in general, the <forward-path> should contain only a mailbox -and domain name, relying on the domain name system to supply routing -information if required. The use of source routes is deprecated; -while servers MUST be prepared to receive and handle them as -discussed in section ##3.3 and below, clients SHOULD NOT transmit -them. - -For relay purposes, the forward-path may be a source route of the -form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE -fully-qualified domain names. This form is used to emphasize the -distinction between an address and a route. The mailbox is an -absolute address, and the route is information about how to get -there. The two concepts should not be confused. - -If source routes are used, RFC 821 and the text below should be -consulted for the mechanisms for constructing and updating the -forward- and reverse-paths. - -The SMTP server transforms the command arguments by moving its own -identifier (its domain name or that of any domain for which it is -acting as a mail exchanger), if it appears, from the forward-path to -the beginning of the reverse-path. - -Notice that the forward-path and reverse-path appear in the SMTP -commands and replies, but not necessarily in the message. That is, -there is no need for these paths and especially this syntax to appear -in the "To:" , "From:", "CC:", etc. fields of the message header. -Conversely, SMTP servers MUST NOT derive final message delivery -information from message header fields. - - When the list of hosts is present, it is a "reverse" source route -and indicates that the mail was relayed through each host on the list -(the first host in the list was the most recent relay). This list is -used as a source route to return non-delivery notices to the sender. -As each relay host adds itself to the beginning of the list, it must -use its name as known in the transport environment to which it is -relaying the mail rather than that of the transport environment from -which the mail came (if they are different). - - - - -APPENDIX F - -Scenarios - -This section presents complete scenarios of several types of SMTP -sessions. - -A Typical SMTP Transaction Scenario - -This SMTP example shows mail sent by Smith at host USC-ISIF, to -Jones, Green, and Brown at host BBN-UNIX. Here we assume that host -USC-ISIF contacts host BBN-UNIX directly. The mail is accepted for -Jones and Brown. Green does not have a mailbox at host BBN-UNIX. - -------------------------------------------------------------- - - R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIF.ARPA - R: 250 BBN-UNIX.ARPA - - S: MAIL FROM:<Smith@USC-ISIF.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@BBN-UNIX.ARPA> - R: 250 OK - - S: RCPT TO:<Green@BBN-UNIX.ARPA> - R: 550 No such user here - - S: RCPT TO:<Brown@BBN-UNIX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 BBN-UNIX.ARPA Service closing transmission channel - - Scenario 1 - -------------------------------------------------------------- - - - - - -Aborted SMTP Transaction Scenario - -------------------------------------------------------------- - - R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready - S: HELO ISI-VAXA.ARPA - R: 250 MIT-Multics.ARPA - - S: MAIL FROM:<Smith@ISI-VAXA.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@MIT-Multics.ARPA> - R: 250 OK - - S: RCPT TO:<Green@MIT-Multics.ARPA> - R: 550 No such user here - - S: RSET - R: 250 OK - - S: QUIT - R: 221 MIT-Multics.ARPA Service closing transmission channel - - Scenario 2 - -------------------------------------------------------------- - - - -Relayed Mail Scenario - -------------------------------------------------------------- - - Step 1 -- Source Host to Relay Host - - R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-AI.ARPA - R: 250 USC-ISIE.ARPA - - S: MAIL FROM:<JQP@MIT-AI.ARPA> - R: 250 OK - - S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Date: 2 Nov 81 22:33:44 - S: From: John Q. Public <JQP@MIT-AI.ARPA> - S: Subject: The Next Meeting of the Board - S: To: Jones@BBN-Vax.ARPA - S: - S: Bill: - S: The next meeting of the board of directors will be - S: on Tuesday. - S: John. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - - Step 2 -- Relay Host to Destination Host - - R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIE.ARPA - R: 250 BBN-VAX.ARPA - - S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@BBN-VAX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ; - 2 Nov 81 22:40:10 UT - S: Date: 2 Nov 81 22:33:44 - S: From: John Q. Public <JQP@MIT-AI.ARPA> - S: Subject: The Next Meeting of the Board - S: To: Jones@BBN-Vax.ARPA - S: - S: Bill: - S: The next meeting of the board of directors will be - S: on Tuesday. - S: John. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - Scenario 3 - -------------------------------------------------------------- - - - - -Verifying and Sending Scenario - -------------------------------------------------------------- - - R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-MC.ARPA - R: 250 SU-SCORE.ARPA - - S: VRFY Crispin - R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA> - - S: SEND FROM:<EAK@MIT-MC.ARPA> - R: 250 OK - - S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 SU-SCORE.ARPA Service closing transmission channel - - Scenario 4 - -------------------------------------------------------------- - - - - -Mailing List Scenario - -First each of two mailing lists are expanded in separate sessions -with different hosts. Then the message is sent to everyone that -appeared on either list (but no duplicates) via a relay host. - -------------------------------------------------------------- - - Step 1 -- Expanding the First List - - R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 MIT-AI.ARPA - - S: EXPN Example-People - R: 250-<ABC@MIT-MC.ARPA> - R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA> - R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA> - R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250-<joe@foo-unix.ARPA> - R: 250 <xyz@bar-unix.ARPA> - - S: QUIT - R: 221 MIT-AI.ARPA Service closing transmission channel - - - Step 2 -- Expanding the Second List - - R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 MIT-MC.ARPA - - S: EXPN Interested-Parties - R: 250-Al Calico <ABC@MIT-MC.ARPA> - R: 250-<XYZ@MIT-AI.ARPA> - R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250-<fred@BBN-UNIX.ARPA> - R: 250 <xyz@bar-unix.ARPA> - - S: QUIT - R: 221 MIT-MC.ARPA Service closing transmission channel - - - Step 3 -- Mailing to All via a Relay Host - - R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 USC-ISIE.ARPA - - S: MAIL FROM:<Account.Person@SU-SCORE.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA> - R: 250 OK - S: RCPT - TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - Scenario 7 - -------------------------------------------------------------- - - - -Too Many Recipients Scenario - -------------------------------------------------------------- - - R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIF.ARPA - R: 250 BERKELEY.ARPA - - S: MAIL FROM:<Postel@USC-ISIF.ARPA> - R: 250 OK - - S: RCPT TO:<fabry@BERKELEY.ARPA> - R: 250 OK - - S: RCPT TO:<eric@BERKELEY.ARPA> - R: 552 Recipient storage full, try again in another transaction - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: MAIL FROM:<Postel@USC-ISIF.ARPA> - R: 250 OK - - S: RCPT TO:<eric@BERKELEY.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 BERKELEY.ARPA Service closing transmission channel - - Scenario 10 - -------------------------------------------------------------- - -Note that a real implementation must handle many recipients as -specified in Section ##4.5.3. - - - -APPENDIX G Other gateway issues. - -In general, gateways between the Internet and other mail systems -SHOULD attempt to preserve any layering semantics across the -boundaries between the two mail systems involved. Gateway- -translation approaches that attempt to take shortcuts by mapping, -e.g., envelope information from one system to the message headers or -body of another have generally proven to be inadequate in important -ways. Systems translating between environments that do not support -both envelopes and headers and Internet mail must be written with the -understanding that some information loss is almost inevitable. - - - -APPENDIX I: Deprecated features of RFC 821 - -A few features of RFC 821 have proven to be problematic and should -not be used in Internet mail. These are: - -(1) TURN - -This command, described in RFC 821, raises important security issues -(described in RFC 1123). Its use is deprecated; SMTP systems SHOULD -NOT use it unless the server can authenticate the client. - -(2) Source routing - -RFC 821 utilized the concept of explicit source routing to get mail -from one host to another via a series of relays. The requirement to -utilize source routes in regular mail traffic was eliminated by the -introduction of the domain name system "MX" record and the last -significant justification for them was eliminated by the -introduction, in RFC 1123, of a clear requirement that addresses -following an "@" must all be fully-qualified domain names. -Consequently, the only remaining justifications for the use of source -routes are support for very old SMTP clients or MUAs and in mail -system debugging. They can, however, still be useful in the latter -circumstance and for routing mail around serious, but temporary, -problems such as problems with the relevant DNS records. - -SMTP servers MUST continue to accept source route syntax as specified -in the main body of this document and in RFC 1123. They MAY, if -necessary, ignore the routes and utilize only the target domain in -the address. If they do utilize the source route, the message MUST -be sent to the first domain shown in the address. In particular, a -server MUST NOT guess at shortcuts within the source route. - -Clients SHOULD NOT utilize explicit source routing except under -unusual circumstances, such as debugging or potentially relaying -around firewall or mail system configuration errors. - -(3) HELO - -As discussed in sections ##3.1 and ##4.1.1, EHLO is strongly -preferred to HELO when the server will accept the former. Servers -must continue to accept and process HELO in order to support older -clients. - - -(4) #-literals - -RFC 821 provided for specifying an Internet address as a decimal -integer host number prefixed by a pound sign, "#". In practice, that -form has been obsolete since the introduction of TCP/IP. It is -deprecated and MUST NOT be used. - -(5) Dates and years - -When dates are inserted into messages by SMTP clients or servers -(e.g., in trace fields), four-digit years MUST BE used. Two-digit -years are deprecated; three-digit years were never permitted in the -Internet mail system. - -(6) Sending versus mailing - -In addition to specifying a mechanism for delivering messages to -user's mailboxes, RFC 821 provided additional, optional, commands to -deliver messages directly to the user's terminal screen. These -commands (SEND, SAML, SOML) were rarely implemented, and changes in -workstation technology and the introduction of other protocols may -have rendered them obsolete even where they are implemented. - -Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers -MAY implement them. If they are implemented by servers, the -implementation model specified in RFC 821 MUST be used and the -command names MUST be published in the response to the EHLO command. - - - -APPENDIX X: Change summary and Loose ends (temporary) - -X.1 Change summary - -X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and -draft-ietf-drums-smtpupd-01.txt - -(i) Slightly clarified the discussions of rejection and failure of -VRFY requests and the associated response codes. - -(ii) Slightly clarified the discussion of deferred address -validation. - -(iii) Removed the IPCE terminology and modified the text in section -##4.1.1.2 to explicitly introduce the "mail gateway" terminology and -to begin to distinguish a mail gateway from a conventional relay. - -(iv) Explicitly noted that SMTP clients for things like POP and IMAP -may send everything to a single relay for further processing, rather -than resolving final domain names. - -(v) Tightened the RSET discussion. - -(vi) Deprecation of 251 only for RCPT (still ok for VRFY) - - - -X.1.2. Substantive changes between draft-ietf-drums-smtpupd-01.txt -and draft-ietf-drums-smtpupd-02.txt. - -Incorporated additional RFC 1123 material; reorganized several -sections for clarity. Added definitions and other previous "loose -end" material. - - -X.1.3. Substantive changes between draft-ietf-drums-smtpupd-02.txt -and draft-ietf-drums-smtpupd-03.txt. - -(i) Eliminated a number of placeholders and tightened some of the -definitions in section 2. Added a few new placeholders for -consistency checking against other documents. - -(ii) Removed the state diagrams, per direction at IETF Montreal. - -(iii) Added new section 6.3, an attempt to summarize WG discussions -on the "posting" versus "delivery" versus "relay" functions of SMTP -and on whether "fixups" are appropriate in different cases. - -(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of -RFC1123. - -(v) Added new text to 3.5.5 to discuss the spammer - EXPN -relationship. - -(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat. - -(v) The remaining miscellaneous changes agreed to in Montreal have -been incorporated except as noted below. - - -X.1.4. Substantive changes between draft-ietf-drums-smtpupd-03.txt -and draft-ietf-drums-smtpupd-04.txt. - -Many small changes have been made between these two versions; the -list that follows is not exhaustive. - -(i) To clarify some of the text, definitions have been introduced to -distinguish among originating, delivery, relay, and gateway SMTP -systems. - -(ii) The role of LF-terminated lines has been clarified. - -(iii) Several changes have been made to clarify the principle -that, no matter what originating and final delivery systems -might do, relay systems are not permitted to tamper with message -content, even to "fix" headers that are determined to be -invalid. If they deem message content to be seriously -unacceptable, they are encouraged to reject the messages in -preference to trying to fix them up, but, in general, the theme -is "don't look/ don't tell". - -(iv) A few more definitions have been added to the terminology -section, and the separate glossary has been eliminated. - -(v) I have taken a shot at text to address some of the controversies -that have raged on the WG mailing list (e.g., sections 7.4 and 7.5). -Since there was no consensus on most of those topics, I expect that -the inserted text will satisfy no one except, perhaps, for agreement -that saying nothing would have been worse. As a mechanism for moving -forward, the text in these controversial areas that now appears will -be considered "base"; alterations will be made only if clear -consensus emerges. - -(vi) Per discussion in Los Angeles, source routes have been further -deprecated. - -(vii) Some of the VRFY/EXPN materials have been moved to "security -considerations", where they appear to belong, some text has been -added, and the conformance statements adjusted to reflect what I -perceive to be WG consensus. - -(viii) New MX resolution material has been added to section 5. While -most of this material is from RFC974, the rules have been further -tightened to reflect current practice and experience (974 is written -in a somewhat speculative fashion for a standard). In particular, -the behavior of trying the target host's A RR when MXs existed but -all of them were eliminated is now prohibited, which seems necessary -if another of other ideas being recommended or considered are to be -feasible. - - -X.1.5. Substantive changes between draft-ietf-drums-smtpupd-04.txt -and draft-ietf-drums-smtpupd-05.txt. - -(i) All normative references to RFC 1123 have been removed from the -main body of the text (some still appear in the appendices where they -will remain). - -(ii) Section 3.5 has been renamed slightly to distinguish between -"debuging of SMTP implementations" and "debugging of addresses". -Better terminology would be welcome. - -(iii) Error conditions resulting from the DATA command have been -clarified. - -(iv) Section 4.2 (SMTP replies) has been revised and tightened to -reflect reality and recent discussion on the list. - -(v) Appendix E has been revised a bit and moved into section 4.2.1. -Given the importance of the "check only first digit" rule, it has to -be there. - -(vi) Added new text for "no SMTP service supported" to sections -3.1, 4.2.2, 4.2.3, and 4.3.2. As noted in 3.1, I'd rather add 521 -(which would work perfectly with the model) rather than overloading -554. - -(vii) The Return-path language in section 4.4 has been cleaned up a -bit. - -(viii) Tightened the "postmaster" language in 4.5.1, requiring a -small change to 4.1.1.3. - -(ix) I have unilaterally (with a little help from my friends), -increased some of the size limits. 64 was much too short for a -domain name, and the DNS limit of 255 (?) has now been inserted. -That leaves the return path much too short, but I haven't fixed it -(maybe that will cause us to get rid of them). We still have a 64 -character limit on the local-part, which is also *much* too short. -Votes for 128 or longer limits accepted. See X.1.6(I) - -(x) The text on the "recipients buffer" has been rewritten so that (I -hope) it makes sense and gives some explicit guidance for how clients -and servers should proceed if limits are imposed. - - -X.1.6. Substantive changes between draft-ietf-drums-smtpupd-05.txt -and draft-ietf-drums-smtpupd-06.txt. - -Most of the changes in this revision have been editorial rather than -substantive. Major substantive changes include: - -(i) The language about maximum sizes of SMTP command lines has been -reworked, per WG mailing list discussion. - -(ii) Several instances of "Should" have been promoted to "Must" when the -reasons for the weaker rule seemed to have disappeared. In -particular, the requirement that an SMTP implementation support -timeouts has become a MUST. Also, conformance to this specification -requires support of EHLO. Older systems should claim conformance to -the [to-be-historical] 821, not this specification. - - - -X.2 Loose ends - -(i) The 822 BNF -> ABNF transition is not yet complete, and most of -what has been done needs checking. - -(ii) Most examples are not yet revised, overview and grammar are -still to be merged. - -(iii) We have agreed that all of the definition of trace ("Received:") -fields should be moved to this document from the message format one. -That work is not yet complete, partially because I’m still waiting on -ABNF. There are also several unanswered questions about exactly what -should be said. - -(iv) The Appendices have not yet been numbered consecutively. Note -that Appendix X is temporary and is not expected to appear in any -final publication. - -(v) See X.1.5(ix), above. - -See also Chris Newman's "Drums open issues" list. diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-07.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-07.txt deleted file mode 100644 index c3363caa..00000000 --- a/Documentation/en/I-D/draft-ietf-drums-smtpupd-07.txt +++ /dev/null @@ -1,4053 +0,0 @@ - - -INTERNET-DRAFT John C. Klensin, Editor -Expires in six months Dawn P. Mann, Co-Editor - May 20, 1998 - - - Simple Mail Transfer Protocol - - draft-ietf-drums-smtpupd-07.txt - - -Status of this Memo - - -This document is an Internet-Draft. 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." - -To view the entire list of current Internet-Drafts, please check -the "1id-abstracts.txt" listing contained in the Internet-Drafts -Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net -(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au -(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu -(US West Coast). - -If consensus is reached on this document, it will be forwarded to the -IESG with the recommendation that it be processed onto the Standards -track. - -[[Sections marked with doubled brackets (e.g., "<<") are explicit -placeholders or known major loose ends. The marking ## is a note in -the draft to recheck a section number and should be ignored.]] - -[[As discussed in the WG, most of the syntax and examples have not -been changed from 821 -- those changes are a last- step item, after -the ABNF document completely stabilizes and differences with 822bis -have been resolved. Similarly, the numbers of appendices will be -rationalized (and Appendix X removed) before the document is -submitted to the IESG. Please check appendix X.2 for additional -problems of which the editor is already painfully aware before -complaining about things that are missing.]] - - - TABLE OF CONTENTS - 0. ABSTRACT - - 1. INTRODUCTION - - 2. THE SMTP MODEL - - 2.1 Basic structure - 2.2 The extension model - 2.3 Other terminology - 2.4 Syntax Principles - - - 3. THE SMTP PROCEDURES: AN OVERVIEW - - 3.1 Session initiation - 3.2 Client initiation - 3.3 Mail transactions - 3.4 Forwarding for Address Correction or Updating - 3.5 Commands for Debugging Addresses - 3.6 Domains - 3.7 Relaying - 3.8 Mail Gatewaying - 3.9 Terminating sessions and connections - 3.10 Mailing lists and Aliases - - - 4. THE SMTP SPECIFICATIONS - - 4.1. SMTP Commands - 4.1.1. Command Semantics and Syntax - 4.1.2. Lower-level Syntax - 4.1.3. Address literals - 4.1.4. Order of commands - 4.1.5. Private-use commands - 4.2. SMTP Replies - 4.2.1. Reply Code Severities and Theory - 4.2.2. Reply Codes by Function Group - 4.2.3. Reply Codes in Numeric Order - 4.2.4. Reply code 502 - 4.2.5 Reply codes after DATA and the subsequent CRLF.CRLF. - 4.3. Sequencing of Commands and Replies - 4.4 Trace information - 4.5. Details - 4.5.1. Minimum Implementation - 4.5.2. Transparency - 4.5.3. Sizes and Timeouts - 4.5.4 SMTP Queuing Strategies - - 5. Address resolution and mail handling - - 6. Problem detection and handling - 6.1 Reliable delivery and replies by email - 6.2 Loop detection - 6.3 Compensating for irregularities - - 7. Security Considerations - 7.1 Mail security and spoofing - 7.2 "Blind" copies - 7.3 VRFY, EXPN, and security - 7.4 Information disclosure - 7.5 Scope of operation of SMTP servers - - 8. IANA Considerations - - 9. References - - 10. Editor's addresses - - 11. Acknowledgments - - APPENDIX A: TCP - APPENDIX B: Generating SMTP commands from RFC 822 headers - APPENDIX C: Source routes - APPENDIX F: Scenarios - APPENDIX G: Other gateway issues. - APPENDIX I: Deprecated features of RFC 821 - APPENDIX X: Change summary and Loose ends (temporary) - - - - - -0. Abstract - -This document is a self-contained specification of the basic protocol -for the Internet electronic mail transport, consolidating and -updating - - * the original SMTP specification of RFC 821 [RFC-821], - * Domain name system requirements and implications for mail - transport from RFC 1035 [RFC-DNS] and RFC 974 [RFC974], - * the clarifications and applicability statements in - RFC 1123 [RFC-1123], and - * material drawn from the SMTP Extension mechanisms [SMTPEXT]. - -It replaces RFC 821, RFC 974, and the mail transport materials of RFC -1123. However, RFC 821 specifies some features that are not in -significant use in the Internet of the mid-1990s and (in appendices) -some additional transport models. Those sections are omitted here in -the interest of clarity and brevity; readers needing them should -refer to RFC 821. - -It also includes some additional material from RFC 1123 that required -amplification. This material has been identified in multiple ways, -mostly by tracking flaming on the header-people list [HEADER-PEOPLE] -and problems of unusual readings or interpretations that have turned -up as the SMTP extensions have been deployed. Where this -specification moves beyond consolidation and actually differs from -earlier documents, it supersedes them technically as well as -textually. - -Although SMTP was designed as a mail transport and delivery protocol, -this specification also contains information that is important to its -use as a "mail posting" protocol, as recommended for POP [RFC-POP2, -RFC-POP3] and IMAP [RFC-IMAP4]. - -Section ##2.3 provides definitions of terms specific to this -document. Except when the historical terminology is necessary for -clarity, this document uses the current "client" and "server" -terminology to identify the sending and receiving SMTP processes, -respectively. - -A companion document discusses message bodies and formats RFC 822, -MIME, and their relationship - [MSGFMT]. - -1. INTRODUCTION - -The objective of the Simple Mail Transfer Protocol (SMTP) is to -transfer mail reliably and efficiently. - -SMTP is independent of the particular transmission subsystem and -requires only a reliable ordered data stream channel. While this -document specifically discusses transport over TCP, other transports -are possible. Appendices to RFC 821 describe some of them. - -An important feature of SMTP is its capability to transport mail -across transport service environments, usually referred to as "mail -gatewaying" (see section 3.8). A transport service environment might -consist of the mutually-TCP-accessible hosts on the public Internet, -a firewall-isolated private TCP/IP LAN, or a LAN or WAN environment -utilizing an entirely different transport-level protocol. It is -important to realize that "transport systems" are one-to-one with -usual definitions of "networks". A process can communicate directly -with another process, and transport mail using this protocol, through -any mutually known transport layer. Conversely, mail can be relayed -(actually gatewayed) between hosts on different transport systems by -a host on both transport systems. The Mail eXchanger mechanisms of -the domain name system [RFC-DNS, and section ##5 of this document] -usually permit relaying and gatewaying to occur invisibly to the user. - - -2. THE SMTP MODEL - -2.1 Basic structure - -The SMTP design is based on the following model of communication: as -the result of a user mail request (or transfer from a mail user agent -(see section ##2.3)), the SMTP client establishes a two-way -transmission channel to an SMTP server. A fully-capable SMTP client -determines the address of an appropriate host running an SMTP server -by resolving the domain name given in the SMTP request to either an -intermediate mail exchanger host or a final target host. In other -cases, common with clients associated with implementations of the POP -[RFC-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the -client is inside an isolated transport service environment, the SMTP -client may send all of its traffic to a single SMTP server which, in -turn, relays the mail to final (or other intermediate) destinations. -The relay and those destinations are expected to support all of the -queuing, retrying, and alternate address functions discussed in this -specification. - -The SMTP server may be either the ultimate destination or an -intermediate "relay" (i.e., may assume the role of an SMTP client -after receiving the message). SMTP commands are generated by the -SMTP client and sent to the SMTP server. SMTP replies are sent from -the SMTP server to the SMTP client in response to the commands. - -Once the transmission channel is established and initial handshaking -completed, the SMTP client normally initiates a mail transaction. -Such a transaction consists of a series of commands to specify the -originator and destination of the mail and transmission of the -message content (including any headers or other structure) itself. -When the same message is sent to multiple recipients, this protocol -encourages the transmission of only one copy of the data for all -recipients at the same destination (or intermediate relay) host. - -The server responds to each command with a reply; replies may -indicate that the command was accepted, that additional commands are -expected, or that a temporary or permanent error condition exists. -Commands specifying the sender or recipients may include -server-permitted SMTP service extension requests as discussed in -section ##2.2. The dialog is purposely lock-step, one-at-a-time, -although this can be modified by mutually-agreed extension requests -(e.g., [RFC-Pipeline]). - -Once a given mail message has been transmitted, the client may either -request that the connection be shut down or may initiate other mail -transactions. - - ------------------------------------------------------------- - - - +----------+ +----------+ - +------+ | | | | - | User |<-->| | SMTP | | - +------+ | Sender- |Commands/Replies| Receiver-| - +------+ | SMTP |<-------------->| SMTP | +------+ - | File |<-->| | and Mail | |<-->| File | - |System| | | | | |System| - +------+ +----------+ +----------+ +------+ - - - SMTP client SMTP server - - Model for SMTP Use - - Figure 1 - - ------------------------------------------------------------- - -In addition, an SMTP client may use a connection to an SMTP server -for ancillary services such as verification of email addresses or -retrieval of mailing list subscriber addresses. - -As suggested above, this protocol provides mechanisms for the -transmission of mail. This transmission normally occurs directly -from the sending user's host to the receiving user's host when the -two hosts are connected to the same transport service. When they are -not connected to the same transport service, transmission occurs via -one or more relay SMTP servers. An intermediate host that acts -as either an SMTP relay or as a gateway into some other transmission -environment may also be selected through the use of the domain name -service (DNS) Mail eXchanger mechanism. - -To provide relay capability, the SMTP server is supplied with the -name of the ultimate destination host as well as the destination -mailbox name. Usually, intermediate hosts are determined via the DNS -MX record, not by explicit "source" routing (see Appendices ##C and -##I). - - - -2.2 The Extension Model - -2.2.1 Background - -In an effort that started in 1990, approximately a decade after RFC -821 was completed, the protocol was modified with a "service -extensions" model permitting the client and server to agree to -utilize shared functionality beyond the original SMTP requirements. -Contemporary SMTP implementations MUST support the basic extension -mechanisms (see below for details), i.e., servers MUST support the -EHLO command even if they do not implement any specific extensions -and clients MUST preferentially utilize EHLO rather than HELO. -(However, for compatibility with older conforming implementations, -SMTP clients and servers MUST support the original HELO mechanisms as -a fallback.) Unless the different characteristics of HELO must be -identified for interoperability purposes, this document discusses -only EHLO. - -SMTP is widely and deployed and high-quality implementations have -proven to be very robust., However, the Internet community now -considers some services to be important that were not anticipated -when the protocol was first designed. If support for those services -is to be added, it must be done in a way that permits older -implementations to continue working acceptably. - -In an effort that started in 1990, approximately a decade after RFC -821 was completed, the protocol was modified with a "service -extensions" model permitting the client and server to agree to -utilize shared functionality beyond the original SMTP requirements. -The SMTP extension mechanism defines a means whereby an extended SMTP -client and server may recognize each other, and the server can inform -the client as to the service extensions that it supports. - -The extension framework consists of: - - (1) The SMTP command EHLO, superseding the earlier HELO, - - (2) a registry of SMTP service extensions, - - (3) additional parameters to the SMTP MAIL FROM and RCPT TO - commands, and - - (4) optional replacements for verbs defined in this protocol, - such as for DATA (e.g., see [RFC-BDAT]). - -SMTP's strength comes primarily from its simplicity. Experience with -many protocols has shown that: - - -- protocols with few options tend towards ubiquity, whereas - -- protocols with many options tend towards obscurity. - -Each and every extension, regardless of its benefits, must be -carefully scrutinized with respect to its implementation, deployment, -and interoperability costs. In many cases, the cost of extending the -SMTP service will likely outweigh the benefit. - -Contemporary SMTP implementations MUST support the basic extension -mechanism (see below for details), i.e., servers MUST support the -EHLO command even if they do not implement any specific extensions -and clients MUST preferentially utilize EHLO rather than HELO. - - - - - -2.2.2 Definition and Registration of Extensions - -The IANA maintains a registry of SMTP service extensions. A -corresponding EHLO keyword value is associated with each extension . -Each service extension registered with the IANA must be defined in -aformal standards-track or IESG-approved experimental protocol -document. The definition must include: - - (1) the textual name of the SMTP service extension; - - (2) the EHLO keyword value associated with the extension; - - (3) the syntax and possible values of parameters associated with - the EHLO keyword value; - - (4) any additional SMTP verbs associated with the extension - (additional verbs will usually be, but are not required - to be, the same as the EHLO keyword value); - - (5) any new parameters the extension associates with the - MAIL FROM or RCPT TO verbs; - - (6) a description of how support for the extension affects the - behavior of a server and client SMTP; and, - - (7) the increment by which the extension is increasing the - maximum length of the commands MAIL FROM and/or RCPT TO, over - that specified in RFC 821. - -In addition, any EHLO keyword value starting with an upper or lower -case "X" refers to a local SMTP service extension used exclusively -through bilateral agreement. Keywords beginning with "X" may not be -used in a registered service extension. Conversely, keyword values -presented in the EHLO response that do not begin with "X" must -correspond to a standard, standards-track, or IESG-approved -experimental SMTP service extension registered with IANA. A -conforming server MUST NOT offer non-"X"-prefixed keyword values that -are not described in a registered extension. - -Additional verbs and parameter names are bound by the same rules as -EHLO keywords; specifically, verbs beginning with "X" are local -extensions that may not be registered or standardized. Conversely, -verbs not beginning with "X" must always be registered. - - -2.3 Terminology - -Most of the terminology in this document is common in the Internet at -the time of its writing. However, the following terms and concepts -are used in special ways here, or represent differences in -terminology between RFC 821 and this document, and should be -understood before reading further. These definitions are normative, -i.e., they contain specifications to which SMTP implementations are -required to conform. - -2.3.1 Mail objects - -SMTP transports a mail object containing an envelope and content. - - (1) The SMTP envelope is straightforward, and is sent as a - series of SMTP protocol units (described in section ##3): it - consists of an originator address (to which error reports - should be directed); a delivery mode (e.g., deliver to - recipient mailboxes); one or more recipient addresses; and - optional protocol extension material. - - (2) The SMTP content is sent in the SMTP DATA protocol unit and - has two parts: the headers and the body. The headers form a - collection of field/value pairs structured as described in - [MSGFMT]; the body, if structured, is defined according to - MIME [RFC-MIME]. The content is textual in nature, expressed - using the US ASCII repertoire[1]. Although extensions (such as - MIME) may relax this restriction for the content body, the - content headers are always encoded using the US ASCII - repertoire. The algorithm defined in [RFC-INTLHDR] is used to - represent header values outside the US ASCII repertoire, while - still encoding them using the US ASCII repertoire. - -2.3.2. Senders and receivers - -In RFC 821, the two hosts participating in an SMTP transaction were -described as the "SMTP-sender" and "SMTP-receiver". This document -has been changed to reflect current industry terminology and hence -refers to them as the "SMTP client" (or sometimes just "the client") -and "SMTP server" (or just "the server"), respectively. Since a -given host may act both as server and client in a relay situation, -"receiver" and "sender" terminology is still used where needed for -clarity. - -2.3.3. Mail agents - -Additional mail system terminology became common after RFC 821 was -published and, where convenient, is used in this specification. In -particular, SMTP servers and clients provide a mail transport service -and therefore act as Mail Transfer Agents (MTAs). Mail User Agents -(MUAs or UAs) are normally thought of as the sources and targets of -mail. At the source, an MUA might collect mail to be transmitted -from a user and hand it off to an MTA; the final ("delivery") MTA -would be thought of as handing the mail off to an MUA (or at least -transferring responsibility to it). However, while these terms are -used with at least the appearance of great precision in other -environments, the implied boundaries between MUAs and MTAs often do -not accurately match common, and conforming, practices with Internet -mail. Hence, the reader should be cautious about inferring the -strong relationships and responsibilities that might be implied if -these terms were used elsewhere. - -2.3.4 host - -For the purposes of this specification, a host is a computer system -attached to the Internet (or, in some cases, to a private TCP/IP -network) and supporting the SMTP protocol. Hosts are known by names -(see "domain"); identifying them by numerical address is discouraged. - -2.3.5 domain - -The name of a host (often referred to as a "fully-qualified domain -name" or "FQDN"), or some entry in the domain name hierarchy, usually -referred to as a "subdomain", that may contain many hosts. A domain, -or domain name, may also refer to an alias (label of a CNAME RR) or -name the label of Mail eXchanger records to be used to deliver mail. -See [RFC-DNS] and section ##5. - -The domain name, as described in this document and in [RFC-DNS], is -the entire, fully-qualified name, and an apparent host name that is -not in FQDN form is no more than a local alias. Local aliases MUST -NOT appear in any SMTP transaction. - - -In other works, if ab.cd.ef is the fully-qualified name of a host (or -label for an MX record), then it is obviously a "domain". However, -"cd.ef" may be only a domain name; it is possible for it to not refer -to any host. - -2.3.6 buffer and state table - -SMTP sessions are stateful, with both parties carefully maintaining a -common view of the current state. In this document we model this -state by a virtual "buffer" and a "state table" on the server which -may be used by the client to, for example, "clear the buffer" or -"reset the state table," causing the information in the buffer to be -discarded and the state to be returned to some previous state - -2.3.7 lines - -SMTP commands and, unless altered by a service extension, message -data, are transmitted in "lines". Lines consist of zero or more data -characters terminated by the ASCII sequence "CR" followed immediately -by "LF". Conforming implementations MUST NOT recognize or generate -any other character or character sequence as a line terminator. - -2.3.8 Gateway, relay, originator, and delivery system - -This specification makes a distinction among four types of SMTP -systems, based on the role those systems play in transmitting -electronic mail. An "originating" system (sometimes called an SMTP -originator) introduces mail into the Internet or, more generally, -into a transport service environment. A "delivery" SMTP system is one -that receives mail from a transport service environment and hands it -to a mail user agent or deposits it in a maildrop which a mail user -agent is expected to subsequently access. A "relay" SMTP system -(usually referred to just as a "relay") receives mail from an SMTP -client and transmits it, without modification to the message data -other than adding trace information, to another SMTP server for -further relaying or for delivery. - -A "gateway" SMTP system (usually referred to just as a "gateway") -receives mail from a client system in one transport environment and -transmits it to a server system in another transport environment. -Differences in protocols or message semantics between the transport -environments on either side of a gateway may require that the gateway -system perform transformations to the message that are not permitted -to SMTP relay systems. - - -2.3.9 Message content and message body - -The terms "message content" and "mail data" are used interchangably -in this document to describe the material transmitted after the DATA -command is accepted and before the end of data indication is -transmitted. Message content includes message headers and the -possibly-structured message body. The MIME specification [RFC-MIME] -provides the Standard mechanisms for structured message bodies See -##2.3.1. - -2.3.10 mailbox and address - -As used in this specification, an "address" is a character string -that identifies a user to whom mail will be sent or a location into -which mail will be deposited. The term "mailbox" refers to that -depository. The two terms are typically used interchangeably unless -the distinction between the location in which mail is placed (the -mailbox) and a reference to it (the address) is important. An -address normally consists of user and domain specifications. The -standard mailbox naming convention is defined to be -"local-part@domain": contemporary usage permits a much broader set of -applications than simple "user names" and, consequently, the -local-part is interpreted and assigned semantics only by the host -specified in the domain part of the address. - - -2.3.11. reply - -An SMTP reply is an acknowledgment (positive or negative) sent from -receiver to sender via the transmission channel in response to a -command. The general form of a reply is a numeric completion code -(indicating failure or success) followed by a text string. The codes -are for use by programs and the text is usually intended for human -users. - - - -2.4 Syntax Principles - - -2.4.1 General syntax and transaction model - -The mail commands and replies have a rigid syntax. Replies also have -a numeric code. Complete lists of commands and replies appear in -Section ##4 "The SMTP Specification". - -Commands and replies are not case sensitive. That is, a command or -reply word MAY be upper case, lower case, or any mixture of upper and -lower case. Note that this is NOT true of mailbox user names. For -some hosts the user name is case sensitive (this practice impedes -interoperability and is discouraged), therefore, SMTP implementations -MUST take care to preserve the case of user names as they appear in -mailbox arguments. Domain names are not case sensitive. - -Commands and replies are composed of characters from the ASCII -character set [1]. When the transport service provides an 8-bit byte -(octet) transmission channel, each 7-bit character is transmitted -right justified in an octet with the high order bit cleared to zero. -More specifically, the unextended SMTP service provides seven bit -transport only. Originating SMTP clients MUST NOT transmit messages -with information in the high-order bit of octets. If such messages -are transmitted in violation of this rule, receiving SMTP servers MAY -clear the high-order bit or reject the message as invalid. In -general, a relay SMTP SHOULD assume that the message content it has -received is valid and, assuming that the envelope permits doing so, -relay it without inspecting that content. Of course, if the content -is mislabelled and the data path cannot accept the actual content, -this may result in ultimate delivery of a severely garbled message to -the recipient. Delivery SMTP systems MAY reject ("bounce") such -messages rather than deliver them. No sending SMTP system is -permitted to send envelope commands in any character set other than -US-ASCII; receiving systems SHOULD reject such commands, normally -using "500 syntax error - invalid character" replies. - -Eight-bit message content transmission MAY be requested of the server -by a client using extended SMTP facilities, notably the "8BITMIME" -extension [8BITMIME]. 8BITMIME SHOULD be supported by SMTP servers. -However, it MUST not be construed as authorization to transmit -unrestricted eight bit material. 8BITMIME MUST NOT be requested by -senders for material with the high bit on that is not in MIME format -with an appropriate content-transfer encoding and servers MAY reject -such messages. - -The metalinguistic notation used in this document corresponds to the -"Augmented BNF" used in other Internet mail system documents. The -reader who is not familiar with that syntax should consult [ABNF]. -Metalanguage terms used in running text are surrounded by pointed -brackets (e.g., <CRLF>) for clarity. - - -2.4.2 Command and reply syntax - -The commands consist of a command code followed by an argument field. -Command codes are four alphabetic characters and are case insensitive. - -This also applies to any symbols representing parameter values, such -as "TO" or "to" for the forward-path. Command codes and the argument -fields are separated by one or more spaces. However, case is -important in the local-part within the reverse-path and forward-path -arguments. In particular, in some hosts the user "smith" is -different from the user "Smith". - -A few SMTP receiver systems, in violation of this specification (and -RFC 821) require that a particular case be transmitted by clients. -Implementations MAY wish to make provision to accommodate those -systems. - -The argument field consists of a variable length character string -ending with the character sequence <CRLF>. The receiver will take no -action until this sequence is received. - -The syntax for each command is shown with the discussion of that -command. Common elements and parameters are shown in section ##4.1.2. - - - -3. THE SMTP PROCEDURES: AN OVERVIEW - -This section contains descriptions of the procedures used in SMTP: -session initiation, the mail transaction, forwarding mail, verifying -mailbox names and expanding mailing lists, and the opening and -closing exchanges. Comments on relaying, a note on mail domains, and -a discussion of changing roles are included at the end of this -section. Several complete scenarios are presented in Appendix ##F. - - -3.1 Session initiation - -An SMTP session is initiated when a client opens a connection to -a server and the server responds with an opening message. - -SMTP server implementations MAY include identification of their -software and version information in the connection greeting reply -after the 220 code (see section ##7.4), a practice that permits more -efficient isolation and repair of any problems. Implementations MAY -make provision for SMTP servers to disable the software and version -announcement where it causes security concerns. While some systems -also identify their contact point for mail problems, this is not a -substitute for maintaining the required "postmaster" address (see -[MSGFMT]). - -The SMTP protocol allows a server to formally reject a transaction -while still allowing the initial connection as follows: a 554 -response MAY be given in the initial connection opening message -instead of the 220. A server taking this approach MUST still wait -for the client to send a QUIT (see section ##4.1.1.10) before closing -the connection and SHOULD respond to any intervening commands with -"503 bad sequence of commands". Since an attempt to make an SMTP -connection to such a system is probably in error, a server returning a -554 response on connection opening SHOULD provide enough information -in the reply text to facilitate debugging of the sending system. - -Once the server has sent the welcoming message and the client has -received it, the client then sends the EHLO command to the server, -indicating the client’s identity. In addition to opening the -session, use of EHLO indicates that the client is able to process -service extensions and requests that the server provide a list of the -extensions it supports. Older SMTP systems, unable to support -service extensions, MAY use HELO instead of EHLO. Servers MUST NOT -return the extended EHLO-style response to a HELO command. - -In the EHLO command the host sending the command identifies itself; -the command may be interpreted as saying "Hello, I am <domain>" (and, -in the case of EHLO, "and I support service extension requests"). - - -3.3. Mail Transactions - -There are three steps to SMTP mail transactions. The transaction -starts with a MAIL command which gives the sender identification. A -series of one or more RCPT commands follows giving the receiver -information. Then a DATA command initiates transfer of the mail data -and is terminated by the "end of mail" data indicator, which also -confirms the transaction. - - The first step in the procedure is the MAIL command. - - MAIL <SP> FROM:<reverse-path> [<SP> <mail-parameters>] <CRLF> - - This command tells the SMTP-receiver that a new mail transaction - is starting and to reset all its state tables and buffers, - including any recipients or mail data. The <reverse-path> contains - the source mailbox, which can be used to report errors (see - section ##4.2 for a discussion of error reporting). If accepted, - the SMTP server returns a 250 OK reply. If the mailbox - specification is not acceptable for some reason, the server MUST - return a reply indicating whether the failure is permanent (i.e., - will occur again if the client tries to send the same address - again) or temporary (i.e., the address might be accepted if the - client tries again later). See section ##4.2.1. Normally, - failures produce 550 or 553 replies. - - Historically, the <reverse-path> can contain more than just a - mailbox, however, contemporary systems SHOULD NOT use source - routing (see Appendix ##C). - - The optional <mail-parameters> are associated with negotiated SMTP - service extensions (see section ##2.2). - - The second step in the procedure is the RCPT command. - - RCPT <SP> TO:<forward-path> [<SP> <rcpt-parameters>] <CRLF> - - This command gives a forward-path (normally a mailbox and domain) - identifying one recipient. If accepted, the SMTP server returns a - 250 OK reply and stores the forward-path. If the recipient is - known not to be a deliverable address, the SMTP server returns a - 550 reply, typically with a string such as "no such user - " and - the mailbox name (other circumstances and reply codes are - possible). This step of the procedure can be repeated any number - of times. The <forward-path> can contain more than just a - mailbox. Historically, the <forward-path> can be a source routing - list of hosts and the destination mailbox, however, contemporary - SMTP clients SHOULD NOT utilize source routes (see Appendix ##C). - Servers MUST be prepared to encounter a list of source routes in - the forward path, but SHOULD ignore the routes or MAY decline to - support the relaying they imply. Similarly, servers MAY decline - to accept mail that is destined for other hosts or systems. These - restrictions make a server useless as a relay for clients that do - not support full SMTP functionality. Consequently, - restricted-capability clients MUST NOT assume that any SMTP server - on the Internet can be used as their mail processing (relaying) - site. If RCPT TO appears without a previous MAIL FROM, the server - MUST return a 503 "Bad sequence of commands" response. The - optional <mail-parameters> are associated with negotiated SMTP - service extensions (see section ##2.2). - - The third step in the procedure is the DATA command (or some - alternative specified in a service extension). - - DATA <CRLF> - - If accepted, the SMTP server returns a 354 Intermediate reply and - considers all succeeding lines up to but not including the end of - mail data indicator to be the message text. When the end of text - is received and stored the SMTP-receiver sends a 250 OK reply. - - Since the mail data is sent on the transmission channel, the end - of mail data indicator must be indicated so that the command and - reply dialog can be resumed. SMTP indicates the end of the mail - data by sending a line containing only a "." (period or full - stop). A transparency procedure is used to prevent this from - interfering with the user's text (see Section ##4.5.2). - - The end of mail data indicator also confirms the mail transaction - and tells the SMTP server to now process the stored recipients and - mail data. If accepted, the SMTP server returns a 250 OK reply. - The DATA command can fail in only two ways: - - o If there was no MAIL FROM, or no RCPT TO, command, or all - such commands were rejected, the server MAY return a "command - out of sequence" (503) reply. If that reply is received, - the client MUST NOT send the message data; more generally, - message data MUST NOT be sent unless a 354 reply is received. - - o If the verb is initially accepted and the 354 reply issued, - the DATA command should fail only if the mail transaction was - incomplete (for example, no recipients), or if resources were - unavailable. However, in practice, some servers do not - perform recipient verification until after the message text - is received. These servers SHOULD treat a failure for one or - more recipients as a "subsequent failure" and return a mail - message as discussed in section ##6. Using a "550 mailbox - not found" (or equivalent) reply code after the data are - accepted makes it difficult or impossible for the client to - determine which recipients failed. - -When RFC 822 format is being used, the mail data include the memo -header items such as Date, Subject, To, Cc, From [MSGFMT]. Server -SMTP systems SHOULD NOT reject messages based on perceived defects in -the RFC 822 or MIME [RFC-MIME] message header or message body. In -particular, they MUST NOT reject messages in which the numbers of -Resent- fields do not match or Resent-to appears without Resent-from -and/or Resent-date. - - -Mail transaction commands MUST be used in the order discussed above. - - - - -3.4. Forwarding for Address Correction or Updating - -Forwarding support is most often required to consolidate and simplify -addresses within, or relative to, some enterprise and less frequently -to establish addresses to link a person’s prior address with a -current one.. Silent forwarding of messages (without server -notification to the sender), for security or non-disclosure purposes, -is common in the contemporary Internet. - -In both the enterprise and the "new address" cases, information -hiding (and sometimes security) considerations argue against exposure -of the "final" address through the SMTP protocol as a side-effectof -the forwarding activity. This may be especially important when the -final address may not even be reachable by the sender. Consequently, -the "forwarding" mechanisms described in section 3.2 of RFC 821, and -especially the 251 (corrected destination) reply code from RCPT TO -are deprecated: Servers SHOULD NOT provide that service or return -that code. - - - -3.5. Commands for Debugging Addresses - -3.5.1 Overview - -SMTP provides commands to verify a user name or obtain the content of -a mailing list. This is done with the VRFY and EXPN commands, which -have character string arguments. Implementations MUST support VRFY -and SHOULD support EXPN (however, see section ##3.5.2 and ##7.3). - -For the VRFY command, the string is a user name or a user name and -domain (see below). The response MAY include the full name of the user -and MUST include the mailbox of the user, e.g., it MUST be in either - User Name <mailbox@domain> -or - mailbox@domain -form. - - -When a name that is the argument to VRFY could identify more than one -mailbox, the server MAY either note the ambiguity or identify the -alternatives. In other words, either of the following are legitimate -response to VRFY: - - 553 User ambiguous - or - 553- Ambiguous; Possibilities are - 553-Joe Smith <jsmith@somedomain> - 553-Harry Smith <hsmith@somedomain> - 553 Melvin Smith <dweep@somedomain> - or - 553-Ambiguous; Possibilities - 553- <jsmith@somedomain> - 553- <hsmith@somedomain> - 553 <dweep@somedomain> - -Under normal circumstances, a client receiving a 553 reply would be -expected to expose the result to the user. Use of exactly the forms -given, and the "user ambiguous" or "ambiguous" keywords, possibly -supplemented by extended reply codes as described in [RFC-REPLY], -will facilitate automated translation into other languages as needed. -Of course, a client that was highly automated or that was operating -in another language than English, might choose to try to translate -the response, to return some other indication to the user than the -literal text of the reply, or to take some automated action such as -consulting a directory service for additional information before -reporting to the user. - -For the EXPN command, the string identifies a mailing list, and the -multiline response MAY include the full name of the users and MUST -give the mailboxes on the mailing list. - -In some hosts the distinction between a mailing list and an alias for -a single mailbox is a bit fuzzy, since a common data structure may -hold both types of entries, and it is possible to have mailing lists -of one mailbox. If a request is made to verify a mailing list, a -positive response can be given if a message so addressed would be -delivered to everyone on the list, otherwise an error should be -reported (e.g., "550 That is a mailing list, not a user"). If a -request is made to expand a user name, the server MAY return a -positive response consisting of a list containing one name, or an -error MAY be reported (e.g., "550 That is a user name, not a mailing -list"). - -In the case of a multiline reply (normal for EXPN) exactly one -mailbox is to be specified on each line of the reply. The case of an -ambiguous request is discussed above. - -"User name" is a fuzzy term and has been used deliberately. An -implementation of the VRFY or EXPN commands MUST include at least -recognition of local mailboxes as "user names". However, since -current Internet practice often results in a single host handling -mail for multiple domains, hosts, especially hosts that provide this -functionality, SHOULD accept the "user@domain" form as a "user name"; -hosts MAY also choose to recognize other strings as "user names". - - - -The case of verifying a user name is straightforward as shown in -example ##4. - - - ----------------------------------------------------------------- - | - | Example of Verifying a User Name - | - | Either - | - | C: VRFY Smith - | S: 250 Fred Smith <Smith@F.ISI.EDU> - | - | Or - | - | C: VRFY Jones - | S: 550 String does not match anything. - | - | Or - | - | C: VRFY Jones - | S: 551 User not local; please try <Jones@ ISIQ.ISI.EDU> - | - | Or - | - | C: VRFY Gourzenkyinplatz - | S: 553 User ambiguous. - | - | Or - | - | C: VRFY fizzle - | S: 252-Cannot VRFY fizzle, but will accept message and - | S: 252 attempt delivery - | - | Example 4 - | - ----------------------------------------------------------------- - - The case of expanding a mailbox list requires a multiline reply - as shown in example ##5. - - ------------------------------------------------------------- - | - | Example of Expanding a Mailing List - | - | Either - | - | C: EXPN Example-People - | S: 250-Jon Postel <Postel@isi.edu> - | S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu> - | S: 250-Sam Q. Smith <SQSmith@specific.generic.com>> - | S: 250-Quincy Smith <Q-Smith@VAXA.EDU> - | S: 250-<joe@totalitarian.org> - | S: 250 <xyz@dominance.universal.int> - | - | Or - | - | C EXPN Executive-Washroom-List - | S: 550 Access Denied to You. - | - | Example 5 - | - ------------------------------------------------------------- - - The character string arguments of the VRFY and EXPN commands - cannot be further restricted due to the variety of - implementations of the user name and mailbox list concepts. On - some systems it may be appropriate for the argument of the EXPN - command to be a file name for a file containing a mailing list, - but again there are a variety of file naming conventions in the - Internet. - - -3.5.2 VRFY normal response. - -When normal (2yz or 551) responses are returned from a VRFY or EXPN -request, the reply SHOULD normally include the mailbox name, e.g., -"<foo@bar>" (where "bar" is a fully qualified domain name) must -appear in the syntax. In exceptional circumstances, free-form text -MAY be returned. In order to facilitate parsing by both computers -and people, addresses SHOULD appear in pointed brackets. When -addresses, rather than free-form debugging information, are returned, -EXPN and VRFY MUST return only valid domain addresses that are usable -in SMTP RCPT commands. Consequently, if an address implies delivery -to a program or other system, the mailbox name used to reach that -target MUST be given. Paths (explicit source routes) MUST NOT be -returned by VRFY or EXPN. - - -Server implementations MUST support VRFY and SHOULD support EXPN. -For security reasons, implementations MAY provide local installations -a way to disable either or both of these commands through -configuration options or the equivalent. When these commands are -supported, they are not required to work across relays when relaying -is supported. Since they were both optional in RFC 821, they MUST, -if supported, be listed in the response to EHLO if service extensions -are supported. - - -3.5.3 Meaning of VRFY or EXPN success response. - -A server MUST NOT return a 220 code in response to a VRFY or EXPN -command unless it has actually verified the address. In particular, -a server MUST NOT return 220 if all it has done is to verify that the -syntax given is valid. In that case, 502 (Command not implemented) -or 500 (Syntax error, command unrecognized) SHOULD be returned. As -stated elsewhere, implementation of VRFY is required and EXPN is -strongly recommended. Hence, except as provided in section ##7.3, -implementations that return 500 or 502 for VRFY are not in compliance -with this specification. - -There may be circumstances where an address appears to be valid but -cannot reasonably be verified in real time, particularly when a -server is acting as a mail exchanger for another server or domain. -"Apparent validity" in this case would normally involve at least -syntax checking and might involve verification that any domains -specified were ones to which the host expected to be able to relay -mail. In these situations, reply code 252 SHOULD BE returned. These -cases parallel the discussion of RCPT verification discussed in -section ##2.1 Implementations generally SHOULD be more aggressive -about address verification in the case of VRFY than in the case of -RCPT, even if it takes a little longer to do so. - - -3.5.4. Semantics and applications of EXPN. - -EXPN is often very useful in debugging and understanding problems -with mailing lists and multiple-target-address aliases. Some systems -have attempted to use source expansion of mailing lists as a means of -eliminating duplicates. The propagation of aliasing systems with -mail on the Internet--both for hosts (typically with MX and CNAME DNS -records) and for mailboxes (various types of local host aliases)--has -made it nearly impossible for these strategies to work, and mail -systems SHOULD NOT attempt them. - - - -3.6. Domains - - -Only resolvable, fully-qualified, domain names (FQDNs) are permitted -when domain names are used in SMTP. In other words, names that can -be resolved to MX RRs or A RRs (as discussed in section ##5) are -permitted, as are CNAME RRs whose targets can be resolved, in turn, -to MX or A RRs. Local nicknames or unqualified names MUST NOT be -used. There are two exceptions to this rule: (i) The domain name -given in the EHLO command MUST BE either a primary host name (a -domain name that resolves to an A RR) or, if the host has no name, an -address literal as described in section ##4.1.1.1 and (ii) The -reserved mailbox name "postmaster" may be used in a RCPT TO command -without domain qualification (see section ##4.1.1.3). - - - -3.7. RELAYING - -In general, the availability of Mail eXchanger records in the domain -name system [RFC-DNS] makes the use of explicit source routes in the -Internet mail system unnecessary. Many historical problems with -their interpretation have made their use undesirable. SMTP clients -SHOULD NOT generate explicit source routes except under unusual -circumstances. SMTP servers MAY decline to act as mail relays or to -accept addresses that specify source routes. They are also permitted -to ignore the route information and simply send to the final -destination specified as the last element in the route . There has -been an invalid practice of using names that do not appear in the DNS -as destination names, with the senders counting on the intermediate -hosts specified in source routing to resolve any problems. If source -routes are stripped, this practice will cause failures -- one of -several reasons why SMTP clients MUST NOT generate invalid source -routes or depend on serial resolution of names. - -When source routes are not used, the process described in RFC 821 for -constructing a reverse-path from the forward-path is not applicable -and the reverse-path at the time of delivery will simply be the -address that appeared in the MAIL command. - -A relay SMTP server is usually the target of a DNS MX record that -designates it, rather than the final delivery system. The relay -server may accept or reject the task of relaying the mail in the same -way it accepts or rejects mail for a local user. If it accepts the -task, it then becomes an SMTP client, establishes a transmission -channel to the next SMTP server specified in the DNS (according to -the rules in section ##5), and sends it the mail. - -If an SMTP server has accepted the task of relaying the mail and -later finds that the destination is incorrect or that the mail cannot -be delivered for some other reason, then it MUST construct an -"undeliverable mail" notification message and send it to the -originator of the undeliverable mail (as indicated by the -reverse-path). Formats specified for non-delivery reports by other -standards SHOULD be used if possible. - -This notification message must be from the SMTP server at the relay -host or the host that first determines that delivery cannot be -accomplished. Of course, SMTP servers MUST NOT send notification -messages about problems transporting notification messages. One way -to prevent loops in error reporting is to specify a null reverse-path -in the MAIL command of a notification message. When such a message -is transmitted the reverse-path MUST be set to null. A MAIL command -with a null reverse-path appears as follows: - - MAIL FROM:<> - -An undeliverable mail notification message is shown in example 6. -This notification is in response to a message originated by JOE at -xyz.somecollege.edu and sent to a user on HOSTY.org - - ------------------------------------------------------------- - | - | Example Undeliverable Mail Notification Message - | - | C: MAIL FROM:<> - | S: 250 ok - | C: RCPT TO:< JOE@xyz.somecollege.edu> - | S: 250 ok - | C: DATA - | S: 354 send the mail data, end with . - | C: Date: 23 Oct 81 11:22:33 - | C: From: SMTP@HOSTY.org - | C: To: JOE@xyz.somecollege.edu - | C: Subject: Mail System Problem - | C: -<<replace with NOTARY format >> - | C: . - | S: 250 ok - | - | Example 6 - | - -As discussed in section ##2.4.1, a relay SMTP has no need to inspect -or act upon the headers or body of the message data and MUST NOT do -so. - - - - -3.8 Mail Gatewaying - -While the relay function discussed above operates within the Internet -SMTP transport service environment, MX records or various forms of -explicit routing may require that an intermediate SMTP server perform -a translation function between one transport service and another. As -discussed in section ##2.3.8, when such a system is at the boundary -between two transport service environments, we refer to it as a -"gateway" or "gateway SMTP". - -Gatewaying mail between different mail environments, i.e., different -mail formats and protocols, is complex and does not easily yield to -standardization. However, some general requirements may be given for -a gateway between the Internet and another mail environment. - - -3.8.1 Header fields MAY be rewritten when necessary as messages are -gatewayed across mail environment boundaries. - -This may involve inspecting the message body or interpreting the -local-part of the destination address in spite of the prohibitions in -section ##2.4.1 - -Other mail systems gatewayed to the Internet often use a subset of -RFC-822 headers or provide similar functionality with a different -syntax, but some of these mail systems do not have an equivalent to -the SMTP envelope. Therefore, when a message leaves the Internet -environment, it may be necessary to fold the SMTP envelope -information into the message header. A possible solution would be to -create new header fields to carry the envelope information (e.g., -"X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would require -changes in mail programs in foreign environments. - - -3.8.2 When forwarding a message into or out of the Internet -environment, a gateway MUST prepend a Received: line, but it MUST NOT -alter in any way a Received: line that is already in the header. - -Received: fields of messages originating from other environments may -not conform exactly to this specification. However, the most -important use of Received: lines is for debugging mail faults, and -this debugging can be severely hampered by well-meaning gateways that -try to "fix" a Received: line. As another consequence of trace -fields arising in non-SMTP environments, receiving systems MUST NOT -reject mail based on the format of a trace field and SHOULD be -extremely robust in the light of unexpected information or formats in -those fields. - -The gateway SHOULD indicate the environment and protocol in the "via" -clauses of Received field(s) that it supplies. - - -3.8.3 From the Internet side, the gateway SHOULD accept all valid -address formats in SMTP commands and in RFC-822 headers, and all -valid RFC-822 messages. Gateways are, of course, subject to the same -rules for handling source routes as those described for other SMTP -systems in section ##3.3. - - -3.8.4 The gateway MUST ensure that all header fields of a message -that it forwards into the Internet meet the requirements for Internet -mail. In particular, all addresses in "From:", "To:", "Cc:", etc., -fields MUSTbe transformed (if necessary) to satisfy RFC-822 syntax, -MUST reference only fully-qualified domain names, and MUSTbe -effective and useful for sending replies. 3.8.5 The translation -algorithm used to convert mail from the Internet protocols to another -environment's protocol SHOULD ensure that error messages from the -foreign mail environment are delivered to the return path from the -SMTP envelope, not to the sender listed in the "From:" field (or -other fields) of the RFC-822 message. - -3.8.6 Similarly, when forwarding a message from another environment -into the Internet, the gateway SHOULD set the envelope return path in -accordance with an error message return address, if supplied by the -foreign environment. If the foreign environment has no equivalent -concept, the gateway must select and use a best approximation, with -the message originator’s address as the default of last resort. - - - -3.9. Terminating Sessions and Connections - -An SMTP connection is terminated when the client sends a QUIT -command. The server responds with a positive reply code, after which -it closes the connection. - -An SMTP server MUST NOT intentionally close the connection except: - - o After receiving a QUIT command and responding with a 221 reply. - - o After detecting the need to shutdown the SMTP service and - returning a message with a 451 response code. This response - code can be issued after the server receives any command or, if - necessary, asynchronously from command receipt (on the - assumption that the client will receive it after the next - command is issued). - -In particular, a server that closes connections in response to -commands that are not understood is in violation of this -specification. Servers are expected to be tolerant of unknown -commands, issuing a 500 reply and awaiting further instructions from -the client. - -An SMTP server which is forcibly shut down via external means SHOULD -attempt to send a line containing 451 response code to the SMTP -client before exiting. The SMTP client will normally read the 451 -response code after sending its next command. - -SMTP clients that experience a connection close, reset, or other -communications failure due to circumstances not under their control -(in violation of the intent of this specification but sometimes -unavoidable) should, to maintain the robustness of the mail system, -treat the mail transaction as if a 451 response had been received and -act accordingly.
- - - - - - - -3.10 Mailing Lists and Aliases - -An SMTP-capable host SHOULD support both the alias and the list form -of address expansion for multiple delivery. When a message is -delivered or forwarded to each address of an expanded list form, the -return address in the envelope ("MAIL FROM:") MUST be changed to be -the address of a person or other entity who administers the list but -the message header MUST be left unchanged; in particular, the "From" -field of the message is unaffected. - -An important mail facility is a mechanism for multi-destination -delivery of a single message, by transforming or "expanding" a -pseudo-mailbox address into a list of destination mailbox addresses. -When a message is sent to such a pseudo-mailbox (sometimes called an -"exploder"), copies are forwarded or redistributed to each mailbox in -the expanded list. We classify such a pseudo-mailbox as an "alias" -or a "list", depending upon the expansion rules. - - -3.10.1 Alias - -To expand an alias, the recipient mailer simply replaces the -pseudo-mailbox address in the envelope with each of the expanded -addresses in turn; the rest of the envelope and the message body are -left unchanged. The message is then delivered or forwarded to each -expanded address. - - -3.10.11 List - -A mailing list may be said to operate by "redistribution" rather than -by "forwarding". To expand a list, the recipient mailer replaces the -pseudo-mailbox address in the envelope with each of the expanded -addresses in turn. The return address in the envelope is changed so -that all error messages generated by the final deliveries will be -returned to a list administrator, not to the message originator, who -generally has no control over the contents of the list and will -typically find error messages annoying. - - - - -4. THE SMTP SPECIFICATIONS - -4.1. SMTP COMMANDS - -4.1.1. COMMAND SEMANTICS AND SYNTAX - -The SMTP commands define the mail transfer or the mail system -function requested by the user. SMTP commands are character strings -terminated by <CRLF>. The command codes themselves are alphabetic -characters terminated by <SP> if parameters follow and <CRLF> -otherwise. (In the interest of improved interoperability, SMTP -receivers are encouraged to tolerate trailing white space before the -terminating <CRLF>.) The syntax of the local part of a mailbox must -conform to receiver site conventions and the syntax specified in -section ##4.1.2. The SMTP commands are discussed below. The SMTP -replies are discussed in Section ##4.2. - -A mail transaction involves several data objects which are -communicated as arguments to different commands. The reverse-path is -the argument of the MAIL command, the forward-path is the argument of -the RCPT command, and the mail data is the argument of the DATA -command. These arguments or data objects must be transmitted and -held pending the confirmation communicated by the end of mail data -indication which finalizes the transaction. The model for this is -that distinct buffers are provided to hold the types of data objects, -that is, there is a reverse-path buffer, a forward-path buffer, and a -mail data buffer. Specific commands cause information to be appended -to a specific buffer, or cause one or more buffers to be cleared. - - -4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) - -These commands are used to identify the SMTP client to the SMTP -server. The argument field contains the fully-qualified domain name -of the SMTP client if one is available. In situations in which the -SMTP client system does not have a meaningful domain name (e.g., when -its address is dynamically allocated and no reverse mapping record is -available), the client should send an address literal (see section -##4.1.3), optionally followed by information that will help to -identify the client system. - -The SMTP server identifies itself to the SMTP client in the -connection greeting reply and in the response to this command. - -A client SMTP SHOULD start an SMTP session by issuing the EHLO -command. If the SMTP server supports the SMTP service extensions it -will give a successful response, a failure response, or an error -response. If the SMTP server, in violation of this specification, -does not support any SMTP service extensions it will generate an -error response. Older client SMTP systems MAY, as discussed above, -use HELO (as specified in RFC 821) instead of EHLO, and servers MUST -support the HELO command and reply properly to it. In any event, a -client MUST issue HELO or EHLO before starting a mail transaction. - -These commands, and a "250 OK" reply to one of them, confirm that -both the SMTP client and the SMTP server are in the initial state, -that is, there is no transaction in progress and all state tables and -buffers are cleared. - -Normally, the response to EHLO will be a multiline reply. Each line -of the response contains a keyword and, optionally, one or more -parameters. The syntax for a positive response, using the ABNF -notation and low-level terminals of [ABNF], is: - - ehlo-ok-rsp ::= "250" domain [ SP greeting ] CRLF - / ( "250-" domain [ SP greeting ] CRLF - *( "250-" ehlo-line CRLF ) - "250" SP ehlo-line CRLF ) - - greeting ::= 1*<any character other than CR or LF> - - ehlo-line ::= ehlo-keyword *( SP ehlo-param ) - - ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") - - ; syntax and values depend on ehlo-keyword - ehlo-param ::= 1*<any CHAR excluding SP and all - control characters (US ASCII 0-31 - inclusive)> - -[[xxx ALPHA ::= <any one of the 52 alphabetic characters - (A through Z in upper case, and, - a through z in lower case)> - - -Although EHLO keywords may be specified in upper, lower, or mixed -case, they must always be recognized and processed in a -case-insensitive manner. This is simply an extension of practices -specified in RFC 821 and section ##2.4.1. - - -4.1.1.2 MAIL (MAIL) - -This command is used to initiate a mail transaction in which the mail -data is delivered to one or more mailboxes. The argument field -contains a reverse-path. - -The reverse-path consists of the sender mailbox or a list of hosts as -described in Appendix C. In some types of reporting messages for -which a reply is likely to cause a mail loop (for example, mail -delivery and nondelivery notifications), the reverse-path may be null -(see section ##3.7). - -This command clears the reverse-path buffer, the forward-path buffer, -and the mail data buffer; and inserts the reverse-path information -from this command into the reverse-path buffer. - -If service extensions were negotiated, the MAIL command may also -carry parameters associated with a particular service extension. - -Syntax: "MAIL FROM:" Reverse-path [ SP Mail-parameters ] - or - "MAIL FROM:<>" [ SP Mail-parameters ] - - -4.1.1.3 RECIPIENT (RCPT) - -This command is used to identify an individual recipient of the mail -data; multiple recipients are specified by multiple use of this -command. - -The forward-path normally consists of the required destination -mailbox(es). Sending systems SHOULD not generate the optimal list of -hosts known as a source route. Receiving systems MUST recognize -source route syntax but SHOULD strip off the source route -specification and utilize the domain name associated with the mailbox -as if the source route had not been provided. - -Similarly, relay hosts SHOULD strip or ignore source routes, and -names MUST NOT be copied into the reverse-path. When mail reaches its -ultimate destination (the forward-path contains only a destination -mailbox), the SMTP server inserts it into the destination mailbox in -accordance with its host mail conventions. - - -For example, mail received at relay host A with envelope commands - - MAIL FROM:<USERX@Y.foo.org> - RCPT TO:<@HOSTA.INT,@HOSTB.INT:USERC@D.bar.org> - -will normally be sent directly on to host D.bar.org with envelope -commands - - MAIL FROM:<USERX@Y.foo.org> - RCPT TO:<USERC@D.bar.org> - -as provided in Appendix C, HostA MAY also choose to relay the message -to HostB, using the envelope commands - - MAIL FROM:<USERX@HOSTY.ARPA> - RCPT TO:<@HOSTB.int:USERC@D. BAR.ORG> - -Of course, since hosts are not required to relay mail at all, HostA -may also reject the message entirely when the RCPT TO command is -received, using a 550 code (since this is a "policy reason"). - -If service extensions were negotiated, the RCPT TO command may also -carry parameters associated with a particular service extension -offered by the server. The client MUST NOT transmit parameters other -than those associated with a service extension offered by the server -in its EHLO response. - -Syntax: "RCPT TO:" Forward-path [ SP Rcpt-parameters ] - or - "RCPT TO:<Postmaster>" [ SP Rcpt-parameters ] - - -4.1.1.4 DATA (DATA) - -The receiver treats the lines (strings ending in CRLF sequences, see -section ##2.3.7) following the command as mail data from the sender. -This command causes the mail data to be appended to the mail data -buffer. The mail data may contain any of the 128 ASCII character -codes, although experience has indicated that use of control -characters other than SP, HT, CR, and LF may cause problems and -should be avoided when possible. - -The mail data is terminated by a line containing only a period, that -is, the character sequence "<CRLF>.<CRLF>" (see Section ##4.5.2 on -Transparency). This is the end of mail data indication. Note that -the first <CRLF> of this terminating sequence is also the <CRLF> that -ends the final line of the data (message text) or, if there was no -data, ends the DATA command itself. An extra <CRLF> MUST NOT be -added, as that would cause an empty line to be added to the message. -The only exception to this rule would arise if the message body were -passed to the originating SMTP-sender with a final "line" that did -not end in <CRLF>; in that case, the originating SMTP system MUST -either reject the message as invalid or add <CRLF> in order to have -the receiving SMTP server recognize the "end of data" condition. - -The custom of accepting lines ending only in <LF>, as a concession to -non-conforming behavior on the part of some UNIX systems, has proven -to cause more interoperability problems than it solves, and SMTP -server systems MUST NOT do this, even in the name of improved -robustness. In particular, the sequence "<LF>.<LF>" (bare line -feeds, without carriage returns) MUST NOT be treated as equivalent to -<CRLF>.<CRLF> as the end of mail data indication. - -Receipt of the end of mail data indication requires the server to -process the stored mail transaction information. This processing -consumes the information in the reverse-path buffer, the forward-path -buffer, and the mail data buffer, and on the completion of this -command these buffers are cleared. If the processing is successful -the receiver must send an OK reply. If the processing fails the -receiver must send a failure reply. The SMTP model does not allow for -partial failures at this point: either the message is accepted by the -server for delivery and a positive response is returned or it is not -accepted and a failure reply is returned. Errors that are diagnosed -subsequently MUST be reported in a mail message, as discussed in -section ##4.4 In sending a positive completion reply to the end of -data indication, the receiver takes full responsibility for the -message (see section ##6.1). - -When the SMTP server accepts a message either for relaying or for -final delivery, it inserts a trace record (also referred to -interchangeably as a "time stamp line" or "Received" line) at the top -of the mail data. This trace record indicates the identity of the -host that sent the message, the identity of the host that received -the message (and is inserting this time stamp), and the date and time -the message was received. Relayed messages will have multiple time -stamp lines. Details for formation of these lines, including their -syntax, is specified in section ##4.4. - - -4.1.1.5 RESET (RSET) - -This command specifies that the current mail transaction will be -aborted. Any stored sender, recipients, and mail data MUST be -discarded, and all buffers and state tables cleared. The receiver -MUST send a "250 OK" reply to a RSET command with no arguments. A -reset command may be issued by the client at any time. It is -effectively equivalent to a NOOP if issued immediately after EHLO, -before EHLO is issued in the session, or immediately before a QUIT. -In other situations, it restores the state to that immediately after -the most recent EHLO. An SMTP server MUST NOT close the connection -as the result of receiving a RSET; that action is reserved for QUIT -(see section ##4.1.1.10, below). - -Since EHLO implies some additional processing and response by the -server, RSET will normally be more efficient than reissuing that -command, even though the formal semantics are the same. - -There are circumstances, contrary to the intent of this -specification, in which an SMTP server may receive an indication that -the underlying TCP connection has been closed or reset. To preserve -the robustness of the mail system, SMTP servers should be prepared -for this condition and should treat it as if a QUIT had been received -before the connection disappeared. - -Syntax: RSET - - -4.1.1.6 VERIFY (VRFY) - -This command asks the receiver to confirm that the argument -identifies a user or mailbox. If it is a user name, information is -returned as specified in section ##3.5. - -This command has no effect on the reverse-path buffer, the -forward-path buffer, or the mail data buffer. - -Syntax: "VRFY" SP String - -4.1.1.7 EXPAND (EXPN) - -This command asks the receiver to confirm that the argument -identifies a mailing list, and if so, to return the membership of -that list. If the command is successful, a multiline reply is -returned containing information as described in section ##3.5. - -This command has no effect on the reverse-path buffer, the -forward-path buffer, or the mail data buffer. - -Syntax: "EXPN" SP String - -4.1.1.8 HELP (HELP) - -This command causes the server to send helpful information to the -client. The command MAY take an argument (e.g., any command name) -and return more specific information as a response. - -This command has no effect on the reverse-path buffer, the -forward-path buffer, or the mail data buffer. - -SMTP servers SHOULD support HELP without arguments and MAY support it -with arguments. - -Syntax: "HELP" [ SP String ] - - -4.1.1.9 NOOP (NOOP) - -This command does not affect any parameters or previously entered -commands. It specifies no action other than that the receiver send -an OK reply. - -This command has no effect on the reverse-path buffer, the -forward-path buffer, or the mail data buffer. - -Syntax: "NOOP" [SP String] - -4.1.1.10 QUIT (QUIT) - -This command specifies that the receiver must send an OK reply, and -then close the transmission channel. - -The receiver MUST NOT intentionally close the transmission channel -until it receives and replies to a QUIT command (even if there was an -error). The sender MUST NOT intentionally close the transmission -channel until it sends a QUIT command and receives the reply (even if -there was an error response to a previous command). If the -connection is closed prematurely due to violations of the above or -system or network failure, the server MUST cancel any pending -transaction, but not undo any previously completed transaction, and -generally MUST act as if the command or transaction in progress had -received a temporary error (i.e., a 4yz response). - -Syntax: "QUIT" - - -4.1.2. LOWER-LEVEL SYNTAX - -The syntax of the argument fields of the above commands (using the -syntax specified in [ABNF] where applicable) is given below. Some of -the productions given below are used only in conjunction with source -routes as described in Appendix C. Terminals not defined in this -document, i.e., ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the -"core" syntax (section 6) of [ABNF]. - -<<Note in draft: it appears stupid, contrary to the reason RFC 2234 -<<was created, and risk-prone to reproduce the definitions of -<<Quoted-string and Atom here. But, if I leave them out, the reader of -<<this document will need a lap or virtual desktop large enough to -<<simultaneously accomodate this spec, [msgfmt], and RFC 2234 -<<([ABNF]). Similarly, it would be nice to use the same definition of -<< <special> and <FWS> here as in 822bis, but the traditional 821 -<< definition of <special> excludes *all* control characters. -<<Please advise >> - - Reverse-path = Path - - Forward-path = Path - - Path = "<" [ A-d-l ":" ] Mailbox ">" - - A-d-l = At-domain *( "," A-d-l ) ; Note that this form, the - so-called "source route", MUST BE - accepted, SHOULD NOT be generated, - and SHOULD be ignored. - - At-domain = "@" Domain - - Mail-parameters = *( SP Keyword "=" Argument ) - - Rcpt-parameters = *( SP Keyword "=" Argument ) - - Keyword = Ldh-str - Argument = Atom - - Domain = sub-domain 1*("." sub-domain) / address-literal - - sub-domain = let-dig *(ldh-str) - address-literal = "[" IPv4-address-literal / - IPv6-address-literal / General-address-literal "]" - IPv4-address-literal = snum 3*3("." snum) - IPv6-address-literal = "IPv6" SP IPv6-addr-string - IPv6-addr-string = String ; IPv6 address in standard form - [IPv6AddrSpec]. Since this - form uses colon characters, - the String will actually need - to be quoted in all cases. - General-address-literal = Standardized-tag SP String - Standardized-tag = Ldh-str ; Specified in a - standards-track RFC - and registered with IANA - snum = 1*3Digit ; representing a decimal integer - value in the range 0 through 255 - let-dig = Alpha / Digit - ldh-str = *( Alpha / Digit / "-" ) let-dig - - Mailbox = Local-part "@" Domain - - Local-part = Dot-string / Quoted-string - -While the above definition for Local-part is relatively permissive, -for maximum interoperability, a host that expects to receive mail -SHOULD avoid defining mailboxes where the Local-part requires (or -uses) the Quoted-string form or where the Local-part is -case-sensitive. For any purposes that require generating or -comparing Local-parts (e.g., to specific mailbox names), all quoted -forms MUST be treated as equivalent and the sending system SHOULD -transmit the form that uses the minimum quoting possible. - -Systems MUST NOT define mailboxes in such a way as to require the use -of non-ASCII characters (octets with the high order bit set to one) -or ASCII "control characters" (decimal value 0-31 and 127). These -characters MUST NOT be used in MAIL FROM or RCPT TO commands or other -commands that require mailbox names. - - - String = Atom / Quoted-string - - special = <<Msg-fmt-special>> / [[placeholder, see above]] - the control characters (ASCII codes 0 through 31 - inclusive and 127) - -Note that the backslash, "\", is a quote character, which is used to -indicate that the next character is to be used literally (instead of -its normal interpretation). For example, "Joe\,Smith" indicates a -single nine character user field with the comma being the fourth -character of the field. - -Characters outside the set of alphas, digits, and hyphen MUST NOT -appear in domain names. In particular, the underscore character is -not permitted. - - - -4.1.3. Address literals - -Sometimes a host is not known to the domain name system and -communication (and, in particular, communication to report and repair -the error) is blocked. To bypass this barrier a special literal form -of the address is allowed as an alternative to a domain name. For -IPv4 addresses, this form uses four or more small decimal integers -separated by dots and enclosed by brackets, e.g., [123.255.37.2], -which indicates an (IPv4) Internet Address in sequence-of-octets -form. For IPv6 and other forms of addressing that might eventually -be standardized, the form consists of a standardized "tag" that -identifies the address syntax, a space, and the address itself, in a -format specified as part of the IPv6 standards [IPv6AddrString]. - - - -4.1.4. Order of commands - -There are restrictions on the order in which these commands may be -used. - -A session that will contain mail transactions MUST first be -initialized by the use of the EHLO command. An SMTP server SHOULD -accept commands for non-mail transactions (e.g., VRFY or EXPN) -without this initialization. - -An EHLO command MAY be issued by a client later in the session. If -it is issued after the session begins, the SMTP server MUST clear all -buffers and reset the state exactly as if a RSET command had been -issued. In other words, the sequence of RSET followed immediately by -EHLO is redundant, but not harmful other than in the performance cost -of executing unnecessary commands. - -If the EHLO command is not acceptable to the SMTP server, 501, 500, -or 502 failure replies MUST be returned as appropriate. The SMTP -server must stay in the same state after transmitting these replies -that it was in before the EHLO was received. - -The SMTP client MUST ensure that the domain parameter to the EHLO -command is a valid principal host name (not a CNAME or MX name) for -its host. If this is not possible (e.g., when the client's address -is dynamically assigned and the client does not have an obvious -name), an address literal SHOULD be substituted for the domain name -and supplemental information provided that will assist in identifying -the client. - -An SMTP server MAY verify that the domain name parameter in the EHLO -command actually corresponds to the IP address of the client. -However, the server MUST NOT refuse to accept a message if the -verification fails -- the information about verification failure is -for logging and tracing only. - -The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time -during a session, or without previously initializing a session. SMTP -servers SHOULD process these normally (i.e., not return a 503 code) -even if no EHLO command has yet been received; clients SHOULD open a -session with EHLO before sending these commands. - -If these rules are followed, the example in RFC 821 that shows "550 -access denied to you" in response to an EXPN command is incorrect -unless an EHLO command precedes the EXPN or the denial of access is -based on the client's IP address. - -The MAIL command (or the obsolete SEND, SOML, or SAML commands) -begins a mail transaction. Once started, a mail transaction consists -of a transaction beginning commands, one or more RCPT commands, and a -DATA command, in that order. A mail transaction may be aborted by -the RSET (or a new EHLO) command. There may be zero or more -transactions in a session. - -If the transaction beginning command argument is not acceptable, a -501 failure reply MUST be returned and the SMTP server must stay in -the same state. If the commands in a transaction are out of order to -the degree that they cannot be processed by the server, a 503 failure -reply MUST be returned and the SMTP server must stay in the same -state. - -The last command in a session must be the QUIT command. The QUIT -command cannot be used at any other time in a session, but SHOULD be -used by the client SMTP to request connection closure, even when no -session opening command was sent and accepted. - - - -4.1.5 Private-use commands - -As specified in section 2.2.2, commands starting in "X" may be used -by bilateral agreement between the client (sending) and server -(receiving) SMTPs. An SMTP server that does not recognize such a -command is expected to reply with "500 Command not recognized". An -extended SMTP server MAY list the feature names associated with these -private commands in the response to the EHLO command. - -Commands sent or accepted by SMTP systems that do not start with "X" -MUST conform to the requirements of section ##2.2.2, above. - - - -4.2. SMTP REPLIES - -Replies to SMTP commands serve to ensure the synchronization of -requests and actions in the process of mail transfer and to guarantee -that the SMTP client always knows the state of the SMTP server. -Every command must generate exactly one reply. - -The details of the command-reply sequence are described in Section -##4.3 on Sequencing. - -An SMTP reply consists of a three digit number (transmitted as three -alphanumeric characters) followed by some text. The number is for -use by automata to determine what state to enter next; the text is -for the human user. The three digits contain enough encoded -information that the SMTP client need not examine the text and may -either discard it or pass it on to the user, as appropriate. -Exceptions are as noted elsewhere in this document. In particular, -the 220, 221, 251, 421, and 551 reply codes are associated with -message text that must be parsed and interpreted by machines. In the -general case, the text may be receiver dependent and context -dependent, so there are likely to be varying texts for each reply -code. A discussion of the theory of reply codes is given insection -##4.2.1. Formally, a reply is defined to be the sequence: a -three-digit code, SP, one line of text, and CRLF, or a multiline -reply (as defined insection ##4.2.1). Only the EXPN and HELP -commands are expected to result in multiline replies in normal -circumstances, however, multiline replies are allowed for any command. - -An SMTP server SHOULD send only the reply codes listed in this -document. An SMTP server SHOULD use the text shown in the examples -whenever appropriate. - -A client SMTP MUST determine its actions only by the reply code, not -by the text (except for 251 and 551 and, if necessary, 220, 221, and -421 replies); in the general case, any text, including no text at all -(although senders SHOULD NOT send bare codes), MUSTbe acceptable. -The space (blank) following the reply code is considered part of the -text. Whenever possible, a sender-SMTP SHOULD test the first digit -(severity indication) of the reply code. - -The list of codes that appears below must not be construed as -permanent. While the addition of new codes should be a rare and -significant activity, with supplemental information in the textual -part of the response being preferred, new codes may be added as the -result of new Standards or Standards-track specifications. -Consequently, a sender-SMTP MUST be prepared to handle codes not -specified in this document and MUST do so by interpreting the first -digit only. - - - -4.2.1. REPLY CODE SEVERITIES AND THEORY - - -The three digits of the reply each have a special significance. The -first digit denotes whether the response is good, bad or incomplete. -An unsophisticated SMTP client, or one that receives an unexpected -code, will be able to determine its next action (proceed as planned, -redo, retrench, etc.) by examining this first digit. An SMTP client -that wants to know approximately what kind of error occurred (e.g., -mail system error, command syntax error) may examine the second -digit. The third digit and any supplemental information that may be -present is reserved for the finest gradation of information. - -There are five values for the first digit of the reply code: - - 1yz Positive Preliminary reply - - The command has been accepted, but the requested action - is being held in abeyance, pending confirmation of the - information in this reply. The SMTP client should send - another command specifying whether to continue or abort - the action. - - [Note: unextended SMTP does not have any commands that allow - this type of reply, and so does not have continue or abort - commands.] - - 2yz Positive Completion reply - - The requested action has been successfully completed. A new - request may be initiated. - - 3yz Positive Intermediate reply - - The command has been accepted, but the requested action is being - held in abeyance, pending receipt of further information. The - SMTP client should send another command specifying this - information. This reply is used in command sequence groups - (i.e., in DATA). - - 4yz Transient Negative Completion reply - - The command was not accepted, and the requested action did not - occur. However, the error condition is temporary and the action - may be requested again. The sender should return to the - beginning of the command sequence (if any). It is difficult to - assign a meaning to "transient" when two different sites - (receiver- and sender- SMTPs) must agree on the interpretation. - Each reply in this category might have a different time value, - but the SMTP client is encouraged to try again. A rule of thumb - to determine whether a reply fits into the 4yz or the 5yz - category (see below) is that replies are 4yz if they can be - repeated without any change in command form or in properties of - the sender or receiver. (E.g., the command is repeated - identically and the receiver does not put up a new - implementation.) - - 5yz Permanent Negative Completion reply - - The command was not accepted and the requested action did not - occur. The SMTP client is discouraged from repeating the exact - request (in the same sequence). Even some "permanent" error - conditions can be corrected, so the human user may want to - direct the SMTP client to reinitiate the command sequence by - direct action at some point in the future (e.g., after the - spelling has been changed, or the user has altered the account - status). - -The second digit encodes responses in specific categories: - - x0z Syntax -- These replies refer to syntax errors, - syntactically correct commands that don't fit any - functional category, and unimplemented or superfluous - commands. - - x1z Information -- These are replies to requests for - information, such as status or help. - - x2z Connections -- These are replies referring to the - transmission channel. - - x3z Unspecified as yet. - - x4z Unspecified as yet. - - x5z Mail system -- These replies indicate the status of - the receiver mail system vis-a-vis the requested - transfer or other mail system action. - -The third digit gives a finer gradation of meaning in each category -specified by the second digit. The list of replies illustrates this. -Each reply text is recommended rather than mandatory, and may even -change according to the command with which it is associated. On the -other hand, the reply codes must strictly follow the specifications -in this section. Receiver implementations should not invent new -codes for slightly different situations from the ones described here, -but rather adapt codes already defined. - -For example, a command such as NOOP, whose successful execution does -not offer the SMTP client any new information, will return a 250 -reply. The reply is 502 when the command requests an unimplemented -non-site-specific action. A refinement of that is the 504 reply for -a command that is implemented, but that requests an unimplemented -parameter. - -The reply text may be longer than a single line; in these cases the -complete text must be marked so the SMTP client knows when it can -stop reading the reply. This requires a special format to indicate a -multiple line reply. - -The format for multiline replies requires that every line, except the -last, begin with the reply code, followed immediately by a hyphen, -"-" (also known as minus), followed by text. The last line will -begin with the reply code, followed immediately by <SP>, optionally -some text, and <CRLF>. As noted above, servers SHOULD send the <SP> -if subsequent text is not sent, but clients MUST be prepared for it -to be omitted. - - For example: - 123-First line - 123-Second line - 123-234 text beginning with numbers - 123 The last line - -In many cases the SMTP client then simply needs to search for the -reply code followed by <SP> at the beginning of a line, and ignore -all preceding lines. In a few cases, there is important data for the -sender in the reply "text". The sender will be able to identify -these cases from the current context. - - -4.2.2. REPLY CODES BY FUNCTION GROUPS - - 500 Syntax error, command unrecognized - [This may include errors such as command line too long] - 501 Syntax error in parameters or arguments - 502 Command not implemented (see section ##4.2.3) - 503 Bad sequence of commands - 504 Command parameter not implemented - - 211 System status, or system help reply - 214 Help message - [Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user] - - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 421 <domain> Service not available, - closing transmission channel - [This may be a reply to any command if the service knows it - must shut down] - - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - [See section ##3.4] - 252 Cannot VRFY user, but will accept message and attempt - delivery - [See section ##3.5.3] - 450 Requested mail action not taken: mailbox unavailable - [E.g., mailbox busy] - 550 Requested action not taken: mailbox unavailable - [E.g., mailbox not found, no access, or command rejected - for policy reasons] - 451 Requested action aborted: error in processing - 551 User not local; please try <forward-path> - [See section ##3.4] - 452 Requested action not taken: insufficient system storage - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - [E.g., mailbox syntax incorrect] - 354 Start mail input; end with <CRLF>.<CRLF> - 554 Transaction failed [Or, in the case of a connection-opening - response, "No SMTP service here"] - - -4.2.3. NUMERIC ORDER LIST OF REPLY CODES - - 211 System status, or system help reply - 214 Help message - [Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user] - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - [See section ##3.4] - 252 Cannot VRFY user, but will accept message and attempt - delivery - [See section ##3.5.3] - - 354 Start mail input; end with <CRLF>.<CRLF> - - 421 <domain> Service not available, - closing transmission channel - [This may be a reply to any command if the service knows it - must shut down] - 450 Requested mail action not taken: mailbox unavailable - [E.g., mailbox busy] - 451 Requested action aborted: local error in processing - 452 Requested action not taken: insufficient system storage - - 500 Syntax error, command unrecognized - [This may include errors such as command line too long] - 501 Syntax error in parameters or arguments - 502 Command not implemented - 503 Bad sequence of commands - 504 Command parameter not implemented - 550 Requested action not taken: mailbox unavailable - [E.g., mailbox not found, no access, or command rejected - for policy reasons] - 551 User not local; please try <forward-path> - [See section ##3.4] - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - [E.g., mailbox syntax incorrect] - 554 Transaction failed [Or, in the case of a connection-opening - response, "No SMTP service here"] - - -4.2.4. Reply code 502 - -Questions have been raised as to when reply code 502 (Command not -implemented) should be returned in preference to other codes. 502 -SHOULD be used when the command is actually recognized by the SMTP -server, but not implemented. If the command is not recognized, code -500 SHOULD be returned. Extended SMTP systems MUST NOT list -capabilities in response to EHLO for which they will return 502 (or -500) replies. - - -4.2.5 Reply codes after DATA and the subsequent <CRLF>.<CRLF>. - -When an SMTP server returns a positive completion status (2yz code) -after the DATA command is completed with <CRLF>.<CRLF>, it accepts -responsibility for: - - o delivering the message (if the recipient mailbox exists), or - - o if attempts to deliver the message fail due to transient - conditions, retrying delivery some reasonable number of times - at intervals as specified in section ##4.2.6. - - o if attempts to deliver the message fail due to permanent - conditions, or if repeated attempts to deliver the message fail - due to transient conditions, returning appropriate notification to - the sender of the original message (using the address in the SMTP - MAIL FROM command). - - -When an SMTP server returns a transient error completion status (4yz) -code after the DATA command is completed with <CRLF>.<CRLF>, it MUST -NOT make any further attempt to deliver that message. The SMTP -client retains responsibility for delivery of that message and may -either return it to the user or requeue it for a subsequent attempt -(see section ##4.5.4.1). The sending user should be able to -interpret the return of a transient or permanent failure status as a -non-delivery indication. - - - -4.3. SEQUENCING OF COMMANDS AND REPLIES - -4.3.1 Sequencing overview - -The communication between the sender and receiver is an alternating -dialogue, controlled by the sender. As such, the sender issues a -command and the receiver responds with a reply. Unless other -arrangements are negotiated through service extensions, the sender -must wait for this response before sending further commands. - -One important reply is the connection greeting. Normally, a receiver -will send a 220 "Service ready" reply when the connection is -completed. The sender should wait for this greeting message before -sending any commands. - -Note: all the greeting-type replies have the official name (i.e., the -fully-qualified primary domain name) of the server host as the first -word following the reply code. Sometimes the host will have no -meaningful name. See ##4.1.3 for a discussion of alternatives in -these situations. - - For example, - - 220 ISIF.USC.EDU Service ready - or - 220 LOSER.BOGUS.COM Trashmail v 6.1.2 Service ready - or - 220 [10.0.0.1] Clueless host service ready - - -The table below lists alternative success and failure replies for -each command. These SHOULD be strictly adhered to: a receiver may -substitute text in the replies, but the meaning and action implied by -the code numbers and by the specific command reply sequence cannot be -altered. - -4.3.2 Command-Reply Sequences - -Each command is listed with its usual possible replies. The prefixes -used before the possible replies are "I" for intermediate, "S" for -success, and "E" for error. Since some servers may generate other -replies under special circumstances, and to allow for future -extension, SMTP clients SHOULD, when possible, interpret only the -first digit of the reply and MUST be prepared to deal with -unrecognized reply codes by interpreting the first digit only. SMTP -servers MUST NOT transmit reply codes to an SMTP client that are -other than three digits or that do not start in a digit between 2 and -5 inclusive. - -These sequencing rules and, in principle, the codes themselves, can -be extended or modified by SMTP extensions offered by the server and -accepted (requested) by the client. - -In addition to the codes listed below, any SMTP command can return -any of the following codes if the corresponding unusual circumstances -are encountered: - - 500 For the "command line too long" case or if the command name - was not recognized. Note that producing a "commmand not - recognized" error in response to the required subset of - these commands is a violation of this specification. - 501 Syntax error in command or arguments. In order to provide - for future extensions, commands that are specified in this - document as not accepting arguments (DATA, NOOP, RSET) - SHOULD return a 501 message if arguments are supplied in the - absence of EHLO-advertised extensions. - 421 Service shutting down and closing transmission channel - - -Specific sequences are: - - CONNECTION ESTABLISHMENT - S: 220 - E: 554 - EHLO (or HELO) - S: 250 - E: 504, 550 - MAIL - S: 250 - E: 552, 451, 452, 550, 553 - RCPT - S: 250, 251 (but see section ##3.4 for discussion of 251) - E: 550, 551, 552, 553, 450, 451, 452, 503, 550 - DATA - I: 354 -> data -> S: 250 - E: 552, 554, 451, 452 - E: 451, 554, 503 - RSET - S: 250 - VRFY - S: 250, 251, 252 - E: 550, 551, 553, 502, 504 - EXPN - S: 250, 252 - E: 550, 500, 502, 504 - HELP - S: 211, 214 - E: 502, 504 - NOOP - S: 250 - QUIT - S: 221 - - - -4.4 Trace information - -When an SMTP server receives a message for delivery or further -processing, it MUST insert trace ("time stamp" or "Received") -information at the beginning of the message content, as discussed -under the DATA command in section ##4.1.1.4. - -This line must be structured as follows: - - * The FROM field, which MUST be supplied in an SMTP - environment, SHOULD contain both (1) the name of the source - host as presented in the EHLO command and (2) an address - literal containing the IP address of the source, determined - from the TCP connection. - - * The ID field MAY contain an "@" as suggested in RFC-822, - but this is not required. - - * The FOR field MAY contain a list of <path> entries when - multiple RCPT commands have been given. This may raise - some security issues and is usually not desirable; see - section ##7.2. - -An Internet mail program MUST NOT change a Received: line that was -previously added to the message header. SMTP servers MUST prepend -Received lines to messages; they MUST NOT change the order of -existing lines or insert Received lines in any other location. - -As the Internet grows, comparability of Received fields is important -for detecting problems, especially slow relays. SMTP servers that -create Received fields SHOULD use explicit offsets in the dates -(e.g., -0800), rather than time zone names of any type. Local time -(with an offset) is preferred to UT when feasible. If a time zone -name is used, it should be included in a comment. - -When the delivery SMTP server makes the "final delivery" of a -message, it inserts a return-path line at the beginning of the mail -data. This use of return-path is required; mail systems MUST support -it. The return-path line preserves the information in the -<reverse-path> from the MAIL command. Here, final delivery means the -message has left the SMTP world. Normally, this would mean it had -been delivered to the destination user or an associated mail drop, -but in some cases it may be further processed and transmitted by -another mail system. - -It is possible for the mailbox in the return path to be different -from the actual sender's mailbox, for example, if error responses are -to be delivered a special error handling mailbox rather than to the -message sender. When mailing lists are involved, this arrangement is -common and useful as a means of directing errors to the list -maintainer rather than the message originator. - -The text above implies that the final mail data will begin with a -return path line, followed by one or more time stamp lines. These -lines will be followed by the mail data headers and body [RFC822]. - -It is sometimes difficult for an SMTP server to determine whether or -not it is making final delivery since forwarding or other operations -may occur after the message is accepted for delivery. Consequently, -any further (forwarding, gateway, or relay) systems MAY remove the -return path and rebuild the MAIL FROM command as needed to ensure -that exactly one such line appears in a delivered message. - -A message-originating SMTP system SHOULD NOT send a message that -already contains a Return-path header. SMTP servers performing a -relay function MUST NOT inspect the message data, and especially not -to the extent needed to determine if Return-path headers are present. -SMTP servers making final delivery MAY remove Return-path headers -before adding their own. - -The primary purpose of the Return-path is to designate the address to -which messages indicating non-delivery or other mail system failures -are to be sent. For this to be unambigious, exactly one return path -should be present when the message is delivered. Systems using RFC -822 syntax with non-SMTP transports SHOULD designate an unambiguous -address, associated with the transport envelope, to which error -reports (e.g., non-delivery messages) should be sent. - - Historical note: Text in RFC 822 that appears to contradict the - use of Return-path (or the envelope MAIL FROM address) as the - destination for error messages is not applicable on the Internet. - The MAIL FROM address (as copied into the Return-path) MUST be - used as the target of any mail containing delivery error messages. - -In particular, - -(i) a gateway from SMTP->elsewhere SHOULD insert a return-path -header, unless it is known that the "elsewhere" transport also uses -Internet domain addresses and maintains the envelope sender address -separately. - -(ii) a gateway from elsewhere->SMTP SHOULD delete any -return-path header present in the message, and either copy -that information to the SMTP envelope or combine it with -information present in the envelope of the other transport -system to construct the MAIL FROM part of the SMTP envelope. - - - -The server must give special treatment to cases in which the -processing following the end of mail data indication is only -partially successful. This could happen if, after accepting several -recipients and the mail data, the SMTP server finds that the mail -data could be successfully delivered to some, but not all, of the -recipients. In such cases, the response to the DATA command must be -an OK reply. However, the SMTP server must compose and send an -"undeliverable mail" notification message to the originator of the -message. A single notification listing all of the failed recipients -or separate notification messages must be sent for each failed -recipient. For economy of processing by the sender, the former is -preferred when possible. All undeliverable mail notification -messages are sent using the MAIL command (even if they result from -processing the obsolete SEND, SOML, or SAML commands) and use a null -return path as discussed in section ##3.7. - -The time stamp line and the return path line are formally defined as -follows: - -Return-path-line = "Return-Path:" FWS Reverse-path CRLF - -Time-stamp-line = "Received:" FWS Stamp CRLF - -Stamp = From-domain By-domain Opt-info ";" - Daytime - -From-domain = "FROM" FWS Extended-Domain FWS - -By-domain = "BY" FWS Extended-Domain FWS - -Extended-Domain = Domain / - ( Domain FWS "(" Address-literal ")" ) / - Address-literal - -Opt-info = [Via] [With] [ID] [For] - -Via = "VIA" FWS Link FWS - -With = "WITH" FWS Protocol FWS - -ID = "ID" FWS String FWS - -For = "FOR" FWS Path FWS - -Link = <<>> / Addtl-Link -Addtl-Link = Atom ; Additional standard names for links are - registered with the Internet Assigned - Numbers Authority (IANA). - SMTP servers SHOULD NOT use unregistered - names. -Protocol = "ESMTP" / "SMTP" / Attdl-Protocol -Attdl-Protocol = Atom ; Additional standard names for protocols - are registered with the Internet Assigned - Numbers Authority (IANA). SMTP servers - SHOULD NOT use unregistered names. - -Daytime = FWS Date FWS Time - -Date = DD FWS Mon FWS YYYY - - Note that the earlier form, which permits two-digit years, has - been deprecated. SMTP systems MUST use four-digit years. - -Time = HH ":" MM ":" SS FWS Zone - -DD = 1*2Digit ; the one or two decimal integer day of the - month in the range 1 to 31. - -Mon = "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | - "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" - -YYYY = 4*4Digit ; the four decimal integer year in the range - 0000 to 9999. - -HH = 2*2Digit ; the two decimal integer hour of the day in - the range 00 to 24. - -MM = 2*2Digit ; the two decimal integer minute of the hour - in the range 00 to 59. - -SS = 2*2Digit ["." 1*Digit] - ; the two decimal integer second of the - minute in the range 00 to 59, with - optional fractional seconds. - -Zone = ( "+" / "-" ) 4*4Digit [ SP "(" String ")" ] - ; A four digit, signed time zone offset, - such as -0600 for US Eastern Standard - Time. This may be supplemented by a time - zone name in parentheses, e.g., "-0800 - (PDT)". See ##___ for additional - discussion. - - Note that there is no default; time zone information - is required and MUST be supplied. - - - - - -4.5. DETAILS - -4.5.1. MINIMUM IMPLEMENTATION - -In order to make SMTP workable, the following minimum -implementation is required for all receivers: - - COMMANDS -- HELO - VRFY - MAIL - RCPT - DATA - RSET - NOOP - QUIT - -Any system that includes an SMTP server supporting mail relaying -or delivery, i.e., the RCPT command, MUST support the reserved -mailbox "postmaster" as a case-insensitive local name. This -postmaster address is not strictly necessary if the server always -returns 554 on connection opening (as described in section ##3.1). The -requirement to accept mail for postmaster implies that RCPT TO -commands which specify a mailbox for postmaster at any of the domains -for which the SMTP server provides mail service, as well as the -special case of "RCPT TO:<Postmaster>" (with no domain specification), -MUST be supported. - -EHLO SHOULD be supported if possible. - - - -4.5.2. TRANSPARENCY - -Without some provision for data transparency, the character -sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent -by the user. In general, users are not aware of such -"forbidden" sequences. To allow all user composed text to be -transmitted transparently, the following procedures are used. - - 1. Before sending a line of mail text, the SMTP client checks - the first character of the line. If it is a period, one - additional period is inserted at the beginning of the line. - - 2. When a line of mail text is received by the SMTP server, - it checks the line. If the line is composed of a single period, - it is treated as the end of mail indicator. If the first - character is a period and there are other characters on the line, - the first character is deleted. - -The mail data may contain any of the 128 ASCII characters. All -characters are to be delivered to the recipient's mailbox, including -format effectors and other control characters. If the transmission -channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII -codes are transmitted right justified in the octets, with the high -order bits cleared to zero. See ##3.7 for special treatment of these -conditions in SMTP systems serving a relay function. - -In some systems it may be necessary to transform the data as it is -received and stored. This may be necessary for hosts that use a -different character set than ASCII as their local character set or -store data in records rather than strings. If such transformationss -are necessary, they must be reversible -- especially if such -transformationss are applied to mail being relayed. - - -4.5.3. SIZES AND TIMEOUTS - -There are several objects that have required minimum/maximum sizes. -Every implementation must be able to receive objects of at least -these sizes. Objects larger than these sizes SHOULD be avoided when -possible. However, some Internet mail constructs, e.g., encoded -X.400 addresses [RFC-X400] will often require larger objects: clients -MAY attempt to transmit these, but MUST be prepared for a server to -reject them if they cannot be handled by it. - - -**************************************************** -* * -* TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * -* TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * -* OF THESE OBJECTS SHOULD BE USED. * -* * -**************************************************** - -local-part - - The maximum total length of a user name or other local-part - -is 64 characters. - -domain - - The maximum total length of a domain name or number is 255 - characters. - -path - - The maximum total length of a reverse-path or - forward-path is 256 characters (including the punctuation - and element separators). - -command line - - The maximum total length of a command line including the - command word and the <CRLF> is 512 characters. SMTP extensions - may be used to increase this limit. - -reply line - - The maximum total length of a reply line including the reply code - and the <CRLF> is 512 characters. More information may be - conveyed through multiple-line replies. - - -text line - - The maximum total length of a text line including the <CRLF> is - 1000 characters (not counting the leading dot duplicated for - transparency). This number may be increased by the use of SMTP - Service Extensions. - -message content - - The maximum total length of a message content (including any - message headers as well as the message body) MUST BE at least 64K - octets. Since the introduction of multimedia mail [RFC-MIME], - message lengths on the Internet have grown dramatically, and - message size restrictions should be avoided if at all possible. - SMTP server systems that must impose restrictions SHOULD implement - the "SIZE" service extension ([RFC-SIZE]), and SMTP client systems - that will send large messages SHOULD utilize it when possible. - -recipients buffer - - The minimum total number of recipients that must be buffered is - 100 recipients. Rejection of messages (for excessive recipients) - with fewer than 100 RCPT TO commands is a violation of this - specification. The general principle that relaying SMTP servers - MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation - tests on message headers suggests that rejecting a message based - on the total number of recipients shown in header fields is to be - discouraged. A server which imposes a limit on the number of - recipients MUST behave in an orderly fashion, e.g., reject - additional addresses over its limit rather than silently - discarding addresses previously accepted. A client that needs to - deliver a message containing over 100 RCPT TO commands SHOULD be - prepared to transmit in 100-recipient "chunks" if the server - declines to accept more than 100 recipients in a single message. - - -**************************************************** -* * -* TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * -* TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * -* OF THESE OBJECTS SHOULD BE USED. * -* * -**************************************************** - -Errors due to exceeding these limits may be reported by using the -reply codes, for example: - -500 Line too long. - -501 Path too long - -452 Too many recipients (see below) - -552 Too much mail data. - -[RFC-821] incorrectly listed the error where an SMTP server exhausts -its implementation limit on the number of RCPT TO commands ("too many -recipients") as having reply code 552. The correct reply code for -this condition is 452. - -When a conforming SMTP server encounters this condition, it has at -least 100 successful RCPT commands in its recipients buffer. If the -server is able to accept the messsage, then at least these 100 -addresses will be removed from the SMTP client's queue. When the -client attempts retransmission of those addresses which recieved 452 -responses, at least 100 of these will be able to fit in the SMTP -server's recipients buffer. Each retransmission attempt which is -able to deliver anything will be able to dispose of at least 100 of -these recipients. - -If an SMTP server has an implementation limit on the number of RCPT -TO commands and this limit is exhausted, it MUST use a response code -of 452. If the server has an configured site-policy limitation on -the number of RCPT TO commands, it MAY instead use a 5XX response -code. - -In order to interoperate with SMTP servers implementing an older -version of the protocol, SMTP clients MAY treat a 552 code obtained -in response to an RCPT command as if it were a 452 response code. - - - - - -An SMTP client MUST provide a timeout mechanism. It MUST use -per-command timeouts rather than somehow trying to time the entire -mail transaction. Timeouts SHOULD be easily reconfigurable, -preferably without recompiling the SMTP code. To implement this, a -timer is set for each SMTP command and for each buffer of the data -transfer. The latter means that the overall timeout is inherently -proportional to the size of the message. - -Based on extensive experience with busy mail-relay hosts, the minimum -per-command timeout values SHOULD be as follows: - -o Initial 220 Message: 5 minutes - - An SMTP client process needs to distinguish between a failed TCP - connection and a delay in receiving the initial 220 greeting - message. Many SMTP servers accept a TCP connection but delay - delivery of the 220 message until their system load permits more - mail to be processed. - -o MAIL Command: 5 minutes - - -o RCPT Command: 5 minutes - - A longer timeout is required if processing of mailing lists and - aliases is not deferred until after the message was accepted. - -o DATA Initiation: 2 minutes - - This is while awaiting the "354 Start Input" reply to a - DATA command. - -o Data Block: 3 minutes - - This is while awaiting the completion of each TCP SEND call - transmitting a chunk of data. - -o DATA Termination: 10 minutes. - - This is while awaiting the "250 OK" reply. When the receiver - gets the final period terminating the message data, it typically - performs processing to deliver the message to a user mailbox. A - spurious timeout at this point would be very wasteful and would - typically result in delivery of multiple copies of the message, - since it has been successfully sent and the server has accepted - responsibility for delivery. See section ##6.1 for additional - discussion. - -An SMTP server SHOULD have a timeout of at least 5 minutes while it -is awaiting the next command from the sender. - - -4.5.4 Queuing Strategies - -The common structure of a host SMTP implementation includes user -mailboxes, one or more areas for queueing messages in transit, and -one or more daemon processes for sending and receiving mail. The -exact structure will vary depending on the needs of the users on the -host and the number and size of mailing lists supported by the host. -We describe several optimizations that have proved helpful, -particularly for mailers supporting high traffic levels. - -Any queueing strategy MUST include: - -o Timeouts on all activities on a per-command basis. - -o Never sending error messages in response to error messages. - - -4.5.4.1 Sending Strategy - -The general model for an SMTP client is one or more processes that -periodically attempt to transmit outgoing mail. In a typical system, -the program that composes a message has some method for requesting -immediate attention for a new piece of outgoing mail, while mail that -cannot be transmitted immediately MUST be queued and periodically -retried by the sender. A mail queue entry will include not only the -message itself but also the envelope information. - -The sender MUST delay retrying a particular destination after one -attempt has failed. In general, the retry interval SHOULD be at -least 30 minutes; however, more sophisticated and variable strategies -will be beneficial when the SMTP client can determine the reason for -non- delivery. - -Retries continue until the message is transmitted or the sender gives -up; the give-up time generally needs to be at least 4-5 days. The -parameters to the retry algorithm MUST be configurable. - -A client SHOULD keep a list of hosts it cannot reach and -corresponding connection timeouts, rather than just retrying queued -mail items. - - -Experience suggests that failures are typically transient (the target -system or its connection has crashed), favoring a policy of two -connection attempts in the first hour the message is in the queue, -and then backing off to one every two or three hours. - -The SMTP client can shorten the queuing delay in cooperation with the -SMTP server. For example, if mail is received from a particular -address, it is likely that mail queued for that host can now be sent. -Application of this principle may, in many cases, eliminate the -requirement for an explicit "send queues now" function such as that -discussed in [RFC-ETRN]. - -The strategy may be further modified as a result of multiple -addresses per host (see below) to optimize delivery time vs. -resource usage. - -An SMTP client may have a large queue of messages for each -unavailable destination host. If all of these messages were retried -in every retry cycle, there would be excessive Internet overhead and -the sending system would be blocked for a long period. Note that an -SMTP client can generally determine that a delivery attempt has -failed only after a timeout of several minutes and even a one-minute -timeout per connection will result in a very large delay if retries -are repeated for dozens, or even hundreds, of queued messages to the -same host. - -At the same time, SMTP clients should use great care in caching -negative responses from servers. In an extreme case, if EHLO is -issued multiple times during the same SMTP connection, different -answers may be returned by the server. More significantly, 5yz -responses to MAIL FROM MUST NOT be cached. - -When the same message will be delivered to several users on the same -host, only one copy of the message SHOULD be transmitted. That is, -the SMTP client SHOULD use the command sequence: RCPT, RCPT,... RCPT, -DATA instead of the sequence: RCPT, DATA, ..., RCPT, DATA, ... RCPT, -DATA. Implementation of this efficiency feature is strongly -encouraged. - -Similarly, to achieve timely delivery, the SMTP client MAY support -multiple concurrent outgoing mail transactions. However, some limit -may be appropriate to protect the host from devoting all its -resources to mail. - -4.5.4.2 Receiving strategy - -The SMTP server SHOULD attempt to keep a pending listen on the SMTP -port at all times. This requires the support of multiple incoming -TCP connections for SMTP. Some limit MAY be imposed. - -As discussed above, when the SMTP server receives mail from a -particular host address, it could notify the SMTP client to retry any -mail pending for that host address. - - - -5. Address resolution and mail handling - -Once an SMTP client lexically identifies a domain to which mail will -be delivered for processing (as described in sections ##3.6 and -##3.7), a DNS lookup is performed to resolve the domain name (see -[RFC-DNS]). The names are expected to be fully-qualified domain -names (FQDNs): mechanisms for inferring FQDNs from partial names or -local aliases are outside of this specification and, due to a history -of problems, are generally discouraged. The lookup first attempts to locate an MX record -associated with the name. If a CNAME record is found instead, the -resulting name is processed as if it were the initial name. If no MX -records are found, but an A RR is found, the A RR is treated as if it -was associated with an implicit MX RR, with a preference of 0, -pointing to that host. If one or more MX RRs are found for a given -name, SMTP systems MUST NOT utilize an A RRs associated with that -name unless they are located using the MX RRs; i.e., the "implicit -MX" rule above applies only if there are no MX records present. If -MX records are present, but none of them are usable, this situation -MUST be reported as an error. - -When the lookup succeeds, the mapping can result in a list of -alternative delivery addresses rather than a single address, because -of (a) multiple MX records, (b) multihoming, or both. To provide -reliable mail transmission, the SMTP client MUST be able to try (and -retry) each of the relevant addresses in this list in order, until a -delivery attempt succeeds. However, there MAY also be a configurable -limit on the number of alternate addresses that can be tried. In any -case, a host SHOULD try at least two addresses. - -The following information is used to rank the host addresses: - - (1) Multiple MX Records -- these contain a preference indication - that should be used in sorting (see below). Lower numbers are - more preferred than higher ones. If there are multiple - destinations with the same preference and there is no clear - reason to favor one (e.g., by recognition of an easily-reached - address), then the sender-SMTP MUST randomize them to - spread the load across multiple mail exchangers for a specific - organization. - - (2) Multihomed host -- The destination host (perhaps taken from the - preferred MX record) may be multihomed, in which case the domain - name resolver will return a list of alternative IP addresses. It - is the responsibility of the domain name resolver interface to - have ordered this list by decreasing preference if necessary, and - SMTP MUST try them in the order presented. - - Although the capability to try multiple alternative addresses is - required, specific installations may want to limit or disable the - use of alternative addresses. The question of whether a sender - should attempt retries using the different addresses of a - multihomed host has been controversial. The main argument for - using the multiple addresses is that it maximizes the probability - of timely delivery, and indeed sometimes the probability of any - delivery; the counterargument is that it may result in - unnecessary resource use. - - Note that resource use is also strongly determined by the sending - strategy discussed in Section #4.5.4.1. - -If a host receives a message with a destination for which it is a -designated Mail eXchanger, it MAY relay the message (potentially -after having rewritten the addresses), make final delivery of the -message, or hand it off using some mechanism outside the -SMTP-provided transport environment. - -If it determines that it should relay the message without rewriting -the address, it must sort the MX records to determine candidates for -delivery. The records are first ordered by preference, with the -lowest-numbered records being most preferred. The relay host must -then inspect the list for any of the names or addresses by which it -might be known in mail transactions. If a matching record is found, -all records at that preference level and higher-numbered ones MUST BE -discarded from consideration. If there are no records left at that -point, it is an error condition, and the message must be returned as -undeliverable. If records do remain, they should be tried, best -preference first, as described above. - - -6. Problem detection and handling - -6.1 Reliable delivery and replies by email - -When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" -message in response to DATA), it is accepting responsibility for -delivering or relaying the message. It must take this responsibility -seriously, i.e., it MUST NOT lose the message for frivolous reasons, -e.g., because the host later crashes or because of a predictable -resource shortage. - -If there is a delivery failure after acceptance of a message, the -receiver-SMTP MUST formulate and mail a notification message. This -notification MUST be sent using a null ("<>") reverse path in the -envelope. The recipient of this notification SHOULD be the address -from the envelope return path (or the Return-Path: line). However, -if this address is null ("<>"), the receiver-SMTP MUST NOT send a -notification. If the address is an explicit source route, it MUST be -stripped down to its final hop. - -DISCUSSION: - For example, suppose that an error notification must be - sent for a message that arrived with: - MAIL FROM:<@a,@b:user@d> - The notification message should be sent using: - RCPT TO:<user@d> - -Some delivery failures after the message is accepted by SMTP will be -unavoidable. For example, it may be impossible for the receiving -SMTP server to validate all the delivery addresses in RCPT command(s) -due to a "soft" domain system error, because the target is a mailing -list (see earlier discussion of RCPT), or because the server is -acting as a relay and has no immediate access to the delivering -system. - -To avoid receiving duplicate messages as the result of timeouts, a -receiver-SMTP MUST seek to minimize the time required to respond to -the final <CRLF>.<CRLF> end of data indicator. See RFC-1047 -[RFC1047] for a discussion of this problem. - - -6.2 Loop detection - -Simple counting of the number of Received lines in a message has -proven to be an effective, although rarely optimal, method of -detecting loops in mail systems. SMTP servers using this technique -should use a large rejection threshold, normally at least 100 -Received entries. Whatever mechanisms are used, servers MUST contain -provisions for detecting and stopping trivial loops. - - -6.3 Compensating for irregularities - -Unfortunately, variations, creative interpretations, and outright -violations of Internet mail protocols do occur; some would suggest -that they occur quite frequently. The debate as to whether a -well-behaved SMTP receiver or relay should reject a malformed -message, attempt to pass it on unchanged, or attempt to repair it to -increase the odds of successful delivery (or subsequent reply) began -almost with the dawn of structured network mail and shows no signs of -abating. Advocates of rejection claim that attempted repairs are -rarely completely adequate and that rejection of bad messages is the -only way to get the offending software repaired. Advocates of -"repair" or "deliver no matter what" argue that users prefer that -mail go through it if at all possible and that there are significant -market pressures in that direction. In practice, these market -pressures may be more important to particular vendors than strict -conformance to the standards, regardless of the preference of the -actual developers. - -The problems associated with ill-formed messages were exacerbated by -the introduction of the split-UA mail reading protocols [RFC-POP2, -RFC-POP3, RFC-IMAP2, RFC-PCMAIL These protocols have encouraged the -use of SMTP as a posting protocol, and SMTP servers as relay systems -for these client hosts (which are often only intermittently connected -to the Internet). Historically, many of those client machines lacked -some of the mechanisms and information assumed by SMTP (and indeed, -by the mail format protocol [RFC-822]). Some could not keep adequate -track of time; others had no concept of time zones; still others -could not identify their own names or addresses; and, of course, none -could satisfy the assumptions that underlay RFC-822's conception of -authenticated addresses. - -In response to these weak SMTP clients, many SMTP systems now -complete messages that are delivered to them in incomplete or -incorrect form. This strategy is generally considered appropriate -when the server can identify or authenticate the client, and there -are prior agreements between them. By contrast, there is at best -great concern about fixes applied by a relay or delivery SMTP server -that has little or no knowledge of the user or client machine. - -The following changes to a message being processed MAY be applied by -an originating SMTP server, or one used as the target of SMTP as an -initial posting protocol, when necessary. The less information the -server has about the client, the less likely these changes are to be -correct and the more caution and conservatism should be applied when -considering whether or not to perform fixes and how. These changes -MUST NOT be applied by an SMTP server that provides an intermediate -relay function. - - - Addition of a message-id field when none appears - - - Addition of a date, time or time zone when none appears - - - Correction of addresses to proper FQDN format - -In all cases, properly-operating clients supplying correct -information are preferred to corrections by the SMTP server. In all -cases, documentation of actions performed by the servers (in trace -fields and/or header comments) is strongly encouraged. - - -7. Security Considerations - -7.1 Mail security and spoofing - -SMTP mail is inherently insecure in that it is feasible for even -fairly casual users to negotiate directly with receiving and relaying -SMTP servers and create messages that will trick a naive recipient -into believing that they came from somewhere else. Constructing such -a message so that the "spoofed" behavior cannot be detected by an -expert is somewhat more difficult, but not sufficiently so as to be a -deterrent to someone who is determined and knowledgeable. -Consequently, as knowledge of Internet mail increases, so does the -knowledge that SMTP mail inherently cannot be authenticated, or -integrity checks provided, at the transport level. - -Real mail security lies only in end-to-end methods involving the -message bodies, e.g., those that can be provided in the MOSS -framework [RFC-MOSS]. - -Efforts to make it more difficult for users to set envelope MAIL FROM -and header "From" fields to point to valid addresses other than their -own are largely misguided: they frustrate legitimate applications in -which mail is sent by one user on behalf of another or in which error -(or normal) replies should be directed to a special address. (Systems -that provide convenient ways for users to alter these fields on a -per-message basis should attempt to establish a primary and permanent -mailbox address for the user so that Sender fields within the message -data can be generated sensibly.) - -This specification does not further address the authentication issues -associated with SMTP other than to advocate that useful functionality -not be disabled in the hope of providing some small margin of -protection against an ignorant user who is trying to fake mail. - - - -7.2 "Blind" copies. - -Addresses that do not appear in the message headers may appear in the -RCPT TO commands to an SMTP server for a number of reasons. The two -most common involve the use of a mailing address as a "list exploder" --- a single address that resolves into multiple addresses -- and the -appearance of "blind copies". In order to avoid defeating some of -the purpose of these mechanisms, SMTP clients and servers SHOULD NOT -copy the full set of RCPT TO command arguments into the headers, -either as part of trace headers or as informational or -private-extension headers. Since this rule is often violated in -practice, and cannot be enforced, sending SMTP systems that are aware -of "bcc" use MAY find it helpful to send each blind copy as a -separate message transaction containing only a single RCPT TO command. - -There is no inherent relationship between either "reverse" (MAIL -FROM, SAML FROM, etc.) or "forward" (RCPT TO) addresses in the SMTP -transaction ("envelope") and the addresses in the headers. Receiving -systems SHOULD NOT attempt to deduce such relationships and use them -to alter the headers of the message for delivery. The popular -"Apparently-to" header is a violation of this principle and SHOULD -NOT be used. - - -7.3 VRFY, EXPN, and security. - -As discussed in section ##3.5, individual sites may want to disable -one or both VRFY or EXPN for security reasons. As a corollary to the -above, implementations that permit this MUST NOT appear to have -verified addresses that are not, in fact, verified. If a site -disables these commands for security reasons, the SMTP server MUST -return a 252 response, rather than a code that could be confused with -successful or unsuccessful verification. - -Returning a 250 reply code with the address listed in the VRFY -command after having checked it only for syntax violates this rule. -Of course, an implementation that "supports" VRFY by always returning -550 whether or not the address is valid is equally not in conformance. - -Within the last few years, the contents of mailing lists have become -popular as an address information source for so-called "spammers." -The use of EXPN to "harvest" addresses has increased as list -administrators have installed protections against inappropriate uses -of the lists themselves. Implementations SHOULD still provide -support for EXPN, but sites should carefully evaluate the tradeoffs.. -As authentication mechanisms are introduced into SMTP, some sites may -choose to make EXPN available only to authenticated requestors. - - -7.4. Information Disclosure - -There has been an ongoing debate about the tradeoffs between the -debugging advantages of announcing server type and version (and, -sometimes, even server domain name) in the greeting response or in -response to the HELP command and the disadvantages of exposing useful -information to potential hostile attack. The utility of the -debugging information is beyond doubt. Those who argue for making it -available point out that it is far better to actually secure an SMTP -server rather than hope that trying to conceal known vunerabilities -by hiding the server's precise identity will provide more protection. -Sites are encouraged to evaluate the tradeoff with that issue in -mind; implementations are strongly encouraged to minimally provide -for making type and version information available in some way to -other network hosts. - - -7.5. Scope of operation of SMTP servers - -It is a well-established principle that an SMTP server may refuse to -accept mail for any operational or technical reason that makes sense -to the site providing the server. However, cooperation among sites -and installations makes the Internet possible. If sites take -excessive advantage of the right to reject traffic, the ubiquity of -email availability (one of the strengths of the Internet) will be -threatened; considerable care should be taken and balance maintained -if a site decides to be selective about the traffic it will accept -and process. - -In recent years, use of the relay function through arbitrary sites -has been used as part of hostile efforts to hide the actual origins -of mail. Some sites have decided to limit the use of the relay -function to known or identifiable sources, and implementations SHOULD -provide the capability to perform this type of filtering. When mail -is rejected for these or other policy reasons, a 550 code should be -used in response to EHLO, MAIL FROM, or RCPT TO as appropriate. - - -8. IANA Considerations - -IANA is [[requested]] to set up three registries. The first consists -of SMTP service extensions with the associated keywords, and, as -needed, parameters and verbs. As specified in section ##2.2.2, no -entry may be made in this registry that starts in an "X". Entries -may be made only for service extensions (and associated keywords, -parameters, or verbs) that are defined in standards-track or -experimental RFCs specifically approved by IESG for this purpose. - -The second registry consists of "tags" that identify forms of domain -literals other than those for IPv4 addresses (specified in RFC 821 -and in this document) and IPv6 addresses (specified in this -document). Additional literal types require standardization before -being used; none are anticipated at this time. - -The third, established by RFC 821 and renewed by this specification, -is a registry of link and protocol identifiers to be used with the -"via" and "with" subclauses of the time stamp ("Received: header") -described in section ##4.4. Link and protocol identifiers in -addition to those specified in this document may be registered only -by standardization or by way of an RFC-documented, IESG-approved, -Experimental protocol extension. - - - -9. REFERENCES - -[1] ASCII - - ASCII, "USA Code for Information Interchange", United States of - America Standards Institute (now American National Standards - Institute), X3.4, 1968. ANSI X3.4-1968 has been replaced by - newer versions with slight modifications, but the 1968 - version remains definitive for the Internet. - -[RFC822] - Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", RFC 822, Department of Electrical Engineering, - University of Delaware, August 1982. - -[3] TCP - Postel, J., ed., "Transmission Control Protocol - DARPA Internet - Program Protocol Specification", RFC 793, USC/Information Sciences - Institute, NTIS AD Number A111091, September 1981. - -[HEADER-PEOPLE] - -[IPv6AddrString] Hinden,R and S. Deering, Eds. "IP Version 6 - Addressing Architecture", RFC 1884, December 1995. - -[RFC-DNS] P. Mockapetris, "Domain names - implementation and - specification", RFC 1035 and P. Mockapetris, "Domain names - - concepts and facilities", RFC 1034. (STD 13) - -[RFC974] C. Partridge, "Mail routing and the domain system", RFC - 974, 01/01/1986 - -[RFC1047] C. Partridge, "Duplicate messages and SMTP", RFC 1047, - 02/01/1988. - -[RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension - for Message Size Declaration", RFC 1870, 11/06/1995. (STD 10) - -[RFC-MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message - Bodies", RFC 2045, 12/02/1996. - -[RFC-INTLHDR] K. Moore, "MIME (Multipurpose Internet Mail Extensions) - Part Three: Message Header Extensions for Non-ASCII Text", - RFC 2047, 12/02/1996. - -[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, - "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, - 07/18/1994. - -[SMTPEX] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. - Crocker, "SMTP Service Extensions", RFC-1869, 11/06/1995. (STD - 10) - -[RFC-1123] R. Braden, "Requirements for Internet hosts - - application and support", 10/01/1989 - -[RFC-MOSS] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object - Security Services", RFC 1848, 10/03/1995. - -[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J. - Reynolds, "Post Office Protocol - version 2", RFC 937, - 02/01/1985 - -[RFC-IMAP2] M. Crispin, "Interactive Mail Access Protocol - Version - 2", RFC 1176, 08/20/1990. - -[RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for - personal computers", RFC 1056, 06/01/1988. - -[RFC-POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3", - RFC 1930, 5/14/96 (Std 53). - -[RFC-IMAP4] M. Crispin, "Internet Message Access Protocol - - Version 4", RFC 2060, 12/04/1996. - -[RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / - ISO 10021 and RFC 822", RFC 1327, 05/18/1992. - -[RFC-ETRN] J. De Winter, "SMTP Service Extension for Remote - Message Queue Starting", RFC 1985, 08/14/1996. - -[RFC-BDAT] G. Vaudreuil, "SMTP Service Extensions for - Transmission of Large and Binary MIME Messages", RFC 1830, - 08/16/1995. - -[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension - for Command Pipelining", RFC 1854, 10/04/1995. - -[RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery - Status Notifications", RFC 1891, 01/15/1996. - -[RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message - Format for Delivery Status Notifications", RFC 1894, - 01/15/1996. - -[RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes", - RFC 1893, 01/15/1996. - -[ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - -[MSGFMT] P. Resnick, Work in progress, - draft-ietf-drums-msg-fmt-04.txt, March 13, 1998 - - -9. Editor's Addresses - - John C. Klensin - MCI Communications - 800 Boylston St., 7th floor - Boston, MA 02199 - USA - Email: Klensin@mci.net - Phone: +1 617 960 1011 - Fax: +1 617 960 1009 - -Dawn P. Mann -Microsoft Corporation -1 Microsoft Way -Redmond, WA 98052-6399 -USA - Email: dawnm@microsoft.com - Tel: +1 425 936 5475 - - - -10. Acknowledgments - -<<>>to be supplied>> - - - -APPENDIX A - -TCP Transport service - -The Transmission Control Protocol [3] is used in the Internet, and in -any network following the Internet standards for internetwork protocols. - -Connection Establishment - - The SMTP transmission channel is a TCP connection established - between the sender process port U and the receiver process port - L. This single full duplex connection is used as the - transmission channel. This protocol is assigned the service - port 25 (31 octal), that is L=25. - -Data Transfer - - The TCP connection supports the transmission of 8-bit bytes. - The SMTP data is 7-bit ASCII characters. Each character is - transmitted as an 8-bit byte with the high-order bit cleared to - zero. Service extensions may modify this rule to permit - transmission of full 8-bit data bytes as part of the message - body, but not in SMTP commands or responses. - - - -APPENDIX B - -Generating SMTP commands from RFC 822 headers - -Some systems use RFC 822 headers (only) in a mail submission -protocol, or otherwise generate SMTP commands from RFC 822 headers -when such a message is handed to an MTA from a UA. While the MTA-UA -protocol is a private matter, not covered by any Internet Standard, -there are problems with this approach. For example, there have been -repeated problems with proper handling of "bcc" copies and -redistribution lists when information that conceptually belongs to a -mail envelopes is not separated early in processing from header -information (and kept separate). - -It is recommended that the UA provide its initial MTA with an -envelope separate from the message itself. However, if the envelope -is not supplied, SMTP commands should be generated as follows: - -(i) each recipient address from a TO, CC, or BCC header field -should be copied to a RCPT command (generating multiple message -copies if that is required for queuing or delivery). This includes -any addresses listed in a RFC 822 "group". Any BCC fields should -then be removed from the headers. Once this process is completed, -the remaining headers should be checked to verify that at least one -To:, Cc:, or Bcc: header remains. If none do, then a bcc: header -with no additional information SHOULD be inserted as specified in -[MSGFMT]. - -(ii) the return address in the MAIL command should, if possible, be -derived from the system's identity for the submitting (local) user. -And the From header field otherwise. If there is a system identity -available, it should also be copied to the Sender header field if it -is different from the address in the From header field. (Any Sender -field that was already there should be removed.) Systems may provide -a way for submitters to override the envelope return address, but may -want to restrict its use to privileged users. (This will not prevent -mail forgery, but may lessen its incidence -- see section 7.1.) - -When an MTA is being used in this way, it bears responsibility for -ensuring that the message being transmitted is valid. The mechanisms -for checking that validity, and for handling (or returning) messages -that are not valid at the time of arrival, are part of the MUA-MTA -interface and not covered by this specification. - -A submission protocol based on Standard RFC 822 information alone -MUST NOT be used to gateway a message from a foreign (non-SMTP) mail -system into an SMTP environment. Additional information to construct -an envelope must come from some source in the other environment, -whether supplemental headers or the foreign system's envelope. - -Attempts to gateway messages using only their header "to" and "cc" -fields, have repeatedly caused mail loops and other behavior adverse -to the proper functioning of the Internet mail environment. These -problems have been especially common when the message originates from -an Internet mailing list and is distributed into the foreign -environment using envelope information. When these messages are then -processed by a header-only remailer, loops back to the Internet -environment (and the mailing list) are almost inevitable. - - -APPENDIX C - -Source routes. - -The <reverse-path> is a reverse source routing list of hosts and a -source mailbox. The first host in the <reverse-path> should be the -host sending the MAIL FROM command. Similarly, the <forward-path> -may be a source routing lists of hosts and a destination mailbox. -However, in general, the <forward-path> should contain only a mailbox -and domain name, relying on the domain name system to supply routing -information if required. The use of source routes is deprecated; -while servers MUST be prepared to receive and handle them as -discussed in section ##3.3 and below, clients SHOULD NOT transmit -them. - -For relay purposes, the forward-path may be a source route of the -form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE -fully-qualified domain names. This form is used to emphasize the -distinction between an address and a route. The mailbox is an -absolute address, and the route is information about how to get -there. The two concepts should not be confused. - -If source routes are used, RFC 821 and the text below should be -consulted for the mechanisms for constructing and updating the -forward- and reverse-paths. - -The SMTP server transforms the command arguments by moving its own -identifier (its domain name or that of any domain for which it is -acting as a mail exchanger), if it appears, from the forward-path to -the beginning of the reverse-path. - -Notice that the forward-path and reverse-path appear in the SMTP -commands and replies, but not necessarily in the message. That is, -there is no need for these paths and especially this syntax to appear -in the "To:" , "From:", "CC:", etc. fields of the message header. -Conversely, SMTP servers MUST NOT derive final message delivery -information from message header fields. - - When the list of hosts is present, it is a "reverse" source route -and indicates that the mail was relayed through each host on the list -(the first host in the list was the most recent relay). This list is -used as a source route to return non-delivery notices to the sender. -As each relay host adds itself to the beginning of the list, it must -use its name as known in the transport environment to which it is -relaying the mail rather than that of the transport environment from -which the mail came (if they are different). - - - - -APPENDIX F - -Scenarios - -This section presents complete scenarios of several types of SMTP -sessions. - -A Typical SMTP Transaction Scenario - -This SMTP example shows mail sent by Smith at host USC-ISIF, to -Jones, Green, and Brown at host BBN-UNIX. Here we assume that host -USC-ISIF contacts host BBN-UNIX directly. The mail is accepted for -Jones and Brown. Green does not have a mailbox at host BBN-UNIX. - -------------------------------------------------------------- - - R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIF.ARPA - R: 250 BBN-UNIX.ARPA - - S: MAIL FROM:<Smith@USC-ISIF.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@BBN-UNIX.ARPA> - R: 250 OK - - S: RCPT TO:<Green@BBN-UNIX.ARPA> - R: 550 No such user here - - S: RCPT TO:<Brown@BBN-UNIX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 BBN-UNIX.ARPA Service closing transmission channel - - Scenario 1 - -------------------------------------------------------------- - - - - - -Aborted SMTP Transaction Scenario - -------------------------------------------------------------- - - R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready - S: HELO ISI-VAXA.ARPA - R: 250 MIT-Multics.ARPA - - S: MAIL FROM:<Smith@ISI-VAXA.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@MIT-Multics.ARPA> - R: 250 OK - - S: RCPT TO:<Green@MIT-Multics.ARPA> - R: 550 No such user here - - S: RSET - R: 250 OK - - S: QUIT - R: 221 MIT-Multics.ARPA Service closing transmission channel - - Scenario 2 - -------------------------------------------------------------- - - - -Relayed Mail Scenario - -------------------------------------------------------------- - - Step 1 -- Source Host to Relay Host - - R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-AI.ARPA - R: 250 USC-ISIE.ARPA - - S: MAIL FROM:<JQP@MIT-AI.ARPA> - R: 250 OK - - S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Date: 2 Nov 81 22:33:44 - S: From: John Q. Public <JQP@MIT-AI.ARPA> - S: Subject: The Next Meeting of the Board - S: To: Jones@BBN-Vax.ARPA - S: - S: Bill: - S: The next meeting of the board of directors will be - S: on Tuesday. - S: John. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - - Step 2 -- Relay Host to Destination Host - - R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIE.ARPA - R: 250 BBN-VAX.ARPA - - S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@BBN-VAX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ; - 2 Nov 81 22:40:10 UT - S: Date: 2 Nov 81 22:33:44 - S: From: John Q. Public <JQP@MIT-AI.ARPA> - S: Subject: The Next Meeting of the Board - S: To: Jones@BBN-Vax.ARPA - S: - S: Bill: - S: The next meeting of the board of directors will be - S: on Tuesday. - S: John. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - Scenario 3 - -------------------------------------------------------------- - - - - -Verifying and Sending Scenario - -------------------------------------------------------------- - - R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-MC.ARPA - R: 250 SU-SCORE.ARPA - - S: VRFY Crispin - R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA> - - S: SEND FROM:<EAK@MIT-MC.ARPA> - R: 250 OK - - S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 SU-SCORE.ARPA Service closing transmission channel - - Scenario 4 - -------------------------------------------------------------- - - - - -Mailing List Scenario - -First each of two mailing lists are expanded in separate sessions -with different hosts. Then the message is sent to everyone that -appeared on either list (but no duplicates) via a relay host. - -------------------------------------------------------------- - - Step 1 -- Expanding the First List - - R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 MIT-AI.ARPA - - S: EXPN Example-People - R: 250-<ABC@MIT-MC.ARPA> - R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA> - R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA> - R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250-<joe@foo-unix.ARPA> - R: 250 <xyz@bar-unix.ARPA> - - S: QUIT - R: 221 MIT-AI.ARPA Service closing transmission channel - - - Step 2 -- Expanding the Second List - - R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 MIT-MC.ARPA - - S: EXPN Interested-Parties - R: 250-Al Calico <ABC@MIT-MC.ARPA> - R: 250-<XYZ@MIT-AI.ARPA> - R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250-<fred@BBN-UNIX.ARPA> - R: 250 <xyz@bar-unix.ARPA> - - S: QUIT - R: 221 MIT-MC.ARPA Service closing transmission channel - - - Step 3 -- Mailing to All via a Relay Host - - R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 USC-ISIE.ARPA - - S: MAIL FROM:<Account.Person@SU-SCORE.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA> - R: 250 OK - S: RCPT - TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - Scenario 7 - -------------------------------------------------------------- - - - -Too Many Recipients Scenario - -------------------------------------------------------------- - - R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIF.ARPA - R: 250 BERKELEY.ARPA - - S: MAIL FROM:<Postel@USC-ISIF.ARPA> - R: 250 OK - - S: RCPT TO:<fabry@BERKELEY.ARPA> - R: 250 OK - - S: RCPT TO:<eric@BERKELEY.ARPA> - R: 552 Recipient storage full, try again in another transaction - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: MAIL FROM:<Postel@USC-ISIF.ARPA> - R: 250 OK - - S: RCPT TO:<eric@BERKELEY.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 BERKELEY.ARPA Service closing transmission channel - - Scenario 10 - -------------------------------------------------------------- - -Note that a real implementation must handle many recipients as -specified in Section ##4.5.3. - - - -APPENDIX G Other gateway issues. - -In general, gateways between the Internet and other mail systems -SHOULD attempt to preserve any layering semantics across the -boundaries between the two mail systems involved. Gateway- -translation approaches that attempt to take shortcuts by mapping, -e.g., envelope information from one system to the message headers or -body of another have generally proven to be inadequate in important -ways. Systems translating between environments that do not support -both envelopes and headers and Internet mail must be written with the -understanding that some information loss is almost inevitable. - - - -APPENDIX I: Deprecated features of RFC 821 - -A few features of RFC 821 have proven to be problematic and should -not be used in Internet mail. These are: - -(1) TURN - -This command, described in RFC 821, raises important security issues -since, in the absence of strong authentication of the host requesting -that the client and server switch roles, it can easily be used to -divert mail from its correct destination. Its use is deprecated; -SMTP systems SHOULD NOT use it unless the server can authenticate the -client. - - -(2) Source routing - -RFC 821 utilized the concept of explicit source routing to get mail -from one host to another via a series of relays. The requirement to -utilize source routes in regular mail traffic was eliminated by the -introduction of the domain name system "MX" record and the last -significant justification for them was eliminated by the -introduction, in RFC 1123, of a clear requirement that addresses -following an "@" must all be fully-qualified domain names. -Consequently, the only remaining justifications for the use of source -routes are support for very old SMTP clients or MUAs and in mail -system debugging. They can, however, still be useful in the latter -circumstance and for routing mail around serious, but temporary, -problems such as problems with the relevant DNS records. - -SMTP servers MUST continue to accept source route syntax as specified -in the main body of this document and in RFC 1123. They MAY, if -necessary, ignore the routes and utilize only the target domain in -the address. If they do utilize the source route, the message MUST -be sent to the first domain shown in the address. In particular, a -server MUST NOT guess at shortcuts within the source route. - -Clients SHOULD NOT utilize explicit source routing except under -unusual circumstances, such as debugging or potentially relaying -around firewall or mail system configuration errors. - -(3) HELO - -As discussed in sections ##3.1 and ##4.1.1, EHLO is strongly -preferred to HELO when the server will accept the former. Servers -must continue to accept and process HELO in order to support older -clients. - - -(4) #-literals - -RFC 821 provided for specifying an Internet address as a decimal -integer host number prefixed by a pound sign, "#". In practice, that -form has been obsolete since the introduction of TCP/IP. It is -deprecated and MUST NOT be used. - -(5) Dates and years - -When dates are inserted into messages by SMTP clients or servers -(e.g., in trace fields), four-digit years MUST BE used. Two-digit -years are deprecated; three-digit years were never permitted in the -Internet mail system. - -(6) Sending versus mailing - -In addition to specifying a mechanism for delivering messages to -user's mailboxes, RFC 821 provided additional, optional, commands to -deliver messages directly to the user's terminal screen. These -commands (SEND, SAML, SOML) were rarely implemented, and changes in -workstation technology and the introduction of other protocols may -have rendered them obsolete even where they are implemented. - -Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers -MAY implement them. If they are implemented by servers, the -implementation model specified in RFC 821 MUST be used and the -command names MUST be published in the response to the EHLO command. - - - -APPENDIX X: Change summary and Loose ends (temporary) - -X.1 Change summary - -X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and -draft-ietf-drums-smtpupd-01.txt - -(i) Slightly clarified the discussions of rejection and failure of -VRFY requests and the associated response codes. - -(ii) Slightly clarified the discussion of deferred address -validation. - -(iii) Removed the IPCE terminology and modified the text in section -##4.1.1.2 to explicitly introduce the "mail gateway" terminology and -to begin to distinguish a mail gateway from a conventional relay. - -(iv) Explicitly noted that SMTP clients for things like POP and IMAP -may send everything to a single relay for further processing, rather -than resolving final domain names. - -(v) Tightened the RSET discussion. - -(vi) Deprecation of 251 only for RCPT (still ok for VRFY) - - - -X.1.2. Substantive changes between draft-ietf-drums-smtpupd-01.txt -and draft-ietf-drums-smtpupd-02.txt. - -Incorporated additional RFC 1123 material; reorganized several -sections for clarity. Added definitions and other previous "loose -end" material. - - -X.1.3. Substantive changes between draft-ietf-drums-smtpupd-02.txt -and draft-ietf-drums-smtpupd-03.txt. - -(i) Eliminated a number of placeholders and tightened some of the -definitions in section 2. Added a few new placeholders for -consistency checking against other documents. - -(ii) Removed the state diagrams, per direction at IETF Montreal. - -(iii) Added new section 6.3, an attempt to summarize WG discussions -on the "posting" versus "delivery" versus "relay" functions of SMTP -and on whether "fixups" are appropriate in different cases. - -(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of -RFC1123. - -(v) Added new text to 3.5.5 to discuss the spammer - EXPN -relationship. - -(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat. - -(v) The remaining miscellaneous changes agreed to in Montreal have -been incorporated except as noted below. - - -X.1.4. Substantive changes between draft-ietf-drums-smtpupd-03.txt -and draft-ietf-drums-smtpupd-04.txt. - -Many small changes have been made between these two versions; the -list that follows is not exhaustive. - -(i) To clarify some of the text, definitions have been introduced to -distinguish among originating, delivery, relay, and gateway SMTP -systems. - -(ii) The role of LF-terminated lines has been clarified. - -(iii) Several changes have been made to clarify the principle -that, no matter what originating and final delivery systems -might do, relay systems are not permitted to tamper with message -content, even to "fix" headers that are determined to be -invalid. If they deem message content to be seriously -unacceptable, they are encouraged to reject the messages in -preference to trying to fix them up, but, in general, the theme -is "don't look/ don't tell". - -(iv) A few more definitions have been added to the terminology -section, and the separate glossary has been eliminated. - -(v) I have taken a shot at text to address some of the controversies -that have raged on the WG mailing list (e.g., sections 7.4 and 7.5). -Since there was no consensus on most of those topics, I expect that -the inserted text will satisfy no one except, perhaps, for agreement -that saying nothing would have been worse. As a mechanism for moving -forward, the text in these controversial areas that now appears will -be considered "base"; alterations will be made only if clear -consensus emerges. - -(vi) Per discussion in Los Angeles, source routes have been further -deprecated. - -(vii) Some of the VRFY/EXPN materials have been moved to "security -considerations", where they appear to belong, some text has been -added, and the conformance statements adjusted to reflect what I -perceive to be WG consensus. - -(viii) New MX resolution material has been added to section 5. While -most of this material is from RFC974, the rules have been further -tightened to reflect current practice and experience (974 is written -in a somewhat speculative fashion for a standard). In particular, -the behavior of trying the target host's A RR when MXs existed but -all of them were eliminated is now prohibited, which seems necessary -if another of other ideas being recommended or considered are to be -feasible. - - -X.1.5. Substantive changes between draft-ietf-drums-smtpupd-04.txt -and draft-ietf-drums-smtpupd-05.txt. - -(i) All normative references to RFC 1123 have been removed from the -main body of the text (some still appear in the appendices where they -will remain). - -(ii) Section 3.5 has been renamed slightly to distinguish between -"debuging of SMTP implementations" and "debugging of addresses". -Better terminology would be welcome. - -(iii) Error conditions resulting from the DATA command have been -clarified. - -(iv) Section 4.2 (SMTP replies) has been revised and tightened to -reflect reality and recent discussion on the list. - -(v) Appendix E has been revised a bit and moved into section 4.2.1. -Given the importance of the "check only first digit" rule, it has to -be there. - -(vi) Added new text for "no SMTP service supported" to sections -3.1, 4.2.2, 4.2.3, and 4.3.2. As noted in 3.1, I'd rather add 521 -(which would work perfectly with the model) rather than overloading -554. - -(vii) The Return-path language in section 4.4 has been cleaned up a -bit. - -(viii) Tightened the "postmaster" language in 4.5.1, requiring a -small change to 4.1.1.3. - -(ix) I have unilaterally (with a little help from my friends), -increased some of the size limits. 64 was much too short for a -domain name, and the DNS limit of 255 (?) has now been inserted. -That leaves the return path much too short, but I haven't fixed it -(maybe that will cause us to get rid of them). We still have a 64 -character limit on the local-part, which is also *much* too short. -Votes for 128 or longer limits accepted. See X.1.6(I) - -(x) The text on the "recipients buffer" has been rewritten so that (I -hope) it makes sense and gives some explicit guidance for how clients -and servers should proceed if limits are imposed. - - -X.1.6. Substantive changes between draft-ietf-drums-smtpupd-05.txt -and draft-ietf-drums-smtpupd-06.txt. - -Most of the changes in this revision have been editorial rather than -substantive. Major substantive changes include: - -(i) The language about maximum sizes of SMTP command lines has been -reworked, per WG mailing list discussion. - -(ii) Several instances of "Should" have been promoted to "Must" when the -reasons for the weaker rule seemed to have disappeared. In -particular, the requirement that an SMTP implementation support -timeouts has become a MUST. Also, conformance to this specification -requires support of EHLO. Older systems should claim conformance to -the [to-be-historical] 821, not this specification. - - -X.1.7. Substantive changes between draft-ietf-drums-smtpupd-06.txt -and draft-ietf-drums-smtpupd-07.txt. - -(i) Removed "implied RSET" text associated with QUIT, as specified -at the December 1997 IETF - -(ii) Required that servers support EHLO, as specified at the December -1997 IETF - - -X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt -and draft-ietf-drums-smtpupd-08.txt. - -This version involves mostly editorial work and cleanup of loose -ends. - -(i) Error code presentation has been restructured. - -(ii) ABNF conversion done - -(iii) IPv6 address format inserted per RFC 1884, since we could not -get clear agreement on an alternative. - -(iv) Trivial, silly, examples removed. Others not yet renumbered. - -(v) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes. Eric -may not like the way I've done either of these change very much: the -first now makes the distinction between returning an address and -returning other stuff (which was permitted by -06, but the text -wasn't as clear as it should have been): if it looks like an address, -it needs to be an address. Similarly, with 4.1.1, Eric wanted to -explicitly permit/legitimize "DATA <SP> <CRLF>". I see several -disadvantages to doing that, so have inserted language that -encourages receivers to tolerate trailing white space, which may have -the same practical effect. - - - - - -X.2 Loose ends - -(i) The 821 BNF -> ABNF transition needs careful checking. - -(ii) Most remaining examples are not yet revised, overview and -grammar are still to be merged. Examples need to be renumbered and -cross references need to be checked. - -(iii) Trace field discussion should be checked carefully, -particularly since the syntax given is slightly different from 821. -Provision has been made, reflecting some current practice, for -(optional) fractional seconds in time stamps. - -(iv) The Appendices have not yet been numbered consecutively. Note -that Appendix X is temporary and is not expected to appear in any -final publication. - -(v) See X.1.5(ix), above. - -(vi) Remaining syntax differences and redundancies wrt 822bis (see -note on section 4.1.2). Note that the use of "Atom" for extension -parameter keywords is slightly different from the specification in -RFC 1869. - -(vii) We don't have a satisfactory definition for "link" as in -"Received:.. via <link>" and, if there is a registry, I can't find -it. Needs to be fixed somehow. diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-08.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-08.txt deleted file mode 100644 index 8124c110..00000000 --- a/Documentation/en/I-D/draft-ietf-drums-smtpupd-08.txt +++ /dev/null @@ -1,3574 +0,0 @@ -INTERNET-DRAFT John C. Klensin, Editor -Expires in six months -August 4, 1998 - - - Simple Mail Transfer Protocol - - draft-ietf-drums-smtpupd-08.txt - -Status of this Memo - -This document is an Internet-Draft. 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." - -To view the entire list of current Internet-Drafts, please check the -"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow -Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), -ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), -ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - -[[Sections marked with doubled brackets (e.g., "<<") are explicit -placeholders or known major loose ends. Please review these ASAP. The -sections with these placeholders are 4.1.1.1, 4.1.2, 4.4, 8, and X.2.]] - -[[Appendix X will be removed before the document is submitted to the -IESG.]] - -[[If consensus is reached on this document, it will be forwarded to the -IESG with the recommendation that it be processed onto the Standards -track.]] - -Copyright Notice - -Copyright (C) The Internet Society (1998). All Rights Reserved. - - Table of Contents - -0. Abstract - -1. Introduction - -2. The SMTP Model -2.1 Basic Structure -2.2 The Extension Model -2.2.1 Background -2.2.2 Definition and Registration of Extensions -2.3 Terminology -2.3.1 Mail Objects -2.3.2 Senders and Receivers -2.3.3 Mail Agents -2.3.4 Host -2.3.5 Domain -2.3.6 Buffer and State Table -2.3.7 Lines -2.3.8 Originator, Delivery, Relay, and Gateway Systems -2.3.9 Message Content and Mail Data -2.3.10 Mailbox and Address -2.3.11 Reply -2.4 Syntax Principles -2.4.1 General Syntax and Transaction Model -2.4.2 Command and Reply Syntax - -3. The SMTP Procedures: An Overview -3.1 Session Initiation -3.2 Client Initiation -3.3 Mail Transactions -3.4 Forwarding for Address Correction or Updating -3.5 Commands for Debugging Addresses -3.5.1 Overview -3.5.2 VRFY Normal Response -3.5.3 Meaning of VRFY or EXPN Success Response -3.5.4 Semantics and Applications of EXPN -3.6 Domains -3.7 Relaying -3.8 Mail Gatewaying -3.8.1 Header Fields in Gatewaying -3.8.2 Received Lines in Gatewaying -3.8.3 Addresses in Gatewaying -3.8.4 Other Header Fields in Gatewaying -3.8.5 Envelopes in Gatewaying -3.9 Terminating Sessions and Connections -3.10 Mailing Lists and Aliases -3.10.1 Alias -3.10.2 List - -4. The SMTP Specifications -4.1 SMTP Commands -4.1.1 Command Semantics and Syntax -4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) -4.1.1.2 MAIL (MAIL) -4.1.1.3 RECIPIENT (RCPT) -4.1.1.4 DATA (DATA) -4.1.1.5 RESET (RSET) -4.1.1.6 VERIFY (VRFY) -4.1.1.7 EXPAND (EXPN) -4.1.1.8 HELP (HELP) -4.1.1.9 NOOP (NOOP) -4.1.1.10 QUIT (QUIT) -4.1.2 Lower-level Syntax -4.1.3 Address Literals -4.1.4 Order of Commands -4.1.5 Private-use Commands -4.2 SMTP Replies -4.2.1 Reply Code Severities and Theory -4.2.2 Reply Codes by Function Groups -4.2.3 Reply Codes in Numeric Order -4.2.4 Reply Code 502 -4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> -4.3 Sequencing of Commands and Replies -4.3.1 Sequencing Overview -4.3.2 Command-Reply Sequences -4.4 Trace Information -4.5 Additional Implementation Issues -4.5.1 Minimum Implementation -4.5.2 Transparency -4.5.3 Sizes and Timeouts -4.5.4 Queuing Strategies -4.5.4.1 Sending Strategy -4.5.4.2 Receiving Strategy - -5. Address Resolution and Mail Handling - -6. Problem Detection and Handling -6.1 Reliable Delivery and Replies by Email -6.2 Loop Detection -6.3 Compensating for Irregularities - -7. Security Considerations -7.1 Mail Security and Spoofing -7.2 "Blind" Copies -7.3 VRFY, EXPN, and Security -7.4 Information Disclosure in Announcements -7.5 Information Disclosure in Trace Fields -7.6 Scope of Operation of SMTP Servers - -8. IANA Considerations - -9. References - -10. Editors' Addresses - -11. Acknowledgments - -A. TCP Transport Service -B. Generating SMTP Commands from RFC 822 Headers -C. Source Routes -D. Scenarios -E. Other Gateway Issues -F. Deprecated Features of RFC 821 -X. Change Summary and Loose Ends (Temporary) - - -0. Abstract - -This document is a self-contained specification of the basic protocol for -the Internet electronic mail transport, consolidating and updating: - - - the original SMTP specification of RFC 821 [RFC-821], - - - domain name system requirements and implications for mail transport from - RFC 1035 [RFC-DNS] and RFC 974 [RFC-974], - - - the clarifications and applicability statements in RFC 1123 [RFC-1123], - and - - - material drawn from the SMTP Extension mechanisms [SMTPEXT]. - -It replaces RFC 821, RFC 974, and the mail transport materials of RFC 1123. -However, RFC 821 specifies some features that are not in significant use in -the Internet of the mid-1990s and (in appendices) some additional transport -models. Those sections are omitted here in the interest of clarity and -brevity; readers needing them should refer to RFC 821. - -It also includes some additional material from RFC 1123 that required -amplification. This material has been identified in multiple ways, mostly -by tracking flaming on various lists and newsgroups and problems of unusual -readings or interpretations that have turned up as the SMTP extensions have -been deployed. Where this specification moves beyond consolidation and -actually differs from earlier documents, it supersedes them technically as -well as textually. - -Although SMTP was designed as a mail transport and delivery protocol, this -specification also contains information that is important to its use as a -"mail posting" protocol, as recommended for POP [RFC-POP2, RFC-POP3] and -IMAP [RFC-IMAP4]. - -Section 2.3 provides definitions of terms specific to this document. Except -when the historical terminology is necessary for clarity, this document -uses the current "client" and "server" terminology to identify the sending -and receiving SMTP processes, respectively. - -A companion document discusses message headers, message bodies and formats -and structures for them, and their relationship - [MSGFMT]. - - -1. Introduction - -The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer -mail reliably and efficiently. - -SMTP is independent of the particular transmission subsystem and requires -only a reliable ordered data stream channel. While this document -specifically discusses transport over TCP, other transports are possible. -Appendices to RFC 821 describe some of them. - -An important feature of SMTP is its capability to transport mail across -transport service environments, usually referred to as "SMTP mail relaying" -(see section 3.8). A transport service environment might consist of the -mutually-TCP-accessible hosts on the public Internet, the -mutually-TCP-accessible hosts on a firewall-isolated private TCP/IP -Intranet, or hosts in some other LAN or WAN environment utilizing a -different transport-level protocol. It is important to realize that -"transport service environments" are one-to-one with usual definitions of -"networks". A process can communicate directly with another process, and -transport mail using this protocol, through any mutually known and -connected transport service. Conversely, mail can be relayed or gatewayed -between processes in two different transport service environments by a -process known and connected to each of the two transport service -environments. The Mail eXchanger mechanisms of the domain name system -[RFC-DNS, and section 5 of this document] allows the identity of hosts -supporting SMTP relay and gateway processes to be specified. - - -2. The SMTP Model - -2.1 Basic Structure - -The SMTP design can be pictured as: - - +----------+ +----------+ - +------+ | | | | - | User |<-->| | SMTP | | - +------+ | Sender- |Commands/Replies| Receiver-| - +------+ | SMTP |<-------------->| SMTP | +------+ - | File |<-->| | and Mail | |<-->| File | - |System| | | | | |System| - +------+ +----------+ +----------+ +------+ - SMTP client SMTP server - -When an SMTP client has a message to transmit, it establishes a two-way -transmission channel to an SMTP server. The role of an SMTP client is to -transfer mail messages to one or more SMTP servers, or report its failure -to do so. - -The means by which a mail message is transferred to an SMTP client, and how -that client determines the domain name(s) to which mail messages are to be -transferred is a local matter, and is not addressed by this document. In -some cases, the domain name(s) transferred to, or determined by, an SMTP -client will identify the final destination(s) of the mail message. In other -cases, common with SMTP clients associated with implementations of the POP -[RFC-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the SMTP client -is inside an isolated transport service environment, the domain name -determined will identify an intermediate destination through which all mail -messages are to be relayed. SMTP clients that transfer all traffic, -regardless of the target domain names associated with the individual -messages, or that do not maintain queues for retrying message transmissions -that initially cannot be completed, may otherwise conform to this -specification but are not considered fully-capable. Fully-capable SMTP -implementations, including the relays used by these less capable ones, and -their destinations, are expected to support all of the queuing, retrying, -and alternate address functions discussed in this specification. - -The means by which an SMTP client, once it has determined a target domain -name, determines the identity of an SMTP server to which a copy of a -message is to be transferred, and then performs that transfer, is covered -by this document. To effect a mail transfer to an SMTP server, an SMTP -client establishes a two-way transmission channel to that SMTP server. An -SMTP client determines the address of an appropriate host running an SMTP -server by resolving a destination domain name to either an intermediate -Mail eXchanger host or a final target host. - -An SMTP server may be either the ultimate destination or an intermediate -"relay" (that is, it may assume the role of an SMTP client after receiving -the message) or "gateway" (that is, it may transport the message further -using some protocol other than SMTP). SMTP commands are generated by the -SMTP client and sent to the SMTP server. SMTP replies are sent from the -SMTP server to the SMTP client in response to the commands. - -Once the transmission channel is established and initial handshaking -completed, the SMTP client normally initiates a mail transaction. Such a -transaction consists of a series of commands to specify the originator and -destination of the mail and transmission of the message content (including -any headers or other structure) itself. When the same message is sent to -multiple recipients, this protocol encourages the transmission of only one -copy of the data for all recipients at the same destination (or -intermediate relay) host. - -The server responds to each command with a reply; replies may indicate that -the command was accepted, that additional commands are expected, or that a -temporary or permanent error condition exists. Commands specifying the -sender or recipients may include server-permitted SMTP service extension -requests as discussed in section 2.2. The dialog is purposely lock-step, -one-at-a-time, although this can be modified by mutually-agreed extension -requests such as in [RFC-Pipeline]. - -Once a given mail message has been transmitted, the client may either -request that the connection be shut down or may initiate other mail -transactions. In addition, an SMTP client may use a connection to an SMTP -server for ancillary services such as verification of email addresses or -retrieval of mailing list subscriber addresses. - -As suggested above, this protocol provides mechanisms for the transmission -of mail. This transmission normally occurs directly from the sending -user's host to the receiving user's host when the two hosts are connected -to the same transport service. When they are not connected to the same -transport service, transmission occurs via one or more relay SMTP servers. -An intermediate host that acts as either an SMTP relay or as a gateway into -some other transmission environment is usually selected through the use of -the domain name service (DNS) Mail eXchanger mechanism. - -To provide relay capability, the SMTP server is supplied with the name of -the ultimate destination host as well as the destination mailbox name. -Usually, intermediate hosts are determined via the DNS MX record, not by -explicit "source" routing (see appendices C and F.2). - -2.2 The Extension Model - -2.2.1 Background - -In an effort that started in 1990, approximately a decade after RFC 821 was -completed, the protocol was modified with a "service extensions" model that -permits the client and server to agree to utilize shared functionality -beyond the original SMTP requirements. The SMTP extension mechanism defines -a means whereby an extended SMTP client and server may recognize each -other, and the server can inform the client as to the service extensions -that it supports. - -Contemporary SMTP implementations MUST support the basic extension -mechanisms. For instance, servers MUST support the EHLO command even if -they do not implement any specific extensions and clients SHOULD -preferentially utilize EHLO rather than HELO. (However, for compatibility -with older conforming implementations, SMTP clients and servers MUST -support the original HELO mechanisms as a fallback.) Unless the different -characteristics of HELO must be identified for interoperability purposes, -this document discusses only EHLO. - -SMTP is widely deployed and high-quality implementations have proven to be -very robust. However, the Internet community now considers some services to -be important that were not anticipated when the protocol was first -designed. If support for those services is to be added, it must be done in -a way that permits older implementations to continue working acceptably. -The extension framework consists of: - - - The SMTP command EHLO, superseding the earlier HELO, - - - a registry of SMTP service extensions, - - - additional parameters to the SMTP MAIL FROM and RCPT TO commands, and - - - optional replacements for verbs defined in this protocol, such as for - DATA (see [RFC-BDAT]). - -SMTP's strength comes primarily from its simplicity. Experience with many -protocols has shown that protocols with few options tend towards ubiquity, -whereas protocols with many options tend towards obscurity. - -Each and every extension, regardless of its benefits, must be carefully -scrutinized with respect to its implementation, deployment, and -interoperability costs. In many cases, the cost of extending the SMTP -service will likely outweigh the benefit. - -2.2.2 Definition and Registration of Extensions - -The IANA maintains a registry of SMTP service extensions. A corresponding -EHLO keyword value is associated with each extension. Each service -extension registered with the IANA must be defined in a formal -standards-track or IESG-approved experimental protocol document. The -definition must include: - - - the textual name of the SMTP service extension; - - - the EHLO keyword value associated with the extension; - - - the syntax and possible values of parameters associated with the - EHLO keyword value; - - - any additional SMTP verbs associated with the extension (additional - verbs will usually be, but are not required to be, the same as the - EHLO keyword value); - - - any new parameters the extension associates with the MAIL FROM or - RCPT TO verbs; - - - a description of how support for the extension affects the behavior - of a server and client SMTP; and, - - - the increment by which the extension is increasing the maximum - length of the commands MAIL FROM and/or RCPT TO, over that specified - in RFC 821. - -In addition, any EHLO keyword value starting with an upper or lower case -"X" refers to a local SMTP service extension used exclusively through -bilateral agreement. Keywords beginning with "X" MUST NOT be used in a -registered service extension. Conversely, keyword values presented in the -EHLO response that do not begin with "X" MUST correspond to a standard, -standards-track, or IESG-approved experimental SMTP service extension -registered with IANA. A conforming server MUST NOT offer non-"X"-prefixed -keyword values that are not described in a registered extension. - -Additional verbs and parameter names are bound by the same rules as EHLO -keywords; specifically, verbs beginning with "X" are local extensions that -may not be registered or standardized. Conversely, verbs not beginning -with "X" must always be registered. - -2.3 Terminology - -Most of the terminology in this document is common in the Internet at the -time of its writing. However, the following terms and concepts are used in -special ways here, or represent differences in terminology between RFC 821 -and this document, and should be understood before reading further. These -definitions are normative, that is, they contain specifications to which -SMTP implementations are required to conform. - -2.3.1 Mail Objects - -SMTP transports a mail object. A mail object contains an envelope and -content. - -The SMTP envelope is sent as a series of SMTP protocol units (described in -section 3). It consists of an originator address (to which error reports -should be directed); a delivery mode (e.g., deliver to recipient -mailboxes); one or more recipient addresses; and optional protocol -extension material. - -The SMTP content is sent in the SMTP DATA protocol unit and has two parts: -the headers and the body. If the content conforms to existing standards, -the headers form a collection of field/value pairs structured as described -in [MSGFMT]; the body, if structured, is defined according to MIME -[RFC-MIME]. The content is textual in nature, expressed using the US-ASCII -repertoire [US-ASCII]. Although SMTP extensions (such as [8BitMIME]) may -relax this restriction for the content body, the content headers are always -encoded using the US-ASCII repertoire. The algorithm defined in -[RFC-INTLHDR] is used to represent header values outside the US-ASCII -repertoire, while still encoding them using the US-ASCII repertoire. - -2.3.2 Senders and Receivers - -In RFC 821, the two hosts participating in an SMTP transaction were -described as the "SMTP-sender" and "SMTP-receiver". This document has been -changed to reflect current industry terminology and hence refers to them as -the "SMTP client" (or sometimes just "the client") and "SMTP server" (or -just "the server"), respectively. Since a given host may act both as -server and client in a relay situation, "receiver" and "sender" terminology -is still used where needed for clarity. - -2.3.3 Mail Agents - -Additional mail system terminology became common after RFC 821 was -published and, where convenient, is used in this specification. In -particular, SMTP servers and clients provide a mail transport service and -therefore act as Mail Transfer Agents (MTAs). Mail User Agents (MUAs or -UAs) are normally thought of as the sources and targets of mail. At the -source, an MUA might collect mail to be transmitted from a user and hand it -off to an MTA; the final ("delivery") MTA would be thought of as handing -the mail off to an MUA (or at least transferring responsibility to it). -However, while these terms are used with at least the appearance of great -precision in other environments, the implied boundaries between MUAs and -MTAs often do not accurately match common, and conforming, practices with -Internet mail. Hence, the reader should be cautious about inferring the -strong relationships and responsibilities that might be implied if these -terms were used elsewhere. - -2.3.4 Host - -For the purposes of this specification, a host is a computer system -attached to the Internet (or, in some cases, to a private TCP/IP network) -and supporting the SMTP protocol. Hosts are known by names (see "domain"); -identifying them by numerical address is discouraged. - -2.3.5 Domain - -A domain (or domain name) consists of one or more dot-separated components, -each consisting of a sequence of letters, digits, and hyphens. Domain -names are used as names of hosts and of other entities in the domain name -hierarchy. For example, a domain may refer to an alias (label of a CNAME -RR) or the label of Mail eXchanger records to be used to deliver mail -instead of representing a host name. See [RFC-DNS] and section 5. - -The domain name, as described in this document and in [RFC-DNS], is the -entire, fully-qualified name (often referred to as an "FQDN"). A domain -name that is not in FQDN form is no more than a local alias. Local aliases -MUST NOT appear in any SMTP transaction. - -2.3.6 Buffer and State Table - -SMTP sessions are stateful, with both parties carefully maintaining a -common view of the current state. In this document we model this state by -a virtual "buffer" and a "state table" on the server which may be used by -the client to, for example, "clear the buffer" or "reset the state table," -causing the information in the buffer to be discarded and the state to be -returned to some previous state - -2.3.7 Lines - -SMTP commands and, unless altered by a service extension, message data, are -transmitted in "lines". Lines consist of zero or more data characters -terminated by the sequence ASCII character "CR" (hex value 0D) followed -immediately by ASCII character "LF" (hex value 0A). This termination -sequence is denoted as <CRLF> in this document. Conforming implementations -MUST NOT recognize or generate any other character or character sequence as -a line terminator. - -2.3.8 Originator, Delivery, Relay, and Gateway Systems - -This specification makes a distinction among four types of SMTP systems, -based on the role those systems play in transmitting electronic mail. An -"originating" system (sometimes called an SMTP originator) introduces mail -into the Internet or, more generally, into a transport service environment. -A "delivery" SMTP system is one that receives mail from a transport service -environment and hands it to a mail user agent or deposits it in a message -store which a mail user agent is expected to subsequently access. A -"relay" SMTP system (usually referred to just as a "relay") receives mail -from an SMTP client and transmits it, without modification to the message -data other than adding trace information, to another SMTP server for -further relaying or for delivery. - -A "gateway" SMTP system (usually referred to just as a "gateway") receives -mail from a client system in one transport environment and transmits it to -a server system in another transport environment. Differences in protocols -or message semantics between the transport environments on either side of a -gateway may require that the gateway system perform transformations to the -message that are not permitted to SMTP relay systems. - -2.3.9 Message Content and Mail Data - -The terms "message content" and "mail data" are used interchangeably in -this document to describe the material transmitted after the DATA command -is accepted and before the end of data indication is transmitted. Message -content includes message headers and the possibly-structured message body. -The MIME specification [RFC-MIME] provides the Standard mechanisms for -structured message bodies. - -2.3.10 Mailbox and Address - -As used in this specification, an "address" is a character string that -identifies a user to whom mail will be sent or a location into which mail -will be deposited. The term "mailbox" refers to that depository. The two -terms are typically used interchangeably unless the distinction between the -location in which mail is placed (the mailbox) and a reference to it (the -address) is important. An address normally consists of user and domain -specifications. The standard mailbox naming convention is defined to be -"local-part@domain": contemporary usage permits a much broader set of -applications than simple "user names" and, consequently, the local-part is -interpreted and assigned semantics only by the host specified in the domain -part of the address. - -2.3.11 Reply - -An SMTP reply is an acknowledgment (positive or negative) sent from -receiver to sender via the transmission channel in response to a command. -The general form of a reply is a numeric completion code (indicating -failure or success) followed by a text string. The codes are for use by -programs and the text is usually intended for human users. - -2.4 Syntax Principles - -2.4.1 General Syntax and Transaction Model - -SMTP commands and replies have a rigid syntax. All commands begin with a -four letter command verb. All Replies begin with a three digit numeric -code. In some commands and replies, arguments MUST follow the verb or reply -code. Some commands do not accept arguments (after the verb), and some -reply codes are followed, sometimes optionally, by free form text. In both -cases, where text appears, it is separated from the verb or reply code by a -<SP>. Complete definitions of commands and replies appear in section 4. - -Verbs and argument values are not case sensitive, with the sole exception -of a mailbox local-part. That is, a command verb, an argument value other -than a mailbox local-part, and free form text MAY be encoded in upper case, -lower case, or any mixture of upper and lower case with no impact on its -meaning. This is NOT true of a mailbox local-part. The local-part of a -mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations -MUST take care to preserve the case of mailbox local-parts. Mailbox -domains are not case sensitive. However, exploiting the case sensitivity -of mailbox local-parts impedes interoperability and is discouraged. - -Commands and replies are composed of characters from the ASCII character -set [US-ASCII]. When the transport service provides an 8-bit byte (octet) -transmission channel, each 7-bit character is transmitted right justified -in an octet with the high order bit cleared to zero. More specifically, the -unextended SMTP service provides seven bit transport only. An originating -SMTP client which has not successfully negotiated an appropriate extension -with a particular server MUST NOT transmit messages with information in the -high-order bit of octets. If such messages are transmitted in violation of -this rule, receiving SMTP servers MAY clear the high-order bit or reject -the message as invalid. In general, a relay SMTP SHOULD assume that the -message content it has received is valid and, assuming that the envelope -permits doing so, relay it without inspecting that content. Of course, if -the content is mislabeled and the data path cannot accept the actual -content, this may result in ultimate delivery of a severely garbled message -to the recipient. Delivery SMTP systems MAY reject ("bounce") such -messages rather than deliver them. No sending SMTP system is permitted to -send envelope commands in any character set other than US-ASCII; receiving -systems SHOULD reject such commands, normally using "500 syntax error - -invalid character" replies. - -Eight-bit message content transmission MAY be requested of the server by a -client using extended SMTP facilities, notably the "8BITMIME" extension -[8BITMIME]. 8BITMIME SHOULD be supported by SMTP servers. However, it MUST -not be construed as authorization to transmit unrestricted eight bit -material. 8BITMIME MUST NOT be requested by senders for material with the -high bit on that is not in MIME format with an appropriate content-transfer -encoding; servers MAY reject such messages. - -The metalinguistic notation used in this document corresponds to the -"Augmented BNF" used in other Internet mail system documents. The reader -who is not familiar with that syntax should consult [ABNF]. Metalanguage -terms used in running text are surrounded by pointed brackets (e.g., -<CRLF>) for clarity. - -2.4.2 Command and Reply Syntax - -The commands consist of a command verb followed by an argument field. -Command verbs are four alphabetic characters and are case insensitive. - -This also applies to any symbols representing parameter values, such as -"TO" or "to" for the forward-path. Command verbs and the argument fields -are separated by one or more spaces. However, case is important in the -local-part within the reverse-path and forward-path arguments. In -particular, for some hosts the user "smith" is different from the user -"Smith". - -A few SMTP servers, in violation of this specification (and RFC 821) -require that command verbs and certain argument text (such as the -forward-path and reverse-path in RCPT and MAIL commands) be encoded by -clients in upper case. Implementations MAY wish to employ this encoding to -accommodate those servers. - -The argument field consists of a variable length character string ending -with the character sequence <CRLF>. The receiver will take no action until -this sequence is received. - -The syntax for each command is shown with the discussion of that command. -Common elements and parameters are shown in section 4.1.2. - - -3. The SMTP Procedures: An Overview - -This section contains descriptions of the procedures used in SMTP: session -initiation, the mail transaction, forwarding mail, verifying mailbox names -and expanding mailing lists, and the opening and closing exchanges. -Comments on relaying, a note on mail domains, and a discussion of changing -roles are included at the end of this section. Several complete scenarios -are presented in appendix D. - -3.1 Session Initiation - -An SMTP session is initiated when a client opens a connection to a server -and the server responds with an opening message. - -SMTP server implementations MAY include identification of their software -and version information in the connection greeting reply after the 220 -code, a practice that permits more efficient isolation and repair of any -problems. Implementations MAY make provision for SMTP servers to disable -the software and version announcement where it causes security concerns. -While some systems also identify their contact point for mail problems, -this is not a substitute for maintaining the required "postmaster" address -(see [MSGFMT]). - -The SMTP protocol allows a server to formally reject a transaction while -still allowing the initial connection as follows: a 554 response MAY be -given in the initial connection opening message instead of the 220. A -server taking this approach MUST still wait for the client to send a QUIT -(see section 4.1.1.10) before closing the connection and SHOULD respond to -any intervening commands with "503 bad sequence of commands". Since an -attempt to make an SMTP connection to such a system is probably in error, a -server returning a 554 response on connection opening SHOULD provide enough -information in the reply text to facilitate debugging of the sending -system. - -3.2 Client Initiation - -Once the server has sent the welcoming message and the client has received -it, the client then sends the EHLO command to the server, indicating the -client's identity. In addition to opening the session, use of EHLO -indicates that the client is able to process service extensions and -requests that the server provide a list of the extensions it supports. -Older SMTP systems, unable to support service extensions, MAY use HELO -instead of EHLO. Servers MUST NOT return the extended EHLO-style response -to a HELO command. - -In the EHLO command the host sending the command identifies itself; the -command may be interpreted as saying "Hello, I am <domain>" (and, in the -case of EHLO, "and I support service extension requests"). - -3.3 Mail Transactions - -There are three steps to SMTP mail transactions. The transaction starts -with a MAIL command which gives the sender identification. A series of one -or more RCPT commands follows giving the receiver information. Then a DATA -command initiates transfer of the mail data and is terminated by the "end -of mail" data indicator, which also confirms the transaction. - -The first step in the procedure is the MAIL command. - - MAIL <SP> FROM:<reverse-path> [ <SP> <mail-parameters> ] <CRLF> - -This command tells the SMTP-receiver that a new mail transaction is -starting and to reset all its state tables and buffers, including any -recipients or mail data. The <reverse-path> contains the source mailbox, -which can be used to report errors (see section 4.2 for a discussion of -error reporting). If accepted, the SMTP server returns a 250 OK reply. If -the mailbox specification is not acceptable for some reason, the server -MUST return a reply indicating whether the failure is permanent (i.e., will -occur again if the client tries to send the same address again) or -temporary (i.e., the address might be accepted if the client tries again -later). Despite the apparent scope of this requirement, there are -circumstances in which the acceptability of the reverse-path may not be -determined until one or more forward-paths (in RCPT commands) can be -examined. In those cases, the server MAY reasonably accept the -reverse-path (with a 250 reply) and then report problems after the -forward-paths are received and examined. Normally, failures produce 550 or -553 replies. - -Historically, the <reverse-path> can contain more than just a mailbox, -however, contemporary systems SHOULD NOT use source routing (see appendix -C). - -The optional <mail-parameters> are associated with negotiated SMTP service -extensions (see section 2.2). - -The second step in the procedure is the RCPT command. - - RCPT <SP> TO:<forward-path> [ <SP> <rcpt-parameters> ] <CRLF> - -This command gives a forward-path (normally a mailbox and domain) -identifying one recipient. If accepted, the SMTP server returns a 250 OK -reply and stores the forward-path. If the recipient is known not to be a -deliverable address, the SMTP server returns a 550 reply, typically with a -string such as "no such user - " and the mailbox name (other circumstances -and reply codes are possible). This step of the procedure can be repeated -any number of times. - -The <forward-path> can contain more than just a mailbox. Historically, the -<forward-path> can be a source routing list of hosts and the destination -mailbox, however, contemporary SMTP clients SHOULD NOT utilize source -routes (see appendix C). Servers MUST be prepared to encounter a list of -source routes in the forward path, but SHOULD ignore the routes or MAY -decline to support the relaying they imply. Similarly, servers MAY decline -to accept mail that is destined for other hosts or systems. These -restrictions make a server useless as a relay for clients that do not -support full SMTP functionality. Consequently, restricted-capability -clients MUST NOT assume that any SMTP server on the Internet can be used as -their mail processing (relaying) site. If RCPT TO appears without a -previous MAIL FROM, the server MUST return a 503 "Bad sequence of commands" -response. The optional <rcpt-parameters> are associated with negotiated -SMTP service extensions (see section 2.2). - -The third step in the procedure is the DATA command (or some alternative -specified in a service extension). - - DATA <CRLF> - -If accepted, the SMTP server returns a 354 Intermediate reply and considers -all succeeding lines up to but not including the end of mail data indicator -to be the message text. When the end of text is successfully received and -stored the SMTP-receiver sends a 250 OK reply. - -Since the mail data is sent on the transmission channel, the end of mail -data must be indicated so that the command and reply dialog can be resumed. -SMTP indicates the end of the mail data by sending a line containing only a -"." (period or full stop). A transparency procedure is used to prevent -this from interfering with the user's text (see section 4.5.2). - -The end of mail data indicator also confirms the mail transaction and tells -the SMTP server to now process the stored recipients and mail data. If -accepted, the SMTP server returns a 250 OK reply. The DATA command can fail -in only two ways: - - - If there was no MAIL FROM, or no RCPT TO, command, or all such commands - were rejected, the server MAY return a "command out of sequence" (503) - reply. If that reply is received, the client MUST NOT send the message - data; more generally, message data MUST NOT be sent unless a 354 reply - is received. - - - If the verb is initially accepted and the 354 reply issued, the DATA - command should fail only if the mail transaction was incomplete (for - example, no recipients), or if resources were unavailable. - -However, in practice, some servers do not perform recipient verification -until after the message text is received. These servers SHOULD treat a -failure for one or more recipients as a "subsequent failure" and return a -mail message as discussed in section 6. Using a "550 mailbox not found" -(or equivalent) reply code after the data are accepted makes it difficult -or impossible for the client to determine which recipients failed. - -When RFC 822 format is being used, the mail data include the memo header -items such as Date, Subject, To, Cc, From [MSGFMT]. Server SMTP systems -SHOULD NOT reject messages based on perceived defects in the RFC 822 or -MIME [RFC-MIME] message header or message body. In particular, they MUST -NOT reject messages in which the numbers of Resent- fields do not match or -Resent-to appears without Resent-from and/or Resent-date. - -Mail transaction commands MUST be used in the order discussed above. - -3.4 Forwarding for Address Correction or Updating - -Forwarding support is most often required to consolidate and simplify -addresses within, or relative to, some enterprise and less frequently to -establish addresses to link a person's prior address with current one. -Silent forwarding of messages (without server notification to the sender), -for security or non-disclosure purposes, is common in the contemporary -Internet. - -In both the enterprise and the "new address" cases, information -hiding (and sometimes security) considerations argue against exposure -of the "final" address through the SMTP protocol as a side-effect of -the forwarding activity. This may be especially important when the -final address may not even be reachable by the sender. Consequently, -the "forwarding" mechanisms described in section 3.2 of RFC 821, and -especially the 251 (corrected destination) reply code from RCPT TO -are deprecated: Servers SHOULD NOT provide that service or return -that code. - -3.5 Commands for Debugging Addresses - -3.5.1 Overview - -SMTP provides commands to verify a user name or obtain the content of a -mailing list. This is done with the VRFY and EXPN commands, which have -character string arguments. Implementations MUST support VRFY and SHOULD -support EXPN (however, see section 3.5.2 and 7.3). - -For the VRFY command, the string is a user name or a user name and domain -(see below). If a normal (i.e., 250) response is returned, the response MAY -include the full name of the user and MUST include the mailbox of the user. -It MUST be in either of the following forms: - - User Name <local-part@domain> - local-part@domain - -When a name that is the argument to VRFY could identify more than one -mailbox, the server MAY either note the ambiguity or identify the -alternatives. In other words, any of the following are legitimate -response to VRFY: - - 553 User ambiguous - -or - - 553- Ambiguous; Possibilities are - 553-Joe Smith <jsmith@foo.com> - 553-Harry Smith <hsmith@foo.com> - 553 Melvin Smith <dweep@foo.com> - -or - - 553-Ambiguous; Possibilities - 553- <jsmith@foo.com> - 553- <hsmith@foo.com> - 553 <dweep@foo.com> - -Under normal circumstances, a client receiving a 553 reply would be -expected to expose the result to the user. Use of exactly the forms given, -and the "user ambiguous" or "ambiguous" keywords, possibly supplemented by -extended reply codes as described in [RFC-REPLY], will facilitate automated -translation into other languages as needed. Of course, a client that was -highly automated or that was operating in another language than English, -might choose to try to translate the response, to return some other -indication to the user than the literal text of the reply, or to take some -automated action such as consulting a directory service for additional -information before reporting to the user. - -For the EXPN command, the string identifies a mailing list, and the -successful (i.e., 250) multiline response MAY include the full name of the -users and MUST give the mailboxes on the mailing list. - -In some hosts the distinction between a mailing list and an alias for a -single mailbox is a bit fuzzy, since a common data structure may hold both -types of entries, and it is possible to have mailing lists of one mailbox. -If a request is made to verify a mailing list, a positive response MAY be -given if a message so addressed would be delivered to everyone on the list, -otherwise an error SHOULD be reported (e.g., "550 That is a mailing list, -not a user" or "252 Unable to verify members of mailing list"). If a -request is made to expand a user name, the server MAY return a positive -response consisting of a list containing one name, or an error MAY be -reported (e.g., "550 That is a user name, not a mailing list"). - -In the case of a successful multiline reply (normal for EXPN) exactly one -mailbox is to be specified on each line of the reply. The case of an -ambiguous request is discussed above. - -"User name" is a fuzzy term and has been used deliberately. An -implementation of the VRFY or EXPN commands MUST include at least -recognition of local mailboxes as "user names". However, since current -Internet practice often results in a single host handling mail for multiple -domains, hosts, especially hosts that provide this functionality, SHOULD -accept the "local-part@domain" form as a "user name"; hosts MAY also choose -to recognize other strings as "user names". - -The case of expanding a mailbox list requires a multiline reply, such as: - - C: EXPN Example-People - S: 250-Jon Postel <Postel@isi.edu> - S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu> - S: 250 Sam Q. Smith <SQSmith@specific.generic.com> - -or - - C EXPN Executive-Washroom-List - S: 550 Access Denied to You. - -The character string arguments of the VRFY and EXPN commands cannot be -further restricted due to the variety of implementations of the user name -and mailbox list concepts. On some systems it may be appropriate for the -argument of the EXPN command to be a file name for a file containing a -mailing list, but again there are a variety of file naming conventions in -the Internet. Similarly, historical variations in what is returned by -these commands are such that the response SHOULD be interpreted very -carefully, if at all, and SHOULD generally only be used for diagnostic -purposes. - -3.5.2 VRFY Normal Response - -When normal (2yz or 551) responses are returned from a VRFY or EXPN -request, the reply MUST normally include the mailbox name. -"<local-part@domain>", where "domain" is a fully qualified domain name, -MUST appear in the syntax. In exceptional circumstances, free-form text -MAY be returned. In order to facilitate parsing by both computers and -people, addresses SHOULD appear in pointed brackets. When addresses, -rather than free-form debugging information, are returned, EXPN and VRFY -MUST return only valid domain addresses that are usable in SMTP RCPT -commands. Consequently, if an address implies delivery to a program or -other system, the mailbox name used to reach that target MUST be given. -Paths (explicit source routes) MUST NOT be returned by VRFY or EXPN. - -Server implementations MUST support VRFY and SHOULD support EXPN. For -security reasons, implementations MAY provide local installations a way to -disable either or both of these commands through configuration options or -the equivalent. When these commands are supported, they are not required -to work across relays when relaying is supported. Since they were both -optional in RFC 821, they MUST be listed as service extensions in an EHLO -response, if they are supported. - -3.5.3 Meaning of VRFY or EXPN Success Response - -A server MUST NOT return a 220 code in response to a VRFY or EXPN command -unless it has actually verified the address. In particular, a server MUST -NOT return 220 if all it has done is to verify that the syntax given is -valid. In that case, 502 (Command not implemented) or 500 (Syntax error, -command unrecognized) SHOULD be returned. As stated elsewhere, -implementation of VRFY is required and EXPN is strongly recommended. -Hence, implementations that return 500 or 502 for VRFY are not in -compliance with this specification. - -There may be circumstances where an address appears to be valid but cannot -reasonably be verified in real time, particularly when a server is acting -as a mail exchanger for another server or domain. "Apparent validity" in -this case would normally involve at least syntax checking and might involve -verification that any domains specified were ones to which the host -expected to be able to relay mail. In these situations, reply code 252 -SHOULD BE returned. These cases parallel the discussion of RCPT -verification discussed in section 2.1 Implementations generally SHOULD be -more aggressive about address verification in the case of VRFY than in the -case of RCPT, even if it takes a little longer to do so. - -3.5.4 Semantics and Applications of EXPN - -EXPN is often very useful in debugging and understanding problems with -mailing lists and multiple-target-address aliases. Some systems have -attempted to use source expansion of mailing lists as a means of -eliminating duplicates. The propagation of aliasing systems with mail on -the Internet, both for hosts (typically with MX and CNAME DNS records) and -for mailboxes (various types of local host aliases), has made it nearly -impossible for these strategies to work, and mail systems SHOULD NOT -attempt them. - -3.6 Domains - -Only resolvable, fully-qualified, domain names (FQDNs) are permitted when -domain names are used in SMTP. In other words, names that can be resolved -to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME -RRs whose targets can be resolved, in turn, to MX or A RRs. Local -nicknames or unqualified names MUST NOT be used. There are two exceptions -to the rule requiring FQDNs: - - - The domain name given in the EHLO command MUST BE either a primary host - name (a domain name that resolves to an A RR) or, if the host has no - name, an address literal as described in section 4.1.1.1. - - - The reserved mailbox name "postmaster" may be used in a RCPT TO command - without domain qualification (see section 4.1.1.3) and MUST be accepted - if so used. - -3.7 Relaying - -In general, the availability of Mail eXchanger records in the domain name -system [RFC-DNS] makes the use of explicit source routes in the Internet -mail system unnecessary. Many historical problems with their -interpretation have made their use undesirable. SMTP clients SHOULD NOT -generate explicit source routes except under unusual circumstances. SMTP -servers MAY decline to act as mail relays or to accept addresses that -specify source routes. When route information is encountered, they are -also permitted to ignore the route information and simply send to the final -destination specified as the last element in the route and SHOULD do so. -There has been an invalid practice of using names that do not appear in the -DNS as destination names, with the senders counting on the intermediate -hosts specified in source routing to resolve any problems. If source -routes are stripped, this practice will cause failures. This is one of -several reasons why SMTP clients MUST NOT generate invalid source routes or -depend on serial resolution of names. - -When source routes are not used, the process described in RFC 821 for -constructing a reverse-path from the forward-path is not applicable and the -reverse-path at the time of delivery will simply be the address that -appeared in the MAIL command. - -A relay SMTP server is usually the target of a DNS MX record that -designates it, rather than the final delivery system. The relay server may -accept or reject the task of relaying the mail in the same way it accepts -or rejects mail for a local user. If it accepts the task, it then becomes -an SMTP client, establishes a transmission channel to the next SMTP server -specified in the DNS (according to the rules in section 5), and sends it -the mail. If it declines to relay mail to a particular address for policy -reasons, a 571 response MAY be returned. - -If an SMTP server has accepted the task of relaying the mail and later -finds that the destination is incorrect or that the mail cannot be -delivered for some other reason, then it MUST construct an "undeliverable -mail" notification message and send it to the originator of the -undeliverable mail (as indicated by the reverse-path). Formats specified -for non-delivery reports by other standards (see, for example, -[RFC-NOTARY1]) SHOULD be used if possible. - -This notification message must be from the SMTP server at the relay host or -the host that first determines that delivery cannot be accomplished. Of -course, SMTP servers MUST NOT send notification messages about problems -transporting notification messages. One way to prevent loops in error -reporting is to specify a null reverse-path in the MAIL command of a -notification message. When such a message is transmitted the reverse-path -MUST be set to null. A MAIL command with a null reverse-path appears as -follows: - - MAIL FROM:<> - -As discussed in section 2.4.1, a relay SMTP has no need to inspect or act -upon the headers or body of the message data and MUST NOT do so except -to add its own "Received:" header (section 4.4) and to perform simple -counting of the number of "Received:" headers in a message (section 6.2). - -3.8 Mail Gatewaying - -While the relay function discussed above operates within the Internet SMTP -transport service environment, MX records or various forms of explicit -routing may require that an intermediate SMTP server perform a translation -function between one transport service and another. As discussed in -section 2.3.8, when such a system is at the boundary between two transport -service environments, we refer to it as a "gateway" or "gateway SMTP". - -Gatewaying mail between different mail environments, such as different mail -formats and protocols, is complex and does not easily yield to -standardization. However, some general requirements may be given for a -gateway between the Internet and another mail environment. - -3.8.1 Header Fields in Gatewaying - -Header fields MAY be rewritten when necessary as messages are gatewayed -across mail environment boundaries. This may involve inspecting the message -body or interpreting the local-part of the destination address in spite of -the prohibitions in section 2.4.1 - -Other mail systems gatewayed to the Internet often use a subset of RFC-822 -headers or provide similar functionality with a different syntax, but some -of these mail systems do not have an equivalent to the SMTP envelope. -Therefore, when a message leaves the Internet environment, it may be -necessary to fold the SMTP envelope information into the message header. A -possible solution would be to create new header fields to carry the -envelope information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, -this would require changes in mail programs in foreign environments and -might risk disclosure of private information (see section 7.2). - -3.8.2 Received Lines in Gatewaying - -When forwarding a message into or out of the Internet environment, a -gateway MUST prepend a Received: line, but it MUST NOT alter in any way a -Received: line that is already in the header. - -Received: fields of messages originating from other environments may not -conform exactly to this specification. However, the most important use of -Received: lines is for debugging mail faults, and this debugging can be -severely hampered by well-meaning gateways that try to "fix" a Received: -line. As another consequence of trace fields arising in non-SMTP -environments, receiving systems MUST NOT reject mail based on the format of -a trace field and SHOULD be extremely robust in the light of unexpected -information or formats in those fields. - -The gateway SHOULD indicate the environment and protocol in the "via" -clauses of Received field(s) that it supplies. - -3.8.3 Addresses in Gatewaying - ->From the Internet side, the gateway SHOULD accept all valid address formats -in SMTP commands and in RFC-822 headers, and all valid RFC-822 messages. -Gateways are, of course, subject to the same rules for handling source -routes as those described for other SMTP systems in section 3.3. - -3.8.4 Other Header Fields in Gatewaying - -The gateway MUST ensure that all header fields of a message that it -forwards into the Internet meet the requirements for Internet mail. In -particular, all addresses in "From:", "To:", "Cc:", etc., fields MUST be -transformed (if necessary) to satisfy RFC-822 syntax, MUST reference only -fully-qualified domain names, and MUST be effective and useful for sending -replies. 3.8.5 The translation algorithm used to convert mail from the -Internet protocols to another environment's protocol SHOULD ensure that -error messages from the foreign mail environment are delivered to the -return path from the SMTP envelope, not to the sender listed in the "From:" -field (or other fields) of the RFC-822 message. - -3.8.5 Envelopes in Gatewaying - -Similarly, when forwarding a message from another environment into the -Internet, the gateway SHOULD set the envelope return path in accordance -with an error message return address, if supplied by the foreign -environment. If the foreign environment has no equivalent concept, the -gateway must select and use a best approximation, with the message -originator's address as the default of last resort. - -3.9 Terminating Sessions and Connections - -An SMTP connection is terminated when the client sends a QUIT command. The -server responds with a positive reply code, after which it closes the -connection. - -An SMTP server MUST NOT intentionally close the connection except: - - - After receiving a QUIT command and responding with a 221 reply. - - - After detecting the need to shutdown the SMTP service and returning a - 421 response code. This response code can be issued after the server - receives any command or, if necessary, asynchronously from command - receipt (on the assumption that the client will receive it after the - next command is issued). - -In particular, a server that closes connections in response to commands -that are not understood is in violation of this specification. Servers are -expected to be tolerant of unknown commands, issuing a 500 reply and -awaiting further instructions from the client. - -An SMTP server which is forcibly shut down via external means SHOULD -attempt to send a line containing a 421 response code to the SMTP client -before exiting. The SMTP client will normally read the 421 response code -after sending its next command. - -SMTP clients that experience a connection close, reset, or other -communications failure due to circumstances not under their control (in -violation of the intent of this specification but sometimes unavoidable) -SHOULD, to maintain the robustness of the mail system, treat the mail -transaction as if a 451 response had been received and act accordingly. - -3.10 Mailing Lists and Aliases - -An SMTP-capable host SHOULD support both the alias and the list form of -address expansion for multiple delivery. When a message is delivered or -forwarded to each address of an expanded list form, the return address in -the envelope ("MAIL FROM:") MUST be changed to be the address of a person -or other entity who administers the list. However, in this case, the -message header (see [MSGFMT]) MUST be left unchanged; in particular, the -"From" field of the message header is unaffected. - -An important mail facility is a mechanism for multi-destination delivery of -a single message, by transforming or "expanding" a pseudo-mailbox address -into a list of destination mailbox addresses. When a message is sent to -such a pseudo-mailbox (sometimes called an "exploder"), copies are -forwarded or redistributed to each mailbox in the expanded list. We -classify such a pseudo-mailbox as an "alias" or a "list", depending upon -the expansion rules. - -3.10.1 Alias - -To expand an alias, the recipient mailer simply replaces the pseudo-mailbox -address in the envelope with each of the expanded addresses in turn; the -rest of the envelope and the message body are left unchanged. The message -is then delivered or forwarded to each expanded address. - -3.10.2 List - -A mailing list may be said to operate by "redistribution" rather than by -"forwarding". To expand a list, the recipient mailer replaces the -pseudo-mailbox address in the envelope with each of the expanded addresses -in turn. The return address in the envelope is changed so that all error -messages generated by the final deliveries will be returned to a list -administrator, not to the message originator, who generally has no control -over the contents of the list and will typically find error messages -annoying. - - -4. The SMTP Specifications - -4.1 SMTP Commands - -4.1.1 Command Semantics and Syntax - -The SMTP commands define the mail transfer or the mail system function -requested by the user. SMTP commands are character strings terminated by -<CRLF>. The commands themselves are alphabetic characters terminated by -<SP> if parameters follow and <CRLF> otherwise. (In the interest of -improved interoperability, SMTP receivers are encouraged to tolerate -trailing white space before the terminating <CRLF>.) The syntax of the -local part of a mailbox must conform to receiver site conventions and the -syntax specified in section 4.1.2. The SMTP commands are discussed below. -The SMTP replies are discussed in section 4.2. - -A mail transaction involves several data objects which are communicated as -arguments to different commands. The reverse-path is the argument of the -MAIL command, the forward-path is the argument of the RCPT command, and the -mail data is the argument of the DATA command. These arguments or data -objects must be transmitted and held pending the confirmation communicated -by the end of mail data indication which finalizes the transaction. The -model for this is that distinct buffers are provided to hold the types of -data objects, that is, there is a reverse-path buffer, a forward-path -buffer, and a mail data buffer. Specific commands cause information to be -appended to a specific buffer, or cause one or more buffers to be cleared. - -4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) - -These commands are used to identify the SMTP client to the SMTP server. -The argument field contains the fully-qualified domain name of the SMTP -client if one is available. In situations in which the SMTP client system -does not have a meaningful domain name (e.g., when its address is -dynamically allocated and no reverse mapping record is available), the -client SHOULD send an address literal (see section 4.1.3), optionally -followed by information that will help to identify the client system. - -The SMTP server identifies itself to the SMTP client in the connection -greeting reply and in the response to this command. - -A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If -the SMTP server supports the SMTP service extensions it will give a -successful response, a failure response, or an error response. If the SMTP -server, in violation of this specification, does not support any SMTP -service extensions it will generate an error response. Older client SMTP -systems MAY, as discussed above, use HELO (as specified in RFC 821) instead -of EHLO, and servers MUST support the HELO command and reply properly to -it. In any event, a client MUST issue HELO or EHLO before starting a mail -transaction. - -These commands, and a "250 OK" reply to one of them, confirm that both the -SMTP client and the SMTP server are in the initial state, that is, there is -no transaction in progress and all state tables and buffers are cleared. - -Normally, the response to EHLO will be a multiline reply. Each line of the -response contains a keyword and, optionally, one or more parameters. The -syntax for a positive response, using the ABNF notation and low-level -terminals of [ABNF], is: - - ehlo-ok-rsp ::= "250" domain [ <SP> greeting ] <CRLF> - / ( "250-" domain [ <SP> greeting ] <CRLF> - *( "250-" ehlo-line <CRLF> ) - "250" <SP> ehlo-line <CRLF> ) - - greeting ::= 1*<any character other than CR or LF> - - ehlo-line ::= ehlo-keyword *( <SP> ehlo-param ) - - ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") - ; syntax and values depend on ehlo-keyword - - ehlo-param ::= 1*<any CHAR excluding <SP> and all - control characters (US-ASCII 0-31 - inclusive)> - - <<xxx ALPHA ::= <any one of the 52 alphabetic characters >> - << (A through Z in upper case, and, >> - << a through z in lower case) >> - -Although EHLO keywords may be specified in upper, lower, or mixed case, -they MUST always be recognized and processed in a case-insensitive manner. -This is simply an extension of practices specified in RFC 821 and section -2.4.1. - -4.1.1.2 MAIL (MAIL) - -This command is used to initiate a mail transaction in which the mail data -is delivered to one or more mailboxes. The argument field contains a -reverse-path. - -The reverse-path consists of the sender mailbox or a list of hosts. In -some types of reporting messages for which a reply is likely to cause a -mail loop (for example, mail delivery and nondelivery notifications), the -reverse-path may be null (see section 3.7). - -This command clears the reverse-path buffer, the forward-path buffer, and -the mail data buffer; and inserts the reverse-path information from this -command into the reverse-path buffer. - -If service extensions were negotiated, the MAIL command may also carry -parameters associated with a particular service extension. - -Syntax: - "MAIL FROM:" Reverse-path [ <SP> Mail-parameters ] -or - "MAIL FROM:<>" [ <SP> Mail-parameters ] - -4.1.1.3 RECIPIENT (RCPT) - -This command is used to identify an individual recipient of the mail data; -multiple recipients are specified by multiple use of this command. - -The forward-path normally consists of the required destination mailbox or -mailboxes. Sending systems SHOULD not generate the optional list of hosts -known as a source route. Receiving systems MUST recognize source route -syntax but SHOULD strip off the source route specification and utilize the -domain name associated with the mailbox as if the source route had not been -provided. - -Similarly, relay hosts SHOULD strip or ignore source routes, and names MUST -NOT be copied into the reverse-path. When mail reaches its ultimate -destination (the forward-path contains only a destination mailbox), the -SMTP server inserts it into the destination mailbox in accordance with its -host mail conventions. - -For example, mail received at relay host xyz.com with envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> - -will normally be sent directly on to host d.bar.org with envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<USERC@D.bar.org> - -As provided in appendix C, xyz.com MAY also choose to relay the message to -jkl.org, using the envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@jkl.org:userc@d.bar.org> - -Of course, since hosts are not required to relay mail at all, xyz.com may -also reject the message entirely when the RCPT TO command is received, -using a 550 code (since this is a "policy reason"). - -If service extensions were negotiated, the RCPT TO command may also carry -parameters associated with a particular service extension offered by the -server. The client MUST NOT transmit parameters other than those -associated with a service extension offered by the server in its EHLO -response. - -Syntax: - "RCPT TO:" Forward-path [ <SP> Rcpt-parameters ] -or - "RCPT TO:<Postmaster>" [ <SP> Rcpt-parameters ] - -4.1.1.4 DATA (DATA) - -The receiver treats the lines (strings ending in <CRLF> sequences, as -described in section 2.3.7) following the command as mail data from the -sender. This command causes the mail data to be appended to the mail data -buffer. The mail data may contain any of the 128 ASCII character codes, -although experience has indicated that use of control characters other than -SP, HT, CR, and LF (especially the ASCII "Null" character) may cause -problems and SHOULD be avoided when possible. - -The mail data is terminated by a line containing only a period, that is, -the character sequence "<CRLF>.<CRLF>" (see section 4.5.2). This is the -end of mail data indication. Note that the first <CRLF> of this -terminating sequence is also the <CRLF> that ends the final line of the -data (message text) or, if there was no data, ends the DATA command itself. -An extra <CRLF> MUST NOT be added, as that would cause an empty line to be -added to the message. The only exception to this rule would arise if the -message body were passed to the originating SMTP-sender with a final "line" -that did not end in <CRLF>; in that case, the originating SMTP system MUST -either reject the message as invalid or add <CRLF> in order to have the -receiving SMTP server recognize the "end of data" condition. - -The custom of accepting lines ending only in <LF>, as a concession to -non-conforming behavior on the part of some UNIX systems, has proven to -cause more interoperability problems than it solves, and SMTP server -systems MUST NOT do this, even in the name of improved robustness. In -particular, the sequence "<LF>.<LF>" (bare line feeds, without carriage -returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end of -mail data indication. - -Receipt of the end of mail data indication requires the server to process -the stored mail transaction information. This processing consumes the -information in the reverse-path buffer, the forward-path buffer, and the -mail data buffer, and on the completion of this command these buffers are -cleared. If the processing is successful, the receiver MUST send an OK -reply. If the processing fails the receiver MUST send a failure reply. The -SMTP model does not allow for partial failures at this point: either the -message is accepted by the server for delivery and a positive response is -returned or it is not accepted and a failure reply is returned. Errors -that are diagnosed subsequently MUST be reported in a mail message, as -discussed in section 4.4 In sending a positive completion reply to the end -of data indication, the receiver takes full responsibility for the message -(see section 6.1). - -When the SMTP server accepts a message either for relaying or for final -delivery, it inserts a trace record (also referred to interchangeably as a -"time stamp line" or "Received" line) at the top of the mail data. This -trace record indicates the identity of the host that sent the message, the -identity of the host that received the message (and is inserting this time -stamp), and the date and time the message was received. Relayed messages -will have multiple time stamp lines. Details for formation of these lines, -including their syntax, is specified in section 4.4. - -4.1.1.5 RESET (RSET) - -This command specifies that the current mail transaction will be aborted. -Any stored sender, recipients, and mail data MUST be discarded, and all -buffers and state tables cleared. The receiver MUST send a "250 OK" reply -to a RSET command with no arguments. A reset command may be issued by the -client at any time. It is effectively equivalent to a NOOP if issued -immediately after EHLO, before EHLO is issued in the session, after an -end-of-data indicator has been sent and acknowledged, or immediately before -a QUIT. In other situations, it restores the state to that immediately -after the most recent EHLO. An SMTP server MUST NOT close the connection -as the result of receiving a RSET; that action is reserved for QUIT (see -section 4.1.1.10). - -Since EHLO implies some additional processing and response by the server, -RSET will normally be more efficient than reissuing that command, even -though the formal semantics are the same. - -There are circumstances, contrary to the intent of this specification, in -which an SMTP server may receive an indication that the underlying TCP -connection has been closed or reset. To preserve the robustness of the -mail system, SMTP servers SHOULD be prepared for this condition and SHOULD -treat it as if a QUIT had been received before the connection disappeared. - -Syntax: - "RSET" - -4.1.1.6 VERIFY (VRFY) - -This command asks the receiver to confirm that the argument identifies a -user or mailbox. If it is a user name, information is returned as -specified in section 3.5. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -Syntax: - "VRFY" <SP> String - -4.1.1.7 EXPAND (EXPN) - -This command asks the receiver to confirm that the argument identifies a -mailing list, and if so, to return the membership of that list. If the -command is successful, a reply is returned containing information as -described in section 3.5. This reply will have multiple lines except in -the trivial case of a one-member list. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -Syntax: - "EXPN" <SP> String - -4.1.1.8 HELP (HELP) - -This command causes the server to send helpful information to the client. -The command MAY take an argument (e.g., any command name) and return more -specific information as a response. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -SMTP servers SHOULD support HELP without arguments and MAY support it with -arguments. - -Syntax: - "HELP" [ <SP> String ] - -4.1.1.9 NOOP (NOOP) - -This command does not affect any parameters or previously entered commands. -It specifies no action other than that the receiver send an OK reply. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -Syntax: - "NOOP" [ <SP> String ] - -4.1.1.10 QUIT (QUIT) - -This command specifies that the receiver MUST send an OK reply, and then -close the transmission channel. - -The receiver MUST NOT intentionally close the transmission channel until it -receives and replies to a QUIT command (even if there was an error). The -sender MUST NOT intentionally close the transmission channel until it sends -a QUIT command and receives the reply (even if there was an error response -to a previous command). If the connection is closed prematurely due to -violations of the above or system or network failure, the server MUST -cancel any pending transaction, but not undo any previously completed -transaction, and generally MUST act as if the command or transaction in -progress had received a temporary error (i.e., a 4yz response). - -Syntax: - "QUIT" - -4.1.2 Lower-level Syntax - -The syntax of the argument fields of the above commands (using the syntax -specified in [ABNF] where applicable) is given below. Some of the -productions given below are used only in conjunction with source routes as -described in appendix C. Terminals not defined in this document, such as -ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the "core" syntax -(section 6) of [ABNF] or in the syntax of [MSGFMT]. - - Reverse-path = Path - - Forward-path = Path - - Path = "<" [ A-d-l ":" ] Mailbox ">" - - A-d-l = At-domain *( "," A-d-l ) ; Note that this form, the - so-called "source route", MUST BE - accepted, SHOULD NOT be generated, - and SHOULD be ignored. - - At-domain = "@" Domain - - Mail-parameters = *( <SP> Keyword "=" Argument ) - - Rcpt-parameters = *( <SP> Keyword "=" Argument ) - - Keyword = Ldh-str - Argument = Atom - - Domain = sub-domain 1*("." sub-domain) / address-literal - - sub-domain = let-dig *(Ldh-str) - address-literal = "[" IPv4-address-literal / - IPv6-address-literal / General-address-literal "]" - IPv4-address-literal = snum 3*3("." snum) - IPv6-address-literal = "IPv6" <SP> IPv6-addr-string - IPv6-addr-string = String ; IPv6 address in standard form - [IPv6AddrSpec]. Since this - form uses colon characters, - the String will actually need - to be quoted in all cases. - General-address-literal = Standardized-tag <SP> String - Standardized-tag = Ldh-str ; Specified in a - standards-track RFC - and registered with IANA - snum = 1*3Digit ; representing a decimal integer - value in the range 0 through 255 - let-dig = Alpha / Digit - ldh-str = *( Alpha / Digit / "-" ) let-dig - - Mailbox = Local-part "@" Domain - - Local-part = Dot-string / Quoted-string - - Dot-string = Atom [ "." Atom ] - -While the above definition for Local-part is relatively permissive, for -maximum interoperability, a host that expects to receive mail SHOULD avoid -defining mailboxes where the Local-part requires (or uses) the -Quoted-string form or where the Local-part is case-sensitive. For any -purposes that require generating or comparing Local-parts (e.g., to -specific mailbox names), all quoted forms MUST be treated as equivalent and -the sending system SHOULD transmit the form that uses the minimum quoting -possible. - -Systems MUST NOT define mailboxes in such a way as to require the use of -non-ASCII characters (octets with the high order bit set to one) or ASCII -"control characters" (decimal value 0-31 and 127). These characters MUST -NOT be used in MAIL FROM or RCPT TO commands or other commands that require -mailbox names. - - String = Atom / Quoted-string - - special = <<Msg-fmt-special>> / [[placeholder, see above]] - the control characters (ASCII codes 0 through 31 - inclusive and 127) - -Note that the backslash, "\", is a quote character, which is used to -indicate that the next character is to be used literally (instead of its -normal interpretation). For example, "Joe\,Smith" indicates a single nine -character user field with the comma being the fourth character of the -field. - -Characters outside the set of alphas, digits, and hyphen MUST NOT appear in -domain names. In particular, the underscore character is not permitted. -SMTP servers that receive a command in which illegal character codes have -been employed, and for which there are no other reasons for rejection, MUST -reject that command with a 501 response. - -4.1.3 Address Literals - -Sometimes a host is not known to the domain name system and communication -(and, in particular, communication to report and repair the error) is -blocked. To bypass this barrier a special literal form of the address is -allowed as an alternative to a domain name. For IPv4 addresses, this form -uses four small decimal integers separated by dots and enclosed by brackets -such as [123.255.37.2], which indicates an (IPv4) Internet Address in -sequence-of-octets form. For IPv6 and other forms of addressing that might -eventually be standardized, the form consists of a standardized "tag" that -identifies the address syntax, a space, and the address itself, in a format -specified as part of the IPv6 standards [IPv6AddrString]. - -4.1.4 Order of Commands - -There are restrictions on the order in which these commands may be used. - -A session that will contain mail transactions MUST first be initialized by -the use of the EHLO command. An SMTP server SHOULD accept commands for -non-mail transactions (e.g., VRFY or EXPN) without this initialization. - -An EHLO command MAY be issued by a client later in the session. If it is -issued after the session begins, the SMTP server MUST clear all buffers and -reset the state exactly as if a RSET command had been issued. In other -words, the sequence of RSET followed immediately by EHLO is redundant, but -not harmful other than in the performance cost of executing unnecessary -commands. - -If the EHLO command is not acceptable to the SMTP server, 501, 500, or 502 -failure replies MUST be returned as appropriate. The SMTP server MUST stay -in the same state after transmitting these replies that it was in before -the EHLO was received. - -The SMTP client MUST ensure that the domain parameter to the EHLO command -is a valid principal host name (not a CNAME or MX name) for its host. If -this is not possible (e.g., when the client's address is dynamically -assigned and the client does not have an obvious name), an address literal -SHOULD be substituted for the domain name and supplemental information -provided that will assist in identifying the client. - -An SMTP server MAY verify that the domain name parameter in the EHLO -command actually corresponds to the IP address of the client. However, the -server MUST NOT refuse to accept a message if the verification fails: the -information about verification failure is for logging and tracing only. - -The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time -during a session, or without previously initializing a session. SMTP -servers SHOULD process these normally (that is, not return a 503 code) even -if no EHLO command has yet been received; clients SHOULD open a session -with EHLO before sending these commands. - -If these rules are followed, the example in RFC 821 that shows "550 access -denied to you" in response to an EXPN command is incorrect unless an EHLO -command precedes the EXPN or the denial of access is based on the client's -IP address or other authentication or authorization-determining mechanisms. - -The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins a -mail transaction. Once started, a mail transaction consists of a -transaction beginning command, one or more RCPT commands, and a DATA -command, in that order. A mail transaction may be aborted by the RSET (or -a new EHLO) command. There may be zero or more transactions in a session. - -If the transaction beginning command argument is not acceptable, a 501 -failure reply MUST be returned and the SMTP server MUST stay in the same -state. If the commands in a transaction are out of order to the degree -that they cannot be processed by the server, a 503 failure reply MUST be -returned and the SMTP server MUST stay in the same state. - -The last command in a session MUST be the QUIT command. The QUIT command -cannot be used at any other time in a session, but SHOULD be used by the -client SMTP to request connection closure, even when no session opening -command was sent and accepted. - -4.1.5 Private-use Commands - -As specified in section 2.2.2, commands starting in "X" may be used by -bilateral agreement between the client (sending) and server (receiving) -SMTP agents. An SMTP server that does not recognize such a command is -expected to reply with "500 Command not recognized". An extended SMTP -server MAY list the feature names associated with these private commands in -the response to the EHLO command. - -Commands sent or accepted by SMTP systems that do not start with "X" MUST -conform to the requirements of section 2.2.2. - -4.2 SMTP Replies - -Replies to SMTP commands serve to ensure the synchronization of requests -and actions in the process of mail transfer and to guarantee that the SMTP -client always knows the state of the SMTP server. Every command MUST -generate exactly one reply. - -The details of the command-reply sequence are described in section 4.3. - -An SMTP reply consists of a three digit number (transmitted as three -alphanumeric characters) followed by some text. The number is for use by -automata to determine what state to enter next; the text is for the human -user. The three digits contain enough encoded information that the SMTP -client need not examine the text and may either discard it or pass it on to -the user, as appropriate. Exceptions are as noted elsewhere in this -document. In particular, the 220, 221, 251, 421, and 551 reply codes are -associated with message text that must be parsed and interpreted by -machines. In the general case, the text may be receiver dependent and -context dependent, so there are likely to be varying texts for each reply -code. A discussion of the theory of reply codes is given in section 4.2.1. -Formally, a reply is defined to be the sequence: a three-digit code, <SP>, -one line of text, and <CRLF>, or a multiline reply (as defined in section -4.2.1). Only the EHLO, EXPN, and HELP commands are expected to result in -multiline replies in normal circumstances, however, multiline replies are -allowed for any command. - -In ABNF, server responses are: - - Greeting = "220 " Domain [ SP text ] CRLF - Reply-line = Reply-code [ SP text ] CRLF - -where "Greeting" appears only in the 220 response that announces that the -server is opening its part of the connection. - -An SMTP server SHOULD send only the reply codes listed in this document. -An SMTP server SHOULD use the text shown in the examples whenever -appropriate. - -An SMTP client MUST determine its actions only by the reply code, not by -the text (except for 251 and 551 and, if necessary, 220, 221, and 421 -replies); in the general case, any text, including no text at all (although -senders SHOULD NOT send bare codes), MUST be acceptable. The space (blank) -following the reply code is considered part of the text. Whenever -possible, a sender-SMTP SHOULD test the first digit (severity indication) -of the reply code. - -The list of codes that appears below must not be construed as permanent. -While the addition of new codes should be a rare and significant activity, -with supplemental information in the textual part of the response being -preferred, new codes may be added as the result of new Standards or -Standards-track specifications. Consequently, a sender-SMTP MUST be -prepared to handle codes not specified in this document and MUST do so by -interpreting the first digit only. - -4.2.1 Reply Code Severities and Theory - -The three digits of the reply each have a special significance. The first -digit denotes whether the response is good, bad or incomplete. An -unsophisticated SMTP client, or one that receives an unexpected code, will -be able to determine its next action (proceed as planned, redo, retrench, -etc.) by examining this first digit. An SMTP client that wants to know -approximately what kind of error occurred (e.g., mail system error, command -syntax error) may examine the second digit. The third digit and any -supplemental information that may be present is reserved for the finest -gradation of information. - -There are five values for the first digit of the reply code: - -1yz Positive Preliminary reply - The command has been accepted, but the requested action is being held in - abeyance, pending confirmation of the information in this reply. The - SMTP client should send another command specifying whether to continue - or abort the action. Note: unextended SMTP does not have any commands - that allow this type of reply, and so does not have continue or abort - commands. - -2yz Positive Completion reply - The requested action has been successfully completed. A new request may - be initiated. - -3yz Positive Intermediate reply - The command has been accepted, but the requested action is being held in - abeyance, pending receipt of further information. The SMTP client - should send another command specifying this information. This reply is - used in command sequence groups (i.e., in DATA). - -4yz Transient Negative Completion reply - The command was not accepted, and the requested action did not occur. - However, the error condition is temporary and the action may be - requested again. The sender should return to the beginning of the - command sequence (if any). It is difficult to assign a meaning to - "transient" when two different sites (receiver- and sender- SMTP agents) - must agree on the interpretation. Each reply in this category might have - a different time value, but the SMTP client is encouraged to try again. - A rule of thumb to determine whether a reply fits into the 4yz or the - 5yz category (see below) is that replies are 4yz if they can be - successful if repeated without any change in command form or in - properties of the sender or receiver. (that is, the command is repeated - identically and the receiver does not put up a new implementation.) - -5yz Permanent Negative Completion reply - The command was not accepted and the requested action did not occur. - The SMTP client is discouraged from repeating the exact request (in the - same sequence). Even some "permanent" error conditions can be - corrected, so the human user may want to direct the SMTP client to - reinitiate the command sequence by direct action at some point in the - future (e.g., after the spelling has been changed, or the user has - altered the account status). - -The second digit encodes responses in specific categories: - -x0z Syntax: These replies refer to syntax errors, syntactically correct - commands that don't fit any functional category, and unimplemented or - superfluous commands. - -x1z Information: These are replies to requests for information, such as - status or help. - -x2z Connections: These are replies referring to the transmission channel. - -x3z Unspecified. - -x4z Unspecified. - -x5z Mail system: These replies indicate the status of the receiver mail - system vis-a-vis the requested transfer or other mail system action. - -The third digit gives a finer gradation of meaning in each category -specified by the second digit. The list of replies illustrates this. Each -reply text is recommended rather than mandatory, and may even change -according to the command with which it is associated. On the other hand, -the reply codes must strictly follow the specifications in this section. -Receiver implementations should not invent new codes for slightly different -situations from the ones described here, but rather adapt codes already -defined. - -For example, a command such as NOOP, whose successful execution does not -offer the SMTP client any new information, will return a 250 reply. The -reply is 502 when the command requests an unimplemented non-site-specific -action. A refinement of that is the 504 reply for a command that is -implemented, but that requests an unimplemented parameter. - -The reply text may be longer than a single line; in these cases the -complete text must be marked so the SMTP client knows when it can stop -reading the reply. This requires a special format to indicate a multiple -line reply. - -The format for multiline replies requires that every line, except the last, -begin with the reply code, followed immediately by a hyphen, "-" (also -known as minus), followed by text. The last line will begin with the reply -code, followed immediately by <SP>, optionally some text, and <CRLF>. As -noted above, servers SHOULD send the <SP> if subsequent text is not sent, -but clients MUST be prepared for it to be omitted. - -For example: - 123-First line - 123-Second line - 123-234 text beginning with numbers - 123 The last line - -In many cases the SMTP client then simply needs to search for the reply -code followed by <SP> at the beginning of a line, and ignore all preceding -lines. In a few cases, there is important data for the sender in the reply -"text". The sender will be able to identify these cases from the current -context. - -4.2.2 Reply Codes by Function Groups - - 500 Syntax error, command unrecognized - (This may include errors such as command line too long) - 501 Syntax error in parameters or arguments - 502 Command not implemented (see section 4.2.4) - 503 Bad sequence of commands - 504 Command parameter not implemented - - 211 System status, or system help reply - 214 Help message - (Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user) - - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 421 <domain> Service not available, closing transmission channel - (This may be a reply to any command if the service knows it - must shut down) - - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - (See section 3.4) - 252 Cannot VRFY user, but will accept message and attempt - delivery - (See section 3.5.3) - 450 Requested mail action not taken: mailbox unavailable - (e.g., mailbox busy) - 550 Requested action not taken: mailbox unavailable - (e.g., mailbox not found, no access, or command rejected - for policy reasons) - 451 Requested action aborted: error in processing - 551 User not local; please try <forward-path> - (See section 3.4) - 452 Requested action not taken: insufficient system storage - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - (e.g., mailbox syntax incorrect) - 571 Address not accepted for policy reasons - 354 Start mail input; end with <CRLF>.<CRLF> - 554 Transaction failed (Or, in the case of a connection-opening - response, "No SMTP service here") - -4.2.3 Reply Codes in Numeric Order - - 211 System status, or system help reply - 214 Help message - (Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user) - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - (See section 3.4) - 252 Cannot VRFY user, but will accept message and attempt - delivery - (See section 3.5.3) - - 354 Start mail input; end with <CRLF>.<CRLF> - - 421 <domain> Service not available, closing transmission channel - (This may be a reply to any command if the service knows it - must shut down) - 450 Requested mail action not taken: mailbox unavailable - (e.g., mailbox busy) - 451 Requested action aborted: local error in processing - 452 Requested action not taken: insufficient system storage - - 500 Syntax error, command unrecognized - (This may include errors such as command line too long) - 501 Syntax error in parameters or arguments - 502 Command not implemented (see section 4.2.4) - 503 Bad sequence of commands - 504 Command parameter not implemented - 550 Requested action not taken: mailbox unavailable - (e.g., mailbox not found, no access, or command rejected - for policy reasons) - 551 User not local; please try <forward-path> - (See section 3.4) - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - (e.g., mailbox syntax incorrect) - 554 Transaction failed (Or, in the case of a connection-opening - response, "No SMTP service here") - 571 Address not accepted for policy reasons - -4.2.4 Reply Code 502 - -Questions have been raised as to when reply code 502 (Command not -implemented) SHOULD be returned in preference to other codes. 502 SHOULD -be used when the command is actually recognized by the SMTP server, but not -implemented. If the command is not recognized, code 500 SHOULD be -returned. Extended SMTP systems MUST NOT list capabilities in response to -EHLO for which they will return 502 (or 500) replies. - -4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> - -When an SMTP server returns a positive completion status (2yz code) after -the DATA command is completed with <CRLF>.<CRLF>, it accepts responsibility -for: - - - delivering the message (if the recipient mailbox exists), or - - - if attempts to deliver the message fail due to transient conditions, - retrying delivery some reasonable number of times at intervals as - specified in section 4.5.4. - - - if attempts to deliver the message fail due to permanent conditions, or - if repeated attempts to deliver the message fail due to transient - conditions, returning appropriate notification to the sender of the - original message (using the address in the SMTP MAIL FROM command). - -When an SMTP server returns a transient error completion status (4yz) code -after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make -any further attempt to deliver that message. The SMTP client retains -responsibility for delivery of that message and may either return it to the -user or requeue it for a subsequent attempt (see section 4.5.4.1). The -sending user SHOULD be able to interpret the return of a transient or -permanent failure status as a non-delivery indication. - -4.3 Sequencing of Commands and Replies - -4.3.1 Sequencing Overview - -The communication between the sender and receiver is an alternating -dialogue, controlled by the sender. As such, the sender issues a command -and the receiver responds with a reply. Unless other arrangements are -negotiated through service extensions, the sender MUST wait for this -response before sending further commands. - -One important reply is the connection greeting. Normally, a receiver will -send a 220 "Service ready" reply when the connection is completed. The -sender SHOULD wait for this greeting message before sending any commands. - -Note: all the greeting-type replies have the official name (the -fully-qualified primary domain name) of the server host as the first word -following the reply code. Sometimes the host will have no meaningful name. -See 4.1.3 for a discussion of alternatives in these situations. - -For example, - 220 ISIF.USC.EDU Service ready -or - 220 mail.foo.com SuperSMTP v 6.1.2 Service ready -or - 220 [10.0.0.1] Clueless host service ready - -The table below lists alternative success and failure replies for each -command. These SHOULD be strictly adhered to: a receiver may substitute -text in the replies, but the meaning and action implied by the code numbers -and by the specific command reply sequence cannot be altered. - -4.3.2 Command-Reply Sequences - -Each command is listed with its usual possible replies. The prefixes used -before the possible replies are "I" for intermediate, "S" for success, and -"E" for error. Since some servers may generate other replies under special -circumstances, and to allow for future extension, SMTP clients SHOULD, when -possible, interpret only the first digit of the reply and MUST be prepared -to deal with unrecognized reply codes by interpreting the first digit only. -Unless extended using the mechanisms described in section 2.2, SMTP servers -MUST NOT transmit reply codes to an SMTP client that are other than three -digits or that do not start in a digit between 2 and 5 inclusive. - -These sequencing rules and, in principle, the codes themselves, can be -extended or modified by SMTP extensions offered by the server and accepted -(requested) by the client. - -In addition to the codes listed below, any SMTP command can return any of -the following codes if the corresponding unusual circumstances are -encountered: - -500 For the "command line too long" case or if the command name was not - recognized. Note that producing a "command not recognized" error in - response to the required subset of these commands is a violation of this - specification. - -501 Syntax error in command or arguments. In order to provide for future - extensions, commands that are specified in this document as not - accepting arguments (DATA, NOOP, RSET) SHOULD return a 501 message if - arguments are supplied in the absence of EHLO-advertised extensions. - -421 Service shutting down and closing transmission channel - -Specific sequences are: - -CONNECTION ESTABLISHMENT - S: 220 - E: 554 -EHLO or HELO - S: 250 - E: 504, 550 -MAIL - S: 250 - E: 552, 451, 452, 550, 553 -RCPT - S: 250, 251 (but see section 3.4 for discussion of 251) - E: 550, 551, 552, 553, 450, 451, 452, 503, 550 -DATA - I: 354 -> data -> S: 250 - E: 552, 554, 451, 452 - E: 451, 554, 503 -RSET - S: 250 -VRFY - S: 250, 251, 252 - E: 550, 551, 553, 502, 504 -EXPN - S: 250, 252 - E: 550, 500, 502, 504 -HELP - S: 211, 214 - E: 502, 504 -NOOP - S: 250 -QUIT - S: 221 - -4.4 Trace Information - -When an SMTP server receives a message for delivery or further processing, -it MUST insert trace ("time stamp" or "Received") information at the -beginning of the message content, as discussed in section 4.1.1.4. - -This line MUST be structured as follows: - - - The FROM field, which MUST be supplied in an SMTP environment, SHOULD - contain both (1) the name of the source host as presented in the EHLO - command and (2) an address literal containing the IP address of the - source, determined from the TCP connection. - - - The ID field MAY contain an "@" as suggested in RFC-822, but this is not - required. - - - The FOR field MAY contain a list of <path> entries when multiple RCPT - commands have been given. This may raise some security issues and is - usually not desirable; see section 7.2. - -An Internet mail program MUST NOT change a Received: line that was -previously added to the message header. SMTP servers MUST prepend Received -lines to messages; they MUST NOT change the order of existing lines or -insert Received lines in any other location. - -As the Internet grows, comparability of Received fields is important for -detecting problems, especially slow relays. SMTP servers that create -Received fields SHOULD use explicit offsets in the dates (e.g., -0800), -rather than time zone names of any type. Local time (with an offset) is -preferred to UT when feasible. This formulation allows slightly more -information about local circumstances to be specified. If UT is needed, -the receiver need merely do some simple arithmetic to convert the values. -Use of UT loses information about the time zone-location of the server. If -a time zone name is used, it SHOULD be included in a comment. - -When the delivery SMTP server makes the "final delivery" of a message, it -inserts a return-path line at the beginning of the mail data. This use of -return-path is required; mail systems MUST support it. The return-path -line preserves the information in the <reverse-path> from the MAIL command. -Here, final delivery means the message has left the SMTP world. Normally, -this would mean it had been delivered to the destination user or an -associated mail drop, but in some cases it may be further processed and -transmitted by another mail system. - -It is possible for the mailbox in the return path to be different from the -actual sender's mailbox, for example, if error responses are to be -delivered to a special error handling mailbox rather than to the message -sender. When mailing lists are involved, this arrangement is common and -useful as a means of directing errors to the list maintainer rather than -the message originator. - -The text above implies that the final mail data will begin with a return -path line, followed by one or more time stamp lines. These lines will be -followed by the mail data headers and body [RFC-822]. - -It is sometimes difficult for an SMTP server to determine whether or not it -is making final delivery since forwarding or other operations may occur -after the message is accepted for delivery. Consequently, any further -(forwarding, gateway, or relay) systems MAY remove the return path and -rebuild the MAIL FROM command as needed to ensure that exactly one such -line appears in a delivered message. - -A message-originating SMTP system SHOULD NOT send a message that already -contains a Return-path header. SMTP servers performing a relay function -MUST NOT inspect the message data, and especially not to the extent needed -to determine if Return-path headers are present. SMTP servers making final -delivery MAY remove Return-path headers before adding their own. - -The primary purpose of the Return-path is to designate the address to which -messages indicating non-delivery or other mail system failures are to be -sent. For this to be unambiguous, exactly one return path SHOULD be -present when the message is delivered. Systems using RFC 822 syntax with -non-SMTP transports SHOULD designate an unambiguous address, associated -with the transport envelope, to which error reports (e.g., non-delivery -messages) should be sent. - -Historical note: Text in RFC 822 that appears to contradict the use of the -Return-path header (or the envelope MAIL FROM address) as the destination -for error messages is not applicable on the Internet. The MAIL FROM address -(as copied into the Return-path) MUST be used as the target of any mail -containing delivery error messages. - -In particular: - - - a gateway from SMTP->elsewhere SHOULD insert a return-path header, - unless it is known that the "elsewhere" transport also uses Internet - domain addresses and maintains the envelope sender address separately. - - - a gateway from elsewhere->SMTP SHOULD delete any return-path header - present in the message, and either copy that information to the SMTP - envelope or combine it with information present in the envelope of the - other transport system to construct the MAIL FROM part of the SMTP - envelope. - -The server must give special treatment to cases in which the processing -following the end of mail data indication is only partially successful. -This could happen if, after accepting several recipients and the mail data, -the SMTP server finds that the mail data could be successfully delivered to -some, but not all, of the recipients. In such cases, the response to the -DATA command MUST be an OK reply. However, the SMTP server MUST compose -and send an "undeliverable mail" notification message to the originator of -the message. - -A single notification listing all of the failed recipients or separate -notification messages MUST be sent for each failed recipient. For economy -of processing by the sender, the former is preferred when possible. All -undeliverable mail notification messages are sent using the MAIL command -(even if they result from processing the obsolete SEND, SOML, or SAML -commands) and use a null return path as discussed in section 3.7. - -The time stamp line and the return path line are formally defined as -follows: - - Return-path-line = "Return-Path:" FWS Reverse-path <CRLF> - - Time-stamp-line = "Received:" FWS Stamp <CRLF> - - Stamp = From-domain By-domain Opt-info ";" FWS Daytime - - From-domain = "FROM" FWS Extended-Domain CFWS - - By-domain = "BY" FWS Extended-Domain CFWS - - Extended-Domain = Domain / - ( Domain FWS "(" TCP-info ")" ) / - ( Address-literal FWS "(" TCP-info ")" - TCP-info = Address-literal / ( Domain FWS Address-literal ) - ; Information derived by server from TCP connection, not client EHLO. - - Opt-info = [Via] [With] [ID] [For] - - Via = "VIA" FWS Link CFWS - - With = "WITH" FWS Protocol CFWS - - ID = "ID" FWS String / msg-id CFWS - - For = "FOR" FWS 1*( Path / Mailbox ) CFWS - - Link = <<>> / Addtl-Link - Addtl-Link = Atom ; Additional standard names for links are - registered with the Internet Assigned - Numbers Authority (IANA). - SMTP servers SHOULD NOT use unregistered - names. - Protocol = "ESMTP" / "SMTP" / Attdl-Protocol - Attdl-Protocol = Atom ; Additional standard names for protocols - are registered with the Internet Assigned - Numbers Authority (IANA). SMTP servers - SHOULD NOT use unregistered names. - - Daytime = FWS [ day-of-week "," FWS ] Date FWS Time - - Date = DD FWS Mon FWS YYYY - ; Note that the earlier form, which permits two-digit years, has - been deprecated. SMTP systems MUST use four-digit years. - - Time = HH ":" MM ":" SS FWS Zone - - DD = 1*2Digit ; the one or two digit integer day of the - month in the range 1 to 31. - - Mon = "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | - "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" - - YYYY = 4*4Digit ; the four decimal integer year in the range - 0000 to 9999. - - HH = 2*2Digit ; the two decimal digit hour of the day in - the range 00 to 24. - - MM = 2*2Digit ; the two decimal digit integer minute of the hour - in the range 00 to 59. - - SS = 2*2Digit [ "." 1*Digit ] - ; the two decimal digit integer second of the - minute in the range 00 to 59, with - optional fractional seconds. - - Zone = ( "+" / "-" ) 4*4Digit [ <SP> "(" String ")" ] - ; A four digit, signed time zone offset, - such as -0500 for US Eastern Standard - Time. This may be supplemented by a time - zone name in parentheses, e.g., "-0800 - (PDT)". Note that there is no default; - time zone information is required and - MUST be supplied. - -4.5 Additional Implementation Issues - -4.5.1 Minimum Implementation - -In order to make SMTP workable, the following minimum implementation is -required for all receivers. The following commands MUST be supported to -conform to this specification: - EHLO - HELO - VRFY - MAIL - RCPT - DATA - RSET - NOOP - QUIT - -Any system that includes an SMTP server supporting mail relaying or -delivery MUST support the reserved mailbox "postmaster" as a -case-insensitive local name. This postmaster address is not strictly -necessary if the server always returns 554 on connection opening (as -described in section 3.1). The requirement to accept mail for postmaster -implies that RCPT TO commands which specify a mailbox for postmaster at any -of the domains for which the SMTP server provides mail service, as well as -the special case of "RCPT TO:<Postmaster>" (with no domain specification), -MUST be supported. This requirement does not imply that SMTP systems must -deliver Postmaster mail in particular cases (e.g., problematic origin -addresses) in which they have substantive reasons for not doing so. - -4.5.2 Transparency - -Without some provision for data transparency, the character sequence -"<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user. In -general, users are not aware of such "forbidden" sequences. To allow all -user composed text to be transmitted transparently, the following -procedures are used: - - - Before sending a line of mail text, the SMTP client checks the first - character of the line. If it is a period, one additional period is - inserted at the beginning of the line. - - - When a line of mail text is received by the SMTP server, it checks the - line. If the line is composed of a single period, it is treated as the - end of mail indicator. If the first character is a period and there are - other characters on the line, the first character is deleted. - -The mail data may contain any of the 128 ASCII characters. All characters -are to be delivered to the recipient's mailbox, including spaces, vertical -and horizontal tabs, and other control characters. If the transmission -channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes -are transmitted right justified in the octets, with the high order bits -cleared to zero. See 3.7 for special treatment of these conditions in SMTP -systems serving a relay function. - -In some systems it may be necessary to transform the data as it is received -and stored. This may be necessary for hosts that use a different character -set than ASCII as their local character set or store data in records rather -than strings. If such transformations are necessary, they MUST be -reversible, especially if such transformations are applied to mail being -relayed. - -4.5.3 Sizes and Timeouts - -There are several objects that have required minimum/maximum sizes. Every -implementation MUST be able to receive objects of at least these sizes. -Objects larger than these sizes SHOULD be avoided when possible. However, -some Internet mail constructs such as encoded X.400 addresses [RFC-X400] -will often require larger objects: clients MAY attempt to transmit these, -but MUST be prepared for a server to reject them if they cannot be handled -by it. To the maximum extent possible, implementation techniques which -impose no limits on the length of these objects should be used. - -local-part - The maximum total length of a user name or other local-part is 64 - characters. - -domain - The maximum total length of a domain name or number is 255 characters. - -path - The maximum total length of a reverse-path or forward-path is 256 - characters (including the punctuation and element separators). - -command line - The maximum total length of a command line including the command word - and the <CRLF> is 512 characters. SMTP extensions may be used to - increase this limit. - -reply line - The maximum total length of a reply line including the reply code and - the <CRLF> is 512 characters. More information may be conveyed through - multiple-line replies. - -text line - The maximum total length of a text line including the <CRLF> is 1000 - characters (not counting the leading dot duplicated for transparency). - This number may be increased by the use of SMTP Service Extensions. - -message content - The maximum total length of a message content (including any message - headers as well as the message body) MUST BE at least 64K octets. Since - the introduction of multimedia mail [RFC-MIME], message lengths on the - Internet have grown dramatically, and message size restrictions should - be avoided if at all possible. SMTP server systems that must impose - restrictions SHOULD implement the "SIZE" service extension ([RFC-SIZE]), - and SMTP client systems that will send large messages SHOULD utilize it - when possible. - -recipients buffer - The minimum total number of recipients that must be buffered is 100 - recipients. Rejection of messages (for excessive recipients) with fewer - than 100 RCPT TO commands is a violation of this specification. The - general principle that relaying SMTP servers MUST NOT, and delivery SMTP - servers SHOULD NOT, perform validation tests on message headers suggests - that rejecting a message based on the total number of recipients shown - in header fields is to be discouraged. A server which imposes a limit - on the number of recipients MUST behave in an orderly fashion, such as - to reject additional addresses over its limit rather than silently - discarding addresses previously accepted. A client that needs to - deliver a message containing over 100 RCPT TO commands SHOULD be - prepared to transmit in 100-recipient "chunks" if the server declines to - accept more than 100 recipients in a single message. - -Errors due to exceeding these limits may be reported by using the reply -codes. Some examples of reply codes are: - - 500 Line too long. -or - 501 Path too long -or - 452 Too many recipients (see below) -or - 552 Too much mail data. - -[RFC-821] incorrectly listed the error where an SMTP server exhausts its -implementation limit on the number of RCPT TO commands ("too many -recipients") as having reply code 552. The correct reply code for this -condition is 452. Clients SHOULD treat a 552 code in this case as a -temporary, rather than permanent failure so the logic below works. - -When a conforming SMTP server encounters this condition, it has at least -100 successful RCPT commands in its recipients buffer. If the server is -able to accept the message, then at least these 100 addresses will be -removed from the SMTP client's queue. When the client attempts -retransmission of those addresses which received 452 responses, at least -100 of these will be able to fit in the SMTP server's recipients buffer. -Each retransmission attempt which is able to deliver anything will be able -to dispose of at least 100 of these recipients. - -If an SMTP server has an implementation limit on the number of RCPT TO -commands and this limit is exhausted, it MUST use a response code of 452. -If the server has a configured site-policy limitation on the number of RCPT -TO commands, it MAY instead use a 5XX response code. - -In order to interoperate with SMTP servers implementing an older version of -the protocol, SMTP clients MAY treat a 552 code obtained in response to an -RCPT command as if it were a 452 response code, especially after some RCPT -commands have already been accepted in the same mail transaction. - -An SMTP client MUST provide a timeout mechanism. It MUST use per-command -timeouts rather than somehow trying to time the entire mail transaction. -Timeouts SHOULD be easily reconfigurable, preferably without recompiling -the SMTP code. To implement this, a timer is set for each SMTP command and -for each buffer of the data transfer. The latter means that the overall -timeout is inherently proportional to the size of the message. - -Based on extensive experience with busy mail-relay hosts, the minimum -per-command timeout values SHOULD be as follows: - -Initial 220 Message: 5 minutes - An SMTP client process needs to distinguish between a failed TCP - connection and a delay in receiving the initial 220 greeting message. - Many SMTP servers accept a TCP connection but delay delivery of the 220 - message until their system load permits more mail to be processed. - -MAIL Command: 5 minutes - -RCPT Command: 5 minutes - A longer timeout is required if processing of mailing lists and aliases - is not deferred until after the message was accepted. - -DATA Initiation: 2 minutes - This is while awaiting the "354 Start Input" reply to a DATA command. - -Data Block: 3 minutes - This is while awaiting the completion of each TCP SEND call transmitting - a chunk of data. - -DATA Termination: 10 minutes. - This is while awaiting the "250 OK" reply. When the receiver gets the - final period terminating the message data, it typically performs - processing to deliver the message to a user mailbox. A spurious timeout - at this point would be very wasteful and would typically result in - delivery of multiple copies of the message, since it has been - successfully sent and the server has accepted responsibility for - delivery. See section 6.1 for additional discussion. - -An SMTP server SHOULD have a timeout of at least 5 minutes while it is -awaiting the next command from the sender. - -4.5.4 Queuing Strategies - -The common structure of a host SMTP implementation includes user mailboxes, -one or more areas for queuing messages in transit, and one or more daemon -processes for sending and receiving mail. The exact structure will vary -depending on the needs of the users on the host and the number and size of -mailing lists supported by the host. We describe several optimizations that -have proved helpful, particularly for mailers supporting high traffic -levels. - -Any queuing strategy MUST include timeouts on all activities on a -per-command basis. A queuing strategy MUST never send error messages in -response to error messages. - -4.5.4.1 Sending Strategy - -The general model for an SMTP client is one or more processes that -periodically attempt to transmit outgoing mail. In a typical system, the -program that composes a message has some method for requesting immediate -attention for a new piece of outgoing mail, while mail that cannot be -transmitted immediately MUST be queued and periodically retried by the -sender. A mail queue entry will include not only the message itself but -also the envelope information. - -The sender MUST delay retrying a particular destination after one attempt -has failed. In general, the retry interval SHOULD be at least 30 minutes; -however, more sophisticated and variable strategies will be beneficial when -the SMTP client can determine the reason for non-delivery. - -Retries continue until the message is transmitted or the sender gives up; -the give-up time generally needs to be at least 4-5 days. The parameters -to the retry algorithm MUST be configurable. - -A client SHOULD keep a list of hosts it cannot reach and corresponding -connection timeouts, rather than just retrying queued mail items. - -Experience suggests that failures are typically transient (the target -system or its connection has crashed), favoring a policy of two connection -attempts in the first hour the message is in the queue, and then backing -off to one every two or three hours. - -The SMTP client can shorten the queuing delay in cooperation with the SMTP -server. For example, if mail is received from a particular address, it is -likely that mail queued for that host can now be sent. Application of this -principle may, in many cases, eliminate the requirement for an explicit -"send queues now" function such as that discussed in [RFC-ETRN]. - -The strategy may be further modified as a result of multiple addresses per -host (see below) to optimize delivery time vs. resource usage. - -An SMTP client may have a large queue of messages for each unavailable -destination host. If all of these messages were retried in every retry -cycle, there would be excessive Internet overhead and the sending system -would be blocked for a long period. Note that an SMTP client can generally -determine that a delivery attempt has failed only after a timeout of -several minutes and even a one-minute timeout per connection will result in -a very large delay if retries are repeated for dozens, or even hundreds, of -queued messages to the same host. - -At the same time, SMTP clients SHOULD use great care in caching negative -responses from servers. In an extreme case, if EHLO is issued multiple -times during the same SMTP connection, different answers may be returned by -the server. More significantly, 5yz responses to MAIL FROM MUST NOT be -cached. - -When a mail message is to be delivered to multiple recipients, and the SMTP -server to which a copy of the message is to be sent is the same for -multiple recipients, then only one copy of the message SHOULD be -transmitted. That is, the SMTP client SHOULD use the command sequence: -MAIL, RCPT, RCPT,... RCPT, DATA instead of the sequence: MAIL, RCPT, DATA, -..., MAIL, RCPT, DATA. However, if there are very many addresses, a limit -on the number of RCPT commands per MAIL command MAY be imposed. -Implementation of this efficiency feature is strongly encouraged. - -Similarly, to achieve timely delivery, the SMTP client MAY support multiple -concurrent outgoing mail transactions. However, some limit may be -appropriate to protect the host from devoting all its resources to mail. - -4.5.4.2 Receiving Strategy - -The SMTP server SHOULD attempt to keep a pending listen on the SMTP port at -all times. This requires the support of multiple incoming TCP connections -for SMTP. Some limit MAY be imposed. - -As discussed above, when the SMTP server receives mail from a particular -host address, it could notify the SMTP client to retry any mail pending for -that host address. - - -5. Address Resolution and Mail Handling - -Once an SMTP client lexically identifies a domain to which mail will be -delivered for processing (as described in sections 3.6 and 3.7), a DNS -lookup is performed to resolve the domain name (see [RFC-DNS]). The names -are expected to be fully-qualified domain names (FQDNs): mechanisms for -inferring FQDNs from partial names or local aliases are outside of this -specification and, due to a history of problems, are generally discouraged. -The lookup first attempts to locate an MX record associated with the name. -If a CNAME record is found instead, the resulting name is processed as if -it were the initial name. If no MX records are found, but an A RR is -found, the A RR is treated as if it was associated with an implicit MX RR, -with a preference of 0, pointing to that host. If one or more MX RRs are -found for a given name, SMTP systems MUST NOT utilize any A RRs associated -with that name unless they are located using the MX RRs; the "implicit MX" -rule above applies only if there are no MX records present. If MX records -are present, but none of them are usable, this situation MUST be reported -as an error. - -When the lookup succeeds, the mapping can result in a list of alternative -delivery addresses rather than a single address, because of multiple MX -records, multihoming, or both. To provide reliable mail transmission, the -SMTP client MUST be able to try (and retry) each of the relevant addresses -in this list in order, until a delivery attempt succeeds. However, there -MAY also be a configurable limit on the number of alternate addresses that -can be tried. In any case, a host SHOULD try at least two addresses. - -Two types of information is used to rank the host addresses: multiple MX -records, and multihomed hosts. - -Multiple MX records contain a preference indication that SHOULD be used in -sorting (see below). Lower numbers are more preferred than higher ones. -If there are multiple destinations with the same preference and there is no -clear reason to favor one (e.g., by recognition of an easily-reached -address), then the sender-SMTP MUST randomize them to spread the load -across multiple mail exchangers for a specific organization. - -The destination host (perhaps taken from the preferred MX record) may be -multihomed, in which case the domain name resolver will return a list of -alternative IP addresses. It is the responsibility of the domain name -resolver interface to have ordered this list by decreasing preference if -necessary, and SMTP MUST try them in the order presented. - -Although the capability to try multiple alternative addresses is required, -specific installations may want to limit or disable the use of alternative -addresses. The question of whether a sender should attempt retries using -the different addresses of a multihomed host has been controversial. The -main argument for using the multiple addresses is that it maximizes the -probability of timely delivery, and indeed sometimes the probability of any -delivery; the counter-argument is that it may result in unnecessary -resource use. Note that resource use is also strongly determined by the -sending strategy discussed in section 4.5.4.1. - -If a host receives a message with a destination for which it is a -designated Mail eXchanger, it MAY relay the message (potentially after -having rewritten the addresses), make final delivery of the message, or -hand it off using some mechanism outside the SMTP-provided transport -environment. - -If it determines that it should relay the message without rewriting the -address, it MUST sort the MX records to determine candidates for delivery. -The records are first ordered by preference, with the lowest-numbered -records being most preferred. The relay host MUST then inspect the list -for any of the names or addresses by which it might be known in mail -transactions. If a matching record is found, all records at that -preference level and higher-numbered ones MUST be discarded from -consideration. If there are no records left at that point, it is an error -condition, and the message MUST be returned as undeliverable. If records -do remain, they SHOULD be tried, best preference first, as described above. - - -6. Problem Detection and Handling - -6.1 Reliable Delivery and Replies by Email - -When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" -message in response to DATA), it is accepting responsibility for delivering -or relaying the message. It must take this responsibility seriously. It -MUST NOT lose the message for frivolous reasons, such as because the host -later crashes or because of a predictable resource shortage. - -If there is a delivery failure after acceptance of a message, the -receiver-SMTP MUST formulate and mail a notification message. This -notification MUST be sent using a null ("<>") reverse path in the envelope. -The recipient of this notification SHOULD be the address from the envelope -return path (or the Return-Path: line). However, if this address is null -("<>"), the receiver-SMTP MUST NOT send a notification. Obviously, nothing -in this section can or should prohibit local decisions (i.e., as part of -the same system environment as the receiver-SMTP) to log or otherwise -transmit information about null address events locally if that is desired. -If the address is an explicit source route, it MUST be stripped down to its -final hop. - -For example, suppose that an error notification must be sent for a message -that arrived with: - MAIL FROM:<@a,@b:user@d> - -The notification message SHOULD be sent using: - RCPT TO:<user@d> - -Some delivery failures after the message is accepted by SMTP will be -unavoidable. For example, it may be impossible for the receiving SMTP -server to validate all the delivery addresses in RCPT command(s) due to a -"soft" domain system error, because the target is a mailing list (see -earlier discussion of RCPT), or because the server is acting as a relay and -has no immediate access to the delivering system. - -To avoid receiving duplicate messages as the result of timeouts, a -receiver-SMTP MUST seek to minimize the time required to respond to the -final <CRLF>.<CRLF> end of data indicator. See RFC-1047 [RFC-1047] for a -discussion of this problem. - -6.2 Loop Detection - -Simple counting of the number of "Received:" headers in a message has -proven to be an effective, although rarely optimal, method of detecting -loops in mail systems. SMTP servers using this technique SHOULD use a -large rejection threshold, normally at least 100 Received entries. -Whatever mechanisms are used, servers MUST contain provisions for detecting -and stopping trivial loops. - -6.3 Compensating for Irregularities - -Unfortunately, variations, creative interpretations, and outright -violations of Internet mail protocols do occur; some would suggest that -they occur quite frequently. The debate as to whether a well-behaved SMTP -receiver or relay should reject a malformed message, attempt to pass it on -unchanged, or attempt to repair it to increase the odds of successful -delivery (or subsequent reply) began almost with the dawn of structured -network mail and shows no signs of abating. Advocates of rejection claim -that attempted repairs are rarely completely adequate and that rejection of -bad messages is the only way to get the offending software repaired. -Advocates of "repair" or "deliver no matter what" argue that users prefer -that mail go through it if at all possible and that there are significant -market pressures in that direction. In practice, these market pressures -may be more important to particular vendors than strict conformance to the -standards, regardless of the preference of the actual developers. - -The problems associated with ill-formed messages were exacerbated by the -introduction of the split-UA mail reading protocols [RFC-POP2, RFC-POP3, -RFC-IMAP2, RFC-PCMAIL]. These protocols have encouraged the use of SMTP as -a posting protocol, and SMTP servers as relay systems for these client -hosts (which are often only intermittently connected to the Internet). -Historically, many of those client machines lacked some of the mechanisms -and information assumed by SMTP (and indeed, by the mail format protocol -[RFC-822]). Some could not keep adequate track of time; others had no -concept of time zones; still others could not identify their own names or -addresses; and, of course, none could satisfy the assumptions that underlay -RFC-822's conception of authenticated addresses. - -In response to these weak SMTP clients, many SMTP systems now complete -messages that are delivered to them in incomplete or incorrect form. This -strategy is generally considered appropriate when the server can identify -or authenticate the client, and there are prior agreements between them. -By contrast, there is at best great concern about fixes applied by a relay -or delivery SMTP server that has little or no knowledge of the user or -client machine. - -The following changes to a message being processed MAY be applied when -necessary by an originating SMTP server, or one used as the target of SMTP -as an initial posting protocol: - - - Addition of a message-id field when none appears - - - Addition of a date, time or time zone when none appears - - - Correction of addresses to proper FQDN format - -The less information the server has about the client, the less likely these -changes are to be correct and the more caution and conservatism should be -applied when considering whether or not to perform fixes and how. These -changes MUST NOT be applied by an SMTP server that provides an intermediate -relay function. - -In all cases, properly-operating clients supplying correct information are -preferred to corrections by the SMTP server. In all cases, documentation of -actions performed by the servers (in trace fields and/or header comments) -is strongly encouraged. - - -7. Security Considerations - -7.1 Mail Security and Spoofing - -SMTP mail is inherently insecure in that it is feasible for even fairly -casual users to negotiate directly with receiving and relaying SMTP servers -and create messages that will trick a naive recipient into believing that -they came from somewhere else. Constructing such a message so that the -"spoofed" behavior cannot be detected by an expert is somewhat more -difficult, but not sufficiently so as to be a deterrent to someone who is -determined and knowledgeable. Consequently, as knowledge of Internet mail -increases, so does the knowledge that SMTP mail inherently cannot be -authenticated, or integrity checks provided, at the transport level. Real -mail security lies only in end-to-end methods involving the message bodies, -such as those that can be provided in the MOSS framework [RFC-MOSS]. - -Various protocol extensions and configuration options that provide -authentication at the transport level (e.g., from an SMTP client to an SMTP -server) improve somewhat on the traditional situation described above. -However, unless they are accompanied by careful handoffs of responsibility -in a carefully-designed trust environment, they remain inherently weaker -than end-to-end mechanisms which use digitally signed messages rather than -depending on the integrity of the transport system. - -Efforts to make it more difficult for users to set envelope MAIL FROM and -header "From" fields to point to valid addresses other than their own are -largely misguided: they frustrate legitimate applications in which mail is -sent by one user on behalf of another or in which error (or normal) replies -should be directed to a special address. (Systems that provide convenient -ways for users to alter these fields on a per-message basis should attempt -to establish a primary and permanent mailbox address for the user so that -Sender fields within the message data can be generated sensibly.) - -This specification does not further address the authentication issues -associated with SMTP other than to advocate that useful functionality not -be disabled in the hope of providing some small margin of protection -against an ignorant user who is trying to fake mail. - -7.2 "Blind" Copies - -Addresses that do not appear in the message headers may appear in the RCPT -TO commands to an SMTP server for a number of reasons. The two most common -involve the use of a mailing address as a "list exploder" (a single address -that resolves into multiple addresses) and the appearance of "blind -copies". Especially when more than one RCPT command is present, and in -order to avoid defeating some of the purpose of these mechanisms, SMTP -clients and servers SHOULD NOT copy the full set of RCPT TO command -arguments into the headers, either as part of trace headers or as -informational or private-extension headers. Since this rule is often -violated in practice, and cannot be enforced, sending SMTP systems that are -aware of "bcc" use MAY find it helpful to send each blind copy as a -separate message transaction containing only a single RCPT TO command. - -There is no inherent relationship between either "reverse" (MAIL FROM, SAML -FROM, etc.) or "forward" (RCPT TO) addresses in the SMTP transaction -("envelope") and the addresses in the headers. Receiving systems SHOULD -NOT attempt to deduce such relationships and use them to alter the headers -of the message for delivery. The popular "Apparently-to" header is a -violation of this principle and SHOULD NOT be used. - -7.3 VRFY, EXPN, and Security - -As discussed in section 3.5, individual sites may want to disable one or -both VRFY or EXPN for security reasons. As a corollary to the above, -implementations that permit this MUST NOT appear to have verified addresses -that are not, in fact, verified. If a site disables these commands for -security reasons, the SMTP server MUST return a 252 response, rather than a -code that could be confused with successful or unsuccessful verification. - -Returning a 250 reply code with the address listed in the VRFY command -after having checked it only for syntax violates this rule. Of course, an -implementation that "supports" VRFY by always returning 550 whether or not -the address is valid is equally not in conformance. - -Within the last few years, the contents of mailing lists have become -popular as an address information source for so-called "spammers." The use -of EXPN to "harvest" addresses has increased as list administrators have -installed protections against inappropriate uses of the lists themselves. -Implementations SHOULD still provide support for EXPN, but sites SHOULD -carefully evaluate the tradeoffs. As authentication mechanisms are -introduced into SMTP, some sites may choose to make EXPN available only to -authenticated requestors. - -7.4 Information Disclosure in Announcements - -There has been an ongoing debate about the tradeoffs between the debugging -advantages of announcing server type and version (and, sometimes, even -server domain name) in the greeting response or in response to the HELP -command and the disadvantages of exposing useful information to potential -hostile attack. The utility of the debugging information is beyond doubt. -Those who argue for making it available point out that it is far better to -actually secure an SMTP server rather than hope that trying to conceal -known vulnerabilities by hiding the server's precise identity will provide -more protection. Sites are encouraged to evaluate the tradeoff with that -issue in mind; implementations are strongly encouraged to minimally provide -for making type and version information available in some way to other -network hosts. - -7.5 Information Disclosure in Trace Fields - -In some circumstances, such as when mail originates from within a LAN whose -hosts are not directly from the public Internet, trace ("Received") fields -produced in conformance with this specification may disclose host names and -similar information that would not normally be available. This ordinarily -does not pose a problem, but sites with special concerns about name -disclosure should be aware of it. Also, the optional FOR clause should be -supplied with caution or not at all when multiple recipients are involved -lest it inadvertently disclose the identities of "blind copy" recipients to -others. - -7.6 Scope of Operation of SMTP Servers - -It is a well-established principle that an SMTP server may refuse to accept -mail for any operational or technical reason that makes sense to the site -providing the server. However, cooperation among sites and installations -makes the Internet possible. If sites take excessive advantage of the -right to reject traffic, the ubiquity of email availability (one of the -strengths of the Internet) will be threatened; considerable care should be -taken and balance maintained if a site decides to be selective about the -traffic it will accept and process. - -In recent years, use of the relay function through arbitrary sites has been -used as part of hostile efforts to hide the actual origins of mail. Some -sites have decided to limit the use of the relay function to known or -identifiable sources, and implementations SHOULD provide the capability to -perform this type of filtering. When mail is rejected for these or other -policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL FROM, -or RCPT TO as appropriate. - - -8. IANA Considerations - -IANA is <<requested>> to set up three registries. The first consists of -SMTP service extensions with the associated keywords, and, as needed, -parameters and verbs. As specified in section 2.2.2, no entry may be made -in this registry that starts in an "X". Entries may be made only for -service extensions (and associated keywords, parameters, or verbs) that are -defined in standards-track or experimental RFCs specifically approved by -the IESG for this purpose. - -The second registry consists of "tags" that identify forms of domain -literals other than those for IPv4 addresses (specified in RFC 821 and in -this document) and IPv6 addresses (specified in this document). Additional -literal types require standardization before being used; none are -anticipated at this time. - -The third, established by RFC 821 and renewed by this specification, is a -registry of link and protocol identifiers to be used with the "via" and -"with" subclauses of the time stamp ("Received: header") described in -section 4.4. Link and protocol identifiers in addition to those specified -in this document may be registered only by standardization or by way of an -RFC-documented, IESG-approved, Experimental protocol extension. - - -9. References - -[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP -Service Extension for 8bit-MIMEtransport", RFC 1652, 07/18/1994. - -[ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax -Specifications: ABNF", RFC 2234, November 1997. - -[IPv6AddrString] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing -Architecture", RFC 1884, December 1995. - -[MSGFMT] P. Resnick, Work in progress, draft-ietf-drums-msg-fmt-05.txt, -August, 1998 - -[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text -Messages", RFC 822, Department of Electrical Engineering, University of -Delaware, August 1982. - -[RFC-974] C. Partridge, "Mail routing and the domain system", RFC 974, -01/01/1986 - -[RFC-1047] C. Partridge, "Duplicate messages and SMTP", RFC 1047, -02/01/1988. - -[RFC-1123] R. Braden, "Requirements for Internet hosts - application and -support", 10/01/1989 - -[RFC-BDAT] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large -and Binary MIME Messages", RFC 1830, 08/16/1995. - -[RFC-DNS] P. Mockapetris, "Domain names - implementation and -specification", RFC 1035 and P. Mockapetris, "Domain names - concepts and -facilities", RFC 1034. (STD 13) - -[RFC-ETRN] J. De Winter, "SMTP Service Extension for Remote Message Queue -Starting", RFC 1985, 08/14/1996. - -[RFC-IMAP2] M. Crispin, "Interactive Mail Access Protocol - Version 2", RFC -1176, 08/20/1990. - -[RFC-IMAP4] M. Crispin, "Internet Message Access Protocol - Version 4", RFC -2060, 12/04/1996. - -[RFC-INTLHDR] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part -Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 12/02/1996. - -[RFC-MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions -(MIME) Part One: Format of Internet Message Bodies", RFC 2045, 12/02/1996. - -[RFC-MOSS] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object -Security Services", RFC 1848, 10/03/1995. - -[RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery Status -Notifications", RFC 1891, 01/15/1996. - -[RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message Format for -Delivery Status Notifications", RFC 1894, 01/15/1996. - -[RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for personal -computers", RFC 1056, 06/01/1988. - -[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension for Command -Pipelining", RFC 1854, 10/04/1995. - -[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J. Reynolds, -"Post Office Protocol - version 2", RFC 937, 02/01/1985 - -[RFC-POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3", RFC 1930, -5/14/96 (Std 53). - -[RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 1893, -01/15/1996. - -[RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension for -Message Size Declaration", RFC 1870, 11/06/1995. (STD 10) - -[RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021 -and RFC 822", RFC 1327, 05/18/1992. - -[SMTPEX] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP -Service Extensions", RFC-1869, 11/06/1995. (STD 10) - -[TCP] Postel, J., ed., "Transmission Control Protocol - DARPA Internet -Program Protocol Specification", RFC 793, USC/Information Sciences -Institute, NTIS AD Number A111091, September 1981. - -[US-ASCII] United States of America Standards Institute (now American -National Standards Institute), X3.4, 1968, "USA Code for Information -Interchange". ANSI X3.4-1968 has been replaced by newer versions with -slight modifications, but the 1968 version remains definitive for the -Internet. - - -10. Editor's Address - -John C. Klensin -MCI Communications -800 Boylston St., 7th floor -Boston, MA 02199 -USA -Email: Klensin@mci.net -Phone: +1 617 960 1011 -Fax: +1 617 960 1009 - - -11. Acknowledgments - -Many people worked long and hard on the many iterations of this document. -There was wide-ranging debate on the mailing list about many technical -issues, and many contributors helped form the wording in this -specification. The hundreds of participants in the many discussions since -RFC 821 was produced are too numerous to mention, but they all helped this -document become what it is. - - -A. TCP Transport Service - -The TCP connection supports the transmission of 8-bit bytes. The SMTP data -is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte -with the high-order bit cleared to zero. Service extensions may modify -this rule to permit transmission of full 8-bit data bytes as part of the -message body, but not in SMTP commands or responses. - - -B. Generating SMTP Commands from RFC 822 Headers - -Some systems use RFC 822 headers (only) in a mail submission protocol, or -otherwise generate SMTP commands from RFC 822 headers when such a message -is handed to an MTA from a UA. While the MTA-UA protocol is a private -matter, not covered by any Internet Standard, there are problems with this -approach. For example, there have been repeated problems with proper -handling of "bcc" copies and redistribution lists when information that -conceptually belongs to a mail envelopes is not separated early in -processing from header information (and kept separate). - -It is recommended that the UA provide its initial MTA with an envelope -separate from the message itself. However, if the envelope is not -supplied, SMTP commands SHOULD be generated as follows: - -1. Each recipient address from a TO, CC, or BCC header field SHOULD be - copied to a RCPT command (generating multiple message copies if that is - required for queuing or delivery). This includes any addresses listed - in a RFC 822 "group". Any BCC fields SHOULD then be removed from the - headers. Once this process is completed, the remaining headers SHOULD - be checked to verify that at least one To:, Cc:, or Bcc: header remains. - If none do, then a bcc: header with no additional information SHOULD be - inserted as specified in [MSGFMT]. - -2. The return address in the MAIL command SHOULD, if possible, be derived - from the system's identity for the submitting (local) user. And the From - header field otherwise. If there is a system identity available, it - SHOULD also be copied to the Sender header field if it is different from - the address in the From header field. (Any Sender field that was - already there SHOULD be removed.) Systems may provide a way for - submitters to override the envelope return address, but may want to - restrict its use to privileged users. This will not prevent mail - forgery, but may lessen its incidence; see section 7.1. - -When an MTA is being used in this way, it bears responsibility for ensuring -that the message being transmitted is valid. The mechanisms for checking -that validity, and for handling (or returning) messages that are not valid -at the time of arrival, are part of the MUA-MTA interface and not covered -by this specification. - -A submission protocol based on Standard RFC 822 information alone MUST NOT -be used to gateway a message from a foreign (non-SMTP) mail system into an -SMTP environment. Additional information to construct an envelope must -come from some source in the other environment, whether supplemental -headers or the foreign system's envelope. - -Attempts to gateway messages using only their header "to" and "cc" fields, -have repeatedly caused mail loops and other behavior adverse to the proper -functioning of the Internet mail environment. These problems have been -especially common when the message originates from an Internet mailing list -and is distributed into the foreign environment using envelope information. -When these messages are then processed by a header-only remailer, loops -back to the Internet environment (and the mailing list) are almost -inevitable. - - -C. Source Routes - -The <reverse-path> is a reverse source routing list of hosts and a source -mailbox. The first host in the <reverse-path> SHOULD be the host sending -the MAIL FROM command. Similarly, the <forward-path> may be a source -routing lists of hosts and a destination mailbox. However, in general, the -<forward-path> SHOULD contain only a mailbox and domain name, relying on -the domain name system to supply routing information if required. The use -of source routes is deprecated; while servers MUST be prepared to receive -and handle them as discussed in section 3.3 and F.2, clients SHOULD NOT -transmit them. - -For relay purposes, the forward-path may be a source route of the form -"@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully-qualified -domain names. This form is used to emphasize the distinction between an -address and a route. The mailbox is an absolute address, and the route is -information about how to get there. The two concepts should not be -confused. - -If source routes are used, RFC 821 and the text below should be consulted -for the mechanisms for constructing and updating the forward- and -reverse-paths. - -The SMTP server transforms the command arguments by moving its own -identifier (its domain name or that of any domain for which it is acting as -a mail exchanger), if it appears, from the forward-path to the beginning of -the reverse-path. - -Notice that the forward-path and reverse-path appear in the SMTP commands -and replies, but not necessarily in the message. That is, there is no need -for these paths and especially this syntax to appear in the "To:" , -"From:", "CC:", etc. fields of the message header. Conversely, SMTP servers -MUST NOT derive final message delivery information from message header -fields. - -When the list of hosts is present, it is a "reverse" source route and -indicates that the mail was relayed through each host on the list (the -first host in the list was the most recent relay). This list is used as a -source route to return non-delivery notices to the sender. As each relay -host adds itself to the beginning of the list, it MUST use its name as -known in the transport environment to which it is relaying the mail rather -than that of the transport environment from which the mail came (if they -are different). - - -D. Scenarios - -This section presents complete scenarios of several types of SMTP sessions. -In the examples, "C:" indicates what is said by the SMTP client, and "S:" -indicates what is said by the SMTP server. - -D.1 A Typical SMTP Transaction Scenario - -This SMTP example shows mail sent by Smith at host bar.com, to Jones, -Green, and Brown at host foo.com. Here we assume that host bar.com -contacts host foo.com directly. The mail is accepted for Jones and Brown. -Green does not have a mailbox at host foo.com. - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<Smith@bar.com> - S: 250 OK - C: RCPT TO:<Jones@foo.com> - S: 250 OK - C: RCPT TO:<Green@foo.com> - S: 550 No such user here - C: RCPT TO:<Brown@foo.com> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.2 Aborted SMTP Transaction Scenario - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<Smith@bar.com> - S: 250 OK - C: RCPT TO:<Jones@foo.com> - S: 250 OK - C: RCPT TO:<Green@foo.com> - S: 550 No such user here - C: RSET - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.3 Relayed Mail Scenario - -Step 1 -- Source Host to Relay Host - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<JQP@bar.com> - S: 250 OK - C: RCPT TO:<@foo.com:Jones@XYZ.COM> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Date: Thu, 21 May 1998 05:33:29 -0700 - C: From: John Q. Public <JQP@bar.com> - C: Subject: The Next Meeting of the Board - C: To: Jones@xyz.com - C: - C: Bill: - C: The next meeting of the board of directors will be - C: on Tuesday. - C: John. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -Step 2 -- Relay Host to Destination Host - - S: 220 xyz.com Simple Mail Transfer Service Ready - C: EHLO foo.com - S: 250 xyz.com is on the air - C: MAIL FROM:<@foo.com:JQP@bar.com> - S: 250 OK - C: RCPT TO:<Jones@XYZ.COM> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Received: from bar.com by foo.com ; Thu, 21 May 1998 05:33:29 -0700 - C: Date: Thu, 21 May 1998 05:33:22 -0700 - C: From: John Q. Public <JQP@bar.com> - C: Subject: The Next Meeting of the Board - C: To: Jones@xyz.com - C: - C: Bill: - C: The next meeting of the board of directors will be - C: on Tuesday. - C: John. - C: . - S: 250 OK - - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.4 Verifying and Sending Scenario - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: VRFY Crispin - S: 250 Mark Crispin <Admin.MRC@foo.com> - C: SEND FROM:<EAK@bar.com> - S: 250 OK - C: RCPT TO:<Admin.MRC@foo.com> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - - -E. Other Gateway Issues - -In general, gateways between the Internet and other mail systems SHOULD -attempt to preserve any layering semantics across the boundaries between -the two mail systems involved. Gateway- translation approaches that -attempt to take shortcuts by mapping, (such as envelope information from -one system to the message headers or body of another) have generally proven -to be inadequate in important ways. Systems translating between -environments that do not support both envelopes and headers and Internet -mail must be written with the understanding that some information loss is -almost inevitable. - - -F. Deprecated Features of RFC 821 - -A few features of RFC 821 have proven to be problematic and SHOULD NOT be -used in Internet mail. - -F.1 TURN - -This command, described in RFC 821, raises important security issues since, -in the absence of strong authentication of the host requesting that the -client and server switch roles, it can easily be used to divert mail from -its correct destination. Its use is deprecated; SMTP systems SHOULD NOT -use it unless the server can authenticate the client. - -F.2 Source Routing - -RFC 821 utilized the concept of explicit source routing to get mail from -one host to another via a series of relays. The requirement to utilize -source routes in regular mail traffic was eliminated by the introduction of -the domain name system "MX" record and the last significant justification -for them was eliminated by the introduction, in RFC 1123, of a clear -requirement that addresses following an "@" must all be fully-qualified -domain names. Consequently, the only remaining justifications for the use -of source routes are support for very old SMTP clients or MUAs and in mail -system debugging. They can, however, still be useful in the latter -circumstance and for routing mail around serious, but temporary, problems -such as problems with the relevant DNS records. - -SMTP servers MUST continue to accept source route syntax as specified in -the main body of this document and in RFC 1123. They MAY, if necessary, -ignore the routes and utilize only the target domain in the address. If -they do utilize the source route, the message MUST be sent to the first -domain shown in the address. In particular, a server MUST NOT guess at -shortcuts within the source route. - -Clients SHOULD NOT utilize explicit source routing except under unusual -circumstances, such as debugging or potentially relaying around firewall or -mail system configuration errors. - -F.3 HELO - -As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to HELO -when the server will accept the former. Servers must continue to accept -and process HELO in order to support older clients. - -F.4 #-literals - -RFC 821 provided for specifying an Internet address as a decimal integer -host number prefixed by a pound sign, "#". In practice, that form has been -obsolete since the introduction of TCP/IP. It is deprecated and MUST NOT -be used. - -F.5 Dates and Years - -When dates are inserted into messages by SMTP clients or servers (e.g., in -trace fields), four-digit years MUST BE used. Two-digit years are -deprecated; three-digit years were never permitted in the Internet mail -system. - -F.6 Sending versus Mailing - -In addition to specifying a mechanism for delivering messages to user's -mailboxes, RFC 821 provided additional, optional, commands to deliver -messages directly to the user's terminal screen. These commands (SEND, -SAML, SOML) were rarely implemented, and changes in workstation technology -and the introduction of other protocols may have rendered them obsolete -even where they are implemented. - -Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers MAY -implement them. If they are implemented by servers, the implementation -model specified in RFC 821 MUST be used and the command names MUST be -published in the response to the EHLO command. - - -X. Change Summary and Loose Ends (Temporary) - -X.1 Change summary - -X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and -draft-ietf-drums-smtpupd-01.txt - -(i) Slightly clarified the discussions of rejection and failure of VRFY -requests and the associated response codes. - -(ii) Slightly clarified the discussion of deferred address validation. - -(iii) Removed the IPCE terminology and modified the text in section 4.1.1.2 -to explicitly introduce the "mail gateway" terminology and to begin to -distinguish a mail gateway from a conventional relay. - -(iv) Explicitly noted that SMTP clients for things like POP and IMAP may -send everything to a single relay for further processing, rather than -resolving final domain names. - -(v) Tightened the RSET discussion. - -(vi) Deprecation of 251 only for RCPT (still ok for VRFY) - -X.1.2. Substantive changes between draft-ietf-drums-smtpupd-01.txt and -draft-ietf-drums-smtpupd-02.txt. - -Incorporated additional RFC 1123 material; reorganized several sections for -clarity. Added definitions and other previous "loose end" material. - -X.1.3. Substantive changes between draft-ietf-drums-smtpupd-02.txt and -draft-ietf-drums-smtpupd-03.txt. - -(i) Eliminated a number of placeholders and tightened some of the -definitions in section 2. Added a few new placeholders for consistency -checking against other documents. - -(ii) Removed the state diagrams, per direction at IETF Montreal. - -(iii) Added new section 6.3, an attempt to summarize WG discussions on the -"posting" versus "delivery" versus "relay" functions of SMTP and on whether -"fixups" are appropriate in different cases. - -(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of RFC1123. - -(v) Added new text to 3.5.5 to discuss the spammer - EXPN relationship. - -(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat. - -(v) The remaining miscellaneous changes agreed to in Montreal have been -incorporated except as noted below. - -X.1.4. Substantive changes between draft-ietf-drums-smtpupd-03.txt and -draft-ietf-drums-smtpupd-04.txt. - -Many small changes have been made between these two versions; the list that -follows is not exhaustive. - -(i) To clarify some of the text, definitions have been introduced to -distinguish among originating, delivery, relay, and gateway SMTP systems. - -(ii) The role of LF-terminated lines has been clarified. - -(iii) Several changes have been made to clarify the principle that, no -matter what originating and final delivery systems might do, relay systems -are not permitted to tamper with message content, even to "fix" headers -that are determined to be invalid. If they deem message content to be -seriously unacceptable, they are encouraged to reject the messages in -preference to trying to fix them up, but, in general, the theme is "don't -look/ don't tell". - -(iv) A few more definitions have been added to the terminology section, and -the separate glossary has been eliminated. - -(v) I have taken a shot at text to address some of the controversies that -have raged on the WG mailing list (e.g., sections 7.4 and 7.5). Since there -was no consensus on most of those topics, I expect that the inserted text -will satisfy no one except, perhaps, for agreement that saying nothing -would have been worse. As a mechanism for moving forward, the text in -these controversial areas that now appears will be considered "base"; -alterations will be made only if clear consensus emerges. - -(vi) Per discussion in Los Angeles, source routes have been further -deprecated. - -(vii) Some of the VRFY/EXPN materials have been moved to "security -considerations", where they appear to belong, some text has been added, and -the conformance statements adjusted to reflect what I perceive to be WG -consensus. - -(viii) New MX resolution material has been added to section 5. While most -of this material is from RFC974, the rules have been further tightened to -reflect current practice and experience (974 is written in a somewhat -speculative fashion for a standard). In particular, the behavior of trying -the target host's A RR when MXs existed but all of them were eliminated is -now prohibited, which seems necessary if another of other ideas being -recommended or considered are to be feasible. - -X.1.5. Substantive changes between draft-ietf-drums-smtpupd-04.txt and -draft-ietf-drums-smtpupd-05.txt. - -(i) All normative references to RFC 1123 have been removed from the main -body of the text (some still appear in the appendices where they will -remain). - -(ii) Section 3.5 has been renamed slightly to distinguish between -"debugging of SMTP implementations" and "debugging of addresses". Better -terminology would be welcome. - -(iii) Error conditions resulting from the DATA command have been clarified. - -(iv) Section 4.2 (SMTP replies) has been revised and tightened to reflect -reality and recent discussion on the list. - -(v) Appendix E has been revised a bit and moved into section 4.2.1. Given -the importance of the "check only first digit" rule, it has to be there. - -(vi) Added new text for "no SMTP service supported" to sections 3.1, 4.2.2, -4.2.3, and 4.3.2. As noted in 3.1, I'd rather add 521 (which would work -perfectly with the model) rather than overloading 554. - -(vii) The Return-path language in section 4.4 has been cleaned up a bit. - -(viii) Tightened the "postmaster" language in 4.5.1, requiring a small -change to 4.1.1.3. - -(ix) I have unilaterally (with a little help from my friends), increased -some of the size limits. 64 was much too short for a domain name, and the -DNS limit of 255 (?) has now been inserted. That leaves the return path -much too short, but I haven't fixed it (maybe that will cause us to get rid -of them). We still have a 64 character limit on the local-part, which is -also *much* too short. Votes for 128 or longer limits accepted. See -X.1.6(I) - -(x) The text on the "recipients buffer" has been rewritten so that (I hope) -it makes sense and gives some explicit guidance for how clients and servers -should proceed if limits are imposed. - -X.1.6. Substantive changes between draft-ietf-drums-smtpupd-05.txt and -draft-ietf-drums-smtpupd-06.txt. - -Most of the changes in this revision have been editorial rather than -substantive. Major substantive changes include: - -(i) The language about maximum sizes of SMTP command lines has been -reworked, per WG mailing list discussion. - -(ii) Several instances of "Should" have been promoted to "Must" when the -reasons for the weaker rule seemed to have disappeared. In particular, the -requirement that an SMTP implementation support timeouts has become a MUST. -Also, conformance to this specification requires support of EHLO. Older -systems should claim conformance to the [to-be-historical] 821, not this -specification. - -X.1.7. Substantive changes between draft-ietf-drums-smtpupd-06.txt and -draft-ietf-drums-smtpupd-07.txt. - -(i) Removed "implied RSET" text associated with QUIT, as specified at the -December 1997 IETF - -(ii) Required that servers support EHLO, as specified at the December 1997 -IETF - -X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt and -draft-ietf-drums-smtpupd-08.txt. - -This version involves mostly editorial work and cleanup of loose ends. - -(iii) Error code presentation has been restructured. - -(iv) ABNF conversion done - -(v) IPv6 address format inserted per RFC 1884, since we could not get clear -agreement on an alternative. - -(vi) Trivial, silly, examples removed. Others not yet renumbered. - -(vii) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes. Eric may -not like the way I've done either of these change very much: the first now -makes the distinction between returning an address and returning other -stuff (which was permitted by -06, but the text wasn't as clear as it -should have been): if it looks like an address, it needs to be an address. -Similarly, with 4.1.1, Eric wanted to explicitly permit/legitimize "DATA -<SP> <CRLF>". I see several disadvantages to doing that, so have inserted -language that encourages receivers to tolerate trailing white space, which -may have the same practical effect. - -X.1.8. Substantive changes between draft-ietf-drums-smtpupd-04.txt and -draft-ietf-drums-smtpupd-05.txt. - -This version is substantially a cleanup, with several clarifications. In -addition - -(i) New 7.5 added (old one renumbered) to discuss info disclosure through -Received fields. - -(ii) Some character set and minor syntax issues clarified. - -(iii) Material on code 571 added (thought this had been done long ago; -slipped through the cracks) - -(iv) Many clarifications added as the result of list discussions and -suggestions. (v) First serious attempt at putting the syntax into ABNF -form. Still not complete. - -X.2 Loose ends - -<< All issues in this section are still open.>> - -(i) The 821 BNF -> ABNF transition needs careful checking. - -(ii) Trace field discussion should be checked carefully, particularly since -the syntax given is slightly different from 821. Provision has been made, -reflecting some current practice, for (optional) fractional seconds in time -stamps. - -(iii) Remaining syntax differences and redundancies with respect to 822bis -(see note on section 4.1.2). Note that the use of "Atom" for extension -parameter keywords is slightly different from the specification in RFC -1869. - -(vi) We don't have a satisfactory definition for "link" as in "Received:.. -via <link>" and, if there is a registry, I can't find it. Needs to be -fixed somehow. - -Z. Full Copyright Statement - -Copyright (C) The Internet Society (1998). All Rights Reserved. - -This document and translations of it may be copied and furnished to others, -and derivative works that comment on or otherwise explain it or assist in -its implementation may be prepared, copied, published and distributed, in -whole or in part, without restriction of any kind, provided that the above -copyright notice and this paragraph are included on all such copies and -derivative works. However, this document itself may not be modified in any -way, such as by removing the copyright notice or references to the Internet -Society or other Internet organizations, except as needed for the purpose -of developing Internet standards in which case the procedures for -copyrights defined in the Internet Standards process must be followed, or -as required to translate it into languages other than English. - -The limited permissions granted above are perpetual and will not be revoked -by the Internet Society or its successors or assigns. - -This document and the information contained herein is provided on an "AS -IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE -DISCLAIMS 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. - - - diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-09.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-09.txt deleted file mode 100644 index 8f7aa50b..00000000 --- a/Documentation/en/I-D/draft-ietf-drums-smtpupd-09.txt +++ /dev/null @@ -1,3734 +0,0 @@ -INTERNET-DRAFT John C. Klensin, Editor -Expires June 1999 -December 29, 1998 - - - Simple Mail Transfer Protocol - - draft-ietf-drums-smtpupd-09.txt - -Status of this Memo - -This document is an Internet-Draft. 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." - -To view the entire list of current Internet-Drafts, please check the -"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow -Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), -ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), -ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - -[[Sections marked with doubled brackets (e.g., "<<") are explicit -placeholders or known major loose ends. Please review these ASAP. The -sections with these placeholders are 4.1.2, 4.4, and X.2.]] - -[[Appendix X will be removed before the document is submitted to the -IESG.]] - -[[If consensus is reached on this document, it will be forwarded to the -IESG with the recommendation that it be processed onto the Standards -track.]] - -Copyright Notice - -Copyright (C) The Internet Society (1998). All Rights Reserved. - - Table of Contents - -0. Abstract - -1. Introduction - -2. The SMTP Model -2.1 Basic Structure -2.2 The Extension Model -2.2.1 Background -2.2.2 Definition and Registration of Extensions -2.3 Terminology -2.3.1 Mail Objects -2.3.2 Senders and Receivers -2.3.3 Mail Agents -2.3.4 Host -2.3.5 Domain -2.3.6 Buffer and State Table -2.3.7 Lines -2.3.8 Originator, Delivery, Relay, and Gateway Systems -2.3.9 Message Content and Mail Data -2.3.10 Mailbox and Address -2.3.11 Reply -2.4 Syntax Principles -2.4.1 General Syntax and Transaction Model -2.4.2 Command and Reply Syntax - -3. The SMTP Procedures: An Overview -3.1 Session Initiation -3.2 Client Initiation -3.3 Mail Transactions -3.4 Forwarding for Address Correction or Updating -3.5 Commands for Debugging Addresses -3.5.1 Overview -3.5.2 VRFY Normal Response -3.5.3 Meaning of VRFY or EXPN Success Response -3.5.4 Semantics and Applications of EXPN -3.6 Domains -3.7 Relaying -3.8 Mail Gatewaying -3.8.1 Header Fields in Gatewaying -3.8.2 Received Lines in Gatewaying -3.8.3 Addresses in Gatewaying -3.8.4 Other Header Fields in Gatewaying -3.8.5 Envelopes in Gatewaying -3.9 Terminating Sessions and Connections -3.10 Mailing Lists and Aliases -3.10.1 Alias -3.10.2 List - -4. The SMTP Specifications -4.1 SMTP Commands -4.1.1 Command Semantics and Syntax -4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) -4.1.1.2 MAIL (MAIL) -4.1.1.3 RECIPIENT (RCPT) -4.1.1.4 DATA (DATA) -4.1.1.5 RESET (RSET) -4.1.1.6 VERIFY (VRFY) -4.1.1.7 EXPAND (EXPN) -4.1.1.8 HELP (HELP) -4.1.1.9 NOOP (NOOP) -4.1.1.10 QUIT (QUIT) -4.1.2 Lower-level Syntax -4.1.3 Address Literals -4.1.4 Order of Commands -4.1.5 Private-use Commands -4.2 SMTP Replies -4.2.1 Reply Code Severities and Theory -4.2.2 Reply Codes by Function Groups -4.2.3 Reply Codes in Numeric Order -4.2.4 Reply Code 502 -4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> -4.3 Sequencing of Commands and Replies -4.3.1 Sequencing Overview -4.3.2 Command-Reply Sequences -4.4 Trace Information -4.5 Additional Implementation Issues -4.5.1 Minimum Implementation -4.5.2 Transparency -4.5.3 Sizes and Timeouts -4.5.4 Queuing Strategies -4.5.4.1 Sending Strategy -4.5.4.2 Receiving Strategy -4.5.5 Messages with a null reverse-path - -5. Address Resolution and Mail Handling - -6. Problem Detection and Handling -6.1 Reliable Delivery and Replies by Email -6.2 Loop Detection -6.3 Compensating for Irregularities - -7. Security Considerations -7.1 Mail Security and Spoofing -7.2 "Blind" Copies -7.3 VRFY, EXPN, and Security -7.4 Information Disclosure in Announcements -7.5 Information Disclosure in Trace Fields -7.6 Scope of Operation of SMTP Servers - -8. IANA Considerations - -9. References - -10. Editors' Addresses - -11. Acknowledgments - -A. TCP Transport Service -B. Generating SMTP Commands from RFC 822 Headers -C. Source Routes -D. Scenarios -E. Other Gateway Issues -F. Deprecated Features of RFC 821 -X. Change Summary and Loose Ends (Temporary) - - -0. Abstract - -This document is a self-contained specification of the basic protocol for -the Internet electronic mail transport, consolidating and updating: - - - the original SMTP specification of RFC 821 [RFC-821], - - - domain name system requirements and implications for mail transport from - RFC 1035 [RFC-DNS] and RFC 974 [RFC-974], - - - the clarifications and applicability statements in RFC 1123 [RFC-1123], - and - - - material drawn from the SMTP Extension mechanisms [SMTPEXT]. - -It replaces RFC 821, RFC 974, and the mail transport materials of RFC 1123. -However, RFC 821 specifies some features that are not in significant use in -the Internet of the mid-1990s and (in appendices) some additional transport -models. Those sections are omitted here in the interest of clarity and -brevity; readers needing them should refer to RFC 821. - -It also includes some additional material from RFC 1123 that required -amplification. This material has been identified in multiple ways, mostly -by tracking flaming on various lists and newsgroups and problems of unusual -readings or interpretations that have turned up as the SMTP extensions have -been deployed. Where this specification moves beyond consolidation and -actually differs from earlier documents, it supersedes them technically as -well as textually. - -Although SMTP was designed as a mail transport and delivery protocol, this -specification also contains information that is important to its use as a -'mail posting' protocol, as recommended for POP [RFC-POP2, RFC-POP3] and -IMAP [RFC-IMAP4]. - -Section 2.3 provides definitions of terms specific to this document. Except -when the historical terminology is necessary for clarity, this document -uses the current 'client' and 'server' terminology to identify the sending -and receiving SMTP processes, respectively. - -A companion document discusses message headers, message bodies and formats -and structures for them, and their relationship - [MSGFMT]. - - -1. Introduction - -The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer -mail reliably and efficiently. - -SMTP is independent of the particular transmission subsystem and requires -only a reliable ordered data stream channel. While this document -specifically discusses transport over TCP, other transports are possible. -Appendices to RFC 821 describe some of them. - -An important feature of SMTP is its capability to transport mail across -transport service environments, usually referred to as "SMTP mail relaying" -(see section 3.8). A transport service environment might consist of the -mutually-TCP-accessible hosts on the public Internet, the -mutually-TCP-accessible hosts on a firewall-isolated private TCP/IP -Intranet, or hosts in some other LAN or WAN environment utilizing a -different transport-level protocol. It is important to realize that -"transport service environments" are one-to-one with usual definitions of -"networks". A process can communicate directly with another process, and -transport mail using this protocol, through any mutually known and -connected transport service. Conversely, mail can be relayed or gatewayed -between processes in two different transport service environments by a -process known and connected to each of the two transport service -environments. The Mail eXchanger mechanisms of the domain name system -[RFC-DNS, and section 5 of this document] allows the identity of hosts -supporting SMTP relay and gateway processes to be specified. - - -2. The SMTP Model - -2.1 Basic Structure - -The SMTP design can be pictured as: - - +----------+ +----------+ - +------+ | | | | - | User |<-->| | SMTP | | - +------+ | Sender- |Commands/Replies| Receiver-| - +------+ | SMTP |<-------------->| SMTP | +------+ - | File |<-->| | and Mail | |<-->| File | - |System| | | | | |System| - +------+ +----------+ +----------+ +------+ - SMTP client SMTP server - -When an SMTP client has a message to transmit, it establishes a two-way -transmission channel to an SMTP server. The role of an SMTP client is to -transfer mail messages to one or more SMTP servers, or report its failure -to do so. - -The means by which a mail message is transferred to an SMTP client, and how -that client determines the domain name(s) to which mail messages are to be -transferred is a local matter, and is not addressed by this document. In -some cases, the domain name(s) transferred to, or determined by, an SMTP -client will identify the final destination(s) of the mail message. In other -cases, common with SMTP clients associated with implementations of the POP -[RFC-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the SMTP client -is inside an isolated transport service environment, the domain name -determined will identify an intermediate destination through which all mail -messages are to be relayed. SMTP clients that transfer all traffic, -regardless of the target domain names associated with the individual -messages, or that do not maintain queues for retrying message transmissions -that initially cannot be completed, may otherwise conform to this -specification but are not considered fully-capable. Fully-capable SMTP -implementations, including the relays used by these less capable ones, and -their destinations, are expected to support all of the queuing, retrying, -and alternate address functions discussed in this specification. - -The means by which an SMTP client, once it has determined a target domain -name, determines the identity of an SMTP server to which a copy of a -message is to be transferred, and then performs that transfer, is covered -by this document. To effect a mail transfer to an SMTP server, an SMTP -client establishes a two-way transmission channel to that SMTP server. An -SMTP client determines the address of an appropriate host running an SMTP -server by resolving a destination domain name to either an intermediate -Mail eXchanger host or a final target host. - -An SMTP server may be either the ultimate destination or an intermediate -"relay" (that is, it may assume the role of an SMTP client after receiving -the message) or "gateway" (that is, it may transport the message further -using some protocol other than SMTP). SMTP commands are generated by the -SMTP client and sent to the SMTP server. SMTP replies are sent from the -SMTP server to the SMTP client in response to the commands. - -Once the transmission channel is established and initial handshaking -completed, the SMTP client normally initiates a mail transaction. Such a -transaction consists of a series of commands to specify the originator and -destination of the mail and transmission of the message content (including -any headers or other structure) itself. When the same message is sent to -multiple recipients, this protocol encourages the transmission of only one -copy of the data for all recipients at the same destination (or -intermediate relay) host. - -The server responds to each command with a reply; replies may indicate that -the command was accepted, that additional commands are expected, or that a -temporary or permanent error condition exists. Commands specifying the -sender or recipients may include server-permitted SMTP service extension -requests as discussed in section 2.2. The dialog is purposely lock-step, -one-at-a-time, although this can be modified by mutually-agreed extension -requests such as in [RFC-Pipeline]. - -Once a given mail message has been transmitted, the client may either -request that the connection be shut down or may initiate other mail -transactions. In addition, an SMTP client may use a connection to an SMTP -server for ancillary services such as verification of email addresses or -retrieval of mailing list subscriber addresses. - -As suggested above, this protocol provides mechanisms for the transmission -of mail. This transmission normally occurs directly from the sending -user's host to the receiving user's host when the two hosts are connected -to the same transport service. When they are not connected to the same -transport service, transmission occurs via one or more relay SMTP servers. -An intermediate host that acts as either an SMTP relay or as a gateway into -some other transmission environment is usually selected through the use of -the domain name service (DNS) Mail eXchanger mechanism. - -To provide relay capability, the SMTP server is supplied with the name of -the ultimate destination host as well as the destination mailbox name. -Usually, intermediate hosts are determined via the DNS MX record, not by -explicit "source" routing (see appendices C and F.2). - -2.2 The Extension Model - -2.2.1 Background - -In an effort that started in 1990, approximately a decade after RFC 821 was -completed, the protocol was modified with a "service extensions" model that -permits the client and server to agree to utilize shared functionality -beyond the original SMTP requirements. The SMTP extension mechanism defines -a means whereby an extended SMTP client and server may recognize each -other, and the server can inform the client as to the service extensions -that it supports. - -Contemporary SMTP implementations MUST support the basic extension -mechanisms. For instance, servers MUST support the EHLO command even if -they do not implement any specific extensions and clients SHOULD -preferentially utilize EHLO rather than HELO. (However, for compatibility -with older conforming implementations, SMTP clients and servers MUST -support the original HELO mechanisms as a fallback.) Unless the different -characteristics of HELO must be identified for interoperability purposes, -this document discusses only EHLO. - -SMTP is widely deployed and high-quality implementations have proven to be -very robust. However, the Internet community now considers some services to -be important that were not anticipated when the protocol was first -designed. If support for those services is to be added, it must be done in -a way that permits older implementations to continue working acceptably. -The extension framework consists of: - - - The SMTP command EHLO, superseding the earlier HELO, - - - a registry of SMTP service extensions, - - - additional parameters to the SMTP MAIL FROM and RCPT TO commands, and - - - optional replacements for verbs defined in this protocol, such as for - DATA (see [RFC-BDAT]). - -SMTP's strength comes primarily from its simplicity. Experience with many -protocols has shown that protocols with few options tend towards ubiquity, -whereas protocols with many options tend towards obscurity. - -Each and every extension, regardless of its benefits, must be carefully -scrutinized with respect to its implementation, deployment, and -interoperability costs. In many cases, the cost of extending the SMTP -service will likely outweigh the benefit. - -2.2.2 Definition and Registration of Extensions - -The IANA maintains a registry of SMTP service extensions. A corresponding -EHLO keyword value is associated with each extension. Each service -extension registered with the IANA must be defined in a formal -standards-track or IESG-approved experimental protocol document. The -definition must include: - - - the textual name of the SMTP service extension; - - - the EHLO keyword value associated with the extension; - - - the syntax and possible values of parameters associated with the - EHLO keyword value; - - - any additional SMTP verbs associated with the extension (additional - verbs will usually be, but are not required to be, the same as the - EHLO keyword value); - - - any new parameters the extension associates with the MAIL FROM or - RCPT TO verbs; - - - a description of how support for the extension affects the behavior - of a server and client SMTP; and, - - - the increment by which the extension is increasing the maximum - length of the commands MAIL FROM and/or RCPT TO, over that specified - in this standard. - -In addition, any EHLO keyword value starting with an upper or lower case -"X" refers to a local SMTP service extension used exclusively through -bilateral agreement. Keywords beginning with "X" MUST NOT be used in a -registered service extension. Conversely, keyword values presented in the -EHLO response that do not begin with "X" MUST correspond to a standard, -standards-track, or IESG-approved experimental SMTP service extension -registered with IANA. A conforming server MUST NOT offer non-"X"-prefixed -keyword values that are not described in a registered extension. - -Additional verbs and parameter names are bound by the same rules as EHLO -keywords; specifically, verbs beginning with "X" are local extensions that -may not be registered or standardized. Conversely, verbs not beginning -with "X" must always be registered. - -2.3 Terminology - -Most of the terminology in this document is common in the Internet at the -time of its writing. However, the following terms and concepts are used -in special ways here, or represent differences in terminology between RFC -821 and this document, and should be understood before reading further. -These definitions are normative, that is, they contain specifications to -which SMTP implementations are required to conform. - -The terms "MUST" and "SHOULD" (and "MUST NOT" and "SHOULD NOT") are used -in the same general sense here as in the Host Requirements Standards -[RFC-1123]. Specifically, "MUST" or "MUST NOT" identify absolute -requirements for conformance to this specification. Implementations that -do not conform to them lie outside the scope of this specification and -often will not interoperate properly with SMTP implementations that do -conform. Implementations that are fully conforming also adhere to all -"SHOULD" and "SHOULD NOT" requirements. Implementations that adhere to -all "MUST" ("MUST NOT") but not to all of these are considered to be -partially conforming. Such implementations may interoperate properly with -fully conforming ones and with each other, but this will typically be the -case only if great care is taken. Consequently, an implementation should -violation "SHOULD" ("SHOULD NOT") requirements only under exceptional and -well-understood circumstances. "SHOULD" (and sometimes "MUST") -requirements are often imposed by this specification when experience has -shown that following such requirements or restrictions leads, in practice, -to better interoperation, or smoother operation of the Internet email -infrastructure. As a consequence, some of these statements constitute -recommended practices, rather than the statistically most common practice -at the time of this writing. Statements using "MAY" describe features or -styles of doing things that may be followed, or not, at the discretion of -the implementation, normally without causing significant interoperability -problems. - -2.3.1 Mail Objects - -SMTP transports a mail object. A mail object contains an envelope and -content. - -The SMTP envelope is sent as a series of SMTP protocol units (described in -section 3). It consists of an originator address (to which error reports -should be directed); a delivery mode (e.g., deliver to recipient -mailboxes); one or more recipient addresses; and optional protocol -extension material. - -The SMTP content is sent in the SMTP DATA protocol unit and has two parts: -the headers and the body. If the content conforms to existing standards, -the headers form a collection of field/value pairs structured as described -in [MSGFMT]; the body, if structured, is defined according to MIME -[RFC-MIME]. The content is textual in nature, expressed using the US-ASCII -repertoire [US-ASCII]. Although SMTP extensions (such as [8BitMIME]) may -relax this restriction for the content body, the content headers are always -encoded using the US-ASCII repertoire. The algorithm defined in -[RFC-INTLHDR] is used to represent header values outside the US-ASCII -repertoire, while still encoding them using the US-ASCII repertoire. - -2.3.2 Senders and Receivers - -In RFC 821, the two hosts participating in an SMTP transaction were -described as the "SMTP-sender" and "SMTP-receiver". This document has been -changed to reflect current industry terminology and hence refers to them as -the "SMTP client" (or sometimes just "the client") and "SMTP server" (or -just "the server"), respectively. Since a given host may act both as -server and client in a relay situation, "receiver" and "sender" terminology -is still used where needed for clarity. - -2.3.3 Mail Agents - -Additional mail system terminology became common after RFC 821 was -published and, where convenient, is used in this specification. In -particular, SMTP servers and clients provide a mail transport service and -therefore act as Mail Transfer Agents (MTAs). Mail User Agents (MUAs or -UAs) are normally thought of as the sources and targets of mail. At the -source, an MUA might collect mail to be transmitted from a user and hand it -off to an MTA; the final ("delivery") MTA would be thought of as handing -the mail off to an MUA (or at least transferring responsibility to it). -However, while these terms are used with at least the appearance of great -precision in other environments, the implied boundaries between MUAs and -MTAs often do not accurately match common, and conforming, practices with -Internet mail. Hence, the reader should be cautious about inferring the -strong relationships and responsibilities that might be implied if these -terms were used elsewhere. - -2.3.4 Host - -For the purposes of this specification, a host is a computer system -attached to the Internet (or, in some cases, to a private TCP/IP network) -and supporting the SMTP protocol. Hosts are known by names (see "domain"); -identifying them by numerical address is discouraged. - -2.3.5 Domain - -A domain (or domain name) consists of one or more dot-separated components, -each consisting of a sequence of letters, digits, and hyphens. Domain -names are used as names of hosts and of other entities in the domain name -hierarchy. For example, a domain may refer to an alias (label of a CNAME -RR) or the label of Mail eXchanger records to be used to deliver mail -instead of representing a host name. See [RFC-DNS] and section 5. - -The domain name, as described in this document and in [RFC-DNS], is the -entire, fully-qualified name (often referred to as an "FQDN"). A domain -name that is not in FQDN form is no more than a local alias. Local aliases -MUST NOT appear in any SMTP transaction. - -2.3.6 Buffer and State Table - -SMTP sessions are stateful, with both parties carefully maintaining a -common view of the current state. In this document we model this state by -a virtual "buffer" and a "state table" on the server which may be used by -the client to, for example, "clear the buffer" or "reset the state table," -causing the information in the buffer to be discarded and the state to be -returned to some previous state - -2.3.7 Lines - -SMTP commands and, unless altered by a service extension, message data, are -transmitted in "lines". Lines consist of zero or more data characters -terminated by the sequence ASCII character "CR" (hex value 0D) followed -immediately by ASCII character "LF" (hex value 0A). This termination -sequence is denoted as <CRLF> in this document. Conforming implementations -MUST NOT recognize or generate any other character or character sequence as -a line terminator. - -2.3.8 Originator, Delivery, Relay, and Gateway Systems - -This specification makes a distinction among four types of SMTP systems, -based on the role those systems play in transmitting electronic mail. An -"originating" system (sometimes called an SMTP originator) introduces mail -into the Internet or, more generally, into a transport service environment. -A "delivery" SMTP system is one that receives mail from a transport service -environment and hands it to a mail user agent or deposits it in a message -store which a mail user agent is expected to subsequently access. A -"relay" SMTP system (usually referred to just as a "relay") receives mail -from an SMTP client and transmits it, without modification to the message -data other than adding trace information, to another SMTP server for -further relaying or for delivery. - -A "gateway" SMTP system (usually referred to just as a "gateway") receives -mail from a client system in one transport environment and transmits it to -a server system in another transport environment. Differences in protocols -or message semantics between the transport environments on either side of a -gateway may require that the gateway system perform transformations to the -message that are not permitted to SMTP relay systems. - -2.3.9 Message Content and Mail Data - -The terms "message content" and "mail data" are used interchangeably in -this document to describe the material transmitted after the DATA command -is accepted and before the end of data indication is transmitted. Message -content includes message headers and the possibly-structured message body. -The MIME specification [RFC-MIME] provides the Standard mechanisms for -structured message bodies. - -2.3.10 Mailbox and Address - -As used in this specification, an "address" is a character string that -identifies a user to whom mail will be sent or a location into which mail -will be deposited. The term "mailbox" refers to that depository. The two -terms are typically used interchangeably unless the distinction between the -location in which mail is placed (the mailbox) and a reference to it (the -address) is important. An address normally consists of user and domain -specifications. The standard mailbox naming convention is defined to be -"local-part@domain": contemporary usage permits a much broader set of -applications than simple "user names" and, consequently, the local-part is -interpreted and assigned semantics only by the host specified in the domain -part of the address. - -2.3.11 Reply - -An SMTP reply is an acknowledgment (positive or negative) sent from -receiver to sender via the transmission channel in response to a command. -The general form of a reply is a numeric completion code (indicating -failure or success) usually followed by a text string. The codes are for -use by programs and the text is usually intended for human users. - -2.4 Syntax Principles - -2.4.1 General Syntax and Transaction Model - -SMTP commands and replies have a rigid syntax. All commands begin with a -four letter command verb. All Replies begin with a three digit numeric -code. In some commands and replies, arguments MUST follow the verb or reply -code. Some commands do not accept arguments (after the verb), and some -reply codes are followed, sometimes optionally, by free form text. In both -cases, where text appears, it is separated from the verb or reply code by a -<SP>. Complete definitions of commands and replies appear in section 4. - -Verbs and argument values are not case sensitive, with the sole -exception in this specification of a mailbox local-part (SMTP -Extensions may explicitly specify case-sensitive elements). That is, a -command verb, an argument value other than a mailbox local-part, and -free form text MAY be encoded in upper case, lower case, or any mixture -of upper and lower case with no impact on its meaning. This is NOT -true of a mailbox local-part. The local-part of a mailbox MUST BE -treated as case sensitive. Therefore, SMTP implementations MUST take -care to preserve the case of mailbox local-parts. Mailbox domains are -not case sensitive. However, exploiting the case sensitivity of -mailbox local-parts impedes interoperability and is discouraged. - -Commands and replies are composed of characters from the ASCII character -set [US-ASCII]. When the transport service provides an 8-bit byte (octet) -transmission channel, each 7-bit character is transmitted right justified -in an octet with the high order bit cleared to zero. More specifically, the -unextended SMTP service provides seven bit transport only. An originating -SMTP client which has not successfully negotiated an appropriate extension -with a particular server MUST NOT transmit messages with information in the -high-order bit of octets. If such messages are transmitted in violation of -this rule, receiving SMTP servers MAY clear the high-order bit or reject -the message as invalid. In general, a relay SMTP SHOULD assume that the -message content it has received is valid and, assuming that the envelope -permits doing so, relay it without inspecting that content. Of course, if -the content is mislabeled and the data path cannot accept the actual -content, this may result in ultimate delivery of a severely garbled message -to the recipient. Delivery SMTP systems MAY reject ("bounce") such -messages rather than deliver them. No sending SMTP system is permitted to -send envelope commands in any character set other than US-ASCII; receiving -systems SHOULD reject such commands, normally using "500 syntax error - -invalid character" replies. - -Eight-bit message content transmission MAY be requested of the server by a -client using extended SMTP facilities, notably the "8BITMIME" extension -[8BITMIME]. 8BITMIME SHOULD be supported by SMTP servers. However, it MUST -not be construed as authorization to transmit unrestricted eight bit -material. 8BITMIME MUST NOT be requested by senders for material with the -high bit on that is not in MIME format with an appropriate content-transfer -encoding; servers MAY reject such messages. - -The metalinguistic notation used in this document corresponds to the -"Augmented BNF" used in other Internet mail system documents. The reader -who is not familiar with that syntax should consult [ABNF]. Metalanguage -terms used in running text are surrounded by pointed brackets (e.g., -<CRLF>) for clarity. - -2.4.2 Command and Reply Syntax - -The commands consist of a command verb followed by an argument field. -Command verbs are four alphabetic characters and are case insensitive. - -This also applies to any symbols representing parameter values, such as -"TO" or "to" for the forward-path. Command verbs and the argument fields -are separated by one or more spaces. However, case is important in the -local-part within the reverse-path and forward-path arguments. In -particular, for some hosts the user "smith" is different from the user -"Smith". - -A few SMTP servers, in violation of this specification (and RFC 821) -require that command verbs and certain argument text (such as the -forward-path and reverse-path in RCPT and MAIL commands) be encoded by -clients in upper case. Implementations MAY wish to employ this encoding to -accommodate those servers. - -The argument field consists of a variable length character string ending -with the character sequence <CRLF>. The receiver will take no action until -this sequence is received. - -The syntax for each command is shown with the discussion of that command. -Common elements and parameters are shown in section 4.1.2. - - -3. The SMTP Procedures: An Overview - -This section contains descriptions of the procedures used in SMTP: session -initiation, the mail transaction, forwarding mail, verifying mailbox names -and expanding mailing lists, and the opening and closing exchanges. -Comments on relaying, a note on mail domains, and a discussion of changing -roles are included at the end of this section. Several complete scenarios -are presented in appendix D. - -3.1 Session Initiation - -An SMTP session is initiated when a client opens a connection to a server -and the server responds with an opening message. - -SMTP server implementations MAY include identification of their software -and version information in the connection greeting reply after the 220 -code, a practice that permits more efficient isolation and repair of any -problems. Implementations MAY make provision for SMTP servers to disable -the software and version announcement where it causes security concerns. -While some systems also identify their contact point for mail problems, -this is not a substitute for maintaining the required "postmaster" address -(see section 4.5.1). - -The SMTP protocol allows a server to formally reject a transaction while -still allowing the initial connection as follows: a 554 response MAY be -given in the initial connection opening message instead of the 220. A -server taking this approach MUST still wait for the client to send a QUIT -(see section 4.1.1.10) before closing the connection and SHOULD respond to -any intervening commands with "503 bad sequence of commands". Since an -attempt to make an SMTP connection to such a system is probably in error, a -server returning a 554 response on connection opening SHOULD provide enough -information in the reply text to facilitate debugging of the sending -system. - -3.2 Client Initiation - -Once the server has sent the welcoming message and the client has received -it, the client normally sends the EHLO command to the server, indicating -the client's identity. In addition to opening the session, use of EHLO -indicates that the client is able to process service extensions and -requests that the server provide a list of the extensions it supports. -Older SMTP systems which are unable to support service extensions and -contemporary clients which do not require service extensions in the mail -session being initiated, MAY use HELO instead of EHLO. Servers MUST NOT -return the extended EHLO-style response to a HELO command. - -In the EHLO command the host sending the command identifies itself; the -command may be interpreted as saying "Hello, I am <domain>" (and, in the -case of EHLO, "and I support service extension requests"). - -3.3 Mail Transactions - -There are three steps to SMTP mail transactions. The transaction starts -with a MAIL command which gives the sender identification. A series of one -or more RCPT commands follows giving the receiver information. Then a DATA -command initiates transfer of the mail data and is terminated by the "end -of mail" data indicator, which also confirms the transaction. - -The first step in the procedure is the MAIL command. - - MAIL FROM:<reverse-path> [ <mail-parameters> ] <CRLF> - -This command tells the SMTP-receiver that a new mail transaction is -starting and to reset all its state tables and buffers, including any -recipients or mail data. The <reverse-path> contains the source mailbox -(between "<" and ">" brackets, which can be used to report errors (see -section 4.2 for a discussion of error reporting). If accepted, the -SMTP server returns a 250 OK reply. If the mailbox specification is -not acceptable for some reason, the server MUST return a reply -indicating whether the failure is permanent (i.e., will occur again if -the client tries to send the same address again) or temporary (i.e., -the address might be accepted if the client tries again later). Despite -the apparent scope of this requirement, there are circumstances in -which the acceptability of the reverse-path may not be determined until -one or more forward-paths (in RCPT commands) can be examined. In those -cases, the server MAY reasonably accept the reverse-path (with a 250 -reply) and then report problems after the forward-paths are received -and examined. Normally, failures produce 550 or 553 replies. - -Historically, the <reverse-path> can contain more than just a mailbox, -however, contemporary systems SHOULD NOT use source routing (see appendix -C). - -The optional <mail-parameters> are associated with negotiated SMTP service -extensions (see section 2.2). - -The second step in the procedure is the RCPT command. - - RCPT TO:<forward-path> [ <SP> <rcpt-parameters> ] <CRLF> - -This command gives a forward-path (normally a mailbox and domain, -always surrounded by "<" and ">" brackets) identifying one recipient. -If accepted, the SMTP server returns a 250 OK reply and stores the -forward-path. If the recipient is known not to be a deliverable -address, the SMTP server returns a 550 reply, typically with a string -such as "no such user - " and the mailbox name (other circumstances and -reply codes are possible). This step of the procedure can be repeated -any number of times. - -The <forward-path> can contain more than just a mailbox. Historically, the -<forward-path> can be a source routing list of hosts and the destination -mailbox, however, contemporary SMTP clients SHOULD NOT utilize source -routes (see appendix C). Servers MUST be prepared to encounter a list of -source routes in the forward path, but SHOULD ignore the routes or MAY -decline to support the relaying they imply. Similarly, servers MAY decline -to accept mail that is destined for other hosts or systems. These -restrictions make a server useless as a relay for clients that do not -support full SMTP functionality. Consequently, restricted-capability -clients MUST NOT assume that any SMTP server on the Internet can be used as -their mail processing (relaying) site. If RCPT TO appears without a -previous MAIL FROM, the server MUST return a 503 "Bad sequence of commands" -response. The optional <rcpt-parameters> are associated with negotiated -SMTP service extensions (see section 2.2). - -The third step in the procedure is the DATA command (or some alternative -specified in a service extension). - - DATA <CRLF> - -If accepted, the SMTP server returns a 354 Intermediate reply and considers -all succeeding lines up to but not including the end of mail data indicator -to be the message text. When the end of text is successfully received and -stored the SMTP-receiver sends a 250 OK reply. - -Since the mail data is sent on the transmission channel, the end of mail -data must be indicated so that the command and reply dialog can be resumed. -SMTP indicates the end of the mail data by sending a line containing only a -"." (period or full stop). A transparency procedure is used to prevent -this from interfering with the user's text (see section 4.5.2). - -The end of mail data indicator also confirms the mail transaction and tells -the SMTP server to now process the stored recipients and mail data. If -accepted, the SMTP server returns a 250 OK reply. The DATA command can fail -in only two ways: - - - If there was no MAIL FROM, or no RCPT TO, command, or all such commands - were rejected, the server MAY return a "command out of sequence" (503) - reply. If that reply is received, the client MUST NOT send the message - data; more generally, message data MUST NOT be sent unless a 354 reply - is received. - - - If the verb is initially accepted and the 354 reply issued, the DATA - command should fail only if the mail transaction was incomplete (for - example, no recipients), or if resources were unavailable, or if the - server determines that the message should be rejected for policy or - other reasons. - -However, in practice, some servers do not perform recipient verification -until after the message text is received. These servers SHOULD treat a -failure for one or more recipients as a "subsequent failure" and return a -mail message as discussed in section 6. Using a "550 mailbox not found" -(or equivalent) reply code after the data are accepted makes it difficult -or impossible for the client to determine which recipients failed. - -When RFC 822 format is being used, the mail data include the memo header -items such as Date, Subject, To, Cc, From [MSGFMT]. Server SMTP systems -SHOULD NOT reject messages based on perceived defects in the RFC 822 or -MIME [RFC-MIME] message header or message body. In particular, they MUST -NOT reject messages in which the numbers of Resent- fields do not match or -Resent-to appears without Resent-from and/or Resent-date. - -Mail transaction commands MUST be used in the order discussed above. - - -3.4 Forwarding for Address Correction or Updating - -Forwarding support is most often required to consolidate and simplify -addresses within, or relative to, some enterprise and less frequently to -establish addresses to link a person's prior address with current one. -Silent forwarding of messages (without server notification to the sender), -for security or non-disclosure purposes, is common in the contemporary -Internet. - -In both the enterprise and the "new address" cases, information hiding -(and sometimes security) considerations argue against exposure of the -"final" address through the SMTP protocol as a side-effect of the -forwarding activity. This may be especially important when the final -address may not even be reachable by the sender. Consequently, the -"forwarding" mechanisms described in section 3.2 of RFC 821, and -especially the 251 (corrected destination) reply code from RCPT TO are -deprecated: Servers SHOULD NOT provide that service or return that code. - - -3.5 Commands for Debugging Addresses - -3.5.1 Overview - -SMTP provides commands to verify a user name or obtain the content of a -mailing list. This is done with the VRFY and EXPN commands, which have -character string arguments. Implementations SHOULD support VRFY and EXPN -(however, see section 3.5.2 and 7.3). - -For the VRFY command, the string is a user name or a user name and domain -(see below). If a normal (i.e., 250) response is returned, the response MAY -include the full name of the user and MUST include the mailbox of the user. -It MUST be in either of the following forms: - - User Name <local-part@domain> - local-part@domain - -When a name that is the argument to VRFY could identify more than one -mailbox, the server MAY either note the ambiguity or identify the -alternatives. In other words, any of the following are legitimate -response to VRFY: - - 553 User ambiguous - -or - - 553- Ambiguous; Possibilities are - 553-Joe Smith <jsmith@foo.com> - 553-Harry Smith <hsmith@foo.com> - 553 Melvin Smith <dweep@foo.com> - -or - - 553-Ambiguous; Possibilities - 553- <jsmith@foo.com> - 553- <hsmith@foo.com> - 553 <dweep@foo.com> - -Under normal circumstances, a client receiving a 553 reply would be -expected to expose the result to the user. Use of exactly the forms -given, and the "user ambiguous" or "ambiguous" keywords, possibly -supplemented by extended reply codes such as those described in -[RFC-REPLY], will facilitate automated translation into other languages as -needed. Of course, a client that was highly automated or that was -operating in another language than English, might choose to try to -translate the response, to return some other indication to the user than -the literal text of the reply, or to take some automated action such as -consulting a directory service for additional information before reporting -to the user. - -For the EXPN command, the string identifies a mailing list, and the -successful (i.e., 250) multiline response MAY include the full name of the -users and MUST give the mailboxes on the mailing list. - -In some hosts the distinction between a mailing list and an alias for a -single mailbox is a bit fuzzy, since a common data structure may hold both -types of entries, and it is possible to have mailing lists of one mailbox. -If a request is made to verify a mailing list, a positive response MAY be -given if a message so addressed would be delivered to everyone on the list, -otherwise an error SHOULD be reported (e.g., "550 That is a mailing list, -not a user" or "252 Unable to verify members of mailing list"). If a -request is made to expand a user name, the server MAY return a positive -response consisting of a list containing one name, or an error MAY be -reported (e.g., "550 That is a user name, not a mailing list"). - -In the case of a successful multiline reply (normal for EXPN) exactly one -mailbox is to be specified on each line of the reply. The case of an -ambiguous request is discussed above. - -"User name" is a fuzzy term and has been used deliberately. An -implementation of the VRFY or EXPN commands MUST include at least -recognition of local mailboxes as "user names". However, since current -Internet practice often results in a single host handling mail for -multiple domains, hosts, especially hosts that provide this functionality, -SHOULD accept the "local-part@domain" form as a "user name"; hosts MAY -also choose to recognize other strings as "user names". - -The case of expanding a mailbox list requires a multiline reply, such as: - - C: EXPN Example-People - S: 250-Jon Postel <Postel@isi.edu> - S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu> - S: 250 Sam Q. Smith <SQSmith@specific.generic.com> - -or - - C EXPN Executive-Washroom-List - S: 550 Access Denied to You. - -The character string arguments of the VRFY and EXPN commands cannot be -further restricted due to the variety of implementations of the user name -and mailbox list concepts. On some systems it may be appropriate for the -argument of the EXPN command to be a file name for a file containing a -mailing list, but again there are a variety of file naming conventions in -the Internet. Similarly, historical variations in what is returned by -these commands are such that the response SHOULD be interpreted very -carefully, if at all, and SHOULD generally only be used for diagnostic -purposes. - -3.5.2 VRFY Normal Response - -When normal (2yz or 551) responses are returned from a VRFY or EXPN -request, the reply MUST normally include the mailbox name. -"<local-part@domain>", where "domain" is a fully qualified domain name, -MUST appear in the syntax. In exceptional circumstances, free-form text -MAY be returned. In order to facilitate parsing by both computers and -people, addresses SHOULD appear in pointed brackets. When addresses, -rather than free-form debugging information, are returned, EXPN and VRFY -MUST return only valid domain addresses that are usable in SMTP RCPT -commands. Consequently, if an address implies delivery to a program or -other system, the mailbox name used to reach that target MUST be given. -Paths (explicit source routes) MUST NOT be returned by VRFY or EXPN. - -Server implementations SHOULD support both VRFY and EXPN. For security -reasons, implementations MAY provide local installations a way to disable -either or both of these commands through configuration options or the -equivalent. When these commands are supported, they are not required to -work across relays when relaying is supported. Since they were both -optional in RFC 821, they MUST be listed as service extensions in an EHLO -response, if they are supported. - -3.5.3 Meaning of VRFY or EXPN Success Response - -A server MUST NOT return a 220 code in response to a VRFY or EXPN command -unless it has actually verified the address. In particular, a server MUST -NOT return 220 if all it has done is to verify that the syntax given is -valid. In that case, 502 (Command not implemented) or 500 (Syntax error, -command unrecognized) SHOULD be returned. As stated elsewhere, -implementation of VRFY and EXPN are strongly recommended. -Hence, implementations that return 500 or 502 for VRFY are not in full -compliance with this specification. - -There may be circumstances where an address appears to be valid but cannot -reasonably be verified in real time, particularly when a server is acting -as a mail exchanger for another server or domain. "Apparent validity" in -this case would normally involve at least syntax checking and might -involve verification that any domains specified were ones to which the -host expected to be able to relay mail. In these situations, reply code -252 SHOULD be returned. These cases parallel the discussion of RCPT -verification discussed in section 2.1. Implementations generally SHOULD -be more aggressive about address verification in the case of VRFY than in -the case of RCPT, even if it takes a little longer to do so. - -3.5.4 Semantics and Applications of EXPN - -EXPN is often very useful in debugging and understanding problems with -mailing lists and multiple-target-address aliases. Some systems have -attempted to use source expansion of mailing lists as a means of -eliminating duplicates. The propagation of aliasing systems with mail on -the Internet, for hosts (typically with MX and CNAME DNS records), for -mailboxes (various types of local host aliases), and in various proxying -arrangements, has made it nearly impossible for these strategies to work, -and mail systems SHOULD NOT attempt them. - -3.6 Domains - -Only resolvable, fully-qualified, domain names (FQDNs) are permitted when -domain names are used in SMTP. In other words, names that can be resolved -to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME -RRs whose targets can be resolved, in turn, to MX or A RRs. Local -nicknames or unqualified names MUST NOT be used. There are two exceptions -to the rule requiring FQDNs: - - - The domain name given in the EHLO command MUST BE either a primary host - name (a domain name that resolves to an A RR) or, if the host has no - name, an address literal as described in section 4.1.1.1. - - - The reserved mailbox name "postmaster" may be used in a RCPT TO command - without domain qualification (see section 4.1.1.3) and MUST be accepted - if so used. - -3.7 Relaying - -In general, the availability of Mail eXchanger records in the domain name -system [RFC-DNS] makes the use of explicit source routes in the Internet -mail system unnecessary. Many historical problems with their -interpretation have made their use undesirable. SMTP clients SHOULD NOT -generate explicit source routes except under unusual circumstances. SMTP -servers MAY decline to act as mail relays or to accept addresses that -specify source routes. When route information is encountered, they are -also permitted to ignore the route information and simply send to the final -destination specified as the last element in the route and SHOULD do so. -There has been an invalid practice of using names that do not appear in the -DNS as destination names, with the senders counting on the intermediate -hosts specified in source routing to resolve any problems. If source -routes are stripped, this practice will cause failures. This is one of -several reasons why SMTP clients MUST NOT generate invalid source routes or -depend on serial resolution of names. - -When source routes are not used, the process described in RFC 821 for -constructing a reverse-path from the forward-path is not applicable and the -reverse-path at the time of delivery will simply be the address that -appeared in the MAIL command. - -A relay SMTP server is usually the target of a DNS MX record that -designates it, rather than the final delivery system. The relay server may -accept or reject the task of relaying the mail in the same way it accepts -or rejects mail for a local user. If it accepts the task, it then becomes -an SMTP client, establishes a transmission channel to the next SMTP server -specified in the DNS (according to the rules in section 5), and sends it -the mail. If it declines to relay mail to a particular address for policy -reasons, a 550 response SHOULD be returned. - -If an SMTP server has accepted the task of relaying the mail and later -finds that the destination is incorrect or that the mail cannot be -delivered for some other reason, then it MUST construct an "undeliverable -mail" notification message and send it to the originator of the -undeliverable mail (as indicated by the reverse-path). Formats specified -for non-delivery reports by other standards (see, for example, -[RFC-NOTARY1]) SHOULD be used if possible. - -This notification message must be from the SMTP server at the relay host -or the host that first determines that delivery cannot be accomplished. -Of course, SMTP servers MUST NOT send notification messages about problems -transporting notification messages. One way to prevent loops in error -reporting is to specify a null reverse-path in the MAIL command of a -notification message. When such a message is transmitted the reverse-path -MUST be set to null (see section 4.5.5 for additional discussion). A MAIL -command with a null reverse-path appears as follows: - - MAIL FROM:<> - -As discussed in section 2.4.1, a relay SMTP has no need to inspect or act -upon the headers or body of the message data and MUST NOT do so except -to add its own "Received:" header (section 4.4) and to perform simple -counting of the number of "Received:" headers in a message (section 6.2). - -3.8 Mail Gatewaying - -While the relay function discussed above operates within the Internet SMTP -transport service environment, MX records or various forms of explicit -routing may require that an intermediate SMTP server perform a translation -function between one transport service and another. As discussed in -section 2.3.8, when such a system is at the boundary between two transport -service environments, we refer to it as a "gateway" or "gateway SMTP". - -Gatewaying mail between different mail environments, such as different mail -formats and protocols, is complex and does not easily yield to -standardization. However, some general requirements may be given for a -gateway between the Internet and another mail environment. - -3.8.1 Header Fields in Gatewaying - -Header fields MAY be rewritten when necessary as messages are gatewayed -across mail environment boundaries. This may involve inspecting the message -body or interpreting the local-part of the destination address in spite of -the prohibitions in section 2.4.1 - -Other mail systems gatewayed to the Internet often use a subset of RFC-822 -headers or provide similar functionality with a different syntax, but some -of these mail systems do not have an equivalent to the SMTP envelope. -Therefore, when a message leaves the Internet environment, it may be -necessary to fold the SMTP envelope information into the message header. A -possible solution would be to create new header fields to carry the -envelope information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, -this would require changes in mail programs in foreign environments and -might risk disclosure of private information (see section 7.2). - -3.8.2 Received Lines in Gatewaying - -When forwarding a message into or out of the Internet environment, a -gateway MUST prepend a Received: line, but it MUST NOT alter in any way a -Received: line that is already in the header. - -Received: fields of messages originating from other environments may not -conform exactly to this specification. However, the most important use of -Received: lines is for debugging mail faults, and this debugging can be -severely hampered by well-meaning gateways that try to "fix" a Received: -line. As another consequence of trace fields arising in non-SMTP -environments, receiving systems MUST NOT reject mail based on the format of -a trace field and SHOULD be extremely robust in the light of unexpected -information or formats in those fields. - -The gateway SHOULD indicate the environment and protocol in the "via" -clauses of Received field(s) that it supplies. - -3.8.3 Addresses in Gatewaying - ->From the Internet side, the gateway SHOULD accept all valid address formats -in SMTP commands and in RFC-822 headers, and all valid RFC-822 messages. -Gateways are, of course, subject to the same rules for handling source -routes as those described for other SMTP systems in section 3.3. - -3.8.4 Other Header Fields in Gatewaying - -The gateway MUST ensure that all header fields of a message that it -forwards into the Internet meet the requirements for Internet mail. In -particular, all addresses in "From:", "To:", "Cc:", etc., fields MUST be -transformed (if necessary) to satisfy RFC-822 syntax, MUST reference only -fully-qualified domain names, and MUST be effective and useful for sending -replies. 3.8.5 The translation algorithm used to convert mail from the -Internet protocols to another environment's protocol SHOULD ensure that -error messages from the foreign mail environment are delivered to the -return path from the SMTP envelope, not to the sender listed in the "From:" -field (or other fields) of the RFC-822 message. - -3.8.5 Envelopes in Gatewaying - -Similarly, when forwarding a message from another environment into the -Internet, the gateway SHOULD set the envelope return path in accordance -with an error message return address, if supplied by the foreign -environment. If the foreign environment has no equivalent concept, the -gateway must select and use a best approximation, with the message -originator's address as the default of last resort. - -3.9 Terminating Sessions and Connections - -An SMTP connection is terminated when the client sends a QUIT command. The -server responds with a positive reply code, after which it closes the -connection. - -An SMTP server MUST NOT intentionally close the connection except: - - - After receiving a QUIT command and responding with a 221 reply. - - - After detecting the need to shutdown the SMTP service and returning a - 421 response code. This response code can be issued after the server - receives any command or, if necessary, asynchronously from command - receipt (on the assumption that the client will receive it after the - next command is issued). - -In particular, a server that closes connections in response to commands -that are not understood is in violation of this specification. Servers are -expected to be tolerant of unknown commands, issuing a 500 reply and -awaiting further instructions from the client. - -An SMTP server which is forcibly shut down via external means SHOULD -attempt to send a line containing a 421 response code to the SMTP client -before exiting. The SMTP client will normally read the 421 response code -after sending its next command. - -SMTP clients that experience a connection close, reset, or other -communications failure due to circumstances not under their control (in -violation of the intent of this specification but sometimes unavoidable) -SHOULD, to maintain the robustness of the mail system, treat the mail -transaction as if a 451 response had been received and act accordingly. - -3.10 Mailing Lists and Aliases - -An SMTP-capable host SHOULD support both the alias and the list models of -address expansion for multiple delivery. When a message is delivered or -forwarded to each address of an expanded list form, the return address in -the envelope ("MAIL FROM:") MUST be changed to be the address of a person -or other entity who administers the list. However, in this case, the -message header (see [MSGFMT]) MUST be left unchanged; in particular, the -"From" field of the message header is unaffected. - -An important mail facility is a mechanism for multi-destination delivery -of a single message, by transforming (or "expanding" or "exploding") a -pseudo-mailbox address into a list of destination mailbox addresses. When -a message is sent to such a pseudo-mailbox (sometimes called an -"exploder"), copies are forwarded or redistributed to each mailbox in the -expanded list. Servers SHOULD simply utilize the addresses on the list; -application of heuristics or other matching rules to eliminate some -addresses, such as that of the originator, is strongly discouraged. We -classify such a pseudo-mailbox as an "alias" or a "list", depending upon -the expansion rules. - -3.10.1 Alias - -To expand an alias, the recipient mailer simply replaces the pseudo-mailbox -address in the envelope with each of the expanded addresses in turn; the -rest of the envelope and the message body are left unchanged. The message -is then delivered or forwarded to each expanded address. - -3.10.2 List - -A mailing list may be said to operate by "redistribution" rather than -by "forwarding". To expand a list, the recipient mailer replaces the -pseudo-mailbox address in the envelope with all of the expanded -addresses. The return address in the envelope is changed so that all -error messages generated by the final deliveries will be returned to a -list administrator, not to the message originator, who generally has no -control over the contents of the list and will typically find error -messages annoying. - - -4. The SMTP Specifications - -4.1 SMTP Commands - -4.1.1 Command Semantics and Syntax - -The SMTP commands define the mail transfer or the mail system function -requested by the user. SMTP commands are character strings terminated by -<CRLF>. The commands themselves are alphabetic characters terminated by -<SP> if parameters follow and <CRLF> otherwise. (In the interest of -improved interoperability, SMTP receivers are encouraged to tolerate -trailing white space before the terminating <CRLF>.) The syntax of the -local part of a mailbox must conform to receiver site conventions and the -syntax specified in section 4.1.2. The SMTP commands are discussed below. -The SMTP replies are discussed in section 4.2. - -A mail transaction involves several data objects which are communicated as -arguments to different commands. The reverse-path is the argument of the -MAIL command, the forward-path is the argument of the RCPT command, and the -mail data is the argument of the DATA command. These arguments or data -objects must be transmitted and held pending the confirmation communicated -by the end of mail data indication which finalizes the transaction. The -model for this is that distinct buffers are provided to hold the types of -data objects, that is, there is a reverse-path buffer, a forward-path -buffer, and a mail data buffer. Specific commands cause information to be -appended to a specific buffer, or cause one or more buffers to be cleared. - -Several commands (RSET, DATA, QUIT) are specified as not permitting -parameters. In the absence of specific extensions offered by the server -and accepted by the client, clients MUST NOT send such parameters and -servers SHOULD reject commands containing them as having invalid syntax. - -4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) - -These commands are used to identify the SMTP client to the SMTP server. -The argument field contains the fully-qualified domain name of the SMTP -client if one is available. In situations in which the SMTP client system -does not have a meaningful domain name (e.g., when its address is -dynamically allocated and no reverse mapping record is available), the -client SHOULD send an address literal (see section 4.1.3), optionally -followed by information that will help to identify the client system. - -The SMTP server identifies itself to the SMTP client in the connection -greeting reply and in the response to this command. - -A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If -the SMTP server supports the SMTP service extensions it will give a -successful response, a failure response, or an error response. If the SMTP -server, in violation of this specification, does not support any SMTP -service extensions it will generate an error response. Older client SMTP -systems MAY, as discussed above, use HELO (as specified in RFC 821) instead -of EHLO, and servers MUST support the HELO command and reply properly to -it. In any event, a client MUST issue HELO or EHLO before starting a mail -transaction. - -These commands, and a "250 OK" reply to one of them, confirm that both the -SMTP client and the SMTP server are in the initial state, that is, there is -no transaction in progress and all state tables and buffers are cleared. - -Normally, the response to EHLO will be a multiline reply. Each line of the -response contains a keyword and, optionally, one or more parameters. The -syntax for a positive response, using the ABNF notation and low-level -terminals of [ABNF], is: - - ehlo-ok-rsp ::= "250" domain [ <SP> greeting ] <CRLF> - / ( "250-" domain [ <SP> greeting ] <CRLF> - *( "250-" ehlo-line <CRLF> ) - "250" <SP> ehlo-line <CRLF> ) - - greeting ::= 1*<any character other than CR or LF> - - ehlo-line ::= ehlo-keyword *( <SP> ehlo-param ) - - ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") - ; syntax and values depend on ehlo-keyword - - ehlo-param ::= 1*<any CHAR excluding <SP> and all - control characters (US-ASCII 0-31 - inclusive)> - - ALPHA ::= any one of the 52 alphabetic characters, i.e., - (A through Z in upper case, and, a through z in lower - case) - -Although EHLO keywords may be specified in upper, lower, or mixed case, -they MUST always be recognized and processed in a case-insensitive manner. -This is simply an extension of practices specified in RFC 821 and section -2.4.1. - -4.1.1.2 MAIL (MAIL) - -This command is used to initiate a mail transaction in which the mail data -is delivered to one or more mailboxes. The argument field contains a -reverse-path. In general, the MAIL command may be sent only when no mail -transaction is in progress, see section 4.1.4. - -The reverse-path consists of the sender mailbox or a list of hosts. In -some types of reporting messages for which a reply is likely to cause a -mail loop (for example, mail delivery and nondelivery notifications), the -reverse-path may be null (see section 3.7). - -This command clears the reverse-path buffer, the forward-path buffer, and -the mail data buffer; and inserts the reverse-path information from this -command into the reverse-path buffer. - -If service extensions were negotiated, the MAIL command may also carry -parameters associated with a particular service extension. - -Syntax: - - "MAIL FROM:" Reverse-path [ <SP> Mail-parameters ] - -or - "MAIL FROM:<>" [ <SP> Mail-parameters ] - -4.1.1.3 RECIPIENT (RCPT) - -This command is used to identify an individual recipient of the mail data; -multiple recipients are specified by multiple use of this command. - -The forward-path normally consists of the required destination mailbox or -mailboxes. Sending systems SHOULD not generate the optional list of hosts -known as a source route. Receiving systems MUST recognize source route -syntax but SHOULD strip off the source route specification and utilize the -domain name associated with the mailbox as if the source route had not been -provided. - -Similarly, relay hosts SHOULD strip or ignore source routes, and names MUST -NOT be copied into the reverse-path. When mail reaches its ultimate -destination (the forward-path contains only a destination mailbox), the -SMTP server inserts it into the destination mailbox in accordance with its -host mail conventions. - -For example, mail received at relay host xyz.com with envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> - -will normally be sent directly on to host d.bar.org with envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<USERC@D.bar.org> - -As provided in appendix C, xyz.com MAY also choose to relay the message to -jkl.org, using the envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@jkl.org:userc@d.bar.org> - -Of course, since hosts are not required to relay mail at all, xyz.com may -also reject the message entirely when the RCPT TO command is received, -using a 550 code (since this is a "policy reason"). - -If service extensions were negotiated, the RCPT TO command may also carry -parameters associated with a particular service extension offered by the -server. The client MUST NOT transmit parameters other than those -associated with a service extension offered by the server in its EHLO -response. - -Syntax: - "RCPT TO:" Forward-path [ <SP> Rcpt-parameters ] -or - "RCPT TO:<Postmaster>" [ <SP> Rcpt-parameters ] - -4.1.1.4 DATA (DATA) - -The receiver treats the lines (strings ending in <CRLF> sequences, as -described in section 2.3.7) following the command as mail data from the -sender. This command causes the mail data to be appended to the mail data -buffer. The mail data may contain any of the 128 ASCII character codes, -although experience has indicated that use of control characters other than -SP, HT, CR, and LF (especially the ASCII "Null" character) may cause -problems and SHOULD be avoided when possible. - -The mail data is terminated by a line containing only a period, that is, -the character sequence "<CRLF>.<CRLF>" (see section 4.5.2). This is the -end of mail data indication. Note that the first <CRLF> of this -terminating sequence is also the <CRLF> that ends the final line of the -data (message text) or, if there was no data, ends the DATA command itself. -An extra <CRLF> MUST NOT be added, as that would cause an empty line to be -added to the message. The only exception to this rule would arise if the -message body were passed to the originating SMTP-sender with a final "line" -that did not end in <CRLF>; in that case, the originating SMTP system MUST -either reject the message as invalid or add <CRLF> in order to have the -receiving SMTP server recognize the "end of data" condition. - -The custom of accepting lines ending only in <LF>, as a concession to -non-conforming behavior on the part of some UNIX systems, has proven to -cause more interoperability problems than it solves, and SMTP server -systems MUST NOT do this, even in the name of improved robustness. In -particular, the sequence "<LF>.<LF>" (bare line feeds, without carriage -returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end of -mail data indication. - -Receipt of the end of mail data indication requires the server to process -the stored mail transaction information. This processing consumes the -information in the reverse-path buffer, the forward-path buffer, and the -mail data buffer, and on the completion of this command these buffers are -cleared. If the processing is successful, the receiver MUST send an OK -reply. If the processing fails the receiver MUST send a failure reply. The -SMTP model does not allow for partial failures at this point: either the -message is accepted by the server for delivery and a positive response is -returned or it is not accepted and a failure reply is returned. Errors -that are diagnosed subsequently MUST be reported in a mail message, as -discussed in section 4.4 In sending a positive completion reply to the end -of data indication, the receiver takes full responsibility for the message -(see section 6.1). - -When the SMTP server accepts a message either for relaying or for final -delivery, it inserts a trace record (also referred to interchangeably as a -"time stamp line" or "Received" line) at the top of the mail data. This -trace record indicates the identity of the host that sent the message, the -identity of the host that received the message (and is inserting this time -stamp), and the date and time the message was received. Relayed messages -will have multiple time stamp lines. Details for formation of these lines, -including their syntax, is specified in section 4.4. - -4.1.1.5 RESET (RSET) - -This command specifies that the current mail transaction will be aborted. -Any stored sender, recipients, and mail data MUST be discarded, and all -buffers and state tables cleared. The receiver MUST send a "250 OK" reply -to a RSET command with no arguments. A reset command may be issued by the -client at any time. It is effectively equivalent to a NOOP if issued -immediately after EHLO, before EHLO is issued in the session, after an -end-of-data indicator has been sent and acknowledged, or immediately before -a QUIT. In other situations, it restores the state to that immediately -after the most recent EHLO. An SMTP server MUST NOT close the connection -as the result of receiving a RSET; that action is reserved for QUIT (see -section 4.1.1.10). - -Since EHLO implies some additional processing and response by the server, -RSET will normally be more efficient than reissuing that command, even -though the formal semantics are the same. - -There are circumstances, contrary to the intent of this specification, in -which an SMTP server may receive an indication that the underlying TCP -connection has been closed or reset. To preserve the robustness of the -mail system, SMTP servers SHOULD be prepared for this condition and SHOULD -treat it as if a QUIT had been received before the connection disappeared. - -Syntax: - "RSET" - -4.1.1.6 VERIFY (VRFY) - -This command asks the receiver to confirm that the argument identifies a -user or mailbox. If it is a user name, information is returned as -specified in section 3.5. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -Syntax: - "VRFY" <SP> String - -4.1.1.7 EXPAND (EXPN) - -This command asks the receiver to confirm that the argument identifies a -mailing list, and if so, to return the membership of that list. If the -command is successful, a reply is returned containing information as -described in section 3.5. This reply will have multiple lines except in -the trivial case of a one-member list. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -Syntax: - "EXPN" <SP> String - -4.1.1.8 HELP (HELP) - -This command causes the server to send helpful information to the client. -The command MAY take an argument (e.g., any command name) and return more -specific information as a response. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -SMTP servers SHOULD support HELP without arguments and MAY support it with -arguments. - -Syntax: - "HELP" [ <SP> String ] - -4.1.1.9 NOOP (NOOP) - -This command does not affect any parameters or previously entered commands. -It specifies no action other than that the receiver send an OK reply. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. If a parameter string is specified, -servers SHOULD ignore it. - -Syntax: - "NOOP" [ <SP> String ] - - -4.1.1.10 QUIT (QUIT) - -This command specifies that the receiver MUST send an OK reply, and then -close the transmission channel. - -The receiver MUST NOT intentionally close the transmission channel until it -receives and replies to a QUIT command (even if there was an error). The -sender MUST NOT intentionally close the transmission channel until it sends -a QUIT command and receives the reply (even if there was an error response -to a previous command). If the connection is closed prematurely due to -violations of the above or system or network failure, the server MUST -cancel any pending transaction, but not undo any previously completed -transaction, and generally MUST act as if the command or transaction in -progress had received a temporary error (i.e., a 4yz response). - -Syntax: - "QUIT" - -4.1.2 Lower-level Syntax - -The syntax of the argument fields of the above commands (using the syntax -specified in [ABNF] where applicable) is given below. Some of the -productions given below are used only in conjunction with source routes as -described in appendix C. Terminals not defined in this document, such as -ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the "core" syntax -(section 6) of [ABNF] or in the syntax of [MSGFMT]. - - Reverse-path = Path - - Forward-path = Path - - Path = "<" [ A-d-l ":" ] Mailbox ">" - - A-d-l = At-domain *( "," A-d-l ) ; Note that this form, the - so-called "source route", MUST BE - accepted, SHOULD NOT be generated, - and SHOULD be ignored. - - At-domain = "@" Domain - - Mail-parameters = *( <SP> Keyword "=" Argument ) - - Rcpt-parameters = *( <SP> Keyword "=" Argument ) - - Keyword = Ldh-str - Argument = Atom - - Domain = sub-domain 1*("." sub-domain) / address-literal - - sub-domain = let-dig *(Ldh-str) - address-literal = "[" IPv4-address-literal / - IPv6-address-literal / General-address-literal "]" - IPv4-address-literal = snum 3*3("." snum) - IPv6-address-literal = "IPv6 " IPv6-addr-string - IPv6-addr-string = String ; IPv6 address in standard form - [IPv6AddrSpec]. Since this - form uses colon characters, - the String will actually need - to be quoted in all cases. - General-address-literal = Standardized-tag <SP> String - Standardized-tag = Ldh-str ; Specified in a - standards-track RFC - and registered with IANA - snum = 1*3Digit ; representing a decimal integer - value in the range 0 through 255 - let-dig = Alpha / Digit - ldh-str = *( Alpha / Digit / "-" ) let-dig - - Mailbox = Local-part "@" Domain - - Local-part = Dot-string / Quoted-string - - Dot-string = Atom [ "." Atom ] - -While the above definition for Local-part is relatively permissive, for -maximum interoperability, a host that expects to receive mail SHOULD avoid -defining mailboxes where the Local-part requires (or uses) the -Quoted-string form or where the Local-part is case-sensitive. For any -purposes that require generating or comparing Local-parts (e.g., to -specific mailbox names), all quoted forms MUST be treated as equivalent and -the sending system SHOULD transmit the form that uses the minimum quoting -possible. - -Systems MUST NOT define mailboxes in such a way as to require the use of -non-ASCII characters (octets with the high order bit set to one) or ASCII -"control characters" (decimal value 0-31 and 127). These characters MUST -NOT be used in MAIL FROM or RCPT TO commands or other commands that require -mailbox names. - - String = Atom / Quoted-string - - special = <<Msg-fmt-special>> / [[placeholder, see above]] - the control characters (ASCII codes 0 through 31 - inclusive and 127) - -Note that the backslash, "\", is a quote character, which is used to -indicate that the next character is to be used literally (instead of its -normal interpretation). For example, "Joe\,Smith" indicates a single nine -character user field with the comma being the fourth character of the -field. - -To promote interoperability and consistent with long-standing guidance -about conservative use of the DNS in naming and applications (e.g., see -section 2.3.1 of the base DNS document [RFC-1015]), characters outside the -set of alphas, digits, and hyphen MUST NOT appear in domain name labels -for SMTP clients or servers. In particular, the underscore character is -not permitted. SMTP servers that receive a command in which illegal -character codes have been employed, and for which there are no other -reasons for rejection, MUST reject that command with a 501 response. - -4.1.3 Address Literals - -Sometimes a host is not known to the domain name system and communication -(and, in particular, communication to report and repair the error) is -blocked. To bypass this barrier a special literal form of the address is -allowed as an alternative to a domain name. For IPv4 addresses, this form -uses four small decimal integers separated by dots and enclosed by brackets -such as [123.255.37.2], which indicates an (IPv4) Internet Address in -sequence-of-octets form. For IPv6 and other forms of addressing that might -eventually be standardized, the form consists of a standardized "tag" that -identifies the address syntax, a space, and the address itself, in a format -specified as part of the IPv6 standards [IPv6AddrString]. - -4.1.4 Order of Commands - -There are restrictions on the order in which these commands may be used. - -A session that will contain mail transactions MUST first be initialized by -the use of the EHLO command. An SMTP server SHOULD accept commands for -non-mail transactions (e.g., VRFY or EXPN) without this initialization. - -An EHLO command MAY be issued by a client later in the session. If it is -issued after the session begins, the SMTP server MUST clear all buffers and -reset the state exactly as if a RSET command had been issued. In other -words, the sequence of RSET followed immediately by EHLO is redundant, but -not harmful other than in the performance cost of executing unnecessary -commands. - -If the EHLO command is not acceptable to the SMTP server, 501, 500, or 502 -failure replies MUST be returned as appropriate. The SMTP server MUST stay -in the same state after transmitting these replies that it was in before -the EHLO was received. - -The SMTP client MUST ensure that the domain parameter to the EHLO command -is a valid principal host name (not a CNAME or MX name) for its host. If -this is not possible (e.g., when the client's address is dynamically -assigned and the client does not have an obvious name), an address literal -SHOULD be substituted for the domain name and supplemental information -provided that will assist in identifying the client. - -An SMTP server MAY verify that the domain name parameter in the EHLO -command actually corresponds to the IP address of the client. However, the -server MUST NOT refuse to accept a message if the verification fails: the -information about verification failure is for logging and tracing only. - -The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time -during a session, or without previously initializing a session. SMTP -servers SHOULD process these normally (that is, not return a 503 code) even -if no EHLO command has yet been received; clients SHOULD open a session -with EHLO before sending these commands. - -If these rules are followed, the example in RFC 821 that shows "550 access -denied to you" in response to an EXPN command is incorrect unless an EHLO -command precedes the EXPN or the denial of access is based on the client's -IP address or other authentication or authorization-determining mechanisms. - -The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins a -mail transaction. Once started, a mail transaction consists of a -transaction beginning command, one or more RCPT commands, and a DATA -command, in that order. A mail transaction may be aborted by the RSET (or -a new EHLO) command. There may be zero or more transactions in a session. -MAIL (or SEND, SOML, or SAML) MUST NOT be sent if a mail transaction is -already open, i.e., it should be sent only if no mail transaction had been -started in the session, or it the previous one successfully concluded with -a successful DATA command, or if the previous one was aborted with a RSET. - -If the transaction beginning command argument is not acceptable, a 501 -failure reply MUST be returned and the SMTP server MUST stay in the same -state. If the commands in a transaction are out of order to the degree -that they cannot be processed by the server, a 503 failure reply MUST be -returned and the SMTP server MUST stay in the same state. - -The last command in a session MUST be the QUIT command. The QUIT command -cannot be used at any other time in a session, but SHOULD be used by the -client SMTP to request connection closure, even when no session opening -command was sent and accepted. - -4.1.5 Private-use Commands - -As specified in section 2.2.2, commands starting in "X" may be used by -bilateral agreement between the client (sending) and server (receiving) -SMTP agents. An SMTP server that does not recognize such a command is -expected to reply with "500 Command not recognized". An extended SMTP -server MAY list the feature names associated with these private commands in -the response to the EHLO command. - -Commands sent or accepted by SMTP systems that do not start with "X" MUST -conform to the requirements of section 2.2.2. - -4.2 SMTP Replies - -Replies to SMTP commands serve to ensure the synchronization of requests -and actions in the process of mail transfer and to guarantee that the SMTP -client always knows the state of the SMTP server. Every command MUST -generate exactly one reply. - -The details of the command-reply sequence are described in section 4.3. - -An SMTP reply consists of a three digit number (transmitted as three -alphanumeric characters) followed by some text unless specified otherwise -in this document. The number is for use by automata to determine what -state to enter next; the text is for the human user. The three digits -contain enough encoded information that the SMTP client need not examine -the text and may either discard it or pass it on to the user, as -appropriate. Exceptions are as noted elsewhere in this document. In -particular, the 220, 221, 251, 421, and 551 reply codes are associated -with message text that must be parsed and interpreted by machines. In the -general case, the text may be receiver dependent and context dependent, so -there are likely to be varying texts for each reply code. A discussion of -the theory of reply codes is given in section 4.2.1. Formally, a reply is -defined to be the sequence: a three-digit code, <SP>, one line of text, -and <CRLF>, or a multiline reply (as defined in section 4.2.1). Since, in -violation of this specification, the text is sometimes not sent, clients -which do not receive it SHOULD be prepared to process the code alone (with -or without a trailing space character). Only the EHLO, EXPN, and HELP -commands are expected to result in multiline replies in normal -circumstances, however, multiline replies are allowed for any command. - -In ABNF, server responses are: - - Greeting = "220 " Domain [ SP text ] CRLF - Reply-line = Reply-code [ SP text ] CRLF - -where "Greeting" appears only in the 220 response that announces that the -server is opening its part of the connection. - -An SMTP server SHOULD send only the reply codes listed in this document. -An SMTP server SHOULD use the text shown in the examples whenever -appropriate. - -An SMTP client MUST determine its actions only by the reply code, not by -the text (except for 251 and 551 and, if necessary, 220, 221, and 421 -replies); in the general case, any text, including no text at all (although -senders SHOULD NOT send bare codes), MUST be acceptable. The space (blank) -following the reply code is considered part of the text. Whenever -possible, a receiver-SMTP SHOULD test the first digit (severity indication) -of the reply code. - -The list of codes that appears below must not be construed as permanent. -While the addition of new codes should be a rare and significant activity, -with supplemental information in the textual part of the response being -preferred, new codes may be added as the result of new Standards or -Standards-track specifications. Consequently, a sender-SMTP MUST be -prepared to handle codes not specified in this document and MUST do so by -interpreting the first digit only. - -4.2.1 Reply Code Severities and Theory - -The three digits of the reply each have a special significance. The first -digit denotes whether the response is good, bad or incomplete. An -unsophisticated SMTP client, or one that receives an unexpected code, will -be able to determine its next action (proceed as planned, redo, retrench, -etc.) by examining this first digit. An SMTP client that wants to know -approximately what kind of error occurred (e.g., mail system error, command -syntax error) may examine the second digit. The third digit and any -supplemental information that may be present is reserved for the finest -gradation of information. - -There are five values for the first digit of the reply code: - -1yz Positive Preliminary reply - The command has been accepted, but the requested action is being held in - abeyance, pending confirmation of the information in this reply. The - SMTP client should send another command specifying whether to continue - or abort the action. Note: unextended SMTP does not have any commands - that allow this type of reply, and so does not have continue or abort - commands. - -2yz Positive Completion reply - The requested action has been successfully completed. A new request may - be initiated. - -3yz Positive Intermediate reply - The command has been accepted, but the requested action is being held in - abeyance, pending receipt of further information. The SMTP client - should send another command specifying this information. This reply is - used in command sequence groups (i.e., in DATA). - -4yz Transient Negative Completion reply - The command was not accepted, and the requested action did not occur. - However, the error condition is temporary and the action may be - requested again. The sender should return to the beginning of the - command sequence (if any). It is difficult to assign a meaning to - "transient" when two different sites (receiver- and sender- SMTP agents) - must agree on the interpretation. Each reply in this category might have - a different time value, but the SMTP client is encouraged to try again. - A rule of thumb to determine whether a reply fits into the 4yz or the - 5yz category (see below) is that replies are 4yz if they can be - successful if repeated without any change in command form or in - properties of the sender or receiver. (that is, the command is repeated - identically and the receiver does not put up a new implementation.) - -5yz Permanent Negative Completion reply - The command was not accepted and the requested action did not occur. - The SMTP client is discouraged from repeating the exact request (in the - same sequence). Even some "permanent" error conditions can be - corrected, so the human user may want to direct the SMTP client to - reinitiate the command sequence by direct action at some point in the - future (e.g., after the spelling has been changed, or the user has - altered the account status). - -The second digit encodes responses in specific categories: - -x0z Syntax: These replies refer to syntax errors, syntactically correct - commands that don't fit any functional category, and unimplemented or - superfluous commands. - -x1z Information: These are replies to requests for information, such as - status or help. - -x2z Connections: These are replies referring to the transmission channel. - -x3z Unspecified. - -x4z Unspecified. - -x5z Mail system: These replies indicate the status of the receiver mail - system vis-a-vis the requested transfer or other mail system action. - -The third digit gives a finer gradation of meaning in each category -specified by the second digit. The list of replies illustrates this. Each -reply text is recommended rather than mandatory, and may even change -according to the command with which it is associated. On the other hand, -the reply codes must strictly follow the specifications in this section. -Receiver implementations should not invent new codes for slightly different -situations from the ones described here, but rather adapt codes already -defined. - -For example, a command such as NOOP, whose successful execution does not -offer the SMTP client any new information, will return a 250 reply. The -reply is 502 when the command requests an unimplemented non-site-specific -action. A refinement of that is the 504 reply for a command that is -implemented, but that requests an unimplemented parameter. - -The reply text may be longer than a single line; in these cases the -complete text must be marked so the SMTP client knows when it can stop -reading the reply. This requires a special format to indicate a multiple -line reply. - -The format for multiline replies requires that every line, except the last, -begin with the reply code, followed immediately by a hyphen, "-" (also -known as minus), followed by text. The last line will begin with the reply -code, followed immediately by <SP>, optionally some text, and <CRLF>. As -noted above, servers SHOULD send the <SP> if subsequent text is not sent, -but clients MUST be prepared for it to be omitted. - -For example: - 123-First line - 123-Second line - 123-234 text beginning with numbers - 123 The last line - -In many cases the SMTP client then simply needs to search for the reply -code followed by <SP> at the beginning of a line, and ignore all preceding -lines. In a few cases, there is important data for the client in the -reply "text". The client will be able to identify these cases from the -current context. - -4.2.2 Reply Codes by Function Groups - - 500 Syntax error, command unrecognized - (This may include errors such as command line too long) - 501 Syntax error in parameters or arguments - 502 Command not implemented (see section 4.2.4) - 503 Bad sequence of commands - 504 Command parameter not implemented - - 211 System status, or system help reply - 214 Help message - (Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user) - - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 421 <domain> Service not available, closing transmission channel - (This may be a reply to any command if the service knows it - must shut down) - - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - (See section 3.4) - 252 Cannot VRFY user, but will accept message and attempt - delivery - (See section 3.5.3) - 450 Requested mail action not taken: mailbox unavailable - (e.g., mailbox busy) - 550 Requested action not taken: mailbox unavailable - (e.g., mailbox not found, no access, or command rejected - for policy reasons) - 451 Requested action aborted: error in processing - 551 User not local; please try <forward-path> - (See section 3.4) - 452 Requested action not taken: insufficient system storage - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - (e.g., mailbox syntax incorrect) - 354 Start mail input; end with <CRLF>.<CRLF> - 554 Transaction failed (Or, in the case of a connection-opening - response, "No SMTP service here") - -4.2.3 Reply Codes in Numeric Order - - 211 System status, or system help reply - 214 Help message - (Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user) - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - (See section 3.4) - 252 Cannot VRFY user, but will accept message and attempt - delivery - (See section 3.5.3) - - 354 Start mail input; end with <CRLF>.<CRLF> - - 421 <domain> Service not available, closing transmission channel - (This may be a reply to any command if the service knows it - must shut down) - 450 Requested mail action not taken: mailbox unavailable - (e.g., mailbox busy) - 451 Requested action aborted: local error in processing - 452 Requested action not taken: insufficient system storage - - 500 Syntax error, command unrecognized - (This may include errors such as command line too long) - 501 Syntax error in parameters or arguments - 502 Command not implemented (see section 4.2.4) - 503 Bad sequence of commands - 504 Command parameter not implemented - 550 Requested action not taken: mailbox unavailable - (e.g., mailbox not found, no access, or command rejected - for policy reasons) - 551 User not local; please try <forward-path> - (See section 3.4) - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - (e.g., mailbox syntax incorrect) - 554 Transaction failed (Or, in the case of a connection-opening - response, "No SMTP service here") - -4.2.4 Reply Code 502 - -Questions have been raised as to when reply code 502 (Command not -implemented) SHOULD be returned in preference to other codes. 502 SHOULD -be used when the command is actually recognized by the SMTP server, but not -implemented. If the command is not recognized, code 500 SHOULD be -returned. Extended SMTP systems MUST NOT list capabilities in response to -EHLO for which they will return 502 (or 500) replies. - -4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> - -When an SMTP server returns a positive completion status (2yz code) after -the DATA command is completed with <CRLF>.<CRLF>, it accepts responsibility -for: - - - delivering the message (if the recipient mailbox exists), or - - - if attempts to deliver the message fail due to transient conditions, - retrying delivery some reasonable number of times at intervals as - specified in section 4.5.4. - - - if attempts to deliver the message fail due to permanent conditions, or - if repeated attempts to deliver the message fail due to transient - conditions, returning appropriate notification to the sender of the - original message (using the address in the SMTP MAIL FROM command). - -When an SMTP server returns a transient error completion status (4yz) code -after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make -any further attempt to deliver that message. The SMTP client retains -responsibility for delivery of that message and may either return it to the -user or requeue it for a subsequent attempt (see section 4.5.4.1). The -sending user SHOULD be able to interpret the return of a transient or -permanent failure status as a non-delivery indication. - -4.3 Sequencing of Commands and Replies - -4.3.1 Sequencing Overview - -The communication between the sender and receiver is an alternating -dialogue, controlled by the sender. As such, the sender issues a command -and the receiver responds with a reply. Unless other arrangements are -negotiated through service extensions, the sender MUST wait for this -response before sending further commands. - -One important reply is the connection greeting. Normally, a receiver will -send a 220 "Service ready" reply when the connection is completed. The -sender SHOULD wait for this greeting message before sending any commands. - -Note: all the greeting-type replies have the official name (the -fully-qualified primary domain name) of the server host as the first word -following the reply code. Sometimes the host will have no meaningful name. -See 4.1.3 for a discussion of alternatives in these situations. - -For example, - 220 ISIF.USC.EDU Service ready -or - 220 mail.foo.com SuperSMTP v 6.1.2 Service ready -or - 220 [10.0.0.1] Clueless host service ready - -The table below lists alternative success and failure replies for each -command. These SHOULD be strictly adhered to: a receiver may substitute -text in the replies, but the meaning and action implied by the code numbers -and by the specific command reply sequence cannot be altered. - -4.3.2 Command-Reply Sequences - -Each command is listed with its usual possible replies. The prefixes used -before the possible replies are "I" for intermediate, "S" for success, and -"E" for error. Since some servers may generate other replies under special -circumstances, and to allow for future extension, SMTP clients SHOULD, when -possible, interpret only the first digit of the reply and MUST be prepared -to deal with unrecognized reply codes by interpreting the first digit only. -Unless extended using the mechanisms described in section 2.2, SMTP servers -MUST NOT transmit reply codes to an SMTP client that are other than three -digits or that do not start in a digit between 2 and 5 inclusive. - -These sequencing rules and, in principle, the codes themselves, can be -extended or modified by SMTP extensions offered by the server and accepted -(requested) by the client. - -In addition to the codes listed below, any SMTP command can return any of -the following codes if the corresponding unusual circumstances are -encountered: - -500 For the "command line too long" case or if the command name was not - recognized. Note that producing a "command not recognized" error in - response to the required subset of these commands is a violation of this - specification. - -501 Syntax error in command or arguments. In order to provide for future - extensions, commands that are specified in this document as not - accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 message if - arguments are supplied in the absence of EHLO-advertised extensions. - -421 Service shutting down and closing transmission channel - -Specific sequences are: - -CONNECTION ESTABLISHMENT - S: 220 - E: 554 -EHLO or HELO - S: 250 - E: 504, 550 -MAIL - S: 250 - E: 552, 451, 452, 550, 553, 503 -RCPT - S: 250, 251 (but see section 3.4 for discussion of 251) - E: 550, 551, 552, 553, 450, 451, 452, 503, 550 -DATA - I: 354 -> data -> S: 250 - E: 552, 554, 451, 452 - E: 451, 554, 503 -RSET - S: 250 -VRFY - S: 250, 251, 252 - E: 550, 551, 553, 502, 504 -EXPN - S: 250, 252 - E: 550, 500, 502, 504 -HELP - S: 211, 214 - E: 502, 504 -NOOP - S: 250 -QUIT - S: 221 - -4.4 Trace Information - -When an SMTP server receives a message for delivery or further processing, -it MUST insert trace ("time stamp" or "Received") information at the -beginning of the message content, as discussed in section 4.1.1.4. - -This line MUST be structured as follows: - - - The FROM field, which MUST be supplied in an SMTP environment, SHOULD - contain both (1) the name of the source host as presented in the EHLO - command and (2) an address literal containing the IP address of the - source, determined from the TCP connection. - - - The ID field MAY contain an "@" as suggested in RFC-822, but this is not - required. - - - The FOR field MAY contain a list of <path> entries when multiple RCPT - commands have been given. This may raise some security issues and is - usually not desirable; see section 7.2. - -An Internet mail program MUST NOT change a Received: line that was -previously added to the message header. SMTP servers MUST prepend Received -lines to messages; they MUST NOT change the order of existing lines or -insert Received lines in any other location. - -As the Internet grows, comparability of Received fields is important for -detecting problems, especially slow relays. SMTP servers that create -Received fields SHOULD use explicit offsets in the dates (e.g., -0800), -rather than time zone names of any type. Local time (with an offset) is -preferred to UT when feasible. This formulation allows slightly more -information about local circumstances to be specified. If UT is needed, -the receiver need merely do some simple arithmetic to convert the values. -Use of UT loses information about the time zone-location of the server. If -a time zone name is used, it SHOULD be included in a comment. - -When the delivery SMTP server makes the "final delivery" of a message, it -inserts a return-path line at the beginning of the mail data. This use of -return-path is required; mail systems MUST support it. The return-path -line preserves the information in the <reverse-path> from the MAIL -command. Here, final delivery means the message has left the SMTP -enviroment. Normally, this would mean it had been delivered to the -destination user or an associated mail drop, but in some cases it may be -further processed and transmitted by another mail system. - -It is possible for the mailbox in the return path to be different from the -actual sender's mailbox, for example, if error responses are to be -delivered to a special error handling mailbox rather than to the message -sender. When mailing lists are involved, this arrangement is common and -useful as a means of directing errors to the list maintainer rather than -the message originator. - -The text above implies that the final mail data will begin with a return -path line, followed by one or more time stamp lines. These lines will be -followed by the mail data headers and body [MSGFMT]. - -It is sometimes difficult for an SMTP server to determine whether or not it -is making final delivery since forwarding or other operations may occur -after the message is accepted for delivery. Consequently, any further -(forwarding, gateway, or relay) systems MAY remove the return path and -rebuild the MAIL FROM command as needed to ensure that exactly one such -line appears in a delivered message. - -A message-originating SMTP system SHOULD NOT send a message that already -contains a Return-path header. SMTP servers performing a relay function -MUST NOT inspect the message data, and especially not to the extent needed -to determine if Return-path headers are present. SMTP servers making final -delivery MAY remove Return-path headers before adding their own. - -The primary purpose of the Return-path is to designate the address to which -messages indicating non-delivery or other mail system failures are to be -sent. For this to be unambiguous, exactly one return path SHOULD be -present when the message is delivered. Systems using RFC 822 syntax with -non-SMTP transports SHOULD designate an unambiguous address, associated -with the transport envelope, to which error reports (e.g., non-delivery -messages) should be sent. - -Historical note: Text in RFC 822 that appears to contradict the use of the -Return-path header (or the envelope MAIL FROM address) as the destination -for error messages is not applicable on the Internet. The MAIL FROM address -(as copied into the Return-path) MUST be used as the target of any mail -containing delivery error messages. - -In particular: - - - a gateway from SMTP->elsewhere SHOULD insert a return-path header, - unless it is known that the "elsewhere" transport also uses Internet - domain addresses and maintains the envelope sender address separately. - - - a gateway from elsewhere->SMTP SHOULD delete any return-path header - present in the message, and either copy that information to the SMTP - envelope or combine it with information present in the envelope of the - other transport system to construct the MAIL FROM part of the SMTP - envelope. - -The server must give special treatment to cases in which the processing -following the end of mail data indication is only partially successful. -This could happen if, after accepting several recipients and the mail data, -the SMTP server finds that the mail data could be successfully delivered to -some, but not all, of the recipients. In such cases, the response to the -DATA command MUST be an OK reply. However, the SMTP server MUST compose -and send an "undeliverable mail" notification message to the originator of -the message. - -A single notification listing all of the failed recipients or separate -notification messages MUST be sent for each failed recipient. For economy -of processing by the sender, the former is preferred when possible. All -undeliverable mail notification messages are sent using the MAIL command -(even if they result from processing the obsolete SEND, SOML, or SAML -commands) and use a null return path as discussed in section 3.7. - -The time stamp line and the return path line are formally defined as -follows: - - Return-path-line = "Return-Path:" FWS Reverse-path <CRLF> - - Time-stamp-line = "Received:" FWS Stamp <CRLF> - - Stamp = From-domain By-domain Opt-info ";" FWS Daytime - - From-domain = "FROM" FWS Extended-Domain CFWS - - By-domain = "BY" FWS Extended-Domain CFWS - - Extended-Domain = Domain / - ( Domain FWS "(" TCP-info ")" ) / - ( Address-literal FWS "(" TCP-info ")" - TCP-info = Address-literal / ( Domain FWS Address-literal ) - ; Information derived by server from TCP connection, - not client EHLO. - - Opt-info = [Via] [With] [ID] [For] - - Via = "VIA" FWS Link CFWS - - With = "WITH" FWS Protocol CFWS - - ID = "ID" FWS String / msg-id CFWS - - For = "FOR" FWS 1*( Path / Mailbox ) CFWS - - Link = "TCP" / Addtl-Link - Addtl-Link = Atom ; Additional standard names for links are - registered with the Internet Assigned - Numbers Authority (IANA). "Via" is - primarily of value with non-Internet - transports. - SMTP servers SHOULD NOT use unregistered - names. - Protocol = "ESMTP" / "SMTP" / Attdl-Protocol - Attdl-Protocol = Atom ; Additional standard names for protocols - are registered with the Internet Assigned - Numbers Authority (IANA). SMTP servers - SHOULD NOT use unregistered names. - - Daytime = FWS [ day-of-week "," FWS ] Date FWS Time - - Date = DD FWS Mon FWS YYYY - ; Note that the earlier form, which permits two-digit years, has - been deprecated. SMTP systems MUST use four-digit years. - - Time = HH ":" MM ":" SS FWS Zone - - DD = 1*2Digit ; the one or two digit integer day of the - month in the range 1 to 31. - - Mon = "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | - "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" - - YYYY = 4*4Digit ; the four decimal integer year in the range - 0000 to 9999. - - HH = 2*2Digit ; the two decimal digit hour of the day in - the range 00 to 24. - - MM = 2*2Digit ; the two decimal digit integer minute of the hour - in the range 00 to 59. - - SS = 2*2Digit [ "." 1*Digit ] - ; the two decimal digit integer second of the - minute in the range 00 to 59, with - optional fractional seconds. - - Zone = ( "+" / "-" ) 4*4Digit [ <SP> "(" String ")" ] - ; A four digit, signed time zone offset, - such as -0500 for US Eastern Standard - Time. This may be supplemented by a time - zone name in parentheses, e.g., "-0800 - (PDT)". Note that there is no default; - time zone information is required and - MUST be supplied. - -4.5 Additional Implementation Issues - -4.5.1 Minimum Implementation - -In order to make SMTP workable, the following minimum implementation is -required for all receivers. The following commands MUST be supported to -conform to this specification: - EHLO - HELO - MAIL - RCPT - DATA - RSET - NOOP - QUIT - -VRFY, required by RFC 1123 [RFC-1123], is no longer required by this -specification. However, since it was required earlier, servers are -strongly encouraged to at least recognize the syntax and provide pro-forma -support. - -Any system that includes an SMTP server supporting mail relaying or -delivery MUST support the reserved mailbox "postmaster" as a -case-insensitive local name. This postmaster address is not strictly -necessary if the server always returns 554 on connection opening (as -described in section 3.1). The requirement to accept mail for postmaster -implies that RCPT TO commands which specify a mailbox for postmaster at any -of the domains for which the SMTP server provides mail service, as well as -the special case of "RCPT TO:<Postmaster>" (with no domain specification), -MUST be supported. This requirement does not imply that SMTP systems must -deliver Postmaster mail in particular cases (e.g., problematic origin -addresses) in which they have substantive reasons for not doing so. - -4.5.2 Transparency - -Without some provision for data transparency, the character sequence -"<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user. In -general, users are not aware of such "forbidden" sequences. To allow all -user composed text to be transmitted transparently, the following -procedures are used: - - - Before sending a line of mail text, the SMTP client checks the first - character of the line. If it is a period, one additional period is - inserted at the beginning of the line. - - - When a line of mail text is received by the SMTP server, it checks the - line. If the line is composed of a single period, it is treated as the - end of mail indicator. If the first character is a period and there are - other characters on the line, the first character is deleted. - -The mail data may contain any of the 128 ASCII characters. All characters -are to be delivered to the recipient's mailbox, including spaces, vertical -and horizontal tabs, and other control characters. If the transmission -channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes -are transmitted right justified in the octets, with the high order bits -cleared to zero. See 3.7 for special treatment of these conditions in SMTP -systems serving a relay function. - -In some systems it may be necessary to transform the data as it is received -and stored. This may be necessary for hosts that use a different character -set than ASCII as their local character set or store data in records rather -than strings. If such transformations are necessary, they MUST be -reversible, especially if such transformations are applied to mail being -relayed. - -4.5.3 Sizes and Timeouts - -There are several objects that have required minimum/maximum sizes. Every -implementation MUST be able to receive objects of at least these sizes. -Objects larger than these sizes SHOULD be avoided when possible. However, -some Internet mail constructs such as encoded X.400 addresses [RFC-X400] -will often require larger objects: clients MAY attempt to transmit these, -but MUST be prepared for a server to reject them if they cannot be handled -by it. To the maximum extent possible, implementation techniques which -impose no limits on the length of these objects should be used. - -local-part - The maximum total length of a user name or other local-part is 64 - characters. - -domain - The maximum total length of a domain name or number is 255 characters. - -path - The maximum total length of a reverse-path or forward-path is 256 - characters (including the punctuation and element separators). - -command line - The maximum total length of a command line including the command word - and the <CRLF> is 512 characters. SMTP extensions may be used to - increase this limit. - -reply line - The maximum total length of a reply line including the reply code and - the <CRLF> is 512 characters. More information may be conveyed through - multiple-line replies. - -text line - The maximum total length of a text line including the <CRLF> is 1000 - characters (not counting the leading dot duplicated for transparency). - This number may be increased by the use of SMTP Service Extensions. - -message content - The maximum total length of a message content (including any message - headers as well as the message body) MUST BE at least 64K octets. Since - the introduction of multimedia mail [RFC-MIME], message lengths on the - Internet have grown dramatically, and message size restrictions should - be avoided if at all possible. SMTP server systems that must impose - restrictions SHOULD implement the "SIZE" service extension ([RFC-SIZE]), - and SMTP client systems that will send large messages SHOULD utilize it - when possible. - -recipients buffer - The minimum total number of recipients that must be buffered is 100 - recipients. Rejection of messages (for excessive recipients) with fewer - than 100 RCPT TO commands is a violation of this specification. The - general principle that relaying SMTP servers MUST NOT, and delivery SMTP - servers SHOULD NOT, perform validation tests on message headers suggests - that rejecting a message based on the total number of recipients shown - in header fields is to be discouraged. A server which imposes a limit - on the number of recipients MUST behave in an orderly fashion, such as - to reject additional addresses over its limit rather than silently - discarding addresses previously accepted. A client that needs to - deliver a message containing over 100 RCPT TO commands SHOULD be - prepared to transmit in 100-recipient "chunks" if the server declines to - accept more than 100 recipients in a single message. - -Errors due to exceeding these limits may be reported by using the reply -codes. Some examples of reply codes are: - - 500 Line too long. -or - 501 Path too long -or - 452 Too many recipients (see below) -or - 552 Too much mail data. - -[RFC-821] incorrectly listed the error where an SMTP server exhausts its -implementation limit on the number of RCPT TO commands ("too many -recipients") as having reply code 552. The correct reply code for this -condition is 452. Clients SHOULD treat a 552 code in this case as a -temporary, rather than permanent failure so the logic below works. - -When a conforming SMTP server encounters this condition, it has at least -100 successful RCPT commands in its recipients buffer. If the server is -able to accept the message, then at least these 100 addresses will be -removed from the SMTP client's queue. When the client attempts -retransmission of those addresses which received 452 responses, at least -100 of these will be able to fit in the SMTP server's recipients buffer. -Each retransmission attempt which is able to deliver anything will be able -to dispose of at least 100 of these recipients. - -If an SMTP server has an implementation limit on the number of RCPT TO -commands and this limit is exhausted, it MUST use a response code of 452. -If the server has a configured site-policy limitation on the number of RCPT -TO commands, it MAY instead use a 5XX response code. - -In order to interoperate with SMTP servers implementing an older version of -the protocol, SMTP clients MAY treat a 552 code obtained in response to an -RCPT command as if it were a 452 response code, especially after some RCPT -commands have already been accepted in the same mail transaction. - -An SMTP client MUST provide a timeout mechanism. It MUST use per-command -timeouts rather than somehow trying to time the entire mail transaction. -Timeouts SHOULD be easily reconfigurable, preferably without recompiling -the SMTP code. To implement this, a timer is set for each SMTP command and -for each buffer of the data transfer. The latter means that the overall -timeout is inherently proportional to the size of the message. - -Based on extensive experience with busy mail-relay hosts, the minimum -per-command timeout values SHOULD be as follows: - -Initial 220 Message: 5 minutes - An SMTP client process needs to distinguish between a failed TCP - connection and a delay in receiving the initial 220 greeting message. - Many SMTP servers accept a TCP connection but delay delivery of the 220 - message until their system load permits more mail to be processed. - -MAIL Command: 5 minutes - -RCPT Command: 5 minutes - A longer timeout is required if processing of mailing lists and aliases - is not deferred until after the message was accepted. - -DATA Initiation: 2 minutes - This is while awaiting the "354 Start Input" reply to a DATA command. - -Data Block: 3 minutes - This is while awaiting the completion of each TCP SEND call transmitting - a chunk of data. - -DATA Termination: 10 minutes. - This is while awaiting the "250 OK" reply. When the receiver gets the - final period terminating the message data, it typically performs - processing to deliver the message to a user mailbox. A spurious timeout - at this point would be very wasteful and would typically result in - delivery of multiple copies of the message, since it has been - successfully sent and the server has accepted responsibility for - delivery. See section 6.1 for additional discussion. - -An SMTP server SHOULD have a timeout of at least 5 minutes while it is -awaiting the next command from the sender. - -4.5.4 Queuing Strategies - -The common structure of a host SMTP implementation includes user mailboxes, -one or more areas for queuing messages in transit, and one or more daemon -processes for sending and receiving mail. The exact structure will vary -depending on the needs of the users on the host and the number and size of -mailing lists supported by the host. We describe several optimizations that -have proved helpful, particularly for mailers supporting high traffic -levels. - -Any queuing strategy MUST include timeouts on all activities on a -per-command basis. A queuing strategy MUST NOT send error messages in -response to error messages under any circumstances. - -4.5.4.1 Sending Strategy - -The general model for an SMTP client is one or more processes that -periodically attempt to transmit outgoing mail. In a typical system, the -program that composes a message has some method for requesting immediate -attention for a new piece of outgoing mail, while mail that cannot be -transmitted immediately MUST be queued and periodically retried by the -sender. A mail queue entry will include not only the message itself but -also the envelope information. - -The sender MUST delay retrying a particular destination after one attempt -has failed. In general, the retry interval SHOULD be at least 30 minutes; -however, more sophisticated and variable strategies will be beneficial when -the SMTP client can determine the reason for non-delivery. - -Retries continue until the message is transmitted or the sender gives up; -the give-up time generally needs to be at least 4-5 days. The parameters -to the retry algorithm MUST be configurable. - -A client SHOULD keep a list of hosts it cannot reach and corresponding -connection timeouts, rather than just retrying queued mail items. - -Experience suggests that failures are typically transient (the target -system or its connection has crashed), favoring a policy of two connection -attempts in the first hour the message is in the queue, and then backing -off to one every two or three hours. - -The SMTP client can shorten the queuing delay in cooperation with the SMTP -server. For example, if mail is received from a particular address, it is -likely that mail queued for that host can now be sent. Application of this -principle may, in many cases, eliminate the requirement for an explicit -"send queues now" function such as that discussed in [RFC-ETRN]. - -The strategy may be further modified as a result of multiple addresses per -host (see below) to optimize delivery time vs. resource usage. - -An SMTP client may have a large queue of messages for each unavailable -destination host. If all of these messages were retried in every retry -cycle, there would be excessive Internet overhead and the sending system -would be blocked for a long period. Note that an SMTP client can generally -determine that a delivery attempt has failed only after a timeout of -several minutes and even a one-minute timeout per connection will result in -a very large delay if retries are repeated for dozens, or even hundreds, of -queued messages to the same host. - -At the same time, SMTP clients SHOULD use great care in caching negative -responses from servers. In an extreme case, if EHLO is issued multiple -times during the same SMTP connection, different answers may be returned by -the server. More significantly, 5yz responses to MAIL FROM MUST NOT be -cached. - -When a mail message is to be delivered to multiple recipients, and the SMTP -server to which a copy of the message is to be sent is the same for -multiple recipients, then only one copy of the message SHOULD be -transmitted. That is, the SMTP client SHOULD use the command sequence: -MAIL, RCPT, RCPT,... RCPT, DATA instead of the sequence: MAIL, RCPT, DATA, -..., MAIL, RCPT, DATA. However, if there are very many addresses, a limit -on the number of RCPT commands per MAIL command MAY be imposed. -Implementation of this efficiency feature is strongly encouraged. - -Similarly, to achieve timely delivery, the SMTP client MAY support multiple -concurrent outgoing mail transactions. However, some limit may be -appropriate to protect the host from devoting all its resources to mail. - -4.5.4.2 Receiving Strategy - -The SMTP server SHOULD attempt to keep a pending listen on the SMTP port at -all times. This requires the support of multiple incoming TCP connections -for SMTP. Some limit MAY be imposed. - -As discussed above, when the SMTP server receives mail from a particular -host address, it could notify the SMTP client to retry any mail pending for -that host address. - -4.5.5 Messages with a null reverse-path - -There are several types of notification messages which are required by -existing and proposed standards to be sent with a null reverse path, -namely non-delivery notifications as discussed in section 3.7, other kinds -of Delivery Status Notifications (DSNs, see [RFC 1894]) and also Message -Disposition Notifications (MDNs, see [RFC 2298]). All of these kinds of -messages are notifications about a previous message, and they are sent to -the reverse-path of the previous mail message. (If the delivery of such a -notification message fails, that usually indicates a problem with the mail -system of the host to which the notification message is addressed. For -this reason, at some hosts the MTA is set up to forward such failed -notification messages to someone who is able to fix problems with the mail -system, e.g. via the postmaster alias.) - -All other types of messages (i.e. any message which is not required by a -standards-track RFC to have a null reverse-path) SHOULD be sent with with -a valid, non-null reverse-path. - -Implementors of automated email processors should be careful to make sure -that the various kinds of messages with null reverse-path are handled -correctly, in particular such systems SHOULD NOT reply to messages with -null reverse-path. - - - - -5. Address Resolution and Mail Handling - -Once an SMTP client lexically identifies a domain to which mail will be -delivered for processing (as described in sections 3.6 and 3.7), a DNS -lookup is performed to resolve the domain name (see [RFC-DNS]). The names -are expected to be fully-qualified domain names (FQDNs): mechanisms for -inferring FQDNs from partial names or local aliases are outside of this -specification and, due to a history of problems, are generally discouraged. -The lookup first attempts to locate an MX record associated with the name. -If a CNAME record is found instead, the resulting name is processed as if -it were the initial name. If no MX records are found, but an A RR is -found, the A RR is treated as if it was associated with an implicit MX RR, -with a preference of 0, pointing to that host. If one or more MX RRs are -found for a given name, SMTP systems MUST NOT utilize any A RRs associated -with that name unless they are located using the MX RRs; the "implicit MX" -rule above applies only if there are no MX records present. If MX records -are present, but none of them are usable, this situation MUST be reported -as an error. - -When the lookup succeeds, the mapping can result in a list of alternative -delivery addresses rather than a single address, because of multiple MX -records, multihoming, or both. To provide reliable mail transmission, the -SMTP client MUST be able to try (and retry) each of the relevant addresses -in this list in order, until a delivery attempt succeeds. However, there -MAY also be a configurable limit on the number of alternate addresses that -can be tried. In any case, a host SHOULD try at least two addresses. - -Two types of information is used to rank the host addresses: multiple MX -records, and multihomed hosts. - -Multiple MX records contain a preference indication that MUST be used in -sorting (see below). Lower numbers are more preferred than higher ones. -If there are multiple destinations with the same preference and there is no -clear reason to favor one (e.g., by recognition of an easily-reached -address), then the sender-SMTP MUST randomize them to spread the load -across multiple mail exchangers for a specific organization. - -The destination host (perhaps taken from the preferred MX record) may be -multihomed, in which case the domain name resolver will return a list of -alternative IP addresses. It is the responsibility of the domain name -resolver interface to have ordered this list by decreasing preference if -necessary, and SMTP MUST try them in the order presented. - -Although the capability to try multiple alternative addresses is required, -specific installations may want to limit or disable the use of alternative -addresses. The question of whether a sender should attempt retries using -the different addresses of a multihomed host has been controversial. The -main argument for using the multiple addresses is that it maximizes the -probability of timely delivery, and indeed sometimes the probability of any -delivery; the counter-argument is that it may result in unnecessary -resource use. Note that resource use is also strongly determined by the -sending strategy discussed in section 4.5.4.1. - -If a host receives a message with a destination for which it is a -designated Mail eXchanger, it MAY relay the message (potentially after -having rewritten the addresses), make final delivery of the message, or -hand it off using some mechanism outside the SMTP-provided transport -environment. - -If it determines that it should relay the message without rewriting the -address, it MUST sort the MX records to determine candidates for delivery. -The records are first ordered by preference, with the lowest-numbered -records being most preferred. The relay host MUST then inspect the list -for any of the names or addresses by which it might be known in mail -transactions. If a matching record is found, all records at that -preference level and higher-numbered ones MUST be discarded from -consideration. If there are no records left at that point, it is an error -condition, and the message MUST be returned as undeliverable. If records -do remain, they SHOULD be tried, best preference first, as described above. - - -6. Problem Detection and Handling - -6.1 Reliable Delivery and Replies by Email - -When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" -message in response to DATA), it is accepting responsibility for delivering -or relaying the message. It must take this responsibility seriously. It -MUST NOT lose the message for frivolous reasons, such as because the host -later crashes or because of a predictable resource shortage. - -If there is a delivery failure after acceptance of a message, the -receiver-SMTP MUST formulate and mail a notification message. This -notification MUST be sent using a null ("<>") reverse path in the envelope. -The recipient of this notification SHOULD be the address from the envelope -return path (or the Return-Path: line). However, if this address is null -("<>"), the receiver-SMTP MUST NOT send a notification. Obviously, nothing -in this section can or should prohibit local decisions (i.e., as part of -the same system environment as the receiver-SMTP) to log or otherwise -transmit information about null address events locally if that is desired. -If the address is an explicit source route, it MUST be stripped down to its -final hop. - -For example, suppose that an error notification must be sent for a message -that arrived with: - MAIL FROM:<@a,@b:user@d> - -The notification message SHOULD be sent using: - RCPT TO:<user@d> - -Some delivery failures after the message is accepted by SMTP will be -unavoidable. For example, it may be impossible for the receiving SMTP -server to validate all the delivery addresses in RCPT command(s) due to a -"soft" domain system error, because the target is a mailing list (see -earlier discussion of RCPT), or because the server is acting as a relay and -has no immediate access to the delivering system. - -To avoid receiving duplicate messages as the result of timeouts, a -receiver-SMTP MUST seek to minimize the time required to respond to the -final <CRLF>.<CRLF> end of data indicator. See RFC-1047 [RFC-1047] for a -discussion of this problem. - -6.2 Loop Detection - -Simple counting of the number of "Received:" headers in a message has -proven to be an effective, although rarely optimal, method of detecting -loops in mail systems. SMTP servers using this technique SHOULD use a -large rejection threshold, normally at least 100 Received entries. -Whatever mechanisms are used, servers MUST contain provisions for detecting -and stopping trivial loops. - -6.3 Compensating for Irregularities - -Unfortunately, variations, creative interpretations, and outright -violations of Internet mail protocols do occur; some would suggest that -they occur quite frequently. The debate as to whether a well-behaved SMTP -receiver or relay should reject a malformed message, attempt to pass it on -unchanged, or attempt to repair it to increase the odds of successful -delivery (or subsequent reply) began almost with the dawn of structured -network mail and shows no signs of abating. Advocates of rejection claim -that attempted repairs are rarely completely adequate and that rejection of -bad messages is the only way to get the offending software repaired. -Advocates of "repair" or "deliver no matter what" argue that users prefer -that mail go through it if at all possible and that there are significant -market pressures in that direction. In practice, these market pressures -may be more important to particular vendors than strict conformance to the -standards, regardless of the preference of the actual developers. - -The problems associated with ill-formed messages were exacerbated by the -introduction of the split-UA mail reading protocols [RFC-POP2, RFC-POP3, -RFC-IMAP2, RFC-PCMAIL]. These protocols have encouraged the use of SMTP as -a posting protocol, and SMTP servers as relay systems for these client -hosts (which are often only intermittently connected to the Internet). -Historically, many of those client machines lacked some of the mechanisms -and information assumed by SMTP (and indeed, by the mail format protocol -[RFC-822]). Some could not keep adequate track of time; others had no -concept of time zones; still others could not identify their own names or -addresses; and, of course, none could satisfy the assumptions that underlay -RFC-822's conception of authenticated addresses. - -In response to these weak SMTP clients, many SMTP systems now complete -messages that are delivered to them in incomplete or incorrect form. This -strategy is generally considered appropriate when the server can identify -or authenticate the client, and there are prior agreements between them. -By contrast, there is at best great concern about fixes applied by a relay -or delivery SMTP server that has little or no knowledge of the user or -client machine. - -The following changes to a message being processed MAY be applied when -necessary by an originating SMTP server, or one used as the target of SMTP -as an initial posting protocol: - - - Addition of a message-id field when none appears - - - Addition of a date, time or time zone when none appears - - - Correction of addresses to proper FQDN format - -The less information the server has about the client, the less likely these -changes are to be correct and the more caution and conservatism should be -applied when considering whether or not to perform fixes and how. These -changes MUST NOT be applied by an SMTP server that provides an intermediate -relay function. - -In all cases, properly-operating clients supplying correct information are -preferred to corrections by the SMTP server. In all cases, documentation of -actions performed by the servers (in trace fields and/or header comments) -is strongly encouraged. - - -7. Security Considerations - -7.1 Mail Security and Spoofing - -SMTP mail is inherently insecure in that it is feasible for even fairly -casual users to negotiate directly with receiving and relaying SMTP servers - - -and create messages that will trick a naive recipient into believing that -they came from somewhere else. Constructing such a message so that the -"spoofed" behavior cannot be detected by an expert is somewhat more -difficult, but not sufficiently so as to be a deterrent to someone who is -determined and knowledgeable. Consequently, as knowledge of Internet mail -increases, so does the knowledge that SMTP mail inherently cannot be -authenticated, or integrity checks provided, at the transport level. Real -mail security lies only in end-to-end methods involving the message bodies, -such as those that can be provided in the MOSS framework [RFC-MOSS]. - -Various protocol extensions and configuration options that provide -authentication at the transport level (e.g., from an SMTP client to an SMTP -server) improve somewhat on the traditional situation described above. -However, unless they are accompanied by careful handoffs of responsibility -in a carefully-designed trust environment, they remain inherently weaker -than end-to-end mechanisms which use digitally signed messages rather than -depending on the integrity of the transport system. - -Efforts to make it more difficult for users to set envelope MAIL FROM and -header "From" fields to point to valid addresses other than their own are -largely misguided: they frustrate legitimate applications in which mail is -sent by one user on behalf of another or in which error (or normal) replies -should be directed to a special address. (Systems that provide convenient -ways for users to alter these fields on a per-message basis should attempt -to establish a primary and permanent mailbox address for the user so that -Sender fields within the message data can be generated sensibly.) - -This specification does not further address the authentication issues -associated with SMTP other than to advocate that useful functionality not -be disabled in the hope of providing some small margin of protection -against an ignorant user who is trying to fake mail. - -7.2 "Blind" Copies - -Addresses that do not appear in the message headers may appear in the RCPT -TO commands to an SMTP server for a number of reasons. The two most common -involve the use of a mailing address as a "list exploder" (a single address -that resolves into multiple addresses) and the appearance of "blind -copies". Especially when more than one RCPT command is present, and in -order to avoid defeating some of the purpose of these mechanisms, SMTP -clients and servers SHOULD NOT copy the full set of RCPT TO command -arguments into the headers, either as part of trace headers or as -informational or private-extension headers. Since this rule is often -violated in practice, and cannot be enforced, sending SMTP systems that are -aware of "bcc" use MAY find it helpful to send each blind copy as a -separate message transaction containing only a single RCPT TO command. - -There is no inherent relationship between either "reverse" (MAIL FROM, SAML -FROM, etc.) or "forward" (RCPT TO) addresses in the SMTP transaction -("envelope") and the addresses in the headers. Receiving systems SHOULD -NOT attempt to deduce such relationships and use them to alter the headers -of the message for delivery. The popular "Apparently-to" header is a -violation of this principle and SHOULD NOT be used. - -7.3 VRFY, EXPN, and Security - -As discussed in section 3.5, individual sites may want to disable one or -both VRFY or EXPN for security reasons. As a corollary to the above, -implementations that permit this MUST NOT appear to have verified addresses -that are not, in fact, verified. If a site disables these commands for -security reasons, the SMTP server MUST return a 252 response, rather than a -code that could be confused with successful or unsuccessful verification. - -Returning a 250 reply code with the address listed in the VRFY command -after having checked it only for syntax violates this rule. Of course, an -implementation that "supports" VRFY by always returning 550 whether or not -the address is valid is equally not in conformance. - -Within the last few years, the contents of mailing lists have become -popular as an address information source for so-called "spammers." The use -of EXPN to "harvest" addresses has increased as list administrators have -installed protections against inappropriate uses of the lists themselves. -Implementations SHOULD still provide support for EXPN, but sites SHOULD -carefully evaluate the tradeoffs. As authentication mechanisms are -introduced into SMTP, some sites may choose to make EXPN available only to -authenticated requestors. - -7.4 Information Disclosure in Announcements - -There has been an ongoing debate about the tradeoffs between the debugging -advantages of announcing server type and version (and, sometimes, even -server domain name) in the greeting response or in response to the HELP -command and the disadvantages of exposing useful information to potential -hostile attack. The utility of the debugging information is beyond doubt. -Those who argue for making it available point out that it is far better to -actually secure an SMTP server rather than hope that trying to conceal -known vulnerabilities by hiding the server's precise identity will provide -more protection. Sites are encouraged to evaluate the tradeoff with that -issue in mind; implementations are strongly encouraged to minimally provide -for making type and version information available in some way to other -network hosts. - -7.5 Information Disclosure in Trace Fields - -In some circumstances, such as when mail originates from within a LAN whose -hosts are not directly from the public Internet, trace ("Received") fields -produced in conformance with this specification may disclose host names and -similar information that would not normally be available. This ordinarily -does not pose a problem, but sites with special concerns about name -disclosure should be aware of it. Also, the optional FOR clause should be -supplied with caution or not at all when multiple recipients are involved -lest it inadvertently disclose the identities of "blind copy" recipients to -others. - -7.6 Scope of Operation of SMTP Servers - -It is a well-established principle that an SMTP server may refuse to accept -mail for any operational or technical reason that makes sense to the site -providing the server. However, cooperation among sites and installations -makes the Internet possible. If sites take excessive advantage of the -right to reject traffic, the ubiquity of email availability (one of the -strengths of the Internet) will be threatened; considerable care should be -taken and balance maintained if a site decides to be selective about the -traffic it will accept and process. - -In recent years, use of the relay function through arbitrary sites has been -used as part of hostile efforts to hide the actual origins of mail. Some -sites have decided to limit the use of the relay function to known or -identifiable sources, and implementations SHOULD provide the capability to -perform this type of filtering. When mail is rejected for these or other -policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL FROM, -or RCPT TO as appropriate. - - -8. IANA Considerations - -IANA will maintain three registries in support of this specification. The -first consists of SMTP service extensions with the associated keywords, -and, as needed, parameters and verbs. As specified in section 2.2.2, no -entry may be made in this registry that starts in an "X". Entries may be -made only for service extensions (and associated keywords, parameters, or -verbs) that are defined in standards-track or experimental RFCs -specifically approved by the IESG for this purpose. - -The second registry consists of "tags" that identify forms of domain -literals other than those for IPv4 addresses (specified in RFC 821 and in -this document) and IPv6 addresses (specified in this document). Additional -literal types require standardization before being used; none are -anticipated at this time. - -The third, established by RFC 821 and renewed by this specification, is a -registry of link and protocol identifiers to be used with the "via" and -"with" subclauses of the time stamp ("Received: header") described in -section 4.4. Link and protocol identifiers in addition to those specified -in this document may be registered only by standardization or by way of an -RFC-documented, IESG-approved, Experimental protocol extension. - - -9. References - -[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP -Service Extension for 8bit-MIMEtransport", RFC 1652, 07/18/1994. - -[ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax -Specifications: ABNF", RFC 2234, November 1997. - -[IPv6AddrString] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing -Architecture", RFC 1884, December 1995. - -[MSGFMT] P. Resnick, Work in progress, draft-ietf-drums-msg-fmt-05.txt, -August, 1998 - -[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text -Messages", RFC 822, Department of Electrical Engineering, University of -Delaware, August 1982. - -[RFC-974] C. Partridge, "Mail routing and the domain system", RFC 974, -01/01/1986 - -[RFC-1047] C. Partridge, "Duplicate messages and SMTP", RFC 1047, -02/01/1988. - -[RFC-1123] R. Braden, "Requirements for Internet hosts - application and -support", 10/01/1989 - -[RFC-BDAT] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large -and Binary MIME Messages", RFC 1830, 08/16/1995. - -[RFC-DNS] P. Mockapetris, "Domain names - implementation and -specification", RFC 1035 and P. Mockapetris, "Domain names - concepts and -facilities", RFC 1034. (STD 13) - -[RFC-ETRN] J. De Winter, "SMTP Service Extension for Remote Message Queue -Starting", RFC 1985, 08/14/1996. - -[RFC-IMAP2] M. Crispin, "Interactive Mail Access Protocol - Version 2", RFC -1176, 08/20/1990. - -[RFC-IMAP4] M. Crispin, "Internet Message Access Protocol - Version 4", RFC -2060, 12/04/1996. - -[RFC-INTLHDR] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part -Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 12/02/1996. - -[RFC-MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions -(MIME) Part One: Format of Internet Message Bodies", RFC 2045, 12/02/1996. - -[RFC-MOSS] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object -Security Services", RFC 1848, 10/03/1995. - -[RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery Status -Notifications", RFC 1891, 01/15/1996. - -[RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message Format for -Delivery Status Notifications", RFC 1894, 01/15/1996. - -[RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for personal -computers", RFC 1056, 06/01/1988. - -[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension for Command -Pipelining", RFC 1854, 10/04/1995. - -[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J. Reynolds, -"Post Office Protocol - version 2", RFC 937, 02/01/1985 - -[RFC-POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3", RFC 1930, -5/14/96 (Std 53). - -[RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 1893, -01/15/1996. - -[RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension for -Message Size Declaration", RFC 1870, 11/06/1995. (STD 10) - -[RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021 -and RFC 822", RFC 1327, 05/18/1992. - -[SMTPEX] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP -Service Extensions", RFC-1869, 11/06/1995. (STD 10) - -[TCP] Postel, J., ed., "Transmission Control Protocol - DARPA Internet -Program Protocol Specification", RFC 793, USC/Information Sciences -Institute, NTIS AD Number A111091, September 1981. - -[US-ASCII] United States of America Standards Institute (now American -National Standards Institute), X3.4, 1968, "USA Code for Information -Interchange". ANSI X3.4-1968 has been replaced by newer versions with -slight modifications, but the 1968 version remains definitive for the -Internet. - - -10. Editor's Address - -John C. Klensin -MCI Communications -800 Boylston St., 7th floor -Boston, MA 02199 -USA -Email: Klensin@mci.net -Phone: +1 617 960 1011 -Fax: +1 617 960 1009 - - -11. Acknowledgments - -Many people worked long and hard on the many iterations of this document. -There was wide-ranging debate on the mailing list about many technical -issues, and many contributors helped form the wording in this -specification. The hundreds of participants in the many discussions since -RFC 821 was produced are too numerous to mention, but they all helped this -document become what it is. - - -A. TCP Transport Service - -The TCP connection supports the transmission of 8-bit bytes. The SMTP data -is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte -with the high-order bit cleared to zero. Service extensions may modify -this rule to permit transmission of full 8-bit data bytes as part of the -message body, but not in SMTP commands or responses. - - -B. Generating SMTP Commands from RFC 822 Headers - -Some systems use RFC 822 headers (only) in a mail submission protocol, or -otherwise generate SMTP commands from RFC 822 headers when such a message -is handed to an MTA from a UA. While the MTA-UA protocol is a private -matter, not covered by any Internet Standard, there are problems with this -approach. For example, there have been repeated problems with proper -handling of "bcc" copies and redistribution lists when information that -conceptually belongs to a mail envelopes is not separated early in -processing from header information (and kept separate). - -It is recommended that the UA provide its initial MTA with an envelope -separate from the message itself. However, if the envelope is not -supplied, SMTP commands SHOULD be generated as follows: - -1. Each recipient address from a TO, CC, or BCC header field SHOULD be - copied to a RCPT command (generating multiple message copies if that is - required for queuing or delivery). This includes any addresses listed - in a RFC 822 "group". Any BCC fields SHOULD then be removed from the - headers. Once this process is completed, the remaining headers SHOULD - be checked to verify that at least one To:, Cc:, or Bcc: header remains. - If none do, then a bcc: header with no additional information SHOULD be - inserted as specified in [MSGFMT]. - -2. The return address in the MAIL command SHOULD, if possible, be derived - from the system's identity for the submitting (local) user, and the From - header field otherwise. If there is a system identity available, it - SHOULD also be copied to the Sender header field if it is different from - the address in the From header field. (Any Sender field that was - already there SHOULD be removed.) Systems may provide a way for - submitters to override the envelope return address, but may want to - restrict its use to privileged users. This will not prevent mail - forgery, but may lessen its incidence; see section 7.1. - -When an MTA is being used in this way, it bears responsibility for ensuring -that the message being transmitted is valid. The mechanisms for checking -that validity, and for handling (or returning) messages that are not valid -at the time of arrival, are part of the MUA-MTA interface and not covered -by this specification. - -A submission protocol based on Standard RFC 822 information alone MUST NOT -be used to gateway a message from a foreign (non-SMTP) mail system into an -SMTP environment. Additional information to construct an envelope must -come from some source in the other environment, whether supplemental -headers or the foreign system's envelope. - -Attempts to gateway messages using only their header "to" and "cc" fields, -have repeatedly caused mail loops and other behavior adverse to the proper -functioning of the Internet mail environment. These problems have been -especially common when the message originates from an Internet mailing list -and is distributed into the foreign environment using envelope information. -When these messages are then processed by a header-only remailer, loops -back to the Internet environment (and the mailing list) are almost -inevitable. - - -C. Source Routes - -The <reverse-path> is a reverse source routing list of hosts and a source -mailbox. The first host in the <reverse-path> SHOULD be the host sending -the MAIL FROM command. Similarly, the <forward-path> may be a source -routing lists of hosts and a destination mailbox. However, in general, the -<forward-path> SHOULD contain only a mailbox and domain name, relying on -the domain name system to supply routing information if required. The use -of source routes is deprecated; while servers MUST be prepared to receive -and handle them as discussed in section 3.3 and F.2, clients SHOULD NOT -transmit them. - -For relay purposes, the forward-path may be a source route of the form -"@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully-qualified -domain names. This form is used to emphasize the distinction between an -address and a route. The mailbox is an absolute address, and the route is -information about how to get there. The two concepts should not be -confused. - -If source routes are used, RFC 821 and the text below should be consulted -for the mechanisms for constructing and updating the forward- and -reverse-paths. - -The SMTP server transforms the command arguments by moving its own -identifier (its domain name or that of any domain for which it is acting as -a mail exchanger), if it appears, from the forward-path to the beginning of -the reverse-path. - -Notice that the forward-path and reverse-path appear in the SMTP commands -and replies, but not necessarily in the message. That is, there is no need -for these paths and especially this syntax to appear in the "To:" , -"From:", "CC:", etc. fields of the message header. Conversely, SMTP servers -MUST NOT derive final message delivery information from message header -fields. - -When the list of hosts is present, it is a "reverse" source route and -indicates that the mail was relayed through each host on the list (the -first host in the list was the most recent relay). This list is used as a -source route to return non-delivery notices to the sender. As each relay -host adds itself to the beginning of the list, it MUST use its name as -known in the transport environment to which it is relaying the mail rather -than that of the transport environment from which the mail came (if they -are different). - - -D. Scenarios - -This section presents complete scenarios of several types of SMTP sessions. -In the examples, "C:" indicates what is said by the SMTP client, and "S:" -indicates what is said by the SMTP server. - -D.1 A Typical SMTP Transaction Scenario - -This SMTP example shows mail sent by Smith at host bar.com, to Jones, -Green, and Brown at host foo.com. Here we assume that host bar.com -contacts host foo.com directly. The mail is accepted for Jones and Brown. -Green does not have a mailbox at host foo.com. - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<Smith@bar.com> - S: 250 OK - C: RCPT TO:<Jones@foo.com> - S: 250 OK - C: RCPT TO:<Green@foo.com> - S: 550 No such user here - C: RCPT TO:<Brown@foo.com> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.2 Aborted SMTP Transaction Scenario - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<Smith@bar.com> - S: 250 OK - C: RCPT TO:<Jones@foo.com> - S: 250 OK - C: RCPT TO:<Green@foo.com> - S: 550 No such user here - C: RSET - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.3 Relayed Mail Scenario - -Step 1 -- Source Host to Relay Host - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<JQP@bar.com> - S: 250 OK - C: RCPT TO:<@foo.com:Jones@XYZ.COM> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Date: Thu, 21 May 1998 05:33:29 -0700 - C: From: John Q. Public <JQP@bar.com> - C: Subject: The Next Meeting of the Board - C: To: Jones@xyz.com - C: - C: Bill: - C: The next meeting of the board of directors will be - C: on Tuesday. - C: John. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -Step 2 -- Relay Host to Destination Host - - S: 220 xyz.com Simple Mail Transfer Service Ready - C: EHLO foo.com - S: 250 xyz.com is on the air - C: MAIL FROM:<@foo.com:JQP@bar.com> - S: 250 OK - C: RCPT TO:<Jones@XYZ.COM> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Received: from bar.com by foo.com ; Thu, 21 May 1998 05:33:29 -0700 - C: Date: Thu, 21 May 1998 05:33:22 -0700 - C: From: John Q. Public <JQP@bar.com> - C: Subject: The Next Meeting of the Board - C: To: Jones@xyz.com - C: - C: Bill: - C: The next meeting of the board of directors will be - C: on Tuesday. - C: John. - C: . - S: 250 OK - - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.4 Verifying and Sending Scenario - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: VRFY Crispin - S: 250 Mark Crispin <Admin.MRC@foo.com> - C: SEND FROM:<EAK@bar.com> - S: 250 OK - C: RCPT TO:<Admin.MRC@foo.com> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - - -E. Other Gateway Issues - -In general, gateways between the Internet and other mail systems SHOULD -attempt to preserve any layering semantics across the boundaries between -the two mail systems involved. Gateway- translation approaches that -attempt to take shortcuts by mapping, (such as envelope information from -one system to the message headers or body of another) have generally proven -to be inadequate in important ways. Systems translating between -environments that do not support both envelopes and headers and Internet -mail must be written with the understanding that some information loss is -almost inevitable. - - -F. Deprecated Features of RFC 821 - -A few features of RFC 821 have proven to be problematic and SHOULD NOT be -used in Internet mail. - -F.1 TURN - -This command, described in RFC 821, raises important security issues since, -in the absence of strong authentication of the host requesting that the -client and server switch roles, it can easily be used to divert mail from -its correct destination. Its use is deprecated; SMTP systems SHOULD NOT -use it unless the server can authenticate the client. - -F.2 Source Routing - -RFC 821 utilized the concept of explicit source routing to get mail from -one host to another via a series of relays. The requirement to utilize -source routes in regular mail traffic was eliminated by the introduction of -the domain name system "MX" record and the last significant justification -for them was eliminated by the introduction, in RFC 1123, of a clear -requirement that addresses following an "@" must all be fully-qualified -domain names. Consequently, the only remaining justifications for the use -of source routes are support for very old SMTP clients or MUAs and in mail -system debugging. They can, however, still be useful in the latter -circumstance and for routing mail around serious, but temporary, problems -such as problems with the relevant DNS records. - -SMTP servers MUST continue to accept source route syntax as specified in -the main body of this document and in RFC 1123. They MAY, if necessary, -ignore the routes and utilize only the target domain in the address. If -they do utilize the source route, the message MUST be sent to the first -domain shown in the address. In particular, a server MUST NOT guess at -shortcuts within the source route. - -Clients SHOULD NOT utilize explicit source routing except under unusual -circumstances, such as debugging or potentially relaying around firewall or -mail system configuration errors. - -F.3 HELO - -As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to HELO -when the server will accept the former. Servers must continue to accept -and process HELO in order to support older clients. - -F.4 #-literals - -RFC 821 provided for specifying an Internet address as a decimal integer -host number prefixed by a pound sign, "#". In practice, that form has been -obsolete since the introduction of TCP/IP. It is deprecated and MUST NOT -be used. - -F.5 Dates and Years - -When dates are inserted into messages by SMTP clients or servers (e.g., in -trace fields), four-digit years MUST BE used. Two-digit years are -deprecated; three-digit years were never permitted in the Internet mail -system. - -F.6 Sending versus Mailing - -In addition to specifying a mechanism for delivering messages to user's -mailboxes, RFC 821 provided additional, optional, commands to deliver -messages directly to the user's terminal screen. These commands (SEND, -SAML, SOML) were rarely implemented, and changes in workstation technology -and the introduction of other protocols may have rendered them obsolete -even where they are implemented. - -Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers MAY -implement them. If they are implemented by servers, the implementation -model specified in RFC 821 MUST be used and the command names MUST be -published in the response to the EHLO command. - - -X. Change Summary and Loose Ends (Temporary) - -X.1 Change summary - -X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and -draft-ietf-drums-smtpupd-01.txt - -(i) Slightly clarified the discussions of rejection and failure of VRFY -requests and the associated response codes. - -(ii) Slightly clarified the discussion of deferred address validation. - -(iii) Removed the IPCE terminology and modified the text in section 4.1.1.2 -to explicitly introduce the "mail gateway" terminology and to begin to -distinguish a mail gateway from a conventional relay. - -(iv) Explicitly noted that SMTP clients for things like POP and IMAP may -send everything to a single relay for further processing, rather than -resolving final domain names. - -(v) Tightened the RSET discussion. - -(vi) Deprecation of 251 only for RCPT (still ok for VRFY) - -X.1.2. Substantive changes between draft-ietf-drums-smtpupd-01.txt and -draft-ietf-drums-smtpupd-02.txt. - -Incorporated additional RFC 1123 material; reorganized several sections for -clarity. Added definitions and other previous "loose end" material. - -X.1.3. Substantive changes between draft-ietf-drums-smtpupd-02.txt and -draft-ietf-drums-smtpupd-03.txt. - -(i) Eliminated a number of placeholders and tightened some of the -definitions in section 2. Added a few new placeholders for consistency -checking against other documents. - -(ii) Removed the state diagrams, per direction at IETF Montreal. - -(iii) Added new section 6.3, an attempt to summarize WG discussions on the -"posting" versus "delivery" versus "relay" functions of SMTP and on whether -"fixups" are appropriate in different cases. - -(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of RFC1123. - -(v) Added new text to 3.5.5 to discuss the spammer - EXPN relationship. - -(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat. - -(v) The remaining miscellaneous changes agreed to in Montreal have been -incorporated except as noted below. - -X.1.4. Substantive changes between draft-ietf-drums-smtpupd-03.txt and -draft-ietf-drums-smtpupd-04.txt. - -Many small changes have been made between these two versions; the list that -follows is not exhaustive. - -(i) To clarify some of the text, definitions have been introduced to -distinguish among originating, delivery, relay, and gateway SMTP systems. - -(ii) The role of LF-terminated lines has been clarified. - -(iii) Several changes have been made to clarify the principle that, no -matter what originating and final delivery systems might do, relay systems -are not permitted to tamper with message content, even to "fix" headers -that are determined to be invalid. If they deem message content to be -seriously unacceptable, they are encouraged to reject the messages in -preference to trying to fix them up, but, in general, the theme is "don't -look/ don't tell". - -(iv) A few more definitions have been added to the terminology section, and -the separate glossary has been eliminated. - -(v) I have taken a shot at text to address some of the controversies that -have raged on the WG mailing list (e.g., sections 7.4 and 7.5). Since there -was no consensus on most of those topics, I expect that the inserted text -will satisfy no one except, perhaps, for agreement that saying nothing -would have been worse. As a mechanism for moving forward, the text in -these controversial areas that now appears will be considered "base"; -alterations will be made only if clear consensus emerges. - -(vi) Per discussion in Los Angeles, source routes have been further -deprecated. - -(vii) Some of the VRFY/EXPN materials have been moved to "security -considerations", where they appear to belong, some text has been added, and -the conformance statements adjusted to reflect what I perceive to be WG -consensus. - -(viii) New MX resolution material has been added to section 5. While most -of this material is from RFC974, the rules have been further tightened to -reflect current practice and experience (974 is written in a somewhat -speculative fashion for a standard). In particular, the behavior of trying -the target host's A RR when MXs existed but all of them were eliminated is -now prohibited, which seems necessary if another of other ideas being -recommended or considered are to be feasible. - -X.1.5. Substantive changes between draft-ietf-drums-smtpupd-04.txt and -draft-ietf-drums-smtpupd-05.txt. - -(i) All normative references to RFC 1123 have been removed from the main -body of the text (some still appear in the appendices where they will -remain). - -(ii) Section 3.5 has been renamed slightly to distinguish between -"debugging of SMTP implementations" and "debugging of addresses". Better -terminology would be welcome. - -(iii) Error conditions resulting from the DATA command have been clarified. - -(iv) Section 4.2 (SMTP replies) has been revised and tightened to reflect -reality and recent discussion on the list. - -(v) Appendix E has been revised a bit and moved into section 4.2.1. Given -the importance of the "check only first digit" rule, it has to be there. - -(vi) Added new text for "no SMTP service supported" to sections 3.1, 4.2.2, -4.2.3, and 4.3.2. As noted in 3.1, I'd rather add 521 (which would work -perfectly with the model) rather than overloading 554. - -(vii) The Return-path language in section 4.4 has been cleaned up a bit. - -(viii) Tightened the "postmaster" language in 4.5.1, requiring a small -change to 4.1.1.3. - -(ix) I have unilaterally (with a little help from my friends), increased -some of the size limits. 64 was much too short for a domain name, and the -DNS limit of 255 (?) has now been inserted. That leaves the return path -much too short, but I haven't fixed it (maybe that will cause us to get rid -of them). We still have a 64 character limit on the local-part, which is -also *much* too short. Votes for 128 or longer limits accepted. See -X.1.6(I) - -(x) The text on the "recipients buffer" has been rewritten so that (I hope) -it makes sense and gives some explicit guidance for how clients and servers -should proceed if limits are imposed. - -X.1.6. Substantive changes between draft-ietf-drums-smtpupd-05.txt and -draft-ietf-drums-smtpupd-06.txt. - -Most of the changes in this revision have been editorial rather than -substantive. Major substantive changes include: - -(i) The language about maximum sizes of SMTP command lines has been -reworked, per WG mailing list discussion. - -(ii) Several instances of "Should" have been promoted to "Must" when the -reasons for the weaker rule seemed to have disappeared. In particular, the -requirement that an SMTP implementation support timeouts has become a MUST. -Also, conformance to this specification requires support of EHLO. Older -systems should claim conformance to the [to-be-historical] 821, not this -specification. - -X.1.7. Substantive changes between draft-ietf-drums-smtpupd-06.txt and -draft-ietf-drums-smtpupd-07.txt. - -(i) Removed "implied RSET" text associated with QUIT, as specified at the -December 1997 IETF - -(ii) Required that servers support EHLO, as specified at the December 1997 -IETF - -X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt and -draft-ietf-drums-smtpupd-08.txt. - -This version involves mostly editorial work and cleanup of loose ends. - -(i) New 7.5 added (old one renumbered) to discuss info disclosure through -Received fields. - -(ii) Some character set and minor syntax issues clarified. - -(iii) Material on code 571 added (thought this had been done long ago; -slipped through the cracks) - -(iv) Many clarifications added as the result of list discussions and -suggestions. - -(v) Error code presentation has been restructured. - -(vi) ABNF conversion done - -(vii) IPv6 address format inserted per RFC 1884, since we could not get -clear agreement on an alternative. - -(viii) Trivial, silly, examples removed. Others not yet renumbered. - -(ix) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes. Eric may -not like the way I've done either of these change very much: the first now -makes the distinction between returning an address and returning other -stuff (which was permitted by -06, but the text wasn't as clear as it -should have been): if it looks like an address, it needs to be an address. -Similarly, with 4.1.1, Eric wanted to explicitly permit/legitimize "DATA -<SP> <CRLF>". I see several disadvantages to doing that, so have inserted -language that encourages receivers to tolerate trailing white space, which -may have the same practical effect. - - -X.1.9. Substantive changes between draft-ietf-drums-smtpupd-08.txt and -draft-ietf-drums-smtpupd-09.txt. - -The first ten of these reflect, in order, minuted items from the Chicago -IETF (IETF 42). - -(i) Clarification of "MUST", etc., in the context of this document -(section 2.3). - -(ii) Altered VRFY text to make implementation a SHOULD (section 3.5.1) and -removed VRFY from the mandatory to implement list (section 4.5.1), per -42nd IETF (Chicago). - -(iii) Clarified that exploders are expected to not purge sender addresses -from lists (section 3.10). Note that the Chicago conclusion was that this -should be a "MUST". I could not figure out how to do that without -absolutely prohibiting removing addresses to prevent loops, to guard -against spammers, or for similar legitimate purposes. So I have written -this as a "SHOULD", with additional "strongly discouraged" words. If -someone still wants a MUST, suggest text. - -(iv) Altered text to permit clients that sometimes, or even always, -initiate sessions with HELO, rather than EHLO, to be fully-conforming -(section 3.2). [[ Editor's note: I continue to believe that a client that -does not have any service extension support, even to the extent of being -able to send EHLO and parse the response without doing anything about it, -should not be considered fully-conforming to this spec (as distinct from -821). Consequently, the new text in 3.2 stops well short of encouraging -clients that don't need service extensions from preferentially using HELO, -and the text in 2.2.1 (which specifies that the extension mechanisms must -be supported) has not been changed. - -(v) Per Chicago discussions, the text requiring that QUIT be sent has not -been changed. The text in 4.1.1.10 requiring that the server wait for -QUIT has been changed to a SHOULD. However, the text in 4.1.1.5, -prohibiting close on receipt of RSET and that elsewhere prohibiting close -as a normal response, has not been changed. - -(vi) Text has been inserted in 4.1.1 and the text in 4.3.2 altered -slightly to clarify the handling of parameters to RSET, DATA, and QUIT and -to 4.1.1.9 specify semantics for parameters to NOOP. I have followed the -minutes on this although I personally agree with kre's mailing list -comments that the "servers SHOULD reject" decision leads to silly states. -I recommend that the WG review this. - -(vii) Per discussion in Chicago, no substantive change has been made to -the specification about underscore characters in domain names (section -4.1.2). However, the text has been altered to more accurately reflect -discussion on the mailing list and the source of the requirement. - -(viii) Per discussion in Chicago, no change has been made to the -preference for local time in Received headers. - -(ix) Per discussion in Chicago, code 571 has been removed and policy -rejection is now reflected i a 550 code (section 3.7 and the response code -lists). - -(x) Per discussion in Chicago, no change has been made to the -specification of use of raw CR or LF. - -(xi) In section 4.3, the text has been changed, per comments from Dan -Bernstein and others, to require that clients be able to handle replies -that do not contain text strings. A few other places patched to match. - -(xii) In sections 4.1.1.1 and 8, the placeholders have been removed. - -(xiii) Per discussion on the mailing list (and specifically James -Berriman's concerns), the text has been clarified (sections 4.1.1.2 and -4.1.4) to prohibit MAIL unless no mail transaction is open. This is a -MUST NOT prohibition -- SHOULD NOT makes no sense if this is the direction -we are going to go. 503 has also been added to the list of valid -responses for "MAIL" in 4.3.1 - it can't be issued before EHLO/HELO in any -event. While it is clear that something should be said, this may not be -the desired outcome (I selected it because it was conservative and easy -given the text that was there already); the WG should check that the text -is as intended. - -(xiv) Per discussion on the mailing list, a new section 4.5.5 has been -added to describe null return paths and their handling (forward pointer -from 3.7). The text in 4.5.5 is substantially that suggested by Norbert -Bollow. As with (xiii), there is now clear text, but it may not be what -the WG desires. Please check. - -[9b] Text lost in upload process restored. - -(xv) "all addresses" substituted for "each...in turn" in 3.10.2. - -(xvi) Requirement for "<" and ">" around paths clarified in section 3.3 -(syntax productions were clear and correct, but not this overview -material). - -[9c] - -(xvii) Clarified text in 3.3 to permit post-DATA bounces on policy -matters. - - - -Z. Full Copyright Statement - -Copyright (C) The Internet Society (1998). All Rights Reserved. - -This document and translations of it may be copied and furnished to others, -and derivative works that comment on or otherwise explain it or assist in -its implementation may be prepared, copied, published and distributed, in -whole or in part, without restriction of any kind, provided that the above -copyright notice and this paragraph are included on all such copies and -derivative works. However, this document itself may not be modified in any -way, such as by removing the copyright notice or references to the Internet -Society or other Internet organizations, except as needed for the purpose -of developing Internet standards in which case the procedures for -copyrights defined in the Internet Standards process must be followed, or -as required to translate it into languages other than English. - -The limited permissions granted above are perpetual and will not be revoked -by the Internet Society or its successors or assigns. - -This document and the information contained herein is provided on an "AS -IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE -DISCLAIMS 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. - -Expires June 1999 diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-10.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-10.txt deleted file mode 100644 index 32e7799d..00000000 --- a/Documentation/en/I-D/draft-ietf-drums-smtpupd-10.txt +++ /dev/null @@ -1,3796 +0,0 @@ -INTERNET-DRAFT John C. Klensin, Editor -Expires July 1999 -February 26, 1999 - - - Simple Mail Transfer Protocol - - draft-ietf-drums-smtpupd-10.txt - -Status of this Memo - -This document is an Internet-Draft and is in full conformance with -all provisions of Section 10 of RFC2026. - -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." - -To view the list Internet-Draft Shadow Directories, see -http://www.ietf.org/shadow.html. - -[[Appendix X will be removed before the document is submitted to the -IESG.]] - -[[If consensus is reached on this document, it will be forwarded to the -IESG with the recommendation that it be processed onto the Standards -track.]] - -Copyright Notice - -Copyright (C) The Internet Society (1998). All Rights Reserved. - - Table of Contents - -0. Abstract - -1. Introduction - -2. The SMTP Model -2.1 Basic Structure -2.2 The Extension Model -2.2.1 Background -2.2.2 Definition and Registration of Extensions -2.3 Terminology -2.3.1 Mail Objects -2.3.2 Senders and Receivers -2.3.3 Mail Agents -2.3.4 Host -2.3.5 Domain -2.3.6 Buffer and State Table -2.3.7 Lines -2.3.8 Originator, Delivery, Relay, and Gateway Systems -2.3.9 Message Content and Mail Data -2.3.10 Mailbox and Address -2.3.11 Reply -2.4 Syntax Principles -2.4.1 General Syntax and Transaction Model -2.4.2 Command and Reply Syntax - -3. The SMTP Procedures: An Overview -3.1 Session Initiation -3.2 Client Initiation -3.3 Mail Transactions -3.4 Forwarding for Address Correction or Updating -3.5 Commands for Debugging Addresses -3.5.1 Overview -3.5.2 VRFY Normal Response -3.5.3 Meaning of VRFY or EXPN Success Response -3.5.4 Semantics and Applications of EXPN -3.6 Domains -3.7 Relaying -3.8 Mail Gatewaying -3.8.1 Header Fields in Gatewaying -3.8.2 Received Lines in Gatewaying -3.8.3 Addresses in Gatewaying -3.8.4 Other Header Fields in Gatewaying -3.8.5 Envelopes in Gatewaying -3.9 Terminating Sessions and Connections -3.10 Mailing Lists and Aliases -3.10.1 Alias -3.10.2 List - -4. The SMTP Specifications -4.1 SMTP Commands -4.1.1 Command Semantics and Syntax -4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) -4.1.1.2 MAIL (MAIL) -4.1.1.3 RECIPIENT (RCPT) -4.1.1.4 DATA (DATA) -4.1.1.5 RESET (RSET) -4.1.1.6 VERIFY (VRFY) -4.1.1.7 EXPAND (EXPN) -4.1.1.8 HELP (HELP) -4.1.1.9 NOOP (NOOP) -4.1.1.10 QUIT (QUIT) -4.1.2 Lower-level Syntax -4.1.3 Address Literals -4.1.4 Order of Commands -4.1.5 Private-use Commands -4.2 SMTP Replies -4.2.1 Reply Code Severities and Theory -4.2.2 Reply Codes by Function Groups -4.2.3 Reply Codes in Numeric Order -4.2.4 Reply Code 502 -4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> -4.3 Sequencing of Commands and Replies -4.3.1 Sequencing Overview -4.3.2 Command-Reply Sequences -4.4 Trace Information -4.5 Additional Implementation Issues -4.5.1 Minimum Implementation -4.5.2 Transparency -4.5.3 Sizes and Timeouts -4.5.4 Queuing Strategies -4.5.4.1 Sending Strategy -4.5.4.2 Receiving Strategy -4.5.5 Messages with a null reverse-path - -5. Address Resolution and Mail Handling - -6. Problem Detection and Handling -6.1 Reliable Delivery and Replies by Email -6.2 Loop Detection -6.3 Compensating for Irregularities - -7. Security Considerations -7.1 Mail Security and Spoofing -7.2 "Blind" Copies -7.3 VRFY, EXPN, and Security -7.4 Information Disclosure in Announcements -7.5 Information Disclosure in Trace Fields -7.6 Scope of Operation of SMTP Servers - -8. IANA Considerations - -9. References - -10. Editors' Addresses - -11. Acknowledgments - -A. TCP Transport Service -B. Generating SMTP Commands from RFC 822 Headers -C. Source Routes -D. Scenarios -E. Other Gateway Issues -F. Deprecated Features of RFC 821 -X. Change Summary and Loose Ends (Temporary) - - -0. Abstract - -This document is a self-contained specification of the basic protocol for -the Internet electronic mail transport, consolidating and updating: - - - the original SMTP specification of RFC 821 [RFC-821], - - - domain name system requirements and implications for mail transport from - RFC 1035 [RFC-DNS] and RFC 974 [RFC-974], - - - the clarifications and applicability statements in RFC 1123 [RFC-1123], - and - - - material drawn from the SMTP Extension mechanisms [SMTPEXT]. - -It replaces RFC 821, RFC 974, and the mail transport materials of RFC -1123. However, RFC 821 specifies some features that were not in -significant use in the Internet by the mid-1990s and (in appendices) -some additional transport models. Those sections are omitted here in -the interest of clarity and brevity; readers needing them should -refer to RFC 821. - -It also includes some additional material from RFC 1123 that required -amplification. This material has been identified in multiple ways, mostly -by tracking flaming on various lists and newsgroups and problems of unusual -readings or interpretations that have turned up as the SMTP extensions have -been deployed. Where this specification moves beyond consolidation and -actually differs from earlier documents, it supersedes them technically as -well as textually. - -Although SMTP was designed as a mail transport and delivery protocol, this -specification also contains information that is important to its use as a -'mail posting' protocol, as recommended for POP [RFC-POP2, RFC-POP3] and -IMAP [RFC-IMAP4]. - -Section 2.3 provides definitions of terms specific to this document. Except -when the historical terminology is necessary for clarity, this document -uses the current 'client' and 'server' terminology to identify the sending -and receiving SMTP processes, respectively. - -A companion document discusses message headers, message bodies and formats -and structures for them, and their relationship - [MSGFMT]. - - -1. Introduction - -The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer -mail reliably and efficiently. - -SMTP is independent of the particular transmission subsystem and requires -only a reliable ordered data stream channel. While this document -specifically discusses transport over TCP, other transports are possible. -Appendices to RFC 821 describe some of them. - -An important feature of SMTP is its capability to transport mail across -transport service environments, usually referred to as "SMTP mail relaying" -(see section 3.8). A transport service environment might consist of the -mutually-TCP-accessible hosts on the public Internet, the -mutually-TCP-accessible hosts on a firewall-isolated private TCP/IP -Intranet, or hosts in some other LAN or WAN environment utilizing a -different transport-level protocol. It is important to realize that -"transport service environments" are one-to-one with usual definitions of -"networks". A process can communicate directly with another process, and -transport mail using this protocol, through any mutually known and -connected transport service. Conversely, mail can be relayed or gatewayed -between processes in two different transport service environments by a -process known and connected to each of the two transport service -environments. The Mail eXchanger mechanisms of the domain name system -[RFC-DNS, and section 5 of this document] allows the identity of hosts -supporting SMTP relay and gateway processes to be specified. - - -2. The SMTP Model - -2.1 Basic Structure - -The SMTP design can be pictured as: - - +----------+ +----------+ - +------+ | | | | - | User |<-->| | SMTP | | - +------+ | Sender- |Commands/Replies| Receiver-| - +------+ | SMTP |<-------------->| SMTP | +------+ - | File |<-->| | and Mail | |<-->| File | - |System| | | | | |System| - +------+ +----------+ +----------+ +------+ - SMTP client SMTP server - -When an SMTP client has a message to transmit, it establishes a two-way -transmission channel to an SMTP server. The role of an SMTP client is to -transfer mail messages to one or more SMTP servers, or report its failure -to do so. - -The means by which a mail message is transferred to an SMTP client, and how -that client determines the domain name(s) to which mail messages are to be -transferred is a local matter, and is not addressed by this document. In -some cases, the domain name(s) transferred to, or determined by, an SMTP -client will identify the final destination(s) of the mail message. In other -cases, common with SMTP clients associated with implementations of the POP -[RFC-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the SMTP client -is inside an isolated transport service environment, the domain name -determined will identify an intermediate destination through which all mail -messages are to be relayed. SMTP clients that transfer all traffic, -regardless of the target domain names associated with the individual -messages, or that do not maintain queues for retrying message transmissions -that initially cannot be completed, may otherwise conform to this -specification but are not considered fully-capable. Fully-capable SMTP -implementations, including the relays used by these less capable ones, and -their destinations, are expected to support all of the queuing, retrying, -and alternate address functions discussed in this specification. - -The means by which an SMTP client, once it has determined a target domain -name, determines the identity of an SMTP server to which a copy of a -message is to be transferred, and then performs that transfer, is covered -by this document. To effect a mail transfer to an SMTP server, an SMTP -client establishes a two-way transmission channel to that SMTP server. An -SMTP client determines the address of an appropriate host running an SMTP -server by resolving a destination domain name to either an intermediate -Mail eXchanger host or a final target host. - -An SMTP server may be either the ultimate destination or an intermediate -"relay" (that is, it may assume the role of an SMTP client after receiving -the message) or "gateway" (that is, it may transport the message further -using some protocol other than SMTP). SMTP commands are generated by the -SMTP client and sent to the SMTP server. SMTP replies are sent from the -SMTP server to the SMTP client in response to the commands. - -Once the transmission channel is established and initial handshaking -completed, the SMTP client normally initiates a mail transaction. Such a -transaction consists of a series of commands to specify the originator and -destination of the mail and transmission of the message content (including -any headers or other structure) itself. When the same message is sent to -multiple recipients, this protocol encourages the transmission of only one -copy of the data for all recipients at the same destination (or -intermediate relay) host. - -The server responds to each command with a reply; replies may indicate that -the command was accepted, that additional commands are expected, or that a -temporary or permanent error condition exists. Commands specifying the -sender or recipients may include server-permitted SMTP service extension -requests as discussed in section 2.2. The dialog is purposely lock-step, -one-at-a-time, although this can be modified by mutually-agreed extension -requests such as in [RFC-Pipeline]. - -Once a given mail message has been transmitted, the client may either -request that the connection be shut down or may initiate other mail -transactions. In addition, an SMTP client may use a connection to an SMTP -server for ancillary services such as verification of email addresses or -retrieval of mailing list subscriber addresses. - -As suggested above, this protocol provides mechanisms for the transmission -of mail. This transmission normally occurs directly from the sending -user's host to the receiving user's host when the two hosts are connected -to the same transport service. When they are not connected to the same -transport service, transmission occurs via one or more relay SMTP servers. -An intermediate host that acts as either an SMTP relay or as a gateway into -some other transmission environment is usually selected through the use of -the domain name service (DNS) Mail eXchanger mechanism. - -To provide relay capability, the SMTP server is supplied with the name of -the ultimate destination host as well as the destination mailbox name. -Usually, intermediate hosts are determined via the DNS MX record, not by -explicit "source" routing (see section 5 and appendices C and F.2). - -2.2 The Extension Model - -2.2.1 Background - -In an effort that started in 1990, approximately a decade after RFC 821 was -completed, the protocol was modified with a "service extensions" model that -permits the client and server to agree to utilize shared functionality -beyond the original SMTP requirements. The SMTP extension mechanism defines -a means whereby an extended SMTP client and server may recognize each -other, and the server can inform the client as to the service extensions -that it supports. - -Contemporary SMTP implementations MUST support the basic extension -mechanisms. For instance, servers MUST support the EHLO command even if -they do not implement any specific extensions and clients SHOULD -preferentially utilize EHLO rather than HELO. (However, for compatibility -with older conforming implementations, SMTP clients and servers MUST -support the original HELO mechanisms as a fallback.) Unless the different -characteristics of HELO must be identified for interoperability purposes, -this document discusses only EHLO. - -SMTP is widely deployed and high-quality implementations have proven to be -very robust. However, the Internet community now considers some services to -be important that were not anticipated when the protocol was first -designed. If support for those services is to be added, it must be done in -a way that permits older implementations to continue working acceptably. -The extension framework consists of: - - - The SMTP command EHLO, superseding the earlier HELO, - - - a registry of SMTP service extensions, - - - additional parameters to the SMTP MAIL FROM and RCPT TO commands, and - - - optional replacements for verbs defined in this protocol, such as for - DATA (see [RFC-BDAT]). - -SMTP's strength comes primarily from its simplicity. Experience with many -protocols has shown that protocols with few options tend towards ubiquity, -whereas protocols with many options tend towards obscurity. - -Each and every extension, regardless of its benefits, must be carefully -scrutinized with respect to its implementation, deployment, and -interoperability costs. In many cases, the cost of extending the SMTP -service will likely outweigh the benefit. - -2.2.2 Definition and Registration of Extensions - -The IANA maintains a registry of SMTP service extensions. A corresponding -EHLO keyword value is associated with each extension. Each service -extension registered with the IANA must be defined in a formal -standards-track or IESG-approved experimental protocol document. The -definition must include: - - - the textual name of the SMTP service extension; - - - the EHLO keyword value associated with the extension; - - - the syntax and possible values of parameters associated with the - EHLO keyword value; - - - any additional SMTP verbs associated with the extension (additional - verbs will usually be, but are not required to be, the same as the - EHLO keyword value); - - - any new parameters the extension associates with the MAIL FROM or - RCPT TO verbs; - - - a description of how support for the extension affects the behavior - of a server and client SMTP; and, - - - the increment by which the extension is increasing the maximum - length of the commands MAIL FROM and/or RCPT TO, over that specified - in this standard. - -In addition, any EHLO keyword value starting with an upper or lower case -"X" refers to a local SMTP service extension used exclusively through -bilateral agreement. Keywords beginning with "X" MUST NOT be used in a -registered service extension. Conversely, keyword values presented in the -EHLO response that do not begin with "X" MUST correspond to a standard, -standards-track, or IESG-approved experimental SMTP service extension -registered with IANA. A conforming server MUST NOT offer non-"X"-prefixed -keyword values that are not described in a registered extension. - -Additional verbs and parameter names are bound by the same rules as EHLO -keywords; specifically, verbs beginning with "X" are local extensions that -may not be registered or standardized. Conversely, verbs not beginning -with "X" must always be registered. - -2.3 Terminology - -Most of the terminology in this document is common in the Internet at the -time of its writing. However, the following terms and concepts are used -in special ways here, or represent differences in terminology between RFC -821 and this document, and should be understood before reading further. -These definitions are normative, that is, they contain specifications to -which SMTP implementations are required to conform. - -The terms "MUST" and "SHOULD" (and "MUST NOT" and "SHOULD NOT") are used -in the same general sense here as in the Host Requirements Standards -[RFC-1123]. Specifically, "MUST" or "MUST NOT" identify absolute -requirements for conformance to this specification. Implementations that -do not conform to them lie outside the scope of this specification and -often will not interoperate properly with SMTP implementations that do -conform. Implementations that are fully conforming also adhere to all -"SHOULD" and "SHOULD NOT" requirements. Implementations that adhere to -all "MUST" ("MUST NOT") but not to all of these are considered to be -partially conforming. Such implementations may interoperate properly with -fully conforming ones and with each other, but this will typically be the -case only if great care is taken. Consequently, an implementation should -violate "SHOULD" ("SHOULD NOT") requirements only under exceptional and -well-understood circumstances. "SHOULD" (and sometimes "MUST") -requirements are often imposed by this specification when experience has -shown that following such requirements or restrictions leads, in practice, -to better interoperation, or smoother operation of the Internet email -infrastructure. As a consequence, some of these statements constitute -recommended practices, rather than the statistically most common practice -at the time of this writing. Statements using "MAY" describe features or -styles of doing things that may be followed, or not, at the discretion of -the implementation, normally without causing significant interoperability -problems. - -2.3.1 Mail Objects - -SMTP transports a mail object. A mail object contains an envelope and -content. - -The SMTP envelope is sent as a series of SMTP protocol units (described in -section 3). It consists of an originator address (to which error reports -should be directed); a delivery mode (e.g., deliver to recipient -mailboxes); one or more recipient addresses; and optional protocol -extension material. - -The SMTP content is sent in the SMTP DATA protocol unit and has two parts: -the headers and the body. If the content conforms to existing standards, -the headers form a collection of field/value pairs structured as described -in [MSGFMT]; the body, if structured, is defined according to MIME -[RFC-MIME]. The content is textual in nature, expressed using the US-ASCII -repertoire [US-ASCII]. Although SMTP extensions (such as [8BitMIME]) may -relax this restriction for the content body, the content headers are always -encoded using the US-ASCII repertoire. The algorithm defined in -[RFC-INTLHDR] is used to represent header values outside the US-ASCII -repertoire, while still encoding them using the US-ASCII repertoire. - -2.3.2 Senders and Receivers - -In RFC 821, the two hosts participating in an SMTP transaction were -described as the "SMTP-sender" and "SMTP-receiver". This document has been -changed to reflect current industry terminology and hence refers to them as -the "SMTP client" (or sometimes just "the client") and "SMTP server" (or -just "the server"), respectively. Since a given host may act both as -server and client in a relay situation, "receiver" and "sender" terminology -is still used where needed for clarity. - -2.3.3 Mail Agents - -Additional mail system terminology became common after RFC 821 was -published and, where convenient, is used in this specification. In -particular, SMTP servers and clients provide a mail transport service and -therefore act as Mail Transfer Agents (MTAs). Mail User Agents (MUAs or -UAs) are normally thought of as the sources and targets of mail. At the -source, an MUA might collect mail to be transmitted from a user and hand it -off to an MTA; the final ("delivery") MTA would be thought of as handing -the mail off to an MUA (or at least transferring responsibility to it). -However, while these terms are used with at least the appearance of great -precision in other environments, the implied boundaries between MUAs and -MTAs often do not accurately match common, and conforming, practices with -Internet mail. Hence, the reader should be cautious about inferring the -strong relationships and responsibilities that might be implied if these -terms were used elsewhere. - -2.3.4 Host - -For the purposes of this specification, a host is a computer system -attached to the Internet (or, in some cases, to a private TCP/IP network) -and supporting the SMTP protocol. Hosts are known by names (see "domain"); -identifying them by numerical address is discouraged. - -2.3.5 Domain - -A domain (or domain name) consists of one or more dot-separated components, -each consisting of a sequence of letters, digits, and hyphens. Domain -names are used as names of hosts and of other entities in the domain name -hierarchy. For example, a domain may refer to an alias (label of a CNAME -RR) or the label of Mail eXchanger records to be used to deliver mail -instead of representing a host name. See [RFC-DNS] and section 5. - -The domain name, as described in this document and in [RFC-DNS], is the -entire, fully-qualified name (often referred to as an "FQDN"). A domain -name that is not in FQDN form is no more than a local alias. Local aliases -MUST NOT appear in any SMTP transaction. - -2.3.6 Buffer and State Table - -SMTP sessions are stateful, with both parties carefully maintaining a -common view of the current state. In this document we model this state by -a virtual "buffer" and a "state table" on the server which may be used by -the client to, for example, "clear the buffer" or "reset the state table," -causing the information in the buffer to be discarded and the state to be -returned to some previous state - -2.3.7 Lines - -SMTP commands and, unless altered by a service extension, message data, are -transmitted in "lines". Lines consist of zero or more data characters -terminated by the sequence ASCII character "CR" (hex value 0D) followed -immediately by ASCII character "LF" (hex value 0A). This termination -sequence is denoted as <CRLF> in this document. Conforming implementations -MUST NOT recognize or generate any other character or character sequence as -a line terminator. - -2.3.8 Originator, Delivery, Relay, and Gateway Systems - -This specification makes a distinction among four types of SMTP systems, -based on the role those systems play in transmitting electronic mail. An -"originating" system (sometimes called an SMTP originator) introduces mail -into the Internet or, more generally, into a transport service environment. -A "delivery" SMTP system is one that receives mail from a transport service -environment and hands it to a mail user agent or deposits it in a message -store which a mail user agent is expected to subsequently access. A -"relay" SMTP system (usually referred to just as a "relay") receives mail -from an SMTP client and transmits it, without modification to the message -data other than adding trace information, to another SMTP server for -further relaying or for delivery. - -A "gateway" SMTP system (usually referred to just as a "gateway") receives -mail from a client system in one transport environment and transmits it to -a server system in another transport environment. Differences in protocols -or message semantics between the transport environments on either side of a -gateway may require that the gateway system perform transformations to the -message that are not permitted to SMTP relay systems. - -2.3.9 Message Content and Mail Data - -The terms "message content" and "mail data" are used interchangeably in -this document to describe the material transmitted after the DATA command -is accepted and before the end of data indication is transmitted. Message -content includes message headers and the possibly-structured message body. -The MIME specification [RFC-MIME] provides the Standard mechanisms for -structured message bodies. - -2.3.10 Mailbox and Address - -As used in this specification, an "address" is a character string that -identifies a user to whom mail will be sent or a location into which mail -will be deposited. The term "mailbox" refers to that depository. The two -terms are typically used interchangeably unless the distinction between the -location in which mail is placed (the mailbox) and a reference to it (the -address) is important. An address normally consists of user and domain -specifications. The standard mailbox naming convention is defined to be -"local-part@domain": contemporary usage permits a much broader set of -applications than simple "user names" and, consequently, the local-part is -interpreted and assigned semantics only by the host specified in the domain -part of the address. - -2.3.11 Reply - -An SMTP reply is an acknowledgment (positive or negative) sent from -receiver to sender via the transmission channel in response to a command. -The general form of a reply is a numeric completion code (indicating -failure or success) usually followed by a text string. The codes are for -use by programs and the text is usually intended for human users. - -2.4 Syntax Principles - -2.4.1 General Syntax and Transaction Model - -SMTP commands and replies have a rigid syntax. All commands begin with a -four letter command verb. All Replies begin with a three digit numeric -code. In some commands and replies, arguments MUST follow the verb or reply -code. Some commands do not accept arguments (after the verb), and some -reply codes are followed, sometimes optionally, by free form text. In both -cases, where text appears, it is separated from the verb or reply code by a -<SP>. Complete definitions of commands and replies appear in section 4. - -Verbs and argument values are not case sensitive, with the sole -exception in this specification of a mailbox local-part (SMTP -Extensions may explicitly specify case-sensitive elements). That is, a -command verb, an argument value other than a mailbox local-part, and -free form text MAY be encoded in upper case, lower case, or any mixture -of upper and lower case with no impact on its meaning. This is NOT -true of a mailbox local-part. The local-part of a mailbox MUST BE -treated as case sensitive. Therefore, SMTP implementations MUST take -care to preserve the case of mailbox local-parts. Mailbox domains are -not case sensitive. However, exploiting the case sensitivity of -mailbox local-parts impedes interoperability and is discouraged. - -Commands and replies are composed of characters from the ASCII character -set [US-ASCII]. When the transport service provides an 8-bit byte (octet) -transmission channel, each 7-bit character is transmitted right justified -in an octet with the high order bit cleared to zero. More specifically, the -unextended SMTP service provides seven bit transport only. An originating -SMTP client which has not successfully negotiated an appropriate extension -with a particular server MUST NOT transmit messages with information in the -high-order bit of octets. If such messages are transmitted in violation of -this rule, receiving SMTP servers MAY clear the high-order bit or reject -the message as invalid. In general, a relay SMTP SHOULD assume that the -message content it has received is valid and, assuming that the envelope -permits doing so, relay it without inspecting that content. Of course, if -the content is mislabeled and the data path cannot accept the actual -content, this may result in ultimate delivery of a severely garbled message -to the recipient. Delivery SMTP systems MAY reject ("bounce") such -messages rather than deliver them. No sending SMTP system is permitted to -send envelope commands in any character set other than US-ASCII; receiving -systems SHOULD reject such commands, normally using "500 syntax error - -invalid character" replies. - -Eight-bit message content transmission MAY be requested of the server by a -client using extended SMTP facilities, notably the "8BITMIME" extension -[8BITMIME]. 8BITMIME SHOULD be supported by SMTP servers. However, it MUST -not be construed as authorization to transmit unrestricted eight bit -material. 8BITMIME MUST NOT be requested by senders for material with the -high bit on that is not in MIME format with an appropriate content-transfer -encoding; servers MAY reject such messages. - -The metalinguistic notation used in this document corresponds to the -"Augmented BNF" used in other Internet mail system documents. The reader -who is not familiar with that syntax should consult [ABNF]. Metalanguage -terms used in running text are surrounded by pointed brackets (e.g., -<CRLF>) for clarity. - -2.4.2 Command and Reply Syntax - -The commands consist of a command verb followed by an argument field. -Command verbs are four alphabetic characters and are case insensitive. - -This also applies to any symbols representing parameter values, such as -"TO" or "to" for the forward-path. Command verbs and the argument fields -are separated by one or more spaces. However, case is important in the -local-part within the reverse-path and forward-path arguments. In -particular, for some hosts the user "smith" is different from the user -"Smith". - -A few SMTP servers, in violation of this specification (and RFC 821) -require that command verbs be encoded by clients in upper case. -Implementations MAY wish to employ this encoding to accommodate those -servers. - -The argument field consists of a variable length character string ending -with the character sequence <CRLF>. The receiver will take no action until -this sequence is received. - -The syntax for each command is shown with the discussion of that command. -Common elements and parameters are shown in section 4.1.2. - - -3. The SMTP Procedures: An Overview - -This section contains descriptions of the procedures used in SMTP: session -initiation, the mail transaction, forwarding mail, verifying mailbox names -and expanding mailing lists, and the opening and closing exchanges. -Comments on relaying, a note on mail domains, and a discussion of changing -roles are included at the end of this section. Several complete scenarios -are presented in appendix D. - -3.1 Session Initiation - -An SMTP session is initiated when a client opens a connection to a server -and the server responds with an opening message. - -SMTP server implementations MAY include identification of their software -and version information in the connection greeting reply after the 220 -code, a practice that permits more efficient isolation and repair of any -problems. Implementations MAY make provision for SMTP servers to disable -the software and version announcement where it causes security concerns. -While some systems also identify their contact point for mail problems, -this is not a substitute for maintaining the required "postmaster" address -(see section 4.5.1). - -The SMTP protocol allows a server to formally reject a transaction while -still allowing the initial connection as follows: a 554 response MAY be -given in the initial connection opening message instead of the 220. A -server taking this approach MUST still wait for the client to send a QUIT -(see section 4.1.1.10) before closing the connection and SHOULD respond to -any intervening commands with "503 bad sequence of commands". Since an -attempt to make an SMTP connection to such a system is probably in error, a -server returning a 554 response on connection opening SHOULD provide enough -information in the reply text to facilitate debugging of the sending -system. - -3.2 Client Initiation - -Once the server has sent the welcoming message and the client has received -it, the client normally sends the EHLO command to the server, indicating -the client's identity. In addition to opening the session, use of EHLO -indicates that the client is able to process service extensions and -requests that the server provide a list of the extensions it supports. -Older SMTP systems which are unable to support service extensions and -contemporary clients which do not require service extensions in the mail -session being initiated, MAY use HELO instead of EHLO. Servers MUST NOT -return the extended EHLO-style response to a HELO command. - -In the EHLO command the host sending the command identifies itself; the -command may be interpreted as saying "Hello, I am <domain>" (and, in the -case of EHLO, "and I support service extension requests"). - -3.3 Mail Transactions - -There are three steps to SMTP mail transactions. The transaction starts -with a MAIL command which gives the sender identification. A series of one -or more RCPT commands follows giving the receiver information. Then a DATA -command initiates transfer of the mail data and is terminated by the "end -of mail" data indicator, which also confirms the transaction. - -The first step in the procedure is the MAIL command. - - MAIL FROM:<reverse-path> [<SP> <mail-parameters> ] <CRLF> - -This command tells the SMTP-receiver that a new mail transaction is -starting and to reset all its state tables and buffers, including any -recipients or mail data. The <reverse-path> contains the source mailbox -(between "<" and ">" brackets, which can be used to report errors (see -section 4.2 for a discussion of error reporting). If accepted, the -SMTP server returns a 250 OK reply. If the mailbox specification is -not acceptable for some reason, the server MUST return a reply -indicating whether the failure is permanent (i.e., will occur again if -the client tries to send the same address again) or temporary (i.e., -the address might be accepted if the client tries again later). Despite -the apparent scope of this requirement, there are circumstances in -which the acceptability of the reverse-path may not be determined until -one or more forward-paths (in RCPT commands) can be examined. In those -cases, the server MAY reasonably accept the reverse-path (with a 250 -reply) and then report problems after the forward-paths are received -and examined. Normally, failures produce 550 or 553 replies. - -Historically, the <reverse-path> can contain more than just a mailbox, -however, contemporary systems SHOULD NOT use source routing (see appendix -C). - -The optional <mail-parameters> are associated with negotiated SMTP service -extensions (see section 2.2). - -The second step in the procedure is the RCPT command. - - RCPT TO:<forward-path> [ <SP> <rcpt-parameters> ] <CRLF> - -This command gives a forward-path (normally a mailbox and domain, -always surrounded by "<" and ">" brackets) identifying one recipient. -If accepted, the SMTP server returns a 250 OK reply and stores the -forward-path. If the recipient is known not to be a deliverable -address, the SMTP server returns a 550 reply, typically with a string -such as "no such user - " and the mailbox name (other circumstances and -reply codes are possible). This step of the procedure can be repeated -any number of times. - -The <forward-path> can contain more than just a mailbox. Historically, the -<forward-path> can be a source routing list of hosts and the destination -mailbox, however, contemporary SMTP clients SHOULD NOT utilize source -routes (see appendix C). Servers MUST be prepared to encounter a list of -source routes in the forward path, but SHOULD ignore the routes or MAY -decline to support the relaying they imply. Similarly, servers MAY decline -to accept mail that is destined for other hosts or systems. These -restrictions make a server useless as a relay for clients that do not -support full SMTP functionality. Consequently, restricted-capability -clients MUST NOT assume that any SMTP server on the Internet can be used as -their mail processing (relaying) site. If RCPT TO appears without a -previous MAIL FROM, the server MUST return a 503 "Bad sequence of commands" -response. The optional <rcpt-parameters> are associated with negotiated -SMTP service extensions (see section 2.2). - -The third step in the procedure is the DATA command (or some alternative -specified in a service extension). - - DATA <CRLF> - -If accepted, the SMTP server returns a 354 Intermediate reply and considers -all succeeding lines up to but not including the end of mail data indicator -to be the message text. When the end of text is successfully received and -stored the SMTP-receiver sends a 250 OK reply. - -Since the mail data is sent on the transmission channel, the end of mail -data must be indicated so that the command and reply dialog can be resumed. -SMTP indicates the end of the mail data by sending a line containing only a -"." (period or full stop). A transparency procedure is used to prevent -this from interfering with the user's text (see section 4.5.2). - -The end of mail data indicator also confirms the mail transaction and tells -the SMTP server to now process the stored recipients and mail data. If -accepted, the SMTP server returns a 250 OK reply. The DATA command can fail -in only two ways: - - - If there was no MAIL FROM, or no RCPT TO, command, or all such commands - were rejected, the server MAY return a "command out of sequence" (503) - reply. If that reply is received, the client MUST NOT send the message - data; more generally, message data MUST NOT be sent unless a 354 reply - is received. - - - If the verb is initially accepted and the 354 reply issued, the DATA - command should fail only if the mail transaction was incomplete (for - example, no recipients), or if resources were unavailable, or if the - server determines that the message should be rejected for policy or - other reasons. - -However, in practice, some servers do not perform recipient verification -until after the message text is received. These servers SHOULD treat a -failure for one or more recipients as a "subsequent failure" and return a -mail message as discussed in section 6. Using a "550 mailbox not found" -(or equivalent) reply code after the data are accepted makes it difficult -or impossible for the client to determine which recipients failed. - -When RFC 822 format is being used, the mail data include the memo header -items such as Date, Subject, To, Cc, From [MSGFMT]. Server SMTP systems -SHOULD NOT reject messages based on perceived defects in the RFC 822 or -MIME [RFC-MIME] message header or message body. In particular, they MUST -NOT reject messages in which the numbers of Resent- fields do not match or -Resent-to appears without Resent-from and/or Resent-date. - -Mail transaction commands MUST be used in the order discussed above. - - -3.4 Forwarding for Address Correction or Updating - -Forwarding support is most often required to consolidate and simplify -addresses within, or relative to, some enterprise and less frequently to -establish addresses to link a person's prior address with current one. -Silent forwarding of messages (without server notification to the sender), -for security or non-disclosure purposes, is common in the contemporary -Internet. - -In both the enterprise and the "new address" cases, information hiding -(and sometimes security) considerations argue against exposure of the -"final" address through the SMTP protocol as a side-effect of the -forwarding activity. This may be especially important when the final -address may not even be reachable by the sender. Consequently, the -"forwarding" mechanisms described in section 3.2 of RFC 821, and -especially the 251 (corrected destination) reply code from RCPT TO are -deprecated: Servers SHOULD NOT provide that service or return that code. - - -3.5 Commands for Debugging Addresses - -3.5.1 Overview - -SMTP provides commands to verify a user name or obtain the content of a -mailing list. This is done with the VRFY and EXPN commands, which have -character string arguments. Implementations SHOULD support VRFY and EXPN -(however, see section 3.5.2 and 7.3). - -For the VRFY command, the string is a user name or a user name and domain -(see below). If a normal (i.e., 250) response is returned, the response MAY -include the full name of the user and MUST include the mailbox of the user. -It MUST be in either of the following forms: - - User Name <local-part@domain> - local-part@domain - -When a name that is the argument to VRFY could identify more than one -mailbox, the server MAY either note the ambiguity or identify the -alternatives. In other words, any of the following are legitimate -response to VRFY: - - 553 User ambiguous - -or - - 553- Ambiguous; Possibilities are - 553-Joe Smith <jsmith@foo.com> - 553-Harry Smith <hsmith@foo.com> - 553 Melvin Smith <dweep@foo.com> - -or - - 553-Ambiguous; Possibilities - 553- <jsmith@foo.com> - 553- <hsmith@foo.com> - 553 <dweep@foo.com> - -Under normal circumstances, a client receiving a 553 reply would be -expected to expose the result to the user. Use of exactly the forms -given, and the "user ambiguous" or "ambiguous" keywords, possibly -supplemented by extended reply codes such as those described in -[RFC-REPLY], will facilitate automated translation into other languages as -needed. Of course, a client that was highly automated or that was -operating in another language than English, might choose to try to -translate the response, to return some other indication to the user than -the literal text of the reply, or to take some automated action such as -consulting a directory service for additional information before reporting -to the user. - -For the EXPN command, the string identifies a mailing list, and the -successful (i.e., 250) multiline response MAY include the full name of the -users and MUST give the mailboxes on the mailing list. - -In some hosts the distinction between a mailing list and an alias for a -single mailbox is a bit fuzzy, since a common data structure may hold both -types of entries, and it is possible to have mailing lists of one mailbox. -If a request is made to verify a mailing list, a positive response MAY be -given if a message so addressed would be delivered to everyone on the list, -otherwise an error SHOULD be reported (e.g., "550 That is a mailing list, -not a user" or "252 Unable to verify members of mailing list"). If a -request is made to expand a user name, the server MAY return a positive -response consisting of a list containing one name, or an error MAY be -reported (e.g., "550 That is a user name, not a mailing list"). - -In the case of a successful multiline reply (normal for EXPN) exactly one -mailbox is to be specified on each line of the reply. The case of an -ambiguous request is discussed above. - -"User name" is a fuzzy term and has been used deliberately. An -implementation of the VRFY or EXPN commands MUST include at least -recognition of local mailboxes as "user names". However, since current -Internet practice often results in a single host handling mail for -multiple domains, hosts, especially hosts that provide this functionality, -SHOULD accept the "local-part@domain" form as a "user name"; hosts MAY -also choose to recognize other strings as "user names". - -The case of expanding a mailbox list requires a multiline reply, such as: - - C: EXPN Example-People - S: 250-Jon Postel <Postel@isi.edu> - S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu> - S: 250 Sam Q. Smith <SQSmith@specific.generic.com> - -or - - C EXPN Executive-Washroom-List - S: 550 Access Denied to You. - -The character string arguments of the VRFY and EXPN commands cannot be -further restricted due to the variety of implementations of the user name -and mailbox list concepts. On some systems it may be appropriate for the -argument of the EXPN command to be a file name for a file containing a -mailing list, but again there are a variety of file naming conventions in -the Internet. Similarly, historical variations in what is returned by -these commands are such that the response SHOULD be interpreted very -carefully, if at all, and SHOULD generally only be used for diagnostic -purposes. - -3.5.2 VRFY Normal Response - -When normal (2yz or 551) responses are returned from a VRFY or EXPN -request, the reply MUST normally include the mailbox name. -"<local-part@domain>", where "domain" is a fully qualified domain name, -MUST appear in the syntax. In exceptional circumstances, free-form text -MAY be returned. In order to facilitate parsing by both computers and -people, addresses SHOULD appear in pointed brackets. When addresses, -rather than free-form debugging information, are returned, EXPN and VRFY -MUST return only valid domain addresses that are usable in SMTP RCPT -commands. Consequently, if an address implies delivery to a program or -other system, the mailbox name used to reach that target MUST be given. -Paths (explicit source routes) MUST NOT be returned by VRFY or EXPN. - -Server implementations SHOULD support both VRFY and EXPN. For security -reasons, implementations MAY provide local installations a way to disable -either or both of these commands through configuration options or the -equivalent. When these commands are supported, they are not required to -work across relays when relaying is supported. Since they were both -optional in RFC 821, they MUST be listed as service extensions in an EHLO -response, if they are supported. - -3.5.3 Meaning of VRFY or EXPN Success Response - -A server MUST NOT return a 220 code in response to a VRFY or EXPN command -unless it has actually verified the address. In particular, a server MUST -NOT return 220 if all it has done is to verify that the syntax given is -valid. In that case, 502 (Command not implemented) or 500 (Syntax error, -command unrecognized) SHOULD be returned. As stated elsewhere, -implementation of VRFY and EXPN are strongly recommended. -Hence, implementations that return 500 or 502 for VRFY are not in full -compliance with this specification. - -There may be circumstances where an address appears to be valid but cannot -reasonably be verified in real time, particularly when a server is acting -as a mail exchanger for another server or domain. "Apparent validity" in -this case would normally involve at least syntax checking and might -involve verification that any domains specified were ones to which the -host expected to be able to relay mail. In these situations, reply code -252 SHOULD be returned. These cases parallel the discussion of RCPT -verification discussed in section 2.1. Implementations generally SHOULD -be more aggressive about address verification in the case of VRFY than in -the case of RCPT, even if it takes a little longer to do so. - -3.5.4 Semantics and Applications of EXPN - -EXPN is often very useful in debugging and understanding problems with -mailing lists and multiple-target-address aliases. Some systems have -attempted to use source expansion of mailing lists as a means of -eliminating duplicates. The propagation of aliasing systems with mail on -the Internet, for hosts (typically with MX and CNAME DNS records), for -mailboxes (various types of local host aliases), and in various proxying -arrangements, has made it nearly impossible for these strategies to work, -and mail systems SHOULD NOT attempt them. - -3.6 Domains - -Only resolvable, fully-qualified, domain names (FQDNs) are permitted when -domain names are used in SMTP. In other words, names that can be resolved -to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME -RRs whose targets can be resolved, in turn, to MX or A RRs. Local -nicknames or unqualified names MUST NOT be used. There are two exceptions -to the rule requiring FQDNs: - - - The domain name given in the EHLO command MUST BE either a primary host - name (a domain name that resolves to an A RR) or, if the host has no - name, an address literal as described in section 4.1.1.1. - - - The reserved mailbox name "postmaster" may be used in a RCPT TO command - without domain qualification (see section 4.1.1.3) and MUST be accepted - if so used. - -3.7 Relaying - -In general, the availability of Mail eXchanger records in the domain name -system [RFC-DNS] makes the use of explicit source routes in the Internet -mail system unnecessary. Many historical problems with their -interpretation have made their use undesirable. SMTP clients SHOULD NOT -generate explicit source routes except under unusual circumstances. SMTP -servers MAY decline to act as mail relays or to accept addresses that -specify source routes. When route information is encountered, SMTP -servers are also permitted to ignore the route information and simply send -to the final destination specified as the last element in the route and -SHOULD do so. There has been an invalid practice of using names that do -not appear in the DNS as destination names, with the senders counting on -the intermediate hosts specified in source routing to resolve any -problems. If source routes are stripped, this practice will cause -failures. This is one of several reasons why SMTP clients MUST NOT -generate invalid source routes or depend on serial resolution of names. - -When source routes are not used, the process described in RFC 821 for -constructing a reverse-path from the forward-path is not applicable and the -reverse-path at the time of delivery will simply be the address that -appeared in the MAIL command. - -A relay SMTP server is usually the target of a DNS MX record that -designates it, rather than the final delivery system. The relay server may -accept or reject the task of relaying the mail in the same way it accepts -or rejects mail for a local user. If it accepts the task, it then becomes -an SMTP client, establishes a transmission channel to the next SMTP server -specified in the DNS (according to the rules in section 5), and sends it -the mail. If it declines to relay mail to a particular address for policy -reasons, a 550 response SHOULD be returned. - -A relay SMTP server may be encountered in one additional circumstance: by -private agreement between an originating client SMTP and an associated -SMTP relay, the client MAY be configured to send all mail to that relay -for further processing. In conformance with this specification and other -Internet Standards and guidelines, the relay SMTP SHOULD be configured -into a client of this type by name (rather than by IP address), and the -name SHOULD be processed as described in section 5. Clients of this sort -will rarely be fully-conformant to this specification since, in most -cases, the use of a single relay for all outgoing mail traffic is used as -an alternative to such requirements as the one to retry mail delivery on -connection failures (see section 5 and elsewhere). - -It is important to note that MX records can point to SMTP servers which -act as gateways into other environments, not just SMTP relays and final -delivery systems; see sections 3.8 and 5. - -If an SMTP server has accepted the task of relaying the mail and later -finds that the destination is incorrect or that the mail cannot be -delivered for some other reason, then it MUST construct an "undeliverable -mail" notification message and send it to the originator of the -undeliverable mail (as indicated by the reverse-path). Formats specified -for non-delivery reports by other standards (see, for example, -[RFC-NOTARY1]) SHOULD be used if possible. - -This notification message must be from the SMTP server at the relay host -or the host that first determines that delivery cannot be accomplished. -Of course, SMTP servers MUST NOT send notification messages about problems -transporting notification messages. One way to prevent loops in error -reporting is to specify a null reverse-path in the MAIL command of a -notification message. When such a message is transmitted the reverse-path -MUST be set to null (see section 4.5.5 for additional discussion). A MAIL -command with a null reverse-path appears as follows: - - MAIL FROM:<> - -As discussed in section 2.4.1, a relay SMTP has no need to inspect or act -upon the headers or body of the message data and MUST NOT do so except -to add its own "Received:" header (section 4.4) and to perform simple -counting of the number of "Received:" headers in a message (section 6.2). - -3.8 Mail Gatewaying - -While the relay function discussed above operates within the Internet SMTP -transport service environment, MX records or various forms of explicit -routing may require that an intermediate SMTP server perform a translation -function between one transport service and another. As discussed in -section 2.3.8, when such a system is at the boundary between two transport -service environments, we refer to it as a "gateway" or "gateway SMTP". - -Gatewaying mail between different mail environments, such as different mail -formats and protocols, is complex and does not easily yield to -standardization. However, some general requirements may be given for a -gateway between the Internet and another mail environment. - -3.8.1 Header Fields in Gatewaying - -Header fields MAY be rewritten when necessary as messages are gatewayed -across mail environment boundaries. This may involve inspecting the message -body or interpreting the local-part of the destination address in spite of -the prohibitions in section 2.4.1 - -Other mail systems gatewayed to the Internet often use a subset of RFC-822 -headers or provide similar functionality with a different syntax, but some -of these mail systems do not have an equivalent to the SMTP envelope. -Therefore, when a message leaves the Internet environment, it may be -necessary to fold the SMTP envelope information into the message header. A -possible solution would be to create new header fields to carry the -envelope information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, -this would require changes in mail programs in foreign environments and -might risk disclosure of private information (see section 7.2). - -3.8.2 Received Lines in Gatewaying - -When forwarding a message into or out of the Internet environment, a -gateway MUST prepend a Received: line, but it MUST NOT alter in any way a -Received: line that is already in the header. - -Received: fields of messages originating from other environments may not -conform exactly to this specification. However, the most important use of -Received: lines is for debugging mail faults, and this debugging can be -severely hampered by well-meaning gateways that try to "fix" a Received: -line. As another consequence of trace fields arising in non-SMTP -environments, receiving systems MUST NOT reject mail based on the format of -a trace field and SHOULD be extremely robust in the light of unexpected -information or formats in those fields. - -The gateway SHOULD indicate the environment and protocol in the "via" -clauses of Received field(s) that it supplies. - -3.8.3 Addresses in Gatewaying - ->From the Internet side, the gateway SHOULD accept all valid address formats -in SMTP commands and in RFC-822 headers, and all valid RFC-822 messages. -Gateways are, of course, subject to the same rules for handling source -routes as those described for other SMTP systems in section 3.3. - -3.8.4 Other Header Fields in Gatewaying - -The gateway MUST ensure that all header fields of a message that it -forwards into the Internet meet the requirements for Internet mail. In -particular, all addresses in "From:", "To:", "Cc:", etc., fields MUST be -transformed (if necessary) to satisfy RFC-822 syntax, MUST reference only -fully-qualified domain names, and MUST be effective and useful for sending -replies. The translation algorithm used to convert mail from the -Internet protocols to another environment's protocol SHOULD ensure that -error messages from the foreign mail environment are delivered to the -return path from the SMTP envelope, not to the sender listed in the "From:" -field (or other fields) of the RFC-822 message. - -3.8.5 Envelopes in Gatewaying - -Similarly, when forwarding a message from another environment into the -Internet, the gateway SHOULD set the envelope return path in accordance -with an error message return address, if supplied by the foreign -environment. If the foreign environment has no equivalent concept, the -gateway must select and use a best approximation, with the message -originator's address as the default of last resort. - -3.9 Terminating Sessions and Connections - -An SMTP connection is terminated when the client sends a QUIT command. The -server responds with a positive reply code, after which it closes the -connection. - -An SMTP server MUST NOT intentionally close the connection except: - - - After receiving a QUIT command and responding with a 221 reply. - - - After detecting the need to shutdown the SMTP service and returning a - 421 response code. This response code can be issued after the server - receives any command or, if necessary, asynchronously from command - receipt (on the assumption that the client will receive it after the - next command is issued). - -In particular, a server that closes connections in response to commands -that are not understood is in violation of this specification. Servers are -expected to be tolerant of unknown commands, issuing a 500 reply and -awaiting further instructions from the client. - -An SMTP server which is forcibly shut down via external means SHOULD -attempt to send a line containing a 421 response code to the SMTP client -before exiting. The SMTP client will normally read the 421 response code -after sending its next command. - -SMTP clients that experience a connection close, reset, or other -communications failure due to circumstances not under their control (in -violation of the intent of this specification but sometimes unavoidable) -SHOULD, to maintain the robustness of the mail system, treat the mail -transaction as if a 451 response had been received and act accordingly. - -3.10 Mailing Lists and Aliases - -An SMTP-capable host SHOULD support both the alias and the list models of -address expansion for multiple delivery. When a message is delivered or -forwarded to each address of an expanded list form, the return address in -the envelope ("MAIL FROM:") MUST be changed to be the address of a person -or other entity who administers the list. However, in this case, the -message header (see [MSGFMT]) MUST be left unchanged; in particular, the -"From" field of the message header is unaffected. - -An important mail facility is a mechanism for multi-destination delivery -of a single message, by transforming (or "expanding" or "exploding") a -pseudo-mailbox address into a list of destination mailbox addresses. When -a message is sent to such a pseudo-mailbox (sometimes called an -"exploder"), copies are forwarded or redistributed to each mailbox in the -expanded list. Servers SHOULD simply utilize the addresses on the list; -application of heuristics or other matching rules to eliminate some -addresses, such as that of the originator, is strongly discouraged. We -classify such a pseudo-mailbox as an "alias" or a "list", depending upon -the expansion rules. - -3.10.1 Alias - -To expand an alias, the recipient mailer simply replaces the pseudo-mailbox -address in the envelope with each of the expanded addresses in turn; the -rest of the envelope and the message body are left unchanged. The message -is then delivered or forwarded to each expanded address. - -3.10.2 List - -A mailing list may be said to operate by "redistribution" rather than -by "forwarding". To expand a list, the recipient mailer replaces the -pseudo-mailbox address in the envelope with all of the expanded -addresses. The return address in the envelope is changed so that all -error messages generated by the final deliveries will be returned to a -list administrator, not to the message originator, who generally has no -control over the contents of the list and will typically find error -messages annoying. - - -4. The SMTP Specifications - -4.1 SMTP Commands - -4.1.1 Command Semantics and Syntax - -The SMTP commands define the mail transfer or the mail system function -requested by the user. SMTP commands are character strings terminated by -<CRLF>. The commands themselves are alphabetic characters terminated by -<SP> if parameters follow and <CRLF> otherwise. (In the interest of -improved interoperability, SMTP receivers are encouraged to tolerate -trailing white space before the terminating <CRLF>.) The syntax of the -local part of a mailbox must conform to receiver site conventions and the -syntax specified in section 4.1.2. The SMTP commands are discussed below. -The SMTP replies are discussed in section 4.2. - -A mail transaction involves several data objects which are communicated as -arguments to different commands. The reverse-path is the argument of the -MAIL command, the forward-path is the argument of the RCPT command, and the -mail data is the argument of the DATA command. These arguments or data -objects must be transmitted and held pending the confirmation communicated -by the end of mail data indication which finalizes the transaction. The -model for this is that distinct buffers are provided to hold the types of -data objects, that is, there is a reverse-path buffer, a forward-path -buffer, and a mail data buffer. Specific commands cause information to be -appended to a specific buffer, or cause one or more buffers to be cleared. - -Several commands (RSET, DATA, QUIT) are specified as not permitting -parameters. In the absence of specific extensions offered by the server -and accepted by the client, clients MUST NOT send such parameters and -servers SHOULD reject commands containing them as having invalid syntax. - -4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) - -These commands are used to identify the SMTP client to the SMTP server. -The argument field contains the fully-qualified domain name of the SMTP -client if one is available. In situations in which the SMTP client system -does not have a meaningful domain name (e.g., when its address is -dynamically allocated and no reverse mapping record is available), the -client SHOULD send an address literal (see section 4.1.3), optionally -followed by information that will help to identify the client system. - -The SMTP server identifies itself to the SMTP client in the connection -greeting reply and in the response to this command. - -A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If -the SMTP server supports the SMTP service extensions it will give a -successful response, a failure response, or an error response. If the SMTP -server, in violation of this specification, does not support any SMTP -service extensions it will generate an error response. Older client SMTP -systems MAY, as discussed above, use HELO (as specified in RFC 821) instead -of EHLO, and servers MUST support the HELO command and reply properly to -it. In any event, a client MUST issue HELO or EHLO before starting a mail -transaction. - -These commands, and a "250 OK" reply to one of them, confirm that both the -SMTP client and the SMTP server are in the initial state, that is, there is -no transaction in progress and all state tables and buffers are cleared. - -Normally, the response to EHLO will be a multiline reply. Each line of the -response contains a keyword and, optionally, one or more parameters. The -syntax for a positive response, using the ABNF notation and low-level -terminals of [ABNF], is: - - ehlo-ok-rsp ::= "250" domain [ <SP> greeting ] <CRLF> - / ( "250-" domain [ <SP> greeting ] <CRLF> - *( "250-" ehlo-line <CRLF> ) - "250" <SP> ehlo-line <CRLF> ) - - greeting ::= 1*<any character other than CR or LF> - - ehlo-line ::= ehlo-keyword *( <SP> ehlo-param ) - - ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") - ; syntax and values depend on ehlo-keyword - - ehlo-param ::= 1*<any CHAR excluding <SP> and all - control characters (US-ASCII 0-31 - inclusive)> - -Although EHLO keywords may be specified in upper, lower, or mixed case, -they MUST always be recognized and processed in a case-insensitive manner. -This is simply an extension of practices specified in RFC 821 and section -2.4.1. - -4.1.1.2 MAIL (MAIL) - -This command is used to initiate a mail transaction in which the mail -data is delivered to an SMTP server which may, in turn, deliver it to -one or more mailboxes or pass it on to another system (possibly using -SMTP). The argument field contains a reverse-path and may contain -optional parameters. In general, the MAIL command may be sent only -when no mail transaction is in progress, see section 4.1.4. - -The reverse-path consists of the sender mailbox. Historically, that -mailbox might optionally have been preceeded by a list of hosts, but -that behavior. In some types of reporting messages for which a reply -is likely to cause a mail loop (for example, mail delivery and -nondelivery notifications), the reverse-path may be null (see section -3.7). - -This command clears the reverse-path buffer, the forward-path buffer, and -the mail data buffer; and inserts the reverse-path information from this -command into the reverse-path buffer. - -If service extensions were negotiated, the MAIL command may also carry -parameters associated with a particular service extension. - -Syntax: - - "MAIL FROM:" Reverse-path [ <SP> Mail-parameters ] - -or - "MAIL FROM:<>" [ <SP> Mail-parameters ] - -4.1.1.3 RECIPIENT (RCPT) - -This command is used to identify an individual recipient of the mail data; -multiple recipients are specified by multiple use of this command. -The argument field contains a forward-path and may contain optional -parameters. - -The forward-path normally consists of the required destination -mailbox. Sending systems SHOULD not generate the optional list of hosts -known as a source route. Receiving systems MUST recognize source route -syntax but SHOULD strip off the source route specification and utilize the -domain name associated with the mailbox as if the source route had not been -provided. - -Similarly, relay hosts SHOULD strip or ignore source routes, and names MUST -NOT be copied into the reverse-path. When mail reaches its ultimate -destination (the forward-path contains only a destination mailbox), the -SMTP server inserts it into the destination mailbox in accordance with its -host mail conventions. - -For example, mail received at relay host xyz.com with envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> - -will normally be sent directly on to host d.bar.org with envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<userc@d.bar.org> - -As provided in appendix C, xyz.com MAY also choose to relay the -message to hosta.int, using the envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> - -or to jkl.org, using the envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@jkl.org:userc@d.bar.org> - -Of course, since hosts are not required to relay mail at all, xyz.com -may also reject the message entirely when the RCPT command is -received, using a 550 code (since this is a "policy reason"). - -If service extensions were negotiated, the RCPT TO command may also carry -parameters associated with a particular service extension offered by the -server. The client MUST NOT transmit parameters other than those -associated with a service extension offered by the server in its EHLO -response. - -Syntax: - "RCPT TO:" Forward-path [ <SP> Rcpt-parameters ] -or - "RCPT TO:<Postmaster>" [ <SP> Rcpt-parameters ] - -4.1.1.4 DATA (DATA) - -The receiver treats the lines (strings ending in <CRLF> sequences, as -described in section 2.3.7) following the command as mail data from the -sender. This command causes the mail data to be appended to the mail data -buffer. The mail data may contain any of the 128 ASCII character codes, -although experience has indicated that use of control characters other than -SP, HT, CR, and LF (especially the ASCII "Null" character) may cause -problems and SHOULD be avoided when possible. - -The mail data is terminated by a line containing only a period, that is, -the character sequence "<CRLF>.<CRLF>" (see section 4.5.2). This is the -end of mail data indication. Note that the first <CRLF> of this -terminating sequence is also the <CRLF> that ends the final line of the -data (message text) or, if there was no data, ends the DATA command itself. -An extra <CRLF> MUST NOT be added, as that would cause an empty line to be -added to the message. The only exception to this rule would arise if the -message body were passed to the originating SMTP-sender with a final "line" -that did not end in <CRLF>; in that case, the originating SMTP system MUST -either reject the message as invalid or add <CRLF> in order to have the -receiving SMTP server recognize the "end of data" condition. - -The custom of accepting lines ending only in <LF>, as a concession to -non-conforming behavior on the part of some UNIX systems, has proven to -cause more interoperability problems than it solves, and SMTP server -systems MUST NOT do this, even in the name of improved robustness. In -particular, the sequence "<LF>.<LF>" (bare line feeds, without carriage -returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end of -mail data indication. - -Receipt of the end of mail data indication requires the server to process -the stored mail transaction information. This processing consumes the -information in the reverse-path buffer, the forward-path buffer, and the -mail data buffer, and on the completion of this command these buffers are -cleared. If the processing is successful, the receiver MUST send an OK -reply. If the processing fails the receiver MUST send a failure reply. The -SMTP model does not allow for partial failures at this point: either the -message is accepted by the server for delivery and a positive response is -returned or it is not accepted and a failure reply is returned. Errors -that are diagnosed subsequently MUST be reported in a mail message, as -discussed in section 4.4 In sending a positive completion reply to the end -of data indication, the receiver takes full responsibility for the message -(see section 6.1). - -When the SMTP server accepts a message either for relaying or for final -delivery, it inserts a trace record (also referred to interchangeably as a -"time stamp line" or "Received" line) at the top of the mail data. This -trace record indicates the identity of the host that sent the message, the -identity of the host that received the message (and is inserting this time -stamp), and the date and time the message was received. Relayed messages -will have multiple time stamp lines. Details for formation of these lines, -including their syntax, is specified in section 4.4. - -4.1.1.5 RESET (RSET) - -This command specifies that the current mail transaction will be aborted. -Any stored sender, recipients, and mail data MUST be discarded, and all -buffers and state tables cleared. The receiver MUST send a "250 OK" reply -to a RSET command with no arguments. A reset command may be issued by the -client at any time. It is effectively equivalent to a NOOP if issued -immediately after EHLO, before EHLO is issued in the session, after an -end-of-data indicator has been sent and acknowledged, or immediately before -a QUIT. In other situations, it restores the state to that immediately -after the most recent EHLO. An SMTP server MUST NOT close the connection -as the result of receiving a RSET; that action is reserved for QUIT (see -section 4.1.1.10). - -Since EHLO implies some additional processing and response by the server, -RSET will normally be more efficient than reissuing that command, even -though the formal semantics are the same. - -There are circumstances, contrary to the intent of this specification, in -which an SMTP server may receive an indication that the underlying TCP -connection has been closed or reset. To preserve the robustness of the -mail system, SMTP servers SHOULD be prepared for this condition and SHOULD -treat it as if a QUIT had been received before the connection disappeared. - -Syntax: - "RSET" - -4.1.1.6 VERIFY (VRFY) - -This command asks the receiver to confirm that the argument identifies a -user or mailbox. If it is a user name, information is returned as -specified in section 3.5. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -Syntax: - "VRFY" <SP> String - -4.1.1.7 EXPAND (EXPN) - -This command asks the receiver to confirm that the argument identifies a -mailing list, and if so, to return the membership of that list. If the -command is successful, a reply is returned containing information as -described in section 3.5. This reply will have multiple lines except in -the trivial case of a one-member list. - - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -Syntax: - "EXPN" <SP> String - -4.1.1.8 HELP (HELP) - -This command causes the server to send helpful information to the client. -The command MAY take an argument (e.g., any command name) and return more -specific information as a response. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -SMTP servers SHOULD support HELP without arguments and MAY support it with -arguments. - -Syntax: - "HELP" [ <SP> String ] - -4.1.1.9 NOOP (NOOP) - -This command does not affect any parameters or previously entered commands. -It specifies no action other than that the receiver send an OK reply. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. If a parameter string is specified, -servers SHOULD ignore it. - -Syntax: - "NOOP" [ <SP> String ] - - -4.1.1.10 QUIT (QUIT) - -This command specifies that the receiver MUST send an OK reply, and then -close the transmission channel. - -The receiver MUST NOT intentionally close the transmission channel until -it receives and replies to a QUIT command (even if there was an error). -The sender MUST NOT intentionally close the transmission channel until it -sends a QUIT command and SHOULD wait until it receives the reply (even if -there was an error response to a previous command). If the connection is -closed prematurely due to violations of the above or system or network -failure, the server MUST cancel any pending transaction, but not undo any -previously completed transaction, and generally MUST act as if the command -or transaction in progress had received a temporary error (i.e., a 4yz -response). - -Syntax: - "QUIT" - -4.1.2 Lower-level Syntax - -The syntax of the argument fields of the above commands (using the syntax -specified in [ABNF] where applicable) is given below. Some of the -productions given below are used only in conjunction with source routes as -described in appendix C. Terminals not defined in this document, such as -ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the "core" syntax -(section 6) of [ABNF] or in the syntax of [MSGFMT]. - - Reverse-path = Path - - Forward-path = Path - - Path = "<" [ A-d-l ":" ] Mailbox ">" - - A-d-l = At-domain *( "," A-d-l ) ; Note that this form, the - so-called "source route", MUST BE - accepted, SHOULD NOT be generated, - and SHOULD be ignored. - - At-domain = "@" Domain - - Mail-parameters = *( <SP> Keyword "=" Argument ) - - Rcpt-parameters = *( <SP> Keyword "=" Argument ) - - Keyword = Ldh-str - Argument = Atom - - Domain = sub-domain 1*("." sub-domain) / address-literal - - sub-domain = let-dig *(Ldh-str) - address-literal = "[" IPv4-address-literal / - IPv6-address-literal / General-address-literal "]" - IPv4-address-literal = snum 3*3("." snum) - IPv6-address-literal = "IPv6 " IPv6-addr-string - IPv6-addr-string = String ; IPv6 address in standard form - [IPv6AddrSpec]. Since this - form uses colon characters, - the String will actually need - to be quoted in all cases. - General-address-literal = Standardized-tag <SP> String - Standardized-tag = Ldh-str ; Specified in a - standards-track RFC - and registered with IANA - snum = 1*3Digit ; representing a decimal integer - value in the range 0 through 255 - let-dig = Alpha / Digit - ldh-str = *( Alpha / Digit / "-" ) let-dig - - Mailbox = Local-part "@" Domain - - Local-part = Dot-string / Quoted-string - - Dot-string = Atom [ "." Atom ] - -While the above definition for Local-part is relatively permissive, for -maximum interoperability, a host that expects to receive mail SHOULD avoid -defining mailboxes where the Local-part requires (or uses) the -Quoted-string form or where the Local-part is case-sensitive. For any -purposes that require generating or comparing Local-parts (e.g., to -specific mailbox names), all quoted forms MUST be treated as equivalent and -the sending system SHOULD transmit the form that uses the minimum quoting -possible. - -Systems MUST NOT define mailboxes in such a way as to require the use of -non-ASCII characters (octets with the high order bit set to one) or ASCII -"control characters" (decimal value 0-31 and 127). These characters MUST -NOT be used in MAIL FROM or RCPT TO commands or other commands that require -mailbox names. - - String = Atom / Quoted-string - - special = <<Msg-fmt-special>> / [[placeholder, see above]] - the control characters (ASCII codes 0 through 31 - inclusive and 127) - -Note that the backslash, "\", is a quote character, which is used to -indicate that the next character is to be used literally (instead of its -normal interpretation). For example, "Joe\,Smith" indicates a single nine -character user field with the comma being the fourth character of the -field. - -To promote interoperability and consistent with long-standing guidance -about conservative use of the DNS in naming and applications (e.g., see -section 2.3.1 of the base DNS document [RFC-1015]), characters outside the -set of alphas, digits, and hyphen MUST NOT appear in domain name labels -for SMTP clients or servers. In particular, the underscore character is -not permitted. SMTP servers that receive a command in which illegal -character codes have been employed, and for which there are no other -reasons for rejection, MUST reject that command with a 501 response. - -4.1.3 Address Literals - -Sometimes a host is not known to the domain name system and communication -(and, in particular, communication to report and repair the error) is -blocked. To bypass this barrier a special literal form of the address is -allowed as an alternative to a domain name. For IPv4 addresses, this form -uses four small decimal integers separated by dots and enclosed by brackets -such as [123.255.37.2], which indicates an (IPv4) Internet Address in -sequence-of-octets form. For IPv6 and other forms of addressing that might -eventually be standardized, the form consists of a standardized "tag" that -identifies the address syntax, a space, and the address itself, in a format -specified as part of the IPv6 standards [IPv6AddrSpec]. - -4.1.4 Order of Commands - -There are restrictions on the order in which these commands may be used. - -A session that will contain mail transactions MUST first be initialized by -the use of the EHLO command. An SMTP server SHOULD accept commands for -non-mail transactions (e.g., VRFY or EXPN) without this initialization. - -An EHLO command MAY be issued by a client later in the session. If it is -issued after the session begins, the SMTP server MUST clear all buffers and -reset the state exactly as if a RSET command had been issued. In other -words, the sequence of RSET followed immediately by EHLO is redundant, but -not harmful other than in the performance cost of executing unnecessary -commands. - -If the EHLO command is not acceptable to the SMTP server, 501, 500, or 502 -failure replies MUST be returned as appropriate. The SMTP server MUST stay -in the same state after transmitting these replies that it was in before -the EHLO was received. - -The SMTP client MUST, if possible, ensure that the domain parameter to the -EHLO command is a valid principal host name (not a CNAME or MX name) for -its host. If this is not possible (e.g., when the client's address is -dynamically assigned and the client does not have an obvious name), an -address literal SHOULD be substituted for the domain name and supplemental -information provided that will assist in identifying the client. - -An SMTP server MAY verify that the domain name parameter in the EHLO -command actually corresponds to the IP address of the client. However, the -server MUST NOT refuse to accept a message for this reason if the -verification fails: the information about verification failure is for -logging and tracing only. - -The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time -during a session, or without previously initializing a session. SMTP -servers SHOULD process these normally (that is, not return a 503 code) even -if no EHLO command has yet been received; clients SHOULD open a session -with EHLO before sending these commands. - -If these rules are followed, the example in RFC 821 that shows "550 access -denied to you" in response to an EXPN command is incorrect unless an EHLO -command precedes the EXPN or the denial of access is based on the client's -IP address or other authentication or authorization-determining mechanisms. - -The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins a -mail transaction. Once started, a mail transaction consists of a -transaction beginning command, one or more RCPT commands, and a DATA -command, in that order. A mail transaction may be aborted by the RSET (or -a new EHLO) command. There may be zero or more transactions in a session. -MAIL (or SEND, SOML, or SAML) MUST NOT be sent if a mail transaction is -already open, i.e., it should be sent only if no mail transaction had been -started in the session, or it the previous one successfully concluded with -a successful DATA command, or if the previous one was aborted with a RSET. - -If the transaction beginning command argument is not acceptable, a 501 -failure reply MUST be returned and the SMTP server MUST stay in the same -state. If the commands in a transaction are out of order to the degree -that they cannot be processed by the server, a 503 failure reply MUST be -returned and the SMTP server MUST stay in the same state. - -The last command in a session MUST be the QUIT command. The QUIT command -cannot be used at any other time in a session, but SHOULD be used by the -client SMTP to request connection closure, even when no session opening -command was sent and accepted. - -4.1.5 Private-use Commands - -As specified in section 2.2.2, commands starting in "X" may be used by -bilateral agreement between the client (sending) and server (receiving) -SMTP agents. An SMTP server that does not recognize such a command is -expected to reply with "500 Command not recognized". An extended SMTP -server MAY list the feature names associated with these private commands in -the response to the EHLO command. - -Commands sent or accepted by SMTP systems that do not start with "X" MUST -conform to the requirements of section 2.2.2. - -4.2 SMTP Replies - -Replies to SMTP commands serve to ensure the synchronization of requests -and actions in the process of mail transfer and to guarantee that the SMTP -client always knows the state of the SMTP server. Every command MUST -generate exactly one reply. - -The details of the command-reply sequence are described in section 4.3. - -An SMTP reply consists of a three digit number (transmitted as three -alphanumeric characters) followed by some text unless specified otherwise -in this document. The number is for use by automata to determine what -state to enter next; the text is for the human user. The three digits -contain enough encoded information that the SMTP client need not examine -the text and may either discard it or pass it on to the user, as -appropriate. Exceptions are as noted elsewhere in this document. In -particular, the 220, 221, 251, 421, and 551 reply codes are associated -with message text that must be parsed and interpreted by machines. In the -general case, the text may be receiver dependent and context dependent, so -there are likely to be varying texts for each reply code. A discussion of -the theory of reply codes is given in section 4.2.1. Formally, a reply is -defined to be the sequence: a three-digit code, <SP>, one line of text, -and <CRLF>, or a multiline reply (as defined in section 4.2.1). Since, in -violation of this specification, the text is sometimes not sent, clients -which do not receive it SHOULD be prepared to process the code alone (with -or without a trailing space character). Only the EHLO, EXPN, and HELP -commands are expected to result in multiline replies in normal -circumstances, however, multiline replies are allowed for any command. - -In ABNF, server responses are: - - Greeting = "220 " Domain [ SP text ] CRLF - Reply-line = Reply-code [ SP text ] CRLF - -where "Greeting" appears only in the 220 response that announces that the -server is opening its part of the connection. - -An SMTP server SHOULD send only the reply codes listed in this document. -An SMTP server SHOULD use the text shown in the examples whenever -appropriate. - -An SMTP client MUST determine its actions only by the reply code, not by -the text (except for 251 and 551 and, if necessary, 220, 221, and 421 -replies); in the general case, any text, including no text at all (although -senders SHOULD NOT send bare codes), MUST be acceptable. The space (blank) -following the reply code is considered part of the text. Whenever -possible, a receiver-SMTP SHOULD test the first digit (severity indication) -of the reply code. - -The list of codes that appears below must not be construed as permanent. -While the addition of new codes should be a rare and significant activity, -with supplemental information in the textual part of the response being -preferred, new codes may be added as the result of new Standards or -Standards-track specifications. Consequently, a sender-SMTP MUST be -prepared to handle codes not specified in this document and MUST do so by -interpreting the first digit only. - -4.2.1 Reply Code Severities and Theory - -The three digits of the reply each have a special significance. The first -digit denotes whether the response is good, bad or incomplete. An -unsophisticated SMTP client, or one that receives an unexpected code, will -be able to determine its next action (proceed as planned, redo, retrench, -etc.) by examining this first digit. An SMTP client that wants to know -approximately what kind of error occurred (e.g., mail system error, command -syntax error) may examine the second digit. The third digit and any -supplemental information that may be present is reserved for the finest -gradation of information. - -There are five values for the first digit of the reply code: - -1yz Positive Preliminary reply - The command has been accepted, but the requested action is being held in - abeyance, pending confirmation of the information in this reply. The - SMTP client should send another command specifying whether to continue - or abort the action. Note: unextended SMTP does not have any commands - that allow this type of reply, and so does not have continue or abort - commands. - -2yz Positive Completion reply - The requested action has been successfully completed. A new request may - be initiated. - -3yz Positive Intermediate reply - The command has been accepted, but the requested action is being held in - abeyance, pending receipt of further information. The SMTP client - should send another command specifying this information. This reply is - used in command sequence groups (i.e., in DATA). - -4yz Transient Negative Completion reply - The command was not accepted, and the requested action did not occur. - However, the error condition is temporary and the action may be - requested again. The sender should return to the beginning of the - command sequence (if any). It is difficult to assign a meaning to - "transient" when two different sites (receiver- and sender- SMTP agents) - must agree on the interpretation. Each reply in this category might have - a different time value, but the SMTP client is encouraged to try again. - A rule of thumb to determine whether a reply fits into the 4yz or the - 5yz category (see below) is that replies are 4yz if they can be - successful if repeated without any change in command form or in - properties of the sender or receiver (that is, the command is repeated - identically and the receiver does not put up a new implementation.) - -5yz Permanent Negative Completion reply - The command was not accepted and the requested action did not occur. - The SMTP client is discouraged from repeating the exact request (in the - same sequence). Even some "permanent" error conditions can be - corrected, so the human user may want to direct the SMTP client to - reinitiate the command sequence by direct action at some point in the - future (e.g., after the spelling has been changed, or the user has - altered the account status). - -The second digit encodes responses in specific categories: - -x0z Syntax: These replies refer to syntax errors, syntactically correct - commands that don't fit any functional category, and unimplemented or - superfluous commands. - -x1z Information: These are replies to requests for information, such as - status or help. - -x2z Connections: These are replies referring to the transmission channel. - -x3z Unspecified. - -x4z Unspecified. - -x5z Mail system: These replies indicate the status of the receiver mail - system vis-a-vis the requested transfer or other mail system action. - -The third digit gives a finer gradation of meaning in each category -specified by the second digit. The list of replies illustrates this. Each -reply text is recommended rather than mandatory, and may even change -according to the command with which it is associated. On the other hand, -the reply codes must strictly follow the specifications in this section. -Receiver implementations should not invent new codes for slightly different -situations from the ones described here, but rather adapt codes already -defined. - -For example, a command such as NOOP, whose successful execution does not -offer the SMTP client any new information, will return a 250 reply. The -reply is 502 when the command requests an unimplemented non-site-specific -action. A refinement of that is the 504 reply for a command that is -implemented, but that requests an unimplemented parameter. - -The reply text may be longer than a single line; in these cases the -complete text must be marked so the SMTP client knows when it can stop -reading the reply. This requires a special format to indicate a multiple -line reply. - -The format for multiline replies requires that every line, except the last, -begin with the reply code, followed immediately by a hyphen, "-" (also -known as minus), followed by text. The last line will begin with the reply -code, followed immediately by <SP>, optionally some text, and <CRLF>. As -noted above, servers SHOULD send the <SP> if subsequent text is not sent, -but clients MUST be prepared for it to be omitted. - -For example: - 123-First line - 123-Second line - 123-234 text beginning with numbers - 123 The last line - -In many cases the SMTP client then simply needs to search for the reply -code followed by <SP> at the beginning of a line, and ignore all preceding -lines. In a few cases, there is important data for the client in the -reply "text". The client will be able to identify these cases from the -current context. - -4.2.2 Reply Codes by Function Groups - - 500 Syntax error, command unrecognized - (This may include errors such as command line too long) - 501 Syntax error in parameters or arguments - 502 Command not implemented (see section 4.2.4) - 503 Bad sequence of commands - 504 Command parameter not implemented - - 211 System status, or system help reply - 214 Help message - (Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user) - - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 421 <domain> Service not available, closing transmission channel - (This may be a reply to any command if the service knows it - must shut down) - - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - (See section 3.4) - 252 Cannot VRFY user, but will accept message and attempt - delivery - (See section 3.5.3) - 450 Requested mail action not taken: mailbox unavailable - (e.g., mailbox busy) - 550 Requested action not taken: mailbox unavailable - (e.g., mailbox not found, no access, or command rejected - for policy reasons) - 451 Requested action aborted: error in processing - 551 User not local; please try <forward-path> - (See section 3.4) - 452 Requested action not taken: insufficient system storage - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - (e.g., mailbox syntax incorrect) - 354 Start mail input; end with <CRLF>.<CRLF> - 554 Transaction failed (Or, in the case of a connection-opening - response, "No SMTP service here") - -4.2.3 Reply Codes in Numeric Order - - 211 System status, or system help reply - 214 Help message - (Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user) - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - (See section 3.4) - 252 Cannot VRFY user, but will accept message and attempt - delivery - (See section 3.5.3) - - 354 Start mail input; end with <CRLF>.<CRLF> - - 421 <domain> Service not available, closing transmission channel - (This may be a reply to any command if the service knows it - must shut down) - 450 Requested mail action not taken: mailbox unavailable - (e.g., mailbox busy) - 451 Requested action aborted: local error in processing - 452 Requested action not taken: insufficient system storage - - 500 Syntax error, command unrecognized - (This may include errors such as command line too long) - 501 Syntax error in parameters or arguments - 502 Command not implemented (see section 4.2.4) - 503 Bad sequence of commands - 504 Command parameter not implemented - 550 Requested action not taken: mailbox unavailable - (e.g., mailbox not found, no access, or command rejected - for policy reasons) - 551 User not local; please try <forward-path> - (See section 3.4) - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - (e.g., mailbox syntax incorrect) - 554 Transaction failed (Or, in the case of a connection-opening - response, "No SMTP service here") - -4.2.4 Reply Code 502 - -Questions have been raised as to when reply code 502 (Command not -implemented) SHOULD be returned in preference to other codes. 502 SHOULD -be used when the command is actually recognized by the SMTP server, but not -implemented. If the command is not recognized, code 500 SHOULD be -returned. Extended SMTP systems MUST NOT list capabilities in response to -EHLO for which they will return 502 (or 500) replies. - -4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> - -When an SMTP server returns a positive completion status (2yz code) after -the DATA command is completed with <CRLF>.<CRLF>, it accepts responsibility -for: - - - delivering the message (if the recipient mailbox exists), or - - - if attempts to deliver the message fail due to transient conditions, - retrying delivery some reasonable number of times at intervals as - specified in section 4.5.4. - - - if attempts to deliver the message fail due to permanent conditions, or - if repeated attempts to deliver the message fail due to transient - conditions, returning appropriate notification to the sender of the - original message (using the address in the SMTP MAIL FROM command). - -When an SMTP server returns a transient error completion status (4yz) code -after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make -any further attempt to deliver that message. The SMTP client retains -responsibility for delivery of that message and may either return it to the -user or requeue it for a subsequent attempt (see section 4.5.4.1). The -sending user SHOULD be able to interpret the return of a transient or -permanent failure status as a non-delivery indication. - -When an SMTP server returns a permanent error status (5yz) code after -the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make -any further attempt to deliver the message. As with temporary error -status codes, the SMTP client retains responsibility for the message, -but SHOULD not again attempt delivery to the same server without user -review and intervention of the message. - -4.3 Sequencing of Commands and Replies - -4.3.1 Sequencing Overview - -The communication between the sender and receiver is an alternating -dialogue, controlled by the sender. As such, the sender issues a command -and the receiver responds with a reply. Unless other arrangements are -negotiated through service extensions, the sender MUST wait for this -response before sending further commands. - -One important reply is the connection greeting. Normally, a receiver will -send a 220 "Service ready" reply when the connection is completed. The -sender SHOULD wait for this greeting message before sending any commands. - -Note: all the greeting-type replies have the official name (the -fully-qualified primary domain name) of the server host as the first word -following the reply code. Sometimes the host will have no meaningful name. -See 4.1.3 for a discussion of alternatives in these situations. - -For example, - 220 ISIF.USC.EDU Service ready -or - 220 mail.foo.com SuperSMTP v 6.1.2 Service ready -or - 220 [10.0.0.1] Clueless host service ready - -The table below lists alternative success and failure replies for each -command. These SHOULD be strictly adhered to: a receiver may substitute -text in the replies, but the meaning and action implied by the code numbers -and by the specific command reply sequence cannot be altered. - -4.3.2 Command-Reply Sequences - -Each command is listed with its usual possible replies. The prefixes used -before the possible replies are "I" for intermediate, "S" for success, and -"E" for error. Since some servers may generate other replies under special -circumstances, and to allow for future extension, SMTP clients SHOULD, when -possible, interpret only the first digit of the reply and MUST be prepared -to deal with unrecognized reply codes by interpreting the first digit only. -Unless extended using the mechanisms described in section 2.2, SMTP servers -MUST NOT transmit reply codes to an SMTP client that are other than three -digits or that do not start in a digit between 2 and 5 inclusive. - -These sequencing rules and, in principle, the codes themselves, can be -extended or modified by SMTP extensions offered by the server and accepted -(requested) by the client. - -In addition to the codes listed below, any SMTP command can return any of -the following codes if the corresponding unusual circumstances are -encountered: - -500 For the "command line too long" case or if the command name was not - recognized. Note that producing a "command not recognized" error in - response to the required subset of these commands is a violation of this - specification. - -501 Syntax error in command or arguments. In order to provide for future - extensions, commands that are specified in this document as not - accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 message if - arguments are supplied in the absence of EHLO-advertised extensions. - -421 Service shutting down and closing transmission channel - -Specific sequences are: - -CONNECTION ESTABLISHMENT - S: 220 - E: 554 -EHLO or HELO - S: 250 - E: 504, 550 -MAIL - S: 250 - E: 552, 451, 452, 550, 553, 503 -RCPT - S: 250, 251 (but see section 3.4 for discussion of 251) - E: 550, 551, 552, 553, 450, 451, 452, 503, 550 -DATA - I: 354 -> data -> S: 250 - E: 552, 554, 451, 452 - E: 451, 554, 503 -RSET - S: 250 -VRFY - S: 250, 251, 252 - E: 550, 551, 553, 502, 504 -EXPN - S: 250, 252 - E: 550, 500, 502, 504 -HELP - S: 211, 214 - E: 502, 504 -NOOP - S: 250 -QUIT - S: 221 - -4.4 Trace Information - -When an SMTP server receives a message for delivery or further processing, -it MUST insert trace ("time stamp" or "Received") information at the -beginning of the message content, as discussed in section 4.1.1.4. - -This line MUST be structured as follows: - - - The FROM field, which MUST be supplied in an SMTP environment, SHOULD - contain both (1) the name of the source host as presented in the EHLO - command and (2) an address literal containing the IP address of the - source, determined from the TCP connection. - - - The ID field MAY contain an "@" as suggested in RFC-822, but this is not - required. - - - The FOR field MAY contain a list of <path> entries when multiple RCPT - commands have been given. This may raise some security issues and is - usually not desirable; see section 7.2. - -An Internet mail program MUST NOT change a Received: line that was -previously added to the message header. SMTP servers MUST prepend Received -lines to messages; they MUST NOT change the order of existing lines or -insert Received lines in any other location. - -As the Internet grows, comparability of Received fields is important for -detecting problems, especially slow relays. SMTP servers that create -Received fields SHOULD use explicit offsets in the dates (e.g., -0800), -rather than time zone names of any type. Local time (with an offset) is -preferred to UT when feasible. This formulation allows slightly more -information about local circumstances to be specified. If UT is needed, -the receiver need merely do some simple arithmetic to convert the values. -Use of UT loses information about the time zone-location of the server. If -a time zone name is used, it SHOULD be included in a comment. - -When the delivery SMTP server makes the "final delivery" of a message, it -inserts a return-path line at the beginning of the mail data. This use of -return-path is required; mail systems MUST support it. The return-path -line preserves the information in the <reverse-path> from the MAIL -command. Here, final delivery means the message has left the SMTP -enviroment. Normally, this would mean it had been delivered to the -destination user or an associated mail drop, but in some cases it may be -further processed and transmitted by another mail system. - -It is possible for the mailbox in the return path to be different from the -actual sender's mailbox, for example, if error responses are to be -delivered to a special error handling mailbox rather than to the message -sender. When mailing lists are involved, this arrangement is common and -useful as a means of directing errors to the list maintainer rather than -the message originator. - -The text above implies that the final mail data will begin with a return -path line, followed by one or more time stamp lines. These lines will be -followed by the mail data headers and body [MSGFMT]. - -It is sometimes difficult for an SMTP server to determine whether or not it -is making final delivery since forwarding or other operations may occur -after the message is accepted for delivery. Consequently, any further -(forwarding, gateway, or relay) systems MAY remove the return path and -rebuild the MAIL FROM command as needed to ensure that exactly one such -line appears in a delivered message. - -A message-originating SMTP system SHOULD NOT send a message that already -contains a Return-path header. SMTP servers performing a relay function -MUST NOT inspect the message data, and especially not to the extent needed -to determine if Return-path headers are present. SMTP servers making final -delivery MAY remove Return-path headers before adding their own. - -The primary purpose of the Return-path is to designate the address to which -messages indicating non-delivery or other mail system failures are to be -sent. For this to be unambiguous, exactly one return path SHOULD be -present when the message is delivered. Systems using RFC 822 syntax with -non-SMTP transports SHOULD designate an unambiguous address, associated -with the transport envelope, to which error reports (e.g., non-delivery -messages) should be sent. - -Historical note: Text in RFC 822 that appears to contradict the use of the -Return-path header (or the envelope MAIL FROM address) as the destination -for error messages is not applicable on the Internet. The MAIL FROM address -(as copied into the Return-path) MUST be used as the target of any mail -containing delivery error messages. - -In particular: - - - a gateway from SMTP->elsewhere SHOULD insert a return-path header, - unless it is known that the "elsewhere" transport also uses Internet - domain addresses and maintains the envelope sender address separately. - - - a gateway from elsewhere->SMTP SHOULD delete any return-path header - present in the message, and either copy that information to the SMTP - envelope or combine it with information present in the envelope of the - other transport system to construct the MAIL FROM part of the SMTP - envelope. - -The server must give special treatment to cases in which the processing -following the end of mail data indication is only partially successful. -This could happen if, after accepting several recipients and the mail data, -the SMTP server finds that the mail data could be successfully delivered to -some, but not all, of the recipients. In such cases, the response to the -DATA command MUST be an OK reply. However, the SMTP server MUST compose -and send an "undeliverable mail" notification message to the originator of -the message. - -A single notification listing all of the failed recipients or separate -notification messages MUST be sent for each failed recipient. For economy -of processing by the sender, the former is preferred when possible. All -undeliverable mail notification messages are sent using the MAIL command -(even if they result from processing the obsolete SEND, SOML, or SAML -commands) and use a null return path as discussed in section 3.7. - -The time stamp line and the return path line are formally defined as -follows: - - Return-path-line = "Return-Path:" FWS Reverse-path <CRLF> - - Time-stamp-line = "Received:" FWS Stamp <CRLF> - - Stamp = From-domain By-domain Opt-info ";" FWS Daytime - - From-domain = "FROM" FWS Extended-Domain CFWS - - By-domain = "BY" FWS Extended-Domain CFWS - - Extended-Domain = Domain / - ( Domain FWS "(" TCP-info ")" ) / - ( Address-literal FWS "(" TCP-info ")" - TCP-info = Address-literal / ( Domain FWS Address-literal ) - ; Information derived by server from TCP connection, - not client EHLO. - - Opt-info = [Via] [With] [ID] [For] - - Via = "VIA" FWS Link CFWS - - With = "WITH" FWS Protocol CFWS - - ID = "ID" FWS String / msg-id CFWS - - For = "FOR" FWS 1*( Path / Mailbox ) CFWS - - Link = "TCP" / Addtl-Link - Addtl-Link = Atom ; Additional standard names for links are - registered with the Internet Assigned - Numbers Authority (IANA). "Via" is - primarily of value with non-Internet - transports. - SMTP servers SHOULD NOT use unregistered - names. - Protocol = "ESMTP" / "SMTP" / Attdl-Protocol - Attdl-Protocol = Atom ; Additional standard names for protocols - are registered with the Internet Assigned - Numbers Authority (IANA). SMTP servers - SHOULD NOT use unregistered names. - - Daytime = FWS [ day-of-week "," FWS ] Date FWS Time - - Date = DD FWS Mon FWS YYYY - ; Note that the earlier form, which permits two-digit years, has - been deprecated. SMTP systems MUST use four-digit years. - - Time = HH ":" MM ":" SS FWS Zone - - DD = 1*2Digit ; the one or two digit integer day of the - month in the range 1 to 31. - - Mon = "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | - "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" - - YYYY = 4*4Digit ; the four decimal integer year in the range - 0000 to 9999. - - HH = 2*2Digit ; the two decimal digit hour of the day in - the range 00 to 24. - - MM = 2*2Digit ; the two decimal digit integer minute of the hour - in the range 00 to 59. - - SS = 2*2Digit [ "." 1*Digit ] - ; the two decimal digit integer second of the - minute in the range 00 to 60 (to allow - for leap seconds), with optional - fractional seconds. - - Zone = ( "+" / "-" ) 4*4Digit [ <SP> "(" String ")" ] - ; A four digit, signed time zone offset, - such as -0500 for US Eastern Standard - Time. This may be supplemented by a time - zone name in parentheses, e.g., "-0800 - (PDT)". Note that there is no default; - time zone information is required and - MUST be supplied. - -4.5 Additional Implementation Issues - -4.5.1 Minimum Implementation - -In order to make SMTP workable, the following minimum implementation is -required for all receivers. The following commands MUST be supported to -conform to this specification: - EHLO - HELO - MAIL - RCPT - DATA - RSET - NOOP - QUIT - VRFY - -Any system that includes an SMTP server supporting mail relaying or -delivery MUST support the reserved mailbox "postmaster" as a -case-insensitive local name. This postmaster address is not strictly -necessary if the server always returns 554 on connection opening (as -described in section 3.1). The requirement to accept mail for postmaster -implies that RCPT TO commands which specify a mailbox for postmaster at any -of the domains for which the SMTP server provides mail service, as well as -the special case of "RCPT TO:<Postmaster>" (with no domain specification), -MUST be supported. This requirement does not imply that SMTP systems must -deliver Postmaster mail in particular cases (e.g., problematic origin -addresses) in which they have substantive reasons for not doing so. - -4.5.2 Transparency - -Without some provision for data transparency, the character sequence -"<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user. In -general, users are not aware of such "forbidden" sequences. To allow all -user composed text to be transmitted transparently, the following -procedures are used: - - - Before sending a line of mail text, the SMTP client checks the first - character of the line. If it is a period, one additional period is - inserted at the beginning of the line. - - - When a line of mail text is received by the SMTP server, it checks the - line. If the line is composed of a single period, it is treated as the - end of mail indicator. If the first character is a period and there are - other characters on the line, the first character is deleted. - -The mail data may contain any of the 128 ASCII characters. All characters -are to be delivered to the recipient's mailbox, including spaces, vertical -and horizontal tabs, and other control characters. If the transmission -channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes -are transmitted right justified in the octets, with the high order bits -cleared to zero. See 3.7 for special treatment of these conditions in SMTP -systems serving a relay function. - -In some systems it may be necessary to transform the data as it is received -and stored. This may be necessary for hosts that use a different character -set than ASCII as their local character set or store data in records rather -than strings. If such transformations are necessary, they MUST be -reversible, especially if such transformations are applied to mail being -relayed. - -4.5.3 Sizes and Timeouts - -There are several objects that have required minimum/maximum sizes. Every -implementation MUST be able to receive objects of at least these sizes. -Objects larger than these sizes SHOULD be avoided when possible. However, -some Internet mail constructs such as encoded X.400 addresses [RFC-X400] -will often require larger objects: clients MAY attempt to transmit these, -but MUST be prepared for a server to reject them if they cannot be handled -by it. To the maximum extent possible, implementation techniques which -impose no limits on the length of these objects should be used. - -local-part - The maximum total length of a user name or other local-part is 64 - characters. - -domain - The maximum total length of a domain name or number is 255 characters. - -path - The maximum total length of a reverse-path or forward-path is 256 - characters (including the punctuation and element separators). - -command line - The maximum total length of a command line including the command word - and the <CRLF> is 512 characters. SMTP extensions may be used to - increase this limit. - -reply line - The maximum total length of a reply line including the reply code and - the <CRLF> is 512 characters. More information may be conveyed through - multiple-line replies. - -text line - The maximum total length of a text line including the <CRLF> is 1000 - characters (not counting the leading dot duplicated for transparency). - This number may be increased by the use of SMTP Service Extensions. - -message content - The maximum total length of a message content (including any message - headers as well as the message body) MUST BE at least 64K octets. Since - the introduction of multimedia mail [RFC-MIME], message lengths on the - Internet have grown dramatically, and message size restrictions should - be avoided if at all possible. SMTP server systems that must impose - restrictions SHOULD implement the "SIZE" service extension ([RFC-SIZE]), - and SMTP client systems that will send large messages SHOULD utilize it - when possible. - -recipients buffer - The minimum total number of recipients that must be buffered is 100 - recipients. Rejection of messages (for excessive recipients) with fewer - than 100 RCPT TO commands is a violation of this specification. The - general principle that relaying SMTP servers MUST NOT, and delivery SMTP - servers SHOULD NOT, perform validation tests on message headers suggests - that rejecting a message based on the total number of recipients shown - in header fields is to be discouraged. A server which imposes a limit - on the number of recipients MUST behave in an orderly fashion, such as - to reject additional addresses over its limit rather than silently - discarding addresses previously accepted. A client that needs to - deliver a message containing over 100 RCPT TO commands SHOULD be - prepared to transmit in 100-recipient "chunks" if the server declines to - accept more than 100 recipients in a single message. - -Errors due to exceeding these limits may be reported by using the reply -codes. Some examples of reply codes are: - - 500 Line too long. -or - 501 Path too long -or - 452 Too many recipients (see below) -or - 552 Too much mail data. - -[RFC-821] incorrectly listed the error where an SMTP server exhausts its -implementation limit on the number of RCPT TO commands ("too many -recipients") as having reply code 552. The correct reply code for this -condition is 452. Clients SHOULD treat a 552 code in this case as a -temporary, rather than permanent failure so the logic below works. - -When a conforming SMTP server encounters this condition, it has at least -100 successful RCPT commands in its recipients buffer. If the server is -able to accept the message, then at least these 100 addresses will be -removed from the SMTP client's queue. When the client attempts -retransmission of those addresses which received 452 responses, at least -100 of these will be able to fit in the SMTP server's recipients buffer. -Each retransmission attempt which is able to deliver anything will be able -to dispose of at least 100 of these recipients. - -If an SMTP server has an implementation limit on the number of RCPT TO -commands and this limit is exhausted, it MUST use a response code of 452. -If the server has a configured site-policy limitation on the number of RCPT -TO commands, it MAY instead use a 5XX response code. - -In order to interoperate with SMTP servers implementing an older version of -the protocol, SMTP clients MAY treat a 552 code obtained in response to an -RCPT command as if it were a 452 response code, especially after some RCPT -commands have already been accepted in the same mail transaction. - -An SMTP client MUST provide a timeout mechanism. It MUST use per-command -timeouts rather than somehow trying to time the entire mail transaction. -Timeouts SHOULD be easily reconfigurable, preferably without recompiling -the SMTP code. To implement this, a timer is set for each SMTP command and -for each buffer of the data transfer. The latter means that the overall -timeout is inherently proportional to the size of the message. - -Based on extensive experience with busy mail-relay hosts, the minimum -per-command timeout values SHOULD be as follows: - -Initial 220 Message: 5 minutes - An SMTP client process needs to distinguish between a failed TCP - connection and a delay in receiving the initial 220 greeting message. - Many SMTP servers accept a TCP connection but delay delivery of the 220 - message until their system load permits more mail to be processed. - -MAIL Command: 5 minutes - -RCPT Command: 5 minutes - A longer timeout is required if processing of mailing lists and aliases - is not deferred until after the message was accepted. - -DATA Initiation: 2 minutes - This is while awaiting the "354 Start Input" reply to a DATA command. - -Data Block: 3 minutes - This is while awaiting the completion of each TCP SEND call transmitting - a chunk of data. - -DATA Termination: 10 minutes. - This is while awaiting the "250 OK" reply. When the receiver gets the - final period terminating the message data, it typically performs - processing to deliver the message to a user mailbox. A spurious timeout - at this point would be very wasteful and would typically result in - delivery of multiple copies of the message, since it has been - successfully sent and the server has accepted responsibility for - delivery. See section 6.1 for additional discussion. - -An SMTP server SHOULD have a timeout of at least 5 minutes while it is -awaiting the next command from the sender. - -4.5.4 Queuing Strategies - -The common structure of a host SMTP implementation includes user mailboxes, -one or more areas for queuing messages in transit, and one or more daemon -processes for sending and receiving mail. The exact structure will vary -depending on the needs of the users on the host and the number and size of -mailing lists supported by the host. We describe several optimizations that -have proved helpful, particularly for mailers supporting high traffic -levels. - -Any queuing strategy MUST include timeouts on all activities on a -per-command basis. A queuing strategy MUST NOT send error messages in -response to error messages under any circumstances. - -4.5.4.1 Sending Strategy - -The general model for an SMTP client is one or more processes that -periodically attempt to transmit outgoing mail. In a typical system, the -program that composes a message has some method for requesting immediate -attention for a new piece of outgoing mail, while mail that cannot be -transmitted immediately MUST be queued and periodically retried by the -sender. A mail queue entry will include not only the message itself but -also the envelope information. - -The sender MUST delay retrying a particular destination after one attempt -has failed. In general, the retry interval SHOULD be at least 30 minutes; -however, more sophisticated and variable strategies will be beneficial when -the SMTP client can determine the reason for non-delivery. - -Retries continue until the message is transmitted or the sender gives up; -the give-up time generally needs to be at least 4-5 days. The parameters -to the retry algorithm MUST be configurable. - -A client SHOULD keep a list of hosts it cannot reach and corresponding -connection timeouts, rather than just retrying queued mail items. - -Experience suggests that failures are typically transient (the target -system or its connection has crashed), favoring a policy of two connection -attempts in the first hour the message is in the queue, and then backing -off to one every two or three hours. - -The SMTP client can shorten the queuing delay in cooperation with the SMTP -server. For example, if mail is received from a particular address, it is -likely that mail queued for that host can now be sent. Application of this -principle may, in many cases, eliminate the requirement for an explicit -"send queues now" function such as that discussed in [RFC-ETRN]. - -The strategy may be further modified as a result of multiple addresses per -host (see below) to optimize delivery time vs. resource usage. - -An SMTP client may have a large queue of messages for each unavailable -destination host. If all of these messages were retried in every retry -cycle, there would be excessive Internet overhead and the sending system -would be blocked for a long period. Note that an SMTP client can generally -determine that a delivery attempt has failed only after a timeout of -several minutes and even a one-minute timeout per connection will result in -a very large delay if retries are repeated for dozens, or even hundreds, of -queued messages to the same host. - -At the same time, SMTP clients SHOULD use great care in caching negative -responses from servers. In an extreme case, if EHLO is issued multiple -times during the same SMTP connection, different answers may be returned by -the server. More significantly, 5yz responses to MAIL FROM MUST NOT be -cached. - -When a mail message is to be delivered to multiple recipients, and the SMTP -server to which a copy of the message is to be sent is the same for -multiple recipients, then only one copy of the message SHOULD be -transmitted. That is, the SMTP client SHOULD use the command sequence: -MAIL, RCPT, RCPT,... RCPT, DATA instead of the sequence: MAIL, RCPT, DATA, -..., MAIL, RCPT, DATA. However, if there are very many addresses, a limit -on the number of RCPT commands per MAIL command MAY be imposed. -Implementation of this efficiency feature is strongly encouraged. - -Similarly, to achieve timely delivery, the SMTP client MAY support multiple -concurrent outgoing mail transactions. However, some limit may be -appropriate to protect the host from devoting all its resources to mail. - -4.5.4.2 Receiving Strategy - -The SMTP server SHOULD attempt to keep a pending listen on the SMTP port at -all times. This requires the support of multiple incoming TCP connections -for SMTP. Some limit MAY be imposed. - -As discussed above, when the SMTP server receives mail from a particular -host address, it could notify the SMTP client to retry any mail pending for -that host address. - -4.5.5 Messages with a null reverse-path - -There are several types of notification messages which are required by -existing and proposed standards to be sent with a null reverse path, -namely non-delivery notifications as discussed in section 3.7, other kinds -of Delivery Status Notifications (DSNs, see [RFC 1894]) and also Message -Disposition Notifications (MDNs, see [RFC 2298]). All of these kinds of -messages are notifications about a previous message, and they are sent to -the reverse-path of the previous mail message. (If the delivery of such a -notification message fails, that usually indicates a problem with the mail -system of the host to which the notification message is addressed. For -this reason, at some hosts the MTA is set up to forward such failed -notification messages to someone who is able to fix problems with the mail -system, e.g. via the postmaster alias.) - -All other types of messages (i.e. any message which is not required by a -standards-track RFC to have a null reverse-path) SHOULD be sent with with -a valid, non-null reverse-path. - -Implementors of automated email processors should be careful to make sure -that the various kinds of messages with null reverse-path are handled -correctly, in particular such systems SHOULD NOT reply to messages with -null reverse-path. - - - -5. Address Resolution and Mail Handling - -Once an SMTP client lexically identifies a domain to which mail will be -delivered for processing (as described in sections 3.6 and 3.7), a DNS -lookup MUST be performed to resolve the domain name (see [RFC-DNS]). The -names are expected to be fully-qualified domain names (FQDNs): mechanisms -for inferring FQDNs from partial names or local aliases are outside of -this specification and, due to a history of problems, are generally -discouraged. The lookup first attempts to locate an MX record associated -with the name. If a CNAME record is found instead, the resulting name is -processed as if it were the initial name. If no MX records are found, but -an A RR is found, the A RR is treated as if it was associated with an -implicit MX RR, with a preference of 0, pointing to that host. If one or -more MX RRs are found for a given name, SMTP systems MUST NOT utilize any -A RRs associated with that name unless they are located using the MX RRs; -the "implicit MX" rule above applies only if there are no MX records -present. If MX records are present, but none of them are usable, this -situation MUST be reported as an error. - -When the lookup succeeds, the mapping can result in a list of alternative -delivery addresses rather than a single address, because of multiple MX -records, multihoming, or both. To provide reliable mail transmission, the -SMTP client MUST be able to try (and retry) each of the relevant addresses -in this list in order, until a delivery attempt succeeds. However, there -MAY also be a configurable limit on the number of alternate addresses that -can be tried. In any case, a host SHOULD try at least two addresses. - -Two types of information is used to rank the host addresses: multiple MX -records, and multihomed hosts. - -Multiple MX records contain a preference indication that MUST be used in -sorting (see below). Lower numbers are more preferred than higher ones. -If there are multiple destinations with the same preference and there is no -clear reason to favor one (e.g., by recognition of an easily-reached -address), then the sender-SMTP MUST randomize them to spread the load -across multiple mail exchangers for a specific organization. - -The destination host (perhaps taken from the preferred MX record) may be -multihomed, in which case the domain name resolver will return a list of -alternative IP addresses. It is the responsibility of the domain name -resolver interface to have ordered this list by decreasing preference if -necessary, and SMTP MUST try them in the order presented. - -Although the capability to try multiple alternative addresses is required, -specific installations may want to limit or disable the use of alternative -addresses. The question of whether a sender should attempt retries using -the different addresses of a multihomed host has been controversial. The -main argument for using the multiple addresses is that it maximizes the -probability of timely delivery, and indeed sometimes the probability of any -delivery; the counter-argument is that it may result in unnecessary -resource use. Note that resource use is also strongly determined by the -sending strategy discussed in section 4.5.4.1. - -If a host receives a message with a destination for which it is a -designated Mail eXchanger, it MAY relay the message (potentially after -having rewritten the addresses), make final delivery of the message, or -hand it off using some mechanism outside the SMTP-provided transport -environment. Of course, neither of the latter require that the list of MX -records be examined further. - -If it determines that it should relay the message without rewriting the -address, it MUST sort the MX records to determine candidates for delivery. -The records are first ordered by preference, with the lowest-numbered -records being most preferred. The relay host MUST then inspect the list -for any of the names or addresses by which it might be known in mail -transactions. If a matching record is found, all records at that -preference level and higher-numbered ones MUST be discarded from -consideration. If there are no records left at that point, it is an error -condition, and the message MUST be returned as undeliverable. If records -do remain, they SHOULD be tried, best preference first, as described above. - - -6. Problem Detection and Handling - -6.1 Reliable Delivery and Replies by Email - -When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" -message in response to DATA), it is accepting responsibility for delivering -or relaying the message. It must take this responsibility seriously. It -MUST NOT lose the message for frivolous reasons, such as because the host -later crashes or because of a predictable resource shortage. - -If there is a delivery failure after acceptance of a message, the -receiver-SMTP MUST formulate and mail a notification message. This -notification MUST be sent using a null ("<>") reverse path in the envelope. -The recipient of this notification MUST be the address from the envelope -return path (or the Return-Path: line). However, if this address is null -("<>"), the receiver-SMTP MUST NOT send a notification. Obviously, nothing -in this section can or should prohibit local decisions (i.e., as part of -the same system environment as the receiver-SMTP) to log or otherwise -transmit information about null address events locally if that is desired. -If the address is an explicit source route, it MUST be stripped down to its -final hop. - -For example, suppose that an error notification must be sent for a message -that arrived with: - MAIL FROM:<@a,@b:user@d> - -The notification message SHOULD be sent using: - RCPT TO:<user@d> - -Some delivery failures after the message is accepted by SMTP will be -unavoidable. For example, it may be impossible for the receiving SMTP -server to validate all the delivery addresses in RCPT command(s) due to a -"soft" domain system error, because the target is a mailing list (see -earlier discussion of RCPT), or because the server is acting as a relay and -has no immediate access to the delivering system. - -To avoid receiving duplicate messages as the result of timeouts, a -receiver-SMTP MUST seek to minimize the time required to respond to the -final <CRLF>.<CRLF> end of data indicator. See RFC-1047 [RFC-1047] for a -discussion of this problem. - -6.2 Loop Detection - -Simple counting of the number of "Received:" headers in a message has -proven to be an effective, although rarely optimal, method of detecting -loops in mail systems. SMTP servers using this technique SHOULD use a -large rejection threshold, normally at least 100 Received entries. -Whatever mechanisms are used, servers MUST contain provisions for detecting -and stopping trivial loops. - -6.3 Compensating for Irregularities - -Unfortunately, variations, creative interpretations, and outright -violations of Internet mail protocols do occur; some would suggest that -they occur quite frequently. The debate as to whether a well-behaved SMTP -receiver or relay should reject a malformed message, attempt to pass it on -unchanged, or attempt to repair it to increase the odds of successful -delivery (or subsequent reply) began almost with the dawn of structured -network mail and shows no signs of abating. Advocates of rejection claim -that attempted repairs are rarely completely adequate and that rejection of -bad messages is the only way to get the offending software repaired. -Advocates of "repair" or "deliver no matter what" argue that users prefer -that mail go through it if at all possible and that there are significant -market pressures in that direction. In practice, these market pressures -may be more important to particular vendors than strict conformance to the -standards, regardless of the preference of the actual developers. - -The problems associated with ill-formed messages were exacerbated by the -introduction of the split-UA mail reading protocols [RFC-POP2, RFC-POP3, -RFC-IMAP2, RFC-PCMAIL]. These protocols have encouraged the use of SMTP as -a posting protocol, and SMTP servers as relay systems for these client -hosts (which are often only intermittently connected to the Internet). -Historically, many of those client machines lacked some of the mechanisms -and information assumed by SMTP (and indeed, by the mail format protocol -[RFC-822]). Some could not keep adequate track of time; others had no -concept of time zones; still others could not identify their own names or -addresses; and, of course, none could satisfy the assumptions that underlay -RFC-822's conception of authenticated addresses. - -In response to these weak SMTP clients, many SMTP systems now complete -messages that are delivered to them in incomplete or incorrect form. This -strategy is generally considered appropriate when the server can identify -or authenticate the client, and there are prior agreements between them. -By contrast, there is at best great concern about fixes applied by a relay -or delivery SMTP server that has little or no knowledge of the user or -client machine. - -The following changes to a message being processed MAY be applied when -necessary by an originating SMTP server, or one used as the target of SMTP -as an initial posting protocol: - - - Addition of a message-id field when none appears - - - Addition of a date, time or time zone when none appears - - - Correction of addresses to proper FQDN format - -The less information the server has about the client, the less likely these -changes are to be correct and the more caution and conservatism should be -applied when considering whether or not to perform fixes and how. These -changes MUST NOT be applied by an SMTP server that provides an intermediate -relay function. - -In all cases, properly-operating clients supplying correct information are -preferred to corrections by the SMTP server. In all cases, documentation of -actions performed by the servers (in trace fields and/or header comments) -is strongly encouraged. - - -7. Security Considerations - -7.1 Mail Security and Spoofing - -SMTP mail is inherently insecure in that it is feasible for even fairly -casual users to negotiate directly with receiving and relaying SMTP servers -and create messages that will trick a naive recipient into believing that -they came from somewhere else. Constructing such a message so that the -"spoofed" behavior cannot be detected by an expert is somewhat more -difficult, but not sufficiently so as to be a deterrent to someone who is -determined and knowledgeable. Consequently, as knowledge of Internet mail -increases, so does the knowledge that SMTP mail inherently cannot be -authenticated, or integrity checks provided, at the transport level. Real -mail security lies only in end-to-end methods involving the message bodies, -such as those that can be provided in the MOSS framework [RFC-MOSS]. - -Various protocol extensions and configuration options that provide -authentication at the transport level (e.g., from an SMTP client to an SMTP -server) improve somewhat on the traditional situation described above. -However, unless they are accompanied by careful handoffs of responsibility -in a carefully-designed trust environment, they remain inherently weaker -than end-to-end mechanisms which use digitally signed messages rather than -depending on the integrity of the transport system. - -Efforts to make it more difficult for users to set envelope MAIL FROM and -header "From" fields to point to valid addresses other than their own are -largely misguided: they frustrate legitimate applications in which mail is -sent by one user on behalf of another or in which error (or normal) replies -should be directed to a special address. (Systems that provide convenient -ways for users to alter these fields on a per-message basis should attempt -to establish a primary and permanent mailbox address for the user so that -Sender fields within the message data can be generated sensibly.) - -This specification does not further address the authentication issues -associated with SMTP other than to advocate that useful functionality not -be disabled in the hope of providing some small margin of protection -against an ignorant user who is trying to fake mail. - -7.2 "Blind" Copies - -Addresses that do not appear in the message headers may appear in the RCPT -TO commands to an SMTP server for a number of reasons. The two most common -involve the use of a mailing address as a "list exploder" (a single address -that resolves into multiple addresses) and the appearance of "blind -copies". Especially when more than one RCPT command is present, and in -order to avoid defeating some of the purpose of these mechanisms, SMTP -clients and servers SHOULD NOT copy the full set of RCPT TO command -arguments into the headers, either as part of trace headers or as -informational or private-extension headers. Since this rule is often -violated in practice, and cannot be enforced, sending SMTP systems that are -aware of "bcc" use MAY find it helpful to send each blind copy as a -separate message transaction containing only a single RCPT TO command. - -There is no inherent relationship between either "reverse" (MAIL FROM, SAML -FROM, etc.) or "forward" (RCPT TO) addresses in the SMTP transaction -("envelope") and the addresses in the headers. Receiving systems SHOULD -NOT attempt to deduce such relationships and use them to alter the headers -of the message for delivery. The popular "Apparently-to" header is a -violation of this principle and SHOULD NOT be used. - -7.3 VRFY, EXPN, and Security - -As discussed in section 3.5, individual sites may want to disable one or -both VRFY or EXPN for security reasons. As a corollary to the above, -implementations that permit this MUST NOT appear to have verified addresses -that are not, in fact, verified. If a site disables these commands for -security reasons, the SMTP server MUST return a 252 response, rather than a -code that could be confused with successful or unsuccessful verification. - -Returning a 250 reply code with the address listed in the VRFY command -after having checked it only for syntax violates this rule. Of course, an -implementation that "supports" VRFY by always returning 550 whether or not -the address is valid is equally not in conformance. - -Within the last few years, the contents of mailing lists have become -popular as an address information source for so-called "spammers." The use -of EXPN to "harvest" addresses has increased as list administrators have -installed protections against inappropriate uses of the lists themselves. -Implementations SHOULD still provide support for EXPN, but sites SHOULD -carefully evaluate the tradeoffs. As authentication mechanisms are -introduced into SMTP, some sites may choose to make EXPN available only to -authenticated requestors. - -7.4 Information Disclosure in Announcements - -There has been an ongoing debate about the tradeoffs between the debugging -advantages of announcing server type and version (and, sometimes, even -server domain name) in the greeting response or in response to the HELP -command and the disadvantages of exposing useful information to potential -hostile attack. The utility of the debugging information is beyond doubt. -Those who argue for making it available point out that it is far better to -actually secure an SMTP server rather than hope that trying to conceal -known vulnerabilities by hiding the server's precise identity will provide -more protection. Sites are encouraged to evaluate the tradeoff with that -issue in mind; implementations are strongly encouraged to minimally provide -for making type and version information available in some way to other -network hosts. - -7.5 Information Disclosure in Trace Fields - -In some circumstances, such as when mail originates from within a LAN whose -hosts are not directly from the public Internet, trace ("Received") fields -produced in conformance with this specification may disclose host names and -similar information that would not normally be available. This ordinarily -does not pose a problem, but sites with special concerns about name -disclosure should be aware of it. Also, the optional FOR clause should be -supplied with caution or not at all when multiple recipients are involved -lest it inadvertently disclose the identities of "blind copy" recipients to -others. - -7.6 Scope of Operation of SMTP Servers - -It is a well-established principle that an SMTP server may refuse to accept -mail for any operational or technical reason that makes sense to the site -providing the server. However, cooperation among sites and installations -makes the Internet possible. If sites take excessive advantage of the -right to reject traffic, the ubiquity of email availability (one of the -strengths of the Internet) will be threatened; considerable care should be -taken and balance maintained if a site decides to be selective about the -traffic it will accept and process. - -In recent years, use of the relay function through arbitrary sites has been -used as part of hostile efforts to hide the actual origins of mail. Some -sites have decided to limit the use of the relay function to known or -identifiable sources, and implementations SHOULD provide the capability to -perform this type of filtering. When mail is rejected for these or other -policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL FROM, -or RCPT TO as appropriate. - - -8. IANA Considerations - -IANA will maintain three registries in support of this specification. The -first consists of SMTP service extensions with the associated keywords, -and, as needed, parameters and verbs. As specified in section 2.2.2, no -entry may be made in this registry that starts in an "X". Entries may be -made only for service extensions (and associated keywords, parameters, or -verbs) that are defined in standards-track or experimental RFCs -specifically approved by the IESG for this purpose. - -The second registry consists of "tags" that identify forms of domain -literals other than those for IPv4 addresses (specified in RFC 821 and in -this document) and IPv6 addresses (specified in this document). Additional -literal types require standardization before being used; none are -anticipated at this time. - -The third, established by RFC 821 and renewed by this specification, is a -registry of link and protocol identifiers to be used with the "via" and -"with" subclauses of the time stamp ("Received: header") described in -section 4.4. Link and protocol identifiers in addition to those specified -in this document may be registered only by standardization or by way of an -RFC-documented, IESG-approved, Experimental protocol extension. - - -9. References - -[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP -Service Extension for 8bit-MIMEtransport", RFC 1652, 07/18/1994. - -[ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax -Specifications: ABNF", RFC 2234, November 1997. - -[IPv6AddrSpec] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing -Architecture", RFC 1884, December 1995. - -[MSGFMT] P. Resnick, Work in progress, draft-ietf-drums-msg-fmt-05.txt, -August, 1998 - -[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text -Messages", RFC 822, Department of Electrical Engineering, University of -Delaware, August 1982. - -[RFC-974] C. Partridge, "Mail routing and the domain system", RFC 974, -01/01/1986 - -[RFC-1047] C. Partridge, "Duplicate messages and SMTP", RFC 1047, -02/01/1988. - -[RFC-1123] R. Braden, "Requirements for Internet hosts - application and -support", 10/01/1989 - -[RFC-BDAT] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large -and Binary MIME Messages", RFC 1830, 08/16/1995. - -[RFC-DNS] P. Mockapetris, "Domain names - implementation and -specification", RFC 1035 and P. Mockapetris, "Domain names - concepts and -facilities", RFC 1034. (STD 13) - -[RFC-ETRN] J. De Winter, "SMTP Service Extension for Remote Message Queue -Starting", RFC 1985, 08/14/1996. - -[RFC-IMAP2] M. Crispin, "Interactive Mail Access Protocol - Version 2", RFC -1176, 08/20/1990. - -[RFC-IMAP4] M. Crispin, "Internet Message Access Protocol - Version 4", RFC -2060, 12/04/1996. - -[RFC-INTLHDR] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part -Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 12/02/1996. - -[RFC-MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions -(MIME) Part One: Format of Internet Message Bodies", RFC 2045, 12/02/1996. - -[RFC-MOSS] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object -Security Services", RFC 1848, 10/03/1995. - -[RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery Status -Notifications", RFC 1891, 01/15/1996. - -[RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message Format for -Delivery Status Notifications", RFC 1894, 01/15/1996. - -[RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for personal -computers", RFC 1056, 06/01/1988. - -[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension for Command -Pipelining", RFC 1854, 10/04/1995. - -[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J. Reynolds, -"Post Office Protocol - version 2", RFC 937, 02/01/1985 - -[RFC-POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3", RFC 1930, -5/14/96 (Std 53). - -[RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 1893, -01/15/1996. - -[RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension for -Message Size Declaration", RFC 1870, 11/06/1995. (STD 10) - -[RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021 -and RFC 822", RFC 1327, 05/18/1992. - -[SMTPEXT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP -Service Extensions", RFC-1869, 11/06/1995. (STD 10) - -[TCP] Postel, J., ed., "Transmission Control Protocol - DARPA Internet -Program Protocol Specification", RFC 793, USC/Information Sciences -Institute, NTIS AD Number A111091, September 1981. - -[US-ASCII] United States of America Standards Institute (now American -National Standards Institute), X3.4, 1968, "USA Code for Information -Interchange". ANSI X3.4-1968 has been replaced by newer versions with -slight modifications, but the 1968 version remains definitive for the -Internet. - - -10. Editor's Address - -John C. Klensin -MCI Communications -800 Boylston St., 7th floor -Boston, MA 02199 -USA -Email: Klensin@mci.net -Phone: +1 617 960 1011 -Fax: +1 617 960 1009 - - -11. Acknowledgments - -Many people worked long and hard on the many iterations of this document. -There was wide-ranging debate on the mailing list about many technical -issues, and many contributors helped form the wording in this -specification. The hundreds of participants in the many discussions since -RFC 821 was produced are too numerous to mention, but they all helped this -document become what it is. - - -A. TCP Transport Service - -The TCP connection supports the transmission of 8-bit bytes. The SMTP data -is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte -with the high-order bit cleared to zero. Service extensions may modify -this rule to permit transmission of full 8-bit data bytes as part of the -message body, but not in SMTP commands or responses. - - -B. Generating SMTP Commands from RFC 822 Headers - -Some systems use RFC 822 headers (only) in a mail submission protocol, or -otherwise generate SMTP commands from RFC 822 headers when such a message -is handed to an MTA from a UA. While the MTA-UA protocol is a private -matter, not covered by any Internet Standard, there are problems with this -approach. For example, there have been repeated problems with proper -handling of "bcc" copies and redistribution lists when information that -conceptually belongs to a mail envelopes is not separated early in -processing from header information (and kept separate). - -It is recommended that the UA provide its initial MTA with an envelope -separate from the message itself. However, if the envelope is not -supplied, SMTP commands SHOULD be generated as follows: - -1. Each recipient address from a TO, CC, or BCC header field SHOULD be - copied to a RCPT command (generating multiple message copies if that is - required for queuing or delivery). This includes any addresses listed - in a RFC 822 "group". Any BCC fields SHOULD then be removed from the - headers. Once this process is completed, the remaining headers SHOULD - be checked to verify that at least one To:, Cc:, or Bcc: header remains. - If none do, then a bcc: header with no additional information SHOULD be - inserted as specified in [MSGFMT]. - -2. The return address in the MAIL command SHOULD, if possible, be derived - from the system's identity for the submitting (local) user, and the From - header field otherwise. If there is a system identity available, it - SHOULD also be copied to the Sender header field if it is different from - the address in the From header field. (Any Sender field that was - already there SHOULD be removed.) Systems may provide a way for - submitters to override the envelope return address, but may want to - restrict its use to privileged users. This will not prevent mail - forgery, but may lessen its incidence; see section 7.1. - -When an MTA is being used in this way, it bears responsibility for ensuring -that the message being transmitted is valid. The mechanisms for checking -that validity, and for handling (or returning) messages that are not valid -at the time of arrival, are part of the MUA-MTA interface and not covered -by this specification. - -A submission protocol based on Standard RFC 822 information alone MUST NOT -be used to gateway a message from a foreign (non-SMTP) mail system into an -SMTP environment. Additional information to construct an envelope must -come from some source in the other environment, whether supplemental -headers or the foreign system's envelope. - -Attempts to gateway messages using only their header "to" and "cc" fields, -have repeatedly caused mail loops and other behavior adverse to the proper -functioning of the Internet mail environment. These problems have been -especially common when the message originates from an Internet mailing list -and is distributed into the foreign environment using envelope information. -When these messages are then processed by a header-only remailer, loops -back to the Internet environment (and the mailing list) are almost -inevitable. - - -C. Source Routes - -The <reverse-path> is a reverse source routing list of hosts and a source -mailbox. The first host in the <reverse-path> SHOULD be the host sending -the MAIL FROM command. Similarly, the <forward-path> may be a source -routing lists of hosts and a destination mailbox. However, in general, the -<forward-path> SHOULD contain only a mailbox and domain name, relying on -the domain name system to supply routing information if required. The use -of source routes is deprecated; while servers MUST be prepared to receive -and handle them as discussed in section 3.3 and F.2, clients SHOULD NOT -transmit them. - -For relay purposes, the forward-path may be a source route of the form -"@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully-qualified -domain names. This form is used to emphasize the distinction between an -address and a route. The mailbox is an absolute address, and the route is -information about how to get there. The two concepts should not be -confused. - -If source routes are used, RFC 821 and the text below should be consulted -for the mechanisms for constructing and updating the forward- and -reverse-paths. - -The SMTP server transforms the command arguments by moving its own -identifier (its domain name or that of any domain for which it is acting as -a mail exchanger), if it appears, from the forward-path to the beginning of -the reverse-path. - -Notice that the forward-path and reverse-path appear in the SMTP commands -and replies, but not necessarily in the message. That is, there is no need -for these paths and especially this syntax to appear in the "To:" , -"From:", "CC:", etc. fields of the message header. Conversely, SMTP servers -MUST NOT derive final message delivery information from message header -fields. - -When the list of hosts is present, it is a "reverse" source route and -indicates that the mail was relayed through each host on the list (the -first host in the list was the most recent relay). This list is used as a -source route to return non-delivery notices to the sender. As each relay -host adds itself to the beginning of the list, it MUST use its name as -known in the transport environment to which it is relaying the mail rather -than that of the transport environment from which the mail came (if they -are different). - - -D. Scenarios - -This section presents complete scenarios of several types of SMTP sessions. -In the examples, "C:" indicates what is said by the SMTP client, and "S:" -indicates what is said by the SMTP server. - -D.1 A Typical SMTP Transaction Scenario - -This SMTP example shows mail sent by Smith at host bar.com, to Jones, -Green, and Brown at host foo.com. Here we assume that host bar.com -contacts host foo.com directly. The mail is accepted for Jones and Brown. -Green does not have a mailbox at host foo.com. - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<Smith@bar.com> - S: 250 OK - C: RCPT TO:<Jones@foo.com> - S: 250 OK - C: RCPT TO:<Green@foo.com> - S: 550 No such user here - C: RCPT TO:<Brown@foo.com> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.2 Aborted SMTP Transaction Scenario - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<Smith@bar.com> - S: 250 OK - C: RCPT TO:<Jones@foo.com> - S: 250 OK - C: RCPT TO:<Green@foo.com> - S: 550 No such user here - C: RSET - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.3 Relayed Mail Scenario - -Step 1 -- Source Host to Relay Host - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<JQP@bar.com> - S: 250 OK - C: RCPT TO:<@foo.com:Jones@XYZ.COM> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Date: Thu, 21 May 1998 05:33:29 -0700 - C: From: John Q. Public <JQP@bar.com> - C: Subject: The Next Meeting of the Board - C: To: Jones@xyz.com - C: - C: Bill: - C: The next meeting of the board of directors will be - C: on Tuesday. - C: John. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -Step 2 -- Relay Host to Destination Host - - S: 220 xyz.com Simple Mail Transfer Service Ready - C: EHLO foo.com - S: 250 xyz.com is on the air - C: MAIL FROM:<@foo.com:JQP@bar.com> - S: 250 OK - C: RCPT TO:<Jones@XYZ.COM> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Received: from bar.com by foo.com ; Thu, 21 May 1998 05:33:29 -0700 - C: Date: Thu, 21 May 1998 05:33:22 -0700 - C: From: John Q. Public <JQP@bar.com> - C: Subject: The Next Meeting of the Board - C: To: Jones@xyz.com - C: - C: Bill: - C: The next meeting of the board of directors will be - C: on Tuesday. - C: John. - C: . - S: 250 OK - - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.4 Verifying and Sending Scenario - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: VRFY Crispin - S: 250 Mark Crispin <Admin.MRC@foo.com> - C: SEND FROM:<EAK@bar.com> - S: 250 OK - C: RCPT TO:<Admin.MRC@foo.com> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - - -E. Other Gateway Issues - -In general, gateways between the Internet and other mail systems SHOULD -attempt to preserve any layering semantics across the boundaries between -the two mail systems involved. Gateway- translation approaches that -attempt to take shortcuts by mapping, (such as envelope information from -one system to the message headers or body of another) have generally proven -to be inadequate in important ways. Systems translating between -environments that do not support both envelopes and headers and Internet -mail must be written with the understanding that some information loss is -almost inevitable. - - -F. Deprecated Features of RFC 821 - -A few features of RFC 821 have proven to be problematic and SHOULD NOT be -used in Internet mail. - -F.1 TURN - -This command, described in RFC 821, raises important security issues since, -in the absence of strong authentication of the host requesting that the -client and server switch roles, it can easily be used to divert mail from -its correct destination. Its use is deprecated; SMTP systems SHOULD NOT -use it unless the server can authenticate the client. - -F.2 Source Routing - -RFC 821 utilized the concept of explicit source routing to get mail from -one host to another via a series of relays. The requirement to utilize -source routes in regular mail traffic was eliminated by the introduction of -the domain name system "MX" record and the last significant justification -for them was eliminated by the introduction, in RFC 1123, of a clear -requirement that addresses following an "@" must all be fully-qualified -domain names. Consequently, the only remaining justifications for the use -of source routes are support for very old SMTP clients or MUAs and in mail -system debugging. They can, however, still be useful in the latter -circumstance and for routing mail around serious, but temporary, problems -such as problems with the relevant DNS records. - -SMTP servers MUST continue to accept source route syntax as specified in -the main body of this document and in RFC 1123. They MAY, if necessary, -ignore the routes and utilize only the target domain in the address. If -they do utilize the source route, the message MUST be sent to the first -domain shown in the address. In particular, a server MUST NOT guess at -shortcuts within the source route. - -Clients SHOULD NOT utilize explicit source routing except under unusual -circumstances, such as debugging or potentially relaying around firewall or -mail system configuration errors. - -F.3 HELO - -As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to HELO -when the server will accept the former. Servers must continue to accept -and process HELO in order to support older clients. - -F.4 #-literals - -RFC 821 provided for specifying an Internet address as a decimal integer -host number prefixed by a pound sign, "#". In practice, that form has been -obsolete since the introduction of TCP/IP. It is deprecated and MUST NOT -be used. - -F.5 Dates and Years - -When dates are inserted into messages by SMTP clients or servers (e.g., in -trace fields), four-digit years MUST BE used. Two-digit years are -deprecated; three-digit years were never permitted in the Internet mail -system. - -F.6 Sending versus Mailing - -In addition to specifying a mechanism for delivering messages to user's -mailboxes, RFC 821 provided additional, optional, commands to deliver -messages directly to the user's terminal screen. These commands (SEND, -SAML, SOML) were rarely implemented, and changes in workstation technology -and the introduction of other protocols may have rendered them obsolete -even where they are implemented. - -Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers MAY -implement them. If they are implemented by servers, the implementation -model specified in RFC 821 MUST be used and the command names MUST be -published in the response to the EHLO command. - - -X. Change Summary and Loose Ends (Temporary) - -X.1 Change summary - -X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and -draft-ietf-drums-smtpupd-01.txt - -(i) Slightly clarified the discussions of rejection and failure of VRFY -requests and the associated response codes. - -(ii) Slightly clarified the discussion of deferred address validation. - -(iii) Removed the IPCE terminology and modified the text in section 4.1.1.2 -to explicitly introduce the "mail gateway" terminology and to begin to -distinguish a mail gateway from a conventional relay. - -(iv) Explicitly noted that SMTP clients for things like POP and IMAP may -send everything to a single relay for further processing, rather than -resolving final domain names. - -(v) Tightened the RSET discussion. - -(vi) Deprecation of 251 only for RCPT (still ok for VRFY) - -X.1.2. Substantive changes between draft-ietf-drums-smtpupd-01.txt and -draft-ietf-drums-smtpupd-02.txt. - -Incorporated additional RFC 1123 material; reorganized several sections for -clarity. Added definitions and other previous "loose end" material. - -X.1.3. Substantive changes between draft-ietf-drums-smtpupd-02.txt and -draft-ietf-drums-smtpupd-03.txt. - -(i) Eliminated a number of placeholders and tightened some of the -definitions in section 2. Added a few new placeholders for consistency -checking against other documents. - -(ii) Removed the state diagrams, per direction at IETF Montreal. - -(iii) Added new section 6.3, an attempt to summarize WG discussions on the -"posting" versus "delivery" versus "relay" functions of SMTP and on whether -"fixups" are appropriate in different cases. - -(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of RFC1123. - -(v) Added new text to 3.5.5 to discuss the spammer - EXPN relationship. - -(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat. - -(v) The remaining miscellaneous changes agreed to in Montreal have been -incorporated except as noted below. - -X.1.4. Substantive changes between draft-ietf-drums-smtpupd-03.txt and -draft-ietf-drums-smtpupd-04.txt. - -Many small changes have been made between these two versions; the list that -follows is not exhaustive. - -(i) To clarify some of the text, definitions have been introduced to -distinguish among originating, delivery, relay, and gateway SMTP systems. - -(ii) The role of LF-terminated lines has been clarified. - -(iii) Several changes have been made to clarify the principle that, no -matter what originating and final delivery systems might do, relay systems -are not permitted to tamper with message content, even to "fix" headers -that are determined to be invalid. If they deem message content to be -seriously unacceptable, they are encouraged to reject the messages in -preference to trying to fix them up, but, in general, the theme is "don't -look/ don't tell". - -(iv) A few more definitions have been added to the terminology section, and -the separate glossary has been eliminated. - -(v) I have taken a shot at text to address some of the controversies that -have raged on the WG mailing list (e.g., sections 7.4 and 7.5). Since there -was no consensus on most of those topics, I expect that the inserted text -will satisfy no one except, perhaps, for agreement that saying nothing -would have been worse. As a mechanism for moving forward, the text in -these controversial areas that now appears will be considered "base"; -alterations will be made only if clear consensus emerges. - -(vi) Per discussion in Los Angeles, source routes have been further -deprecated. - -(vii) Some of the VRFY/EXPN materials have been moved to "security -considerations", where they appear to belong, some text has been added, and -the conformance statements adjusted to reflect what I perceive to be WG -consensus. - -(viii) New MX resolution material has been added to section 5. While most -of this material is from RFC974, the rules have been further tightened to -reflect current practice and experience (974 is written in a somewhat -speculative fashion for a standard). In particular, the behavior of trying -the target host's A RR when MXs existed but all of them were eliminated is -now prohibited, which seems necessary if another of other ideas being -recommended or considered are to be feasible. - -X.1.5. Substantive changes between draft-ietf-drums-smtpupd-04.txt and -draft-ietf-drums-smtpupd-05.txt. - -(i) All normative references to RFC 1123 have been removed from the main -body of the text (some still appear in the appendices where they will -remain). - -(ii) Section 3.5 has been renamed slightly to distinguish between -"debugging of SMTP implementations" and "debugging of addresses". Better -terminology would be welcome. - -(iii) Error conditions resulting from the DATA command have been clarified. - -(iv) Section 4.2 (SMTP replies) has been revised and tightened to reflect -reality and recent discussion on the list. - -(v) Appendix E has been revised a bit and moved into section 4.2.1. Given -the importance of the "check only first digit" rule, it has to be there. - -(vi) Added new text for "no SMTP service supported" to sections 3.1, 4.2.2, -4.2.3, and 4.3.2. As noted in 3.1, I'd rather add 521 (which would work -perfectly with the model) rather than overloading 554. - -(vii) The Return-path language in section 4.4 has been cleaned up a bit. - -(viii) Tightened the "postmaster" language in 4.5.1, requiring a small -change to 4.1.1.3. - -(ix) I have unilaterally (with a little help from my friends), increased -some of the size limits. 64 was much too short for a domain name, and the -DNS limit of 255 (?) has now been inserted. That leaves the return path -much too short, but I haven't fixed it (maybe that will cause us to get rid -of them). We still have a 64 character limit on the local-part, which is -also *much* too short. Votes for 128 or longer limits accepted. See -X.1.6(I) - -(x) The text on the "recipients buffer" has been rewritten so that (I hope) -it makes sense and gives some explicit guidance for how clients and servers -should proceed if limits are imposed. - -X.1.6. Substantive changes between draft-ietf-drums-smtpupd-05.txt and -draft-ietf-drums-smtpupd-06.txt. - -Most of the changes in this revision have been editorial rather than -substantive. Major substantive changes include: - -(i) The language about maximum sizes of SMTP command lines has been -reworked, per WG mailing list discussion. - -(ii) Several instances of "Should" have been promoted to "Must" when the -reasons for the weaker rule seemed to have disappeared. In particular, the -requirement that an SMTP implementation support timeouts has become a MUST. -Also, conformance to this specification requires support of EHLO. Older -systems should claim conformance to the [to-be-historical] 821, not this -specification. - -X.1.7. Substantive changes between draft-ietf-drums-smtpupd-06.txt and -draft-ietf-drums-smtpupd-07.txt. - -(i) Removed "implied RSET" text associated with QUIT, as specified at the -December 1997 IETF - -(ii) Required that servers support EHLO, as specified at the December 1997 -IETF - -X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt and -draft-ietf-drums-smtpupd-08.txt. - -This version involves mostly editorial work and cleanup of loose ends. - -(i) New 7.5 added (old one renumbered) to discuss info disclosure through -Received fields. - -(ii) Some character set and minor syntax issues clarified. - -(iii) Material on code 571 added (thought this had been done long ago; -slipped through the cracks) - -(iv) Many clarifications added as the result of list discussions and -suggestions. - -(v) Error code presentation has been restructured. - -(vi) ABNF conversion done - -(vii) IPv6 address format inserted per RFC 1884, since we could not get -clear agreement on an alternative. - -(viii) Trivial, silly, examples removed. Others not yet renumbered. - -(ix) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes. Eric may -not like the way I've done either of these change very much: the first now -makes the distinction between returning an address and returning other -stuff (which was permitted by -06, but the text wasn't as clear as it -should have been): if it looks like an address, it needs to be an address. -Similarly, with 4.1.1, Eric wanted to explicitly permit/legitimize "DATA -<SP> <CRLF>". I see several disadvantages to doing that, so have inserted -language that encourages receivers to tolerate trailing white space, which -may have the same practical effect. - - -X.1.9. Substantive changes between draft-ietf-drums-smtpupd-08.txt and -draft-ietf-drums-smtpupd-09.txt. - -The first ten of these reflect, in order, minuted items from the Chicago -IETF (IETF 42). - -(i) Clarification of "MUST", etc., in the context of this document -(section 2.3). - -(ii) Altered VRFY text to make implementation a SHOULD (section 3.5.1) and -removed VRFY from the mandatory to implement list (section 4.5.1), per -42nd IETF (Chicago). - -(iii) Clarified that exploders are expected to not purge sender addresses -from lists (section 3.10). Note that the Chicago conclusion was that this -should be a "MUST". I could not figure out how to do that without -absolutely prohibiting removing addresses to prevent loops, to guard -against spammers, or for similar legitimate purposes. So I have written -this as a "SHOULD", with additional "strongly discouraged" words. If -someone still wants a MUST, suggest text. - -(iv) Altered text to permit clients that sometimes, or even always, -initiate sessions with HELO, rather than EHLO, to be fully-conforming -(section 3.2). [[ Editor's note: I continue to believe that a client that -does not have any service extension support, even to the extent of being -able to send EHLO and parse the response without doing anything about it, -should not be considered fully-conforming to this spec (as distinct from -821). Consequently, the new text in 3.2 stops well short of encouraging -clients that don't need service extensions from preferentially using HELO, -and the text in 2.2.1 (which specifies that the extension mechanisms must -be supported) has not been changed. - -(v) Per Chicago discussions, the text requiring that QUIT be sent has not -been changed. The text in 4.1.1.10 requiring that the server wait for -QUIT has been changed to a SHOULD. However, the text in 4.1.1.5, -prohibiting close on receipt of RSET and that elsewhere prohibiting close -as a normal response, has not been changed. - -(vi) Text has been inserted in 4.1.1 and the text in 4.3.2 altered -slightly to clarify the handling of parameters to RSET, DATA, and QUIT and -to 4.1.1.9 specify semantics for parameters to NOOP. I have followed the -minutes on this although I personally agree with kre's mailing list -comments that the "servers SHOULD reject" decision leads to silly states. -I recommend that the WG review this. - -(vii) Per discussion in Chicago, no substantive change has been made to -the specification about underscore characters in domain names (section -4.1.2). However, the text has been altered to more accurately reflect -discussion on the mailing list and the source of the requirement. - -(viii) Per discussion in Chicago, no change has been made to the -preference for local time in Received headers. - -(ix) Per discussion in Chicago, code 571 has been removed and policy -rejection is now reflected i a 550 code (section 3.7 and the response code -lists). - -(x) Per discussion in Chicago, no change has been made to the -specification of use of raw CR or LF. - -(xi) In section 4.3, the text has been changed, per comments from Dan -Bernstein and others, to require that clients be able to handle replies -that do not contain text strings. A few other places patched to match. - -(xii) In sections 4.1.1.1 and 8, the placeholders have been removed. - -(xiii) Per discussion on the mailing list (and specifically James -Berriman's concerns), the text has been clarified (sections 4.1.1.2 and -4.1.4) to prohibit MAIL unless no mail transaction is open. This is a -MUST NOT prohibition -- SHOULD NOT makes no sense if this is the direction -we are going to go. 503 has also been added to the list of valid -responses for "MAIL" in 4.3.1 - it can't be issued before EHLO/HELO in any -event. While it is clear that something should be said, this may not be -the desired outcome (I selected it because it was conservative and easy -given the text that was there already); the WG should check that the text -is as intended. - -(xiv) Per discussion on the mailing list, a new section 4.5.5 has been -added to describe null return paths and their handling (forward pointer -from 3.7). The text in 4.5.5 is substantially that suggested by Norbert -Bollow. As with (xiii), there is now clear text, but it may not be what -the WG desires. Please check. - -(xv) "all addresses" substituted for "each...in turn" in 3.10.2. - -(xvi) Requirement for "<" and ">" around paths clarified in section 3.3 -(syntax productions were clear and correct, but not this overview -material). - -(xvii) Clarified text in 3.3 to permit post-DATA bounces on policy -matters. - - -X.1.10. Substantive changes between draft-ietf-drums-smtpupd-09.txt -and draft-ietf-drums-smtpupd-10.txt. - -(i) A large series of typos, most of them caught by Philip Hazel, -corrected. - -(ii) Residual problems with references to mailboxes, forward, and -reverse paths in 4.1.1.2 and 4.1.1.3 corrected and some text, I hope, -clarified. - -(iii) Text added to 4.2.5 to talk about 5yz errors after DATA. This -text should be checked carefully -- it is a proposal and may or may -not reflect WG consensus. - -(iv) Upper bound on "seconds" has been changed to 60 (not 61), per -list discussion. Years are still four-digits and will stay that way -unless the list discussion converges on something else. The increase -to 60 seconds includes an explicit note about leap seconds. - -(v) Text has been inserted to reflect the Orlando consensus about "QUIT", -i.e., the client MUST send a QUIT command and SHOULD wait for the results -before closing the connection. Servers are still not permitted to close -without receiving a QUIT and sending a 221 response (except, of course, -under the usual "unavoidable circumstances", in which case they should get -off a 451 if that is feasible). - -(vi) The EHLO response specification has been changed back to reflect -non-advertisement of VRFY and some text implying that VRFY was optional to -support has been removed (WG consensus seemed to be moving in that -direction at one point, and the editor reacted prematurely). This makes -the text compatible with RFC1869 and restores VRFY to its RFC1123 status. - -(vii) The text in section 5 has been clarified with regard to what a relay -that receives a message because of its designation as an MX can do and 3.7 -has been slightly modified to point to it. - -(viii) New text has been added to 3.7 to clarify the use of "SMTP server" -relays in "dumb" originating clients. - -(viii) Small wording changes inserted into 4.1.4 (e.g., insertion of ", if -possible," into the first sentence of the fifth paragraph to eliminate the -apparent conflict with the second sentence). - - -Z. Full Copyright Statement - -Copyright (C) The Internet Society (1998). All Rights Reserved. - -This document and translations of it may be copied and furnished to others, -and derivative works that comment on or otherwise explain it or assist in -its implementation may be prepared, copied, published and distributed, in -whole or in part, without restriction of any kind, provided that the above -copyright notice and this paragraph are included on all such copies and -derivative works. However, this document itself may not be modified in any -way, such as by removing the copyright notice or references to the Internet -Society or other Internet organizations, except as needed for the purpose -of developing Internet standards in which case the procedures for -copyrights defined in the Internet Standards process must be followed, or -as required to translate it into languages other than English. - -The limited permissions granted above are perpetual and will not be revoked -by the Internet Society or its successors or assigns. - -This document and the information contained herein is provided on an "AS -IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE -DISCLAIMS 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. - -Expires July 1999 diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-11.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-11.txt deleted file mode 100644 index ec272339..00000000 --- a/Documentation/en/I-D/draft-ietf-drums-smtpupd-11.txt +++ /dev/null @@ -1,4018 +0,0 @@ -INTERNET-DRAFT John C. Klensin, Editor -Expires September 9, 2000 -March 9, 2000 - - - Simple Mail Transfer Protocol - - draft-ietf-drums-smtpupd-11.txt - -Status of this Memo - -This document is an Internet-Draft and is in full conformance with -all provisions of Section 10 of RFC2026. - -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. - -[[Appendix X will be removed before the document is submitted to the -IESG.]] - -[[If consensus is reached on this document, it will be forwarded to the -IESG with the recommendation that it be processed onto the Standards -track.]] - -Copyright Notice - -Copyright (C) The Internet Society (1998). All Rights Reserved. - - Table of Contents - -0. Abstract - -1. Introduction - -2. The SMTP Model -2.1 Basic Structure -2.2 The Extension Model -2.2.1 Background -2.2.2 Definition and Registration of Extensions -2.3 Terminology -2.3.1 Mail Objects -2.3.2 Senders and Receivers -2.3.3 Mail Agents and Message Stores -2.3.4 Host -2.3.5 Domain -2.3.6 Buffer and State Table -2.3.7 Lines -2.3.8 Originator, Delivery, Relay, and Gateway Systems -2.3.9 Message Content and Mail Data -2.3.10 Mailbox and Address -2.3.11 Reply -2.4 General Syntax Principles and Transaction Model - -3. The SMTP Procedures: An Overview -3.1 Session Initiation -3.2 Client Initiation -3.3 Mail Transactions -3.4 Forwarding for Address Correction or Updating -3.5 Commands for Debugging Addresses -3.5.1 Overview -3.5.2 VRFY Normal Response -3.5.3 Meaning of VRFY or EXPN Success Response -3.5.4 Semantics and Applications of EXPN -3.6 Domains -3.7 Relaying -3.8 Mail Gatewaying -3.8.1 Header Fields in Gatewaying -3.8.2 Received Lines in Gatewaying -3.8.3 Addresses in Gatewaying -3.8.4 Other Header Fields in Gatewaying -3.8.5 Envelopes in Gatewaying -3.9 Terminating Sessions and Connections -3.10 Mailing Lists and Aliases -3.10.1 Alias -3.10.2 List - -4. The SMTP Specifications -4.1 SMTP Commands -4.1.1 Command Semantics and Syntax -4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) -4.1.1.2 MAIL (MAIL) -4.1.1.3 RECIPIENT (RCPT) -4.1.1.4 DATA (DATA) -4.1.1.5 RESET (RSET) -4.1.1.6 VERIFY (VRFY) -4.1.1.7 EXPAND (EXPN) -4.1.1.8 HELP (HELP) -4.1.1.9 NOOP (NOOP) -4.1.1.10 QUIT (QUIT) -4.1.2 Lower-level Syntax -4.1.3 Address Literals -4.1.4 Order of Commands -4.1.5 Private-use Commands -4.2 SMTP Replies -4.2.1 Reply Code Severities and Theory -4.2.2 Reply Codes by Function Groups -4.2.3 Reply Codes in Numeric Order -4.2.4 Reply Code 502 -4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> -4.3 Sequencing of Commands and Replies -4.3.1 Sequencing Overview -4.3.2 Command-Reply Sequences -4.4 Trace Information -4.5 Additional Implementation Issues -4.5.1 Minimum Implementation -4.5.2 Transparency -4.5.3 Sizes and Timeouts -4.5.3.1 Size limits and minimums -4.5.3.2 Timeouts -4.5.4 Queuing Strategies -4.5.4.1 Sending Strategy -4.5.4.2 Receiving Strategy -4.5.5 Messages with a null reverse-path - -5. Address Resolution and Mail Handling - -6. Problem Detection and Handling -6.1 Reliable Delivery and Replies by Email -6.2 Loop Detection -6.3 Compensating for Irregularities - -7. Security Considerations -7.1 Mail Security and Spoofing -7.2 "Blind" Copies -7.3 VRFY, EXPN, and Security -7.4 Information Disclosure in Announcements -7.5 Information Disclosure in Trace Fields -7.6 Scope of Operation of SMTP Servers - -8. IANA Considerations - -9. References - -10. Editors' Addresses - -11. Acknowledgments - -Appendices -A. TCP Transport Service -B. Generating SMTP Commands from RFC 822 Headers -C. Source Routes -D. Scenarios -E. Other Gateway Issues -F. Deprecated Features of RFC 821 -X. Change Summary and Loose Ends (Temporary) - - -0. Abstract - -This document is a self-contained specification of the basic protocol for -the Internet electronic mail transport, consolidating and updating: - - - the original SMTP specification of RFC 821 [RFC-821], - - - domain name system requirements and implications for mail transport from - RFC 1035 [RFC-DNS] and RFC 974 [RFC-974], - - - the clarifications and applicability statements in RFC 1123 [RFC-1123], - and - - - material drawn from the SMTP Extension mechanisms [SMTPEXT]. - -It replaces RFC 821, RFC 974, and the mail transport materials of RFC -1123. However, RFC 821 specifies some features that were not in -significant use in the Internet by the mid-1990s and (in appendices) -some additional transport models. Those sections are omitted here in -the interest of clarity and brevity; readers needing them should -refer to RFC 821. - -It also includes some additional material from RFC 1123 that required -amplification. This material has been identified in multiple ways, mostly -by tracking flaming on various lists and newsgroups and problems of unusual -readings or interpretations that have turned up as the SMTP extensions have -been deployed. Where this specification moves beyond consolidation and -actually differs from earlier documents, it supersedes them technically as -well as textually. - -Although SMTP was designed as a mail transport and delivery protocol, this -specification also contains information that is important to its use as a -'mail posting' protocol, as recommended for POP [RFC-POP2, RFC-POP3] and -IMAP [RFC-IMAP4]. - -Section 2.3 provides definitions of terms specific to this document. Except -when the historical terminology is necessary for clarity, this document -uses the current 'client' and 'server' terminology to identify the sending -and receiving SMTP processes, respectively. - -A companion document [MSGFMT] discusses message headers, message bodies -and formats and structures for them, and their relationship. - -Comments on this draft should be addressed to the IETF DRUMS Working -Group: - General Discussion:drums@cs.utk.edu - To Subscribe: drums-request@cs.utk.edu - Archive: ftp://cs.utk.edu/pub/drums/mail-archive/ - - - -1. Introduction - -The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer -mail reliably and efficiently. - -SMTP is independent of the particular transmission subsystem and requires -only a reliable ordered data stream channel. While this document -specifically discusses transport over TCP, other transports are possible. -Appendices to RFC 821 describe some of them. - -An important feature of SMTP is its capability to transport mail across -networks, usually referred to as "SMTP mail relaying" (see section 3.8). -A network consists of the mutually-TCP-accessible hosts on the public -Internet, the mutually-TCP-accessible hosts on a firewall-isolated TCP/IP -Intranet, or hosts in some other LAN or WAN environment utilizing a -non-TCP transport-level protocol. Using SMTP, a process can transfer -mail to another process on the same network or to some other network via -a relay or gateway process accessible to both networks. - -Inthis way, a mail message may pass through a number of intermediate -relay or gateway hosts on its path from sender to ultimate recipient. -The Mail eXchanger mechanisms of the domain name system [RFC-DNS, and -section 5 of this document] are used to identify the appropriate next-hop -destination for a message being transported. - - -2. The SMTP Model - -2.1 Basic Structure - -The SMTP design can be pictured as: - - +----------+ +----------+ - +------+ | | | | - | User |<-->| | SMTP | | - +------+ | Client- |Commands/Replies| Server- | - +------+ | SMTP |<-------------->| SMTP | +------+ - | File |<-->| | and Mail | |<-->| File | - |System| | | | | |System| - +------+ +----------+ +----------+ +------+ - SMTP client SMTP server - -When an SMTP client has a message to transmit, it establishes a two-way -transmission channel to an SMTP server. The responsibility of an SMTP client is to -transfer mail messages to one or more SMTP servers, or report its failure -to do so. - -The means by which a mail message is presented to an SMTP client, and how -that client determines the domain name(s) to which mail messages are to be -transferred is a local matter, and is not addressed by this document. In -some cases, the domain name(s) transferred to, or determined by, an SMTP -client will identify the final destination(s) of the mail message. In other -cases, common with SMTP clients associated with implementations of the POP -[RFC-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the SMTP client -is inside an isolated transport service environment, the domain name -determined will identify an intermediate destination through which all mail -messages are to be relayed. SMTP clients that transfer all traffic, -regardless of the target domain names associated with the individual -messages, or that do not maintain queues for retrying message transmissions -that initially cannot be completed, may otherwise conform to this -specification but are not considered fully-capable. Fully-capable SMTP -implementations, including the relays used by these less capable ones, and -their destinations, are expected to support all of the queuing, retrying, -and alternate address functions discussed in this specification. - -The means by which an SMTP client, once it has determined a target domain -name, determines the identity of an SMTP server to which a copy of a -message is to be transferred, and then performs that transfer, is covered -by this document. To effect a mail transfer to an SMTP server, an SMTP -client establishes a two-way transmission channel to that SMTP server. An -SMTP client determines the address of an appropriate host running an SMTP -server by resolving a destination domain name to either an intermediate -Mail eXchanger host or a final target host. - -An SMTP server may be either the ultimate destination or an intermediate -"relay" (that is, it may assume the role of an SMTP client after receiving -the message) or "gateway" (that is, it may transport the message further -using some protocol other than SMTP). SMTP commands are generated by the -SMTP client and sent to the SMTP server. SMTP replies are sent from the -SMTP server to the SMTP client in response to the commands. - -In other words, message transfer can occur in a single connection between -the original SMTP-sender and the final SMTP-recipient, or can occur in a -series of hops through intermediary systems. In either case, a formal -handoff of responsibility for the message occurs: the protocol requires -that a server accept responsibility for either delivering a message or -properly reporting the failure to do so. - -Once the transmission channel is established and initial handshaking -completed, the SMTP client normally initiates a mail transaction. Such a -transaction consists of a series of commands to specify the originator and -destination of the mail and transmission of the message content (including -any headers or other structure) itself. When the same message is sent to -multiple recipients, this protocol encourages the transmission of only one -copy of the data for all recipients at the same destination (or -intermediate relay) host. - -The server responds to each command with a reply; replies may indicate that -the command was accepted, that additional commands are expected, or that a -temporary or permanent error condition exists. Commands specifying the -sender or recipients may include server-permitted SMTP service extension -requests as discussed in section 2.2. The dialog is purposely lock-step, -one-at-a-time, although this can be modified by mutually-agreed extension -requests such as in [RFC-Pipeline]. - -Once a given mail message has been transmitted, the client may either -request that the connection be shut down or may initiate other mail -transactions. In addition, an SMTP client may use a connection to an SMTP -server for ancillary services such as verification of email addresses or -retrieval of mailing list subscriber addresses. - -As suggested above, this protocol provides mechanisms for the transmission -of mail. This transmission normally occurs directly from the sending -user's host to the receiving user's host when the two hosts are connected -to the same transport service. When they are not connected to the same -transport service, transmission occurs via one or more relay SMTP servers. -An intermediate host that acts as either an SMTP relay or as a gateway into -some other transmission environment is usually selected through the use of -the domain name service (DNS) Mail eXchanger mechanism. - -To provide relay capability, the SMTP server is supplied with the name of -the ultimate destination host as well as the destination mailbox name. -Usually, intermediate hosts are determined via the DNS MX record, not by -explicit "source" routing (see section 5 and appendices C and F.2). - -2.2 The Extension Model - -2.2.1 Background - -In an effort that started in 1990, approximately a decade after RFC 821 was -completed, the protocol was modified with a "service extensions" model that -permits the client and server to agree to utilize shared functionality -beyond the original SMTP requirements. The SMTP extension mechanism defines -a means whereby an extended SMTP client and server may recognize each -other, and the server can inform the client as to the service extensions -that it supports. - -Contemporary SMTP implementations MUST support the basic extension -mechanisms. For instance, servers MUST support the EHLO command even if -they do not implement any specific extensions and clients SHOULD -preferentially utilize EHLO rather than HELO. (However, for compatibility -with older conforming implementations, SMTP clients and servers MUST -support the original HELO mechanisms as a fallback.) Unless the different -characteristics of HELO must be identified for interoperability purposes, -this document discusses only EHLO. - -SMTP is widely deployed and high-quality implementations have proven to be -very robust. However, the Internet community now considers some services to -be important that were not anticipated when the protocol was first -designed. If support for those services is to be added, it must be done in -a way that permits older implementations to continue working acceptably. -The extension framework consists of: - - - The SMTP command EHLO, superseding the earlier HELO, - - - a registry of SMTP service extensions, - - - additional parameters to the SMTP MAIL and RCPT commands, and - - - optional replacements for verbs defined in this protocol, such as for - DATA (see [RFC-BDAT]). - -SMTP's strength comes primarily from its simplicity. Experience with many -protocols has shown that protocols with few options tend towards ubiquity, -whereas protocols with many options tend towards obscurity. - -Each and every extension, regardless of its benefits, must be carefully -scrutinized with respect to its implementation, deployment, and -interoperability costs. In many cases, the cost of extending the SMTP -service will likely outweigh the benefit. - -2.2.2 Definition and Registration of Extensions - -The IANA maintains a registry of SMTP service extensions. A corresponding -EHLO keyword value is associated with each extension. Each service -extension registered with the IANA must be defined in a formal -standards-track or IESG-approved experimental protocol document. The -definition must include: - - - the textual name of the SMTP service extension; - - - the EHLO keyword value associated with the extension; - - - the syntax and possible values of parameters associated with the - EHLO keyword value; - - - any additional SMTP verbs associated with the extension (additional - verbs will usually be, but are not required to be, the same as the - EHLO keyword value); - - - any new parameters the extension associates with the MAIL or RCPT - verbs; - - - a description of how support for the extension affects the behavior - of a server and client SMTP; and, - - - the increment by which the extension is increasing the maximum - length of the commands MAIL and/or RCPT, over that specified - in this standard. - -In addition, any EHLO keyword value starting with an upper or lower case -"X" refers to a local SMTP service extension used exclusively through -bilateral agreement. Keywords beginning with "X" MUST NOT be used in a -registered service extension. Conversely, keyword values presented in the -EHLO response that do not begin with "X" MUST correspond to a standard, -standards-track, or IESG-approved experimental SMTP service extension -registered with IANA. A conforming server MUST NOT offer non-"X"-prefixed -keyword values that are not described in a registered extension. - -Additional verbs and parameter names are bound by the same rules as EHLO -keywords; specifically, verbs beginning with "X" are local extensions that -may not be registered or standardized. Conversely, verbs not beginning -with "X" must always be registered. - -2.3 Terminology - -Most of the terminology in this document is common in the Internet at the -time of its writing. However, the following terms and concepts are used -in special ways here, or represent differences in terminology between RFC -821 and this document, and should be understood before reading further. -These definitions are normative, that is, they contain specifications to -which SMTP implementations are required to conform. - -The terms "MUST" and "SHOULD" (and "MUST NOT" and "SHOULD NOT") are -used in the same general sense here as in the Host Requirements -Standards [RFC-1123]. Specifically, "MUST" or "MUST NOT" identify -absolute requirements for conformance to this specification. -Implementations that do not conform to them lie outside the scope of -this specification and often will not interoperate properly with SMTP -implementations that do conform. Implementations that are fully -conforming also adhere to all "SHOULD" and "SHOULD NOT" requirements. -Implementations that adhere to all "MUST" ("MUST NOT") but not to all -of these are considered to be partially conforming. Such -implementations may interoperate properly with fully conforming ones -and with each other, but this will typically be the case only if great -care is taken. Consequently, an implementation should violate "SHOULD" -("SHOULD NOT") requirements only under exceptional and well-understood -circumstances. "SHOULD" (and sometimes "MUST") requirements are often -imposed by this specification when experience has shown that following -such requirements or restrictions leads, in practice, to better -interoperation, or smoother operation of the Internet email -infrastructure. As a consequence, some of these statements constitute -recommended practices, rather than the statistically most common -practice at the time of this writing. Statements using "MAY" describe -features or styles of doing things that may be followed, or not, at the -discretion of the implementation, normally without causing significant -interoperability problems. - -2.3.1 Mail Objects - -SMTP transports a mail object. A mail object contains an envelope and -content. - -The SMTP envelope is sent as a series of SMTP protocol units (described -in section 3). It consists of an originator address (to which error -reports should be directed); a delivery mode (e.g., deliver to -recipient mailboxes); one or more recipient addresses; and optional -protocol extension material. - -The SMTP content is sent in the SMTP DATA protocol unit and has two -parts: the headers and the body. If the content conforms to other -contemporary standards, the headers form a collection of field/value -pairs structured as described in [MSGFMT]; the body, if structured, is -defined according to MIME [RFC-MIME]. The content is textual in nature, -expressed using the US-ASCII repertoire [US-ASCII]. Although SMTP -extensions (such as [8BitMIME]) may relax this restriction for the -content body, the content headers are always encoded using the US-ASCII -repertoire. The algorithm defined in [RFC-INTLHDR] is used to represent -header values outside the US-ASCII repertoire, while still encoding -them using the US-ASCII repertoire. - -2.3.2 Senders and Receivers - -In RFC 821, the two hosts participating in an SMTP transaction were -described as the "SMTP-sender" and "SMTP-receiver". This document has -been changed to reflect current industry terminology and hence refers -to them as the "SMTP client" (or sometimes just "the client") and "SMTP -server" (or just "the server"), respectively. Since a given host may -act both as server and client in a relay situation, "receiver" and -"sender" terminology is still used where needed for clarity. - -2.3.3 Mail Agents and Message Stores - -Additional mail system terminology became common after RFC 821 was -published and, where convenient, is used in this specification. In -particular, SMTP servers and clients provide a mail transport service -and therefore act as "Mail Transfer Agents" (MTAs). "Mail User Agents" -(MUAs or UAs) are normally thought of as the sources and targets of -mail. At the source, an MUA might collect mail to be transmitted from -a user and hand it off to an MTA; the final ("delivery") MTA would be -thought of as handing the mail off to an MUA (or at least transferring -responsibility to it, e.g., by depositing the message in a "message -store"). However, while these terms are used with at least the -appearance of great precision in other environments, the implied -boundaries between MUAs and MTAs often do not accurately match common, -and conforming, practices with Internet mail. Hence, the reader should -be cautious about inferring the strong relationships and -responsibilities that might be implied if these terms were used -elsewhere. - -2.3.4 Host - -For the purposes of this specification, a host is a computer system -attached to the Internet (or, in some cases, to a private TCP/IP -network) and supporting the SMTP protocol. Hosts are known by names -(see "domain"); identifying them by numerical address is discouraged. - -2.3.5 Domain - -A domain (or domain name) consists of one or more dot-separated -components. These components ("labels" in DNS terminology [RFC-DNS] -are restricted for SMTP purposes to consist of a sequence of letters, -digits, and hyphens drawn from the ASCII character set [US-ASCII}. -Domain names are used as names of hosts and of other entities in the -domain name hierarchy. For example, a domain may refer to an alias -(label of a CNAME RR) or the label of Mail eXchanger records to be used -to deliver mail instead of representing a host name. See [RFC-DNS] and -section 5. - -The domain name, as described in this document and in [RFC-DNS], is the -entire, fully-qualified name (often referred to as an "FQDN"). A -domain name that is not in FQDN form is no more than a local alias. -Local aliases MUST NOT appear in any SMTP transaction. - -2.3.6 Buffer and State Table - -SMTP sessions are stateful, with both parties carefully maintaining a -common view of the current state. In this document we model this state -by a virtual "buffer" and a "state table" on the server which may be -used by the client to, for example, "clear the buffer" or "reset the -state table," causing the information in the buffer to be discarded and -the state to be returned to some previous state. - -2.3.7 Lines - -SMTP commands and, unless altered by a service extension, message data, -are transmitted in "lines". Lines consist of zero or more data -characters terminated by the sequence ASCII character "CR" (hex value -0D) followed immediately by ASCII character "LF" (hex value 0A). This -termination sequence is denoted as <CRLF> in this document. Conforming -implementations MUST NOT recognize or generate any other character or -character sequence as a line terminator. Limits MAY be imposed on line -lengths by servers (see section 4.5.3). - -2.3.8 Originator, Delivery, Relay, and Gateway Systems - -This specification makes a distinction among four types of SMTP -systems, based on the role those systems play in transmitting -electronic mail. An "originating" system (sometimes called an SMTP -originator) introduces mail into the Internet or, more generally, into -a transport service environment. A "delivery" SMTP system is one that -receives mail from a transport service environment and passes it to a -mail user agent or deposits it in a message store which a mail user -agent is expected to subsequently access. A "relay" SMTP system -(usually referred to just as a "relay") receives mail from an SMTP -client and transmits it, without modification to the message data other -than adding trace information, to another SMTP server for further -relaying or for delivery. - -A "gateway" SMTP system (usually referred to just as a "gateway") -receives mail from a client system in one transport environment and -transmits it to a server system in another transport environment. -Differences in protocols or message semantics between the transport -environments on either side of a gateway may require that the gateway -system perform transformations to the message that are not permitted to -SMTP relay systems. For the purposes of this specification, firewalls -that rewrite addresses should be considered as gateways, even if SMTP -is used on both sides of them. (See [IAB-Firewalls].) - -2.3.9 Message Content and Mail Data - -The terms "message content" and "mail data" are used interchangeably in -this document to describe the material transmitted after the DATA -command is accepted and before the end of data indication is -transmitted. Message content includes message headers and the -possibly-structured message body. The MIME specification [RFC-MIME] -provides the Standard mechanisms for structured message bodies. - -2.3.10 Mailbox and Address - -As used in this specification, an "address" is a character string that -identifies a user to whom mail will be sent or a location into which -mail will be deposited. The term "mailbox" refers to that depository. -The two terms are typically used interchangeably unless the distinction -between the location in which mail is placed (the mailbox) and a -reference to it (the address) is important. An address normally -consists of user and domain specifications. The standard mailbox -naming convention is defined to be "local-part@domain": contemporary -usage permits a much broader set of applications than simple "user -names". Consequently, and due to a long history of problems when -intermediate hosts have attempted to optimize transport by modifying -them, the local-part MUST be interpreted and assigned semantics only by -the host specified in the domain part of the address. - -2.3.11 Reply - -An SMTP reply is an acknowledgment (positive or negative) sent from -receiver to sender via the transmission channel in response to a -command. The general form of a reply is a numeric completion code -(indicating failure or success) usually followed by a text string. The -codes are for use by programs and the text is usually intended for -human users. Recent work [RFC-Reply] has specified further structuring -of the reply strings, including the use of supplemental and more -specific completion codes. - -2.4 General Syntax Principles and Transaction Model - -SMTP commands and replies have a rigid syntax. All commands begin with -a four letter command verb. All Replies begin with a three digit -numeric code. In some commands and replies, arguments MUST follow the -verb or reply code. Some commands do not accept arguments (after the -verb), and some reply codes are followed, sometimes optionally, by free -form text. In both cases, where text appears, it is separated from the -verb or reply code by a space character. Complete definitions of -commands and replies appear in section 4. - -Verbs and argument values (e.g., "TO:" or "to:" in the MAIL command and -extension name keywords) are not case sensitive, with the sole -exception in this specification of a mailbox local-part (SMTP -Extensions may explicitly specify case-sensitive elements). That is, a -command verb, an argument value other than a mailbox local-part, and -free form text MAY be encoded in upper case, lower case, or any mixture -of upper and lower case with no impact on its meaning. This is NOT -true of a mailbox local-part. The local-part of a mailbox MUST BE -treated as case sensitive. Therefore, SMTP implementations MUST take -care to preserve the case of mailbox local-parts. Mailbox domains are -not case sensitive. In particular, for some hosts the user "smith" is -different from the user "Smith". However, exploiting the case -sensitivity of mailbox local-parts impedes interoperability and is -discouraged. - -A few SMTP servers, in violation of this specification (and RFC 821) -require that command verbs be encoded by clients in upper case. -Implementations MAY wish to employ this encoding to accommodate those -servers. - -The argument field consists of a variable length character string -ending with the end of the line, i.e., with the character sequence -<CRLF>. The receiver will take no action until this sequence is -received. - -The syntax for each command is shown with the discussion of that -command. Common elements and parameters are shown in section 4.1.2. - -Commands and replies are composed of characters from the ASCII -character set [US-ASCII]. When the transport service provides an 8-bit -byte (octet) transmission channel, each 7-bit character is transmitted -right justified in an octet with the high order bit cleared to zero. -More specifically, the unextended SMTP service provides seven bit -transport only. An originating SMTP client which has not successfully -negotiated an appropriate extension with a particular server MUST NOT -transmit messages with information in the high-order bit of octets. If -such messages are transmitted in violation of this rule, receiving SMTP -servers MAY clear the high-order bit or reject the message as invalid. -In general, a relay SMTP SHOULD assume that the message content it has -received is valid and, assuming that the envelope permits doing so, -relay it without inspecting that content. Of course, if the content is -mislabeled and the data path cannot accept the actual content, this may -result in ultimate delivery of a severely garbled message to the -recipient. Delivery SMTP systems MAY reject ("bounce") such messages -rather than deliver them. No sending SMTP system is permitted to send -envelope commands in any character set other than US-ASCII; receiving -systems SHOULD reject such commands, normally using "500 syntax error - -invalid character" replies. - -Eight-bit message content transmission MAY be requested of the server -by a client using extended SMTP facilities, notably the "8BITMIME" -extension [8BITMIME]. 8BITMIME SHOULD be supported by SMTP servers. -However, it MUST not be construed as authorization to transmit -unrestricted eight bit material. 8BITMIME MUST NOT be requested by -senders for material with the high bit on that is not in MIME format -with an appropriate content-transfer encoding; servers MAY reject such -messages. - -The metalinguistic notation used in this document corresponds to the -"Augmented BNF" used in other Internet mail system documents. The -reader who is not familiar with that syntax should consult [ABNF]. -Metalanguage terms used in running text are surrounded by pointed -brackets (e.g., <CRLF>) for clarity. - - -3. The SMTP Procedures: An Overview - -This section contains descriptions of the procedures used in SMTP: -session initiation, the mail transaction, forwarding mail, verifying -mailbox names and expanding mailing lists, and the opening and closing -exchanges. Comments on relaying, a note on mail domains, and a -discussion of changing roles are included at the end of this section. -Several complete scenarios are presented in appendix D. - -3.1 Session Initiation - -An SMTP session is initiated when a client opens a connection to a -server and the server responds with an opening message. - -SMTP server implementations MAY include identification of their -software and version information in the connection greeting reply after -the 220 code, a practice that permits more efficient isolation and -repair of any problems. Implementations MAY make provision for SMTP -servers to disable the software and version announcement where it -causes security concerns. While some systems also identify their -contact point for mail problems, this is not a substitute for -maintaining the required "postmaster" address (see section 4.5.1). - -The SMTP protocol allows a server to formally reject a transaction -while still allowing the initial connection as follows: a 554 response -MAY be given in the initial connection opening message instead of the -220. A server taking this approach MUST still wait for the client to -send a QUIT (see section 4.1.1.10) before closing the connection and -SHOULD respond to any intervening commands with "503 bad sequence of -commands". Since an attempt to make an SMTP connection to such a -system is probably in error, a server returning a 554 response on -connection opening SHOULD provide enough information in the reply text -to facilitate debugging of the sending system. - -3.2 Client Initiation - -Once the server has sent the welcoming message and the client has -received it, the client normally sends the EHLO command to the server, -indicating the client's identity. In addition to opening the session, -use of EHLO indicates that the client is able to process service -extensions and requests that the server provide a list of the -extensions it supports. Older SMTP systems which are unable to support -service extensions and contemporary clients which do not require -service extensions in the mail session being initiated, MAY use HELO -instead of EHLO. Servers MUST NOT return the extended EHLO-style -response to a HELO command. For a particular connection attempt, if -the server returns a "command not recognized" response to EHLO, the -client SHOULD be able to fall back and send HELO. - -In the EHLO command the host sending the command identifies itself; the -command may be interpreted as saying "Hello, I am <domain>" (and, in -the case of EHLO, "and I support service extension requests"). - -3.3 Mail Transactions - -There are three steps to SMTP mail transactions. The transaction -starts with a MAIL command which gives the sender identification. A -series of one or more RCPT commands follows giving the receiver -information. Then a DATA command initiates transfer of the mail data -and is terminated by the "end of mail" data indicator, which also -confirms the transaction. - -The first step in the procedure is the MAIL command. - - MAIL FROM:<reverse-path> [<SP> <mail-parameters> ] <CRLF> - -This command tells the SMTP-receiver that a new mail transaction is -starting and to reset all its state tables and buffers, including any -recipients or mail data. The <reverse-path> portion of the first or -only argument contains the source mailbox (between "<" and ">" -brackets), which can be used to report errors (see section 4.2 for a -discussion of error reporting). If accepted, the SMTP server returns a -250 OK reply. If the mailbox specification is not acceptable for some -reason, the server MUST return a reply indicating whether the failure -is permanent (i.e., will occur again if the client tries to send the -same address again) or temporary (i.e., the address might be accepted -if the client tries again later). Despite the apparent scope of this -requirement, there are circumstances in which the acceptability of the -reverse-path may not be determined until one or more forward-paths (in -RCPT commands) can be examined. In those cases, the server MAY -reasonably accept the reverse-path (with a 250 reply) and then report -problems after the forward-paths are received and examined. Normally, -failures produce 550 or 553 replies. - -Historically, the <reverse-path> can contain more than just a mailbox, -however, contemporary systems SHOULD NOT use source routing (see -appendix C). - -The optional <mail-parameters> are associated with negotiated SMTP -service extensions (see section 2.2). - -The second step in the procedure is the RCPT command. - - RCPT TO:<forward-path> [ <SP> <rcpt-parameters> ] <CRLF> - -The first or only argument to this command includes a forward-path -(normally a mailbox and domain, always surrounded by "<" and ">" -brackets) identifying one recipient. If accepted, the SMTP server -returns a 250 OK reply and stores the forward-path. If the recipient -is known not to be a deliverable address, the SMTP server returns a 550 -reply, typically with a string such as "no such user - " and the -mailbox name (other circumstances and reply codes are possible). This -step of the procedure can be repeated any number of times. - -The <forward-path> can contain more than just a mailbox. Historically, -the <forward-path> can be a source routing list of hosts and the -destination mailbox, however, contemporary SMTP clients SHOULD NOT -utilize source routes (see appendix C). Servers MUST be prepared to -encounter a list of source routes in the forward path, but SHOULD -ignore the routes or MAY decline to support the relaying they imply. -Similarly, servers MAY decline to accept mail that is destined for -other hosts or systems. These restrictions make a server useless as a -relay for clients that do not support full SMTP functionality. -Consequently, restricted-capability clients MUST NOT assume that any -SMTP server on the Internet can be used as their mail processing -(relaying) site. If a RCPT command appears without a previous MAIL -command, the server MUST return a 503 "Bad sequence of commands" -response. The optional <rcpt-parameters> are associated with negotiated -SMTP service extensions (see section 2.2). - -The third step in the procedure is the DATA command (or some -alternative specified in a service extension). - - DATA <CRLF> - -If accepted, the SMTP server returns a 354 Intermediate reply and -considers all succeeding lines up to but not including the end of mail -data indicator to be the message text. When the end of text is -successfully received and stored the SMTP-receiver sends a 250 OK reply. - -Since the mail data is sent on the transmission channel, the end of -mail data must be indicated so that the command and reply dialog can be -resumed. SMTP indicates the end of the mail data by sending a line -containing only a "." (period or full stop). A transparency procedure -is used to prevent this from interfering with the user's text (see -section 4.5.2). - -The end of mail data indicator also confirms the mail transaction and -tells the SMTP server to now process the stored recipients and mail -data. If accepted, the SMTP server returns a 250 OK reply. The DATA -command can fail in only two ways: - - - If there was no MAIL, or no RCPT, command, or all such commands - were rejected, the server MAY return a "command out of sequence" - (503) reply in response to the DATA command. If that reply is - received, the client MUST NOT send the message data; more generally, - message data MUST NOT be sent unless a 354 reply is received. - - - If the verb is initially accepted and the 354 reply issued, the DATA - command should fail only if the mail transaction was incomplete (for - example, no recipients), or if resources were unavailable - (including, of course, the server unexpectedly becoming - unavailable), or if the server determines that the message should be - rejected for policy or other reasons. - -However, in practice, some servers do not perform recipient -verification until after the message text is received. These servers -SHOULD treat a failure for one or more recipients as a "subsequent -failure" and return a mail message as discussed in section 6. Using a -"550 mailbox not found" (or equivalent) reply code after the data are -accepted makes it difficult or impossible for the client to determine -which recipients failed. - -When RFC 822 format is being used, the mail data include the memo -header items such as Date, Subject, To, Cc, From [MSGFMT]. Server SMTP -systems SHOULD NOT reject messages based on perceived defects in the -RFC 822 or MIME [RFC-MIME] message header or message body. In -particular, they MUST NOT reject messages in which the numbers of -Resent- fields do not match or Resent-to appears without Resent-from -and/or Resent-date. - -Mail transaction commands MUST be used in the order discussed above. - - -3.4 Forwarding for Address Correction or Updating - -Forwarding support is most often required to consolidate and simplify -addresses within, or relative to, some enterprise and less frequently -to establish addresses to link a person's prior address with current -one. Silent forwarding of messages (without server notification to the -sender), for security or non-disclosure purposes, is common in the -contemporary Internet. - -In both the enterprise and the "new address" cases, information hiding -(and sometimes security) considerations argue against exposure of the -"final" address through the SMTP protocol as a side-effect of the -forwarding activity. This may be especially important when the final -address may not even be reachable by the sender. Consequently, the -"forwarding" mechanisms described in section 3.2 of RFC 821, and -especially the 251 (corrected destination) reply code from RCPT are -deprecated: Servers SHOULD NOT provide that service or return that code. - - -3.5 Commands for Debugging Addresses - -3.5.1 Overview - -SMTP provides commands to verify a user name or obtain the content of a -mailing list. This is done with the VRFY and EXPN commands, which have -character string arguments. Implementations SHOULD support VRFY and -EXPN (however, see section 3.5.2 and 7.3). - -For the VRFY command, the string is a user name or a user name and -domain (see below). If a normal (i.e., 250) response is returned, the -response MAY include the full name of the user and MUST include the -mailbox of the user. It MUST be in either of the following forms: - - User Name <local-part@domain> - local-part@domain - -When a name that is the argument to VRFY could identify more than one -mailbox, the server MAY either note the ambiguity or identify the -alternatives. In other words, any of the following are legitimate -response to VRFY: - - 553 User ambiguous - -or - - 553- Ambiguous; Possibilities are - 553-Joe Smith <jsmith@foo.com> - 553-Harry Smith <hsmith@foo.com> - 553 Melvin Smith <dweep@foo.com> - -or - - 553-Ambiguous; Possibilities - 553- <jsmith@foo.com> - 553- <hsmith@foo.com> - 553 <dweep@foo.com> - -Under normal circumstances, a client receiving a 553 reply would be -expected to expose the result to the user. Use of exactly the forms -given, and the "user ambiguous" or "ambiguous" keywords, possibly -supplemented by extended reply codes such as those described in -[RFC-REPLY], will facilitate automated translation into other languages -as needed. Of course, a client that was highly automated or that was -operating in another language than English, might choose to try to -translate the response, to return some other indication to the user -than the literal text of the reply, or to take some automated action -such as consulting a directory service for additional information -before reporting to the user. - -For the EXPN command, the string identifies a mailing list, and the -successful (i.e., 250) multiline response MAY include the full name of -the users and MUST give the mailboxes on the mailing list. - -In some hosts the distinction between a mailing list and an alias for a -single mailbox is a bit fuzzy, since a common data structure may hold -both types of entries, and it is possible to have mailing lists of one -mailbox. If a request is made to verify a mailing list, a positive -response MAY be given if a message so addressed would be delivered to -everyone on the list, otherwise an error SHOULD be reported (e.g., "550 -That is a mailing list, not a user" or "252 Unable to verify members of -mailing list"). If a request is made to expand a user name, the server -MAY return a positive response consisting of a list containing one -name, or an error MAY be reported (e.g., "550 That is a user name, not -a mailing list"). - -In the case of a successful multiline reply (normal for EXPN) exactly -one mailbox is to be specified on each line of the reply. The case of -an ambiguous request is discussed above. - -"User name" is a fuzzy term and has been used deliberately. An -implementation of the VRFY or EXPN commands MUST include at least -recognition of local mailboxes as "user names". However, since current -Internet practice often results in a single host handling mail for -multiple domains, hosts, especially hosts that provide this -functionality, SHOULD accept the "local-part@domain" form as a "user -name"; hosts MAY also choose to recognize other strings as "user names". - -The case of expanding a mailbox list requires a multiline reply, such -as: - - C: EXPN Example-People - S: 250-Jon Postel <Postel@isi.edu> - S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu> - S: 250 Sam Q. Smith <SQSmith@specific.generic.com> - -or - - C EXPN Executive-Washroom-List - S: 550 Access Denied to You. - -The character string arguments of the VRFY and EXPN commands cannot be -further restricted due to the variety of implementations of the user -name and mailbox list concepts. On some systems it may be appropriate -for the argument of the EXPN command to be a file name for a file -containing a mailing list, but again there are a variety of file naming -conventions in the Internet. Similarly, historical variations in what -is returned by these commands are such that the response SHOULD be -interpreted very carefully, if at all, and SHOULD generally only be -used for diagnostic purposes. - -3.5.2 VRFY Normal Response - -When normal (2yz or 551) responses are returned from a VRFY or EXPN -request, the reply MUST normally include the mailbox name. -"<local-part@domain>", where "domain" is a fully qualified domain name, -MUST appear in the syntax. In exceptional circumstances, free-form -text MAY be returned. In order to facilitate parsing by both computers -and people, addresses SHOULD appear in pointed brackets. When -addresses, rather than free-form debugging information, are returned, -EXPN and VRFY MUST return only valid domain addresses that are usable -in SMTP RCPT commands. Consequently, if an address implies delivery to -a program or other system, the mailbox name used to reach that target -MUST be given. Paths (explicit source routes) MUST NOT be returned by -VRFY or EXPN. - -Server implementations SHOULD support both VRFY and EXPN. For security -reasons, implementations MAY provide local installations a way to -disable either or both of these commands through configuration options -or the equivalent. When these commands are supported, they are not -required to work across relays when relaying is supported. Since they -were both optional in RFC 821, they MUST be listed as service -extensions in an EHLO response, if they are supported. - -3.5.3 Meaning of VRFY or EXPN Success Response - -A server MUST NOT return a 220 code in response to a VRFY or EXPN -command unless it has actually verified the address. In particular, a -server MUST NOT return 220 if all it has done is to verify that the -syntax given is valid. In that case, 502 (Command not implemented) or -500 (Syntax error, command unrecognized) SHOULD be returned. As stated -elsewhere, implementation (in the sense of actually validating -addresses and returning information) of VRFY and EXPN are strongly -recommended. Hence, implementations that return 500 or 502 for VRFY -are not in full compliance with this specification. - -There may be circumstances where an address appears to be valid but -cannot reasonably be verified in real time, particularly when a server -is acting as a mail exchanger for another server or domain. "Apparent -validity" in this case would normally involve at least syntax checking -and might involve verification that any domains specified were ones to -which the host expected to be able to relay mail. In these situations, -reply code 252 SHOULD be returned. These cases parallel the discussion -of RCPT verification discussed in section 2.1. Implementations -generally SHOULD be more aggressive about address verification in the -case of VRFY than in the case of RCPT, even if it takes a little longer -to do so. - -3.5.4 Semantics and Applications of EXPN - -EXPN is often very useful in debugging and understanding problems with -mailing lists and multiple-target-address aliases. Some systems have -attempted to use source expansion of mailing lists as a means of -eliminating duplicates. The propagation of aliasing systems with mail -on the Internet, for hosts (typically with MX and CNAME DNS records), -for mailboxes (various types of local host aliases), and in various -proxying arrangements, has made it nearly impossible for these -strategies to work, and mail systems SHOULD NOT attempt them. - -3.6 Domains - -Only resolvable, fully-qualified, domain names (FQDNs) are permitted -when domain names are used in SMTP. In other words, names that can be -resolved to MX RRs or A RRs (as discussed in section 5) are permitted, -as are CNAME RRs whose targets can be resolved, in turn, to MX or A -RRs. Local nicknames or unqualified names MUST NOT be used. There are -two exceptions to the rule requiring FQDNs: - - - The domain name given in the EHLO command MUST BE either a primary - host name (a domain name that resolves to an A RR) or, if the host - has no name, an address literal as described in section 4.1.1.1. - - - The reserved mailbox name "postmaster" may be used in a RCPT command - without domain qualification (see section 4.1.1.3) and MUST be - accepted if so used. - -3.7 Relaying - -In general, the availability of Mail eXchanger records in the domain -name system [RFC-DNS, RFC-974] makes the use of explicit source routes -in the Internet mail system unnecessary. Many historical problems with -their interpretation have made their use undesirable. SMTP clients -SHOULD NOT generate explicit source routes except under unusual -circumstances. SMTP servers MAY decline to act as mail relays or to -accept addresses that specify source routes. When route information is -encountered, SMTP servers are also permitted to ignore the route -information and simply send to the final destination specified as the -last element in the route and SHOULD do so. There has been an invalid -practice of using names that do not appear in the DNS as destination -names, with the senders counting on the intermediate hosts specified in -source routing to resolve any problems. If source routes are stripped, -this practice will cause failures. This is one of several reasons why -SMTP clients MUST NOT generate invalid source routes or depend on -serial resolution of names. - -When source routes are not used, the process described in RFC 821 for -constructing a reverse-path from the forward-path is not applicable and -the reverse-path at the time of delivery will simply be the address -that appeared in the MAIL command. - -A relay SMTP server is usually the target of a DNS MX record that -designates it, rather than the final delivery system. The relay server -may accept or reject the task of relaying the mail in the same way it -accepts or rejects mail for a local user. If it accepts the task, it -then becomes an SMTP client, establishes a transmission channel to the -next SMTP server specified in the DNS (according to the rules in -section 5), and sends it the mail. If it declines to relay mail to a -particular address for policy reasons, a 550 response SHOULD be -returned. - -Many mail-sending clients exist, especially in conjunction with -facilities that receive mail via POP3 or IMAP, that have limited -capability to support some of the requirements of this specification, -such as the ability to queue messages for subsequent delivery attempts. -For these clients, it is common practice to make private arrangements -to send all messages to a single server for processing and subsequent -distribution. SMTP, as specified here, is not ideally suited for this -role, and work is underway on standardized mail submission protocols -that might eventually supercede the current practices. In any event, -because these arrangements are private and fall outside the scope of -this specification, they are not described here. - -It is important to note that MX records can point to SMTP servers which -act as gateways into other environments, not just SMTP relays and final -delivery systems; see sections 3.8 and 5. - -If an SMTP server has accepted the task of relaying the mail and later -finds that the destination is incorrect or that the mail cannot be -delivered for some other reason, then it MUST construct an -"undeliverable mail" notification message and send it to the originator -of the undeliverable mail (as indicated by the reverse-path). Formats -specified for non-delivery reports by other standards (see, for -example, [RFC-NOTARY1]) SHOULD be used if possible. - -This notification message must be from the SMTP server at the relay -host or the host that first determines that delivery cannot be -accomplished. Of course, SMTP servers MUST NOT send notification -messages about problems transporting notification messages. One way to -prevent loops in error reporting is to specify a null reverse-path in -the MAIL command of a notification message. When such a message is -transmitted the reverse-path MUST be set to null (see section 4.5.5 for -additional discussion). A MAIL command with a null reverse-path -appears as follows: - - MAIL FROM:<> - -As discussed in section 2.4.1, a relay SMTP has no need to inspect or -act upon the headers or body of the message data and MUST NOT do so -except to add its own "Received:" header (section 4.4) and, optionally, -to attempt to detect looping in the mail system (see section 6.2). - -3.8 Mail Gatewaying - -While the relay function discussed above operates within the Internet -SMTP transport service environment, MX records or various forms of -explicit routing may require that an intermediate SMTP server perform a -translation function between one transport service and another. As -discussed in section 2.3.8, when such a system is at the boundary -between two transport service environments, we refer to it as a -"gateway" or "gateway SMTP". - -Gatewaying mail between different mail environments, such as different -mail formats and protocols, is complex and does not easily yield to -standardization. However, some general requirements may be given for a -gateway between the Internet and another mail environment. - -3.8.1 Header Fields in Gatewaying - -Header fields MAY be rewritten when necessary as messages are gatewayed -across mail environment boundaries. This may involve inspecting the -message body or interpreting the local-part of the destination address -in spite of the prohibitions in section 2.4.1 - -Other mail systems gatewayed to the Internet often use a subset of -RFC-822 headers or provide similar functionality with a different -syntax, but some of these mail systems do not have an equivalent to the -SMTP envelope. Therefore, when a message leaves the Internet -environment, it may be necessary to fold the SMTP envelope information -into the message header. A possible solution would be to create new -header fields to carry the envelope information (e.g., "X-SMTP-MAIL:" -and "X-SMTP-RCPT:"); however, this would require changes in mail -programs in foreign environments and might risk disclosure of private -information (see section 7.2). - -3.8.2 Received Lines in Gatewaying - -When forwarding a message into or out of the Internet environment, a -gateway MUST prepend a Received: line, but it MUST NOT alter in any way -a Received: line that is already in the header. - -"Received:" fields of messages originating from other environments may -not conform exactly to this specification. However, the most important -use of Received: lines is for debugging mail faults, and this debugging -can be severely hampered by well-meaning gateways that try to "fix" a -Received: line. As another consequence of trace fields arising in -non-SMTP environments, receiving systems MUST NOT reject mail based on -the format of a trace field and SHOULD be extremely robust in the light -of unexpected information or formats in those fields. - -The gateway SHOULD indicate the environment and protocol in the "via" -clauses of Received field(s) that it supplies. - -3.8.3 Addresses in Gatewaying - ->From the Internet side, the gateway SHOULD accept all valid address -formats in SMTP commands and in RFC-822 headers, and all valid RFC-822 -messages. Addresses and headers generated by gateways MUST conform to -applicable Internet standards (including this one and RFC-822). -Gateways are, of course, subject to the same rules for handling source -routes as those described for other SMTP systems in section 3.3. - -3.8.4 Other Header Fields in Gatewaying - -The gateway MUST ensure that all header fields of a message that it -forwards into the Internet meet the requirements for Internet mail. In -particular, all addresses in "From:", "To:", "Cc:", etc., fields MUST -be transformed (if necessary) to satisfy RFC-822 syntax, MUST reference -only fully-qualified domain names, and MUST be effective and useful for -sending replies. The translation algorithm used to convert mail from -the Internet protocols to another environment's protocol SHOULD ensure -that error messages from the foreign mail environment are delivered to -the return path from the SMTP envelope, not to the sender listed in the -"From:" field (or other fields) of the RFC-822 message. - -3.8.5 Envelopes in Gatewaying - -Similarly, when forwarding a message from another environment into the -Internet, the gateway SHOULD set the envelope return path in accordance -with an error message return address, if supplied by the foreign -environment. If the foreign environment has no equivalent concept, the -gateway must select and use a best approximation, with the message -originator's address as the default of last resort. - -3.9 Terminating Sessions and Connections - -An SMTP connection is terminated when the client sends a QUIT command. -The server responds with a positive reply code, after which it closes -the connection. - -An SMTP server MUST NOT intentionally close the connection except: - - - After receiving a QUIT command and responding with a 221 reply. - - - After detecting the need to shutdown the SMTP service and returning - a 421 response code. This response code can be issued after the - server receives any command or, if necessary, asynchronously from - command receipt (on the assumption that the client will receive it - after the next command is issued). - -In particular, a server that closes connections in response to commands -that are not understood is in violation of this specification. Servers -are expected to be tolerant of unknown commands, issuing a 500 reply -and awaiting further instructions from the client. - -An SMTP server which is forcibly shut down via external means SHOULD -attempt to send a line containing a 421 response code to the SMTP -client before exiting. The SMTP client will normally read the 421 -response code after sending its next command. - -SMTP clients that experience a connection close, reset, or other -communications failure due to circumstances not under their control (in -violation of the intent of this specification but sometimes -unavoidable) SHOULD, to maintain the robustness of the mail system, -treat the mail transaction as if a 451 response had been received and -act accordingly. - -3.10 Mailing Lists and Aliases - -An SMTP-capable host SHOULD support both the alias and the list models -of address expansion for multiple delivery. When a message is -delivered or forwarded to each address of an expanded list form, the -return address in the envelope ("MAIL FROM:") MUST be changed to be the -address of a person or other entity who administers the list. However, -in this case, the message header (see [MSGFMT]) MUST be left unchanged; -in particular, the "From" field of the message header is unaffected. - -An important mail facility is a mechanism for multi-destination -delivery of a single message, by transforming (or "expanding" or -"exploding") a pseudo-mailbox address into a list of destination -mailbox addresses. When a message is sent to such a pseudo-mailbox -(sometimes called an "exploder"), copies are forwarded or redistributed -to each mailbox in the expanded list. Servers SHOULD simply utilize -the addresses on the list; application of heuristics or other matching -rules to eliminate some addresses, such as that of the originator, is -strongly discouraged. We classify such a pseudo-mailbox as an "alias" -or a "list", depending upon the expansion rules. - -3.10.1 Alias - -To expand an alias, the recipient mailer simply replaces the -pseudo-mailbox address in the envelope with each of the expanded -addresses in turn; the rest of the envelope and the message body are -left unchanged. The message is then delivered or forwarded to each -expanded address. - -3.10.2 List - -A mailing list may be said to operate by "redistribution" rather than -by "forwarding". To expand a list, the recipient mailer replaces the -pseudo-mailbox address in the envelope with all of the expanded -addresses. The return address in the envelope is changed so that all -error messages generated by the final deliveries will be returned to a -list administrator, not to the message originator, who generally has no -control over the contents of the list and will typically find error -messages annoying. - - -4. The SMTP Specifications - -4.1 SMTP Commands - -4.1.1 Command Semantics and Syntax - -The SMTP commands define the mail transfer or the mail system function -requested by the user. SMTP commands are character strings terminated -by <CRLF>. The commands themselves are alphabetic characters -terminated by <SP> if parameters follow and <CRLF> otherwise. (In the -interest of improved interoperability, SMTP receivers are encouraged to -tolerate trailing white space before the terminating <CRLF>.) The -syntax of the local part of a mailbox must conform to receiver site -conventions and the syntax specified in section 4.1.2. The SMTP -commands are discussed below. The SMTP replies are discussed in -section 4.2. - -A mail transaction involves several data objects which are communicated -as arguments to different commands. The reverse-path is the argument -of the MAIL command, the forward-path is the argument of the RCPT -command, and the mail data is the argument of the DATA command. These -arguments or data objects must be transmitted and held pending the -confirmation communicated by the end of mail data indication which -finalizes the transaction. The model for this is that distinct buffers -are provided to hold the types of data objects, that is, there is a -reverse-path buffer, a forward-path buffer, and a mail data buffer. -Specific commands cause information to be appended to a specific -buffer, or cause one or more buffers to be cleared. - -Several commands (RSET, DATA, QUIT) are specified as not permitting -parameters. In the absence of specific extensions offered by the -server and accepted by the client, clients MUST NOT send such -parameters and servers SHOULD reject commands containing them as having -invalid syntax. - -4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) - -These commands are used to identify the SMTP client to the SMTP server. -The argument field contains the fully-qualified domain name of the SMTP -client if one is available. In situations in which the SMTP client -system does not have a meaningful domain name (e.g., when its address -is dynamically allocated and no reverse mapping record is available), -the client SHOULD send an address literal (see section 4.1.3), -optionally followed by information that will help to identify the -client system. - -The SMTP server identifies itself to the SMTP client in the connection -greeting reply and in the response to this command. - -A client SMTP SHOULD start an SMTP session by issuing the EHLO command. -If the SMTP server supports the SMTP service extensions it will give a -successful response, a failure response, or an error response. If the -SMTP server, in violation of this specification, does not support any -SMTP service extensions it will generate an error response. Older -client SMTP systems MAY, as discussed above, use HELO (as specified in -RFC 821) instead of EHLO, and servers MUST support the HELO command and -reply properly to it. In any event, a client MUST issue HELO or EHLO -before starting a mail transaction. - -These commands, and a "250 OK" reply to one of them, confirm that both -the SMTP client and the SMTP server are in the initial state, that is, -there is no transaction in progress and all state tables and buffers -are cleared. - -Syntax: - ehlo = "EHLO" SP Domain CRLF - helo = "HELO" SP Domain CRLF - -Normally, the response to EHLO will be a multiline reply. Each line of -the response contains a keyword and, optionally, one or more -parameters. The syntax for a positive response, using the ABNF -notation and low-level terminals of [ABNF], is: - - ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF ) - / ( "250-" domain [ SP ehlo-greet ] CRLF - *( "250-" ehlo-line CRLF ) - "250" SP ehlo-line CRLF ) - - ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127) - ; string of any characters other than CR or LF - - ehlo-line = ehlo-keyword *( SP ehlo-param ) - - ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") - ; additional syntax of ehlo-params depends on - ; ehlo-keyword - - ehlo-param = 1*(%d33-127) - ; any CHAR excluding <SP> and all - ; control characters (US-ASCII 0-31 inclusive) - -Although EHLO keywords may be specified in upper, lower, or mixed case, -they MUST always be recognized and processed in a case-insensitive -manner. This is simply an extension of practices specified in RFC 821 -and section 2.4.1. - -4.1.1.2 MAIL (MAIL) - -This command is used to initiate a mail transaction in which the mail -data is delivered to an SMTP server which may, in turn, deliver it to -one or more mailboxes or pass it on to another system (possibly using -SMTP). The argument field contains a reverse-path and may contain -optional parameters. In general, the MAIL command may be sent only -when no mail transaction is in progress, see section 4.1.4. - -The reverse-path consists of the sender mailbox. Historically, that -mailbox might optionally have been preceeded by a list of hosts, but -that behavior. In some types of reporting messages for which a reply -is likely to cause a mail loop (for example, mail delivery and -nondelivery notifications), the reverse-path may be null (see section -3.7). - -This command clears the reverse-path buffer, the forward-path buffer, -and the mail data buffer; and inserts the reverse-path information from -this command into the reverse-path buffer. - -If service extensions were negotiated, the MAIL command may also carry -parameters associated with a particular service extension. - -Syntax: - - "MAIL FROM:" ("<>" / Reverse-Path) - [SP Mail-parameters] CRLF - -4.1.1.3 RECIPIENT (RCPT) - -This command is used to identify an individual recipient of the mail -data; multiple recipients are specified by multiple use of this -command. The argument field contains a forward-path and may contain -optional parameters. - -The forward-path normally consists of the required destination mailbox. -Sending systems SHOULD not generate the optional list of hosts known as -a source route. Receiving systems MUST recognize source route syntax -but SHOULD strip off the source route specification and utilize the -domain name associated with the mailbox as if the source route had not -been provided. - -Similarly, relay hosts SHOULD strip or ignore source routes, and names -MUST NOT be copied into the reverse-path. When mail reaches its -ultimate destination (the forward-path contains only a destination -mailbox), the SMTP server inserts it into the destination mailbox in -accordance with its host mail conventions. - -For example, mail received at relay host xyz.com with envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> - -will normally be sent directly on to host d.bar.org with envelope -commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<userc@d.bar.org> - -As provided in appendix C, xyz.com MAY also choose to relay the message -to hosta.int, using the envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> - -or to jkl.org, using the envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@jkl.org:userc@d.bar.org> - -Of course, since hosts are not required to relay mail at all, xyz.com -may also reject the message entirely when the RCPT command is received, -using a 550 code (since this is a "policy reason"). - -If service extensions were negotiated, the RCPT command may also carry -parameters associated with a particular service extension offered by -the server. The client MUST NOT transmit parameters other than those -associated with a service extension offered by the server in its EHLO -response. - -Syntax: - "RCPT TO:" ("<Postmaster@" domain ">" / Forward-Path) - [SP Rcpt-parameters] CRLF - -4.1.1.4 DATA (DATA) - -The receiver treats the lines (strings ending in <CRLF> sequences, as -described in section 2.3.7) following the command as mail data from the -sender. This command causes the mail data to be appended to the mail -data buffer. The mail data may contain any of the 128 ASCII character -codes, although experience has indicated that use of control characters -other than SP, HT, CR, and LF (especially the ASCII "Null" character) -may cause problems and SHOULD be avoided when possible. - -The mail data is terminated by a line containing only a period, that -is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2). This -is the end of mail data indication. Note that the first <CRLF> of this -terminating sequence is also the <CRLF> that ends the final line of the -data (message text) or, if there was no data, ends the DATA command -itself. An extra <CRLF> MUST NOT be added, as that would cause an -empty line to be added to the message. The only exception to this rule -would arise if the message body were passed to the originating -SMTP-sender with a final "line" that did not end in <CRLF>; in that -case, the originating SMTP system MUST either reject the message as -invalid or add <CRLF> in order to have the receiving SMTP server -recognize the "end of data" condition. - -The custom of accepting lines ending only in <LF>, as a concession to -non-conforming behavior on the part of some UNIX systems, has proven to -cause more interoperability problems than it solves, and SMTP server -systems MUST NOT do this, even in the name of improved robustness. In -particular, the sequence "<LF>.<LF>" (bare line feeds, without carriage -returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end -of mail data indication. - -Receipt of the end of mail data indication requires the server to -process the stored mail transaction information. This processing -consumes the information in the reverse-path buffer, the forward-path -buffer, and the mail data buffer, and on the completion of this command -these buffers are cleared. If the processing is successful, the -receiver MUST send an OK reply. If the processing fails the receiver -MUST send a failure reply. The SMTP model does not allow for partial -failures at this point: either the message is accepted by the server -for delivery and a positive response is returned or it is not accepted -and a failure reply is returned. Errors that are diagnosed -subsequently MUST be reported in a mail message, as discussed in -section 4.4 In sending a positive completion reply to the end of data -indication, the receiver takes full responsibility for the message (see -section 6.1). - -When the SMTP server accepts a message either for relaying or for final -delivery, it inserts a trace record (also referred to interchangeably -as a "time stamp line" or "Received" line) at the top of the mail data. -This trace record indicates the identity of the host that sent the -message, the identity of the host that received the message (and is -inserting this time stamp), and the date and time the message was -received. Relayed messages will have multiple time stamp lines. -Details for formation of these lines, including their syntax, is -specified in section 4.4. - -Syntax: - "DATA" CRLF - - -4.1.1.5 RESET (RSET) - -This command specifies that the current mail transaction will be -aborted. Any stored sender, recipients, and mail data MUST be -discarded, and all buffers and state tables cleared. The receiver MUST -send a "250 OK" reply to a RSET command with no arguments. A reset -command may be issued by the client at any time. It is effectively -equivalent to a NOOP if issued immediately after EHLO, before EHLO is -issued in the session, after an end-of-data indicator has been sent and -acknowledged, or immediately before a QUIT. In other situations, it -restores the state to that immediately after the most recent EHLO. An -SMTP server MUST NOT close the connection as the result of receiving a -RSET; that action is reserved for QUIT (see section 4.1.1.10). - -Since EHLO implies some additional processing and response by the -server, RSET will normally be more efficient than reissuing that -command, even though the formal semantics are the same. - -There are circumstances, contrary to the intent of this specification, -in which an SMTP server may receive an indication that the underlying -TCP connection has been closed or reset. To preserve the robustness of -the mail system, SMTP servers SHOULD be prepared for this condition and -SHOULD treat it as if a QUIT had been received before the connection -disappeared. - -Syntax: - "RSET" CRLF - - -4.1.1.6 VERIFY (VRFY) - -This command asks the receiver to confirm that the argument identifies -a user or mailbox. If it is a user name, information is returned as -specified in section 3.5. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -Syntax: - "VRFY" SP String CRLF - -4.1.1.7 EXPAND (EXPN) - -This command asks the receiver to confirm that the argument identifies -a mailing list, and if so, to return the membership of that list. If -the command is successful, a reply is returned containing information -as described in section 3.5. This reply will have multiple lines -except in the trivial case of a one-member list. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -Syntax: - "EXPN" SP String CRLF - -4.1.1.8 HELP (HELP) - -This command causes the server to send helpful information to the -client. The command MAY take an argument (e.g., any command name) and -return more specific information as a response. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -SMTP servers SHOULD support HELP without arguments and MAY support it -with arguments. - -Syntax: - "HELP" [ SP String ] CRLF - -4.1.1.9 NOOP (NOOP) - -This command does not affect any parameters or previously entered -commands. It specifies no action other than that the receiver send an -OK reply. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. If a parameter string is specified, -servers SHOULD ignore it. - -Syntax: - "NOOP" [ SP String ] CRLF - - -4.1.1.10 QUIT (QUIT) - -This command specifies that the receiver MUST send an OK reply, and -then close the transmission channel. - -The receiver MUST NOT intentionally close the transmission channel -until it receives and replies to a QUIT command (even if there was an -error). The sender MUST NOT intentionally close the transmission -channel until it sends a QUIT command and SHOULD wait until it receives -the reply (even if there was an error response to a previous command). -If the connection is closed prematurely due to violations of the above -or system or network failure, the server MUST cancel any pending -transaction, but not undo any previously completed transaction, and -generally MUST act as if the command or transaction in progress had -received a temporary error (i.e., a 4yz response). - -Syntax: - "QUIT" CRLF - - -4.1.2 Lower-level Syntax - -The syntax of the argument fields of the above commands (using the -syntax specified in [ABNF] where applicable) is given below. Some of -the productions given below are used only in conjunction with source -routes as described in appendix C. Terminals not defined in this -document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the -"core" syntax (section 6) of [ABNF] or in the syntax of [MSGFMT]. - - Reverse-path = Path - Forward-path = Path - Path = "<" [ A-d-l ":" ] Mailbox ">" - A-d-l = At-domain *( "," A-d-l ) - ; Note that this form, the so-called "source route", - ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be - ; ignored. - At-domain = "@" domain - Mail-parameters = esmtp-param *(SP esmtp-param) - Rcpt-parameters = esmtp-param *(SP esmtp-param) - esmtp-param = esmtp-keyword ["=" esmtp-value] - esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") - esmtp-value = 1*(%d33-60 / %d62-127) - ; any CHAR excluding "=", SP, and control - ; characters - Keyword = Ldh-str - Argument = Atom - Domain = (sub-domain 1*("." sub-domain)) / address-literal - sub-domain = Let-dig [Ldh-str] - - address-literal = "[" IPv4-address-literal / - IPv6-address-literal / - General-address-literal "]" - ; See section 4.1.3 - - Mailbox = Local-part "@" Domain - - Local-part = Dot-string / Quoted-string - ; MAY be case-sensitive - - Dot-string = Atom [ "." Atom ] - - Atom = 1*atext - - Quoted-string = DQUOTE *qcontent DQUOTE - - String = Atom / Quoted-string - - -While the above definition for Local-part is relatively permissive, for -maximum interoperability, a host that expects to receive mail SHOULD -avoid defining mailboxes where the Local-part requires (or uses) the -Quoted-string form or where the Local-part is case-sensitive. For any -purposes that require generating or comparing Local-parts (e.g., to -specific mailbox names), all quoted forms MUST be treated as equivalent -and the sending system SHOULD transmit the form that uses the minimum -quoting possible. - -Systems MUST NOT define mailboxes in such a way as to require the use -in SMTP of non-ASCII characters (octets with the high order bit set to -one) or ASCII "control characters" (decimal value 0-31 and 127). These -characters MUST NOT be used in MAIL or RCPT commands or other commands -that require mailbox names. - -Note that the backslash, "\", is a quote character, which is used to -indicate that the next character is to be used literally (instead of -its normal interpretation). For example, "Joe\,Smith" indicates a -single nine character user field with the comma being the fourth -character of the field. - -To promote interoperability and consistent with long-standing guidance -about conservative use of the DNS in naming and applications (e.g., see -section 2.3.1 of the base DNS document [RFC-1015]), characters outside -the set of alphas, digits, and hyphen MUST NOT appear in domain name -labels for SMTP clients or servers. In particular, the underscore -character is not permitted. SMTP servers that receive a command in -which invalid character codes have been employed, and for which there -are no other reasons for rejection, MUST reject that command with a 501 -response. - -4.1.3 Address Literals - -Sometimes a host is not known to the domain name system and -communication (and, in particular, communication to report and repair -the error) is blocked. To bypass this barrier a special literal form -of the address is allowed as an alternative to a domain name. For IPv4 -addresses, this form uses four small decimal integers separated by dots -and enclosed by brackets such as [123.255.37.2], which indicates an -(IPv4) Internet Address in sequence-of-octets form. For IPv6 and other -forms of addressing that might eventually be standardized, the form -consists of a standardized "tag" that identifies the address syntax, a -space, and the address itself, in a format specified as part of the -IPv6 standards [IPv6AddrSpec]. - -Specifically: - - IPv4-address-literal = Snum 3("." Snum) - IPv6-address-literal = "IPv6:" IPv6-addr - General-address-literal = Standardized-tag ":" 1*dcontent - Standardized-tag = Ldh-str - ; MUST be specified in a standards-track RFC - ; and registered with IANA - - Snum = 1*3DIGIT ; representing a decimal integer - ; value in the range 0 through 255 - Let-dig = ALPHA / DIGIT - Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig - - IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp - IPv6-hex = 1*4HEXDIG - IPv6-full = IPv6-hex 7(":" IPv6-hex) - IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":" - IPv6-hex)] - ; The "::" represents at least 2 16-bit groups of zeros - ; No more than 6 groups in addition to the "::" may be - ; present - IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal - IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::" - [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal - ; The "::" represents at least 2 16-bit groups of zeros - ; No more than 4 groups in addition to the "::" and - ; IPv4-address-literal may be present - - -4.1.4 Order of Commands - -There are restrictions on the order in which these commands may be used. - -A session that will contain mail transactions MUST first be initialized -by the use of the EHLO command. An SMTP server SHOULD accept commands -for non-mail transactions (e.g., VRFY or EXPN) without this -initialization. - -An EHLO command MAY be issued by a client later in the session. If it -is issued after the session begins, the SMTP server MUST clear all -buffers and reset the state exactly as if a RSET command had been -issued. In other words, the sequence of RSET followed immediately by -EHLO is redundant, but not harmful other than in the performance cost -of executing unnecessary commands. - -If the EHLO command is not acceptable to the SMTP server, 501, 500, or -502 failure replies MUST be returned as appropriate. The SMTP server -MUST stay in the same state after transmitting these replies that it -was in before the EHLO was received. - -The SMTP client MUST, if possible, ensure that the domain parameter to -the EHLO command is a valid principal host name (not a CNAME or MX -name) for its host. If this is not possible (e.g., when the client's -address is dynamically assigned and the client does not have an obvious -name), an address literal SHOULD be substituted for the domain name and -supplemental information provided that will assist in identifying the -client. - -An SMTP server MAY verify that the domain name parameter in the EHLO -command actually corresponds to the IP address of the client. However, -the server MUST NOT refuse to accept a message for this reason if the -verification fails: the information about verification failure is for -logging and tracing only. - -The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time -during a session, or without previously initializing a session. SMTP -servers SHOULD process these normally (that is, not return a 503 code) -even if no EHLO command has yet been received; clients SHOULD open a -session with EHLO before sending these commands. - -If these rules are followed, the example in RFC 821 that shows "550 -access denied to you" in response to an EXPN command is incorrect -unless an EHLO command precedes the EXPN or the denial of access is -based on the client's IP address or other authentication or -authorization-determining mechanisms. - -The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins -a mail transaction. Once started, a mail transaction consists of a -transaction beginning command, one or more RCPT commands, and a DATA -command, in that order. A mail transaction may be aborted by the RSET -(or a new EHLO) command. There may be zero or more transactions in a -session. MAIL (or SEND, SOML, or SAML) MUST NOT be sent if a mail -transaction is already open, i.e., it should be sent only if no mail -transaction had been started in the session, or it the previous one -successfully concluded with a successful DATA command, or if the -previous one was aborted with a RSET. - -If the transaction beginning command argument is not acceptable, a 501 -failure reply MUST be returned and the SMTP server MUST stay in the -same state. If the commands in a transaction are out of order to the -degree that they cannot be processed by the server, a 503 failure reply -MUST be returned and the SMTP server MUST stay in the same state. - -The last command in a session MUST be the QUIT command. The QUIT -command cannot be used at any other time in a session, but SHOULD be -used by the client SMTP to request connection closure, even when no -session opening command was sent and accepted. - -4.1.5 Private-use Commands - -As specified in section 2.2.2, commands starting in "X" may be used by -bilateral agreement between the client (sending) and server (receiving) -SMTP agents. An SMTP server that does not recognize such a command is -expected to reply with "500 Command not recognized". An extended SMTP -server MAY list the feature names associated with these private -commands in the response to the EHLO command. - -Commands sent or accepted by SMTP systems that do not start with "X" -MUST conform to the requirements of section 2.2.2. - - -4.2 SMTP Replies - -Replies to SMTP commands serve to ensure the synchronization of -requests and actions in the process of mail transfer and to guarantee -that the SMTP client always knows the state of the SMTP server. Every -command MUST generate exactly one reply. - -The details of the command-reply sequence are described in section 4.3. - -An SMTP reply consists of a three digit number (transmitted as three -alphanumeric characters) followed by some text unless specified -otherwise in this document. The number is for use by automata to -determine what state to enter next; the text is for the human user. -The three digits contain enough encoded information that the SMTP -client need not examine the text and may either discard it or pass it -on to the user, as appropriate. Exceptions are as noted elsewhere in -this document. In particular, the 220, 221, 251, 421, and 551 reply -codes are associated with message text that must be parsed and -interpreted by machines. In the general case, the text may be receiver -dependent and context dependent, so there are likely to be varying -texts for each reply code. A discussion of the theory of reply codes -is given in section 4.2.1. Formally, a reply is defined to be the -sequence: a three-digit code, <SP>, one line of text, and <CRLF>, or a -multiline reply (as defined in section 4.2.1). Since, in violation of -this specification, the text is sometimes not sent, clients which do -not receive it SHOULD be prepared to process the code alone (with or -without a trailing space character). Only the EHLO, EXPN, and HELP -commands are expected to result in multiline replies in normal -circumstances, however, multiline replies are allowed for any command. - -In ABNF, server responses are: - - Greeting = "220 " Domain [ SP text ] CRLF - Reply-line = Reply-code [ SP text ] CRLF - -where "Greeting" appears only in the 220 response that announces that -the server is opening its part of the connection. - -An SMTP server SHOULD send only the reply codes listed in this -document. An SMTP server SHOULD use the text shown in the examples -whenever appropriate. - -An SMTP client MUST determine its actions only by the reply code, not -by the text (except for 251 and 551 and, if necessary, 220, 221, and -421 replies); in the general case, any text, including no text at all -(although senders SHOULD NOT send bare codes), MUST be acceptable. The -space (blank) following the reply code is considered part of the text. -Whenever possible, a receiver-SMTP SHOULD test the first digit -(severity indication) of the reply code. - -The list of codes that appears below MUST NOT be construed as -permanent. While the addition of new codes should be a rare and -significant activity, with supplemental information in the textual part -of the response being preferred, new codes may be added as the result -of new Standards or Standards-track specifications. Consequently, a -sender-SMTP MUST be prepared to handle codes not specified in this -document and MUST do so by interpreting the first digit only. - -4.2.1 Reply Code Severities and Theory - -The three digits of the reply each have a special significance. The -first digit denotes whether the response is good, bad or incomplete. An -unsophisticated SMTP client, or one that receives an unexpected code, -will be able to determine its next action (proceed as planned, redo, -retrench, etc.) by examining this first digit. An SMTP client that -wants to know approximately what kind of error occurred (e.g., mail -system error, command syntax error) may examine the second digit. The -third digit and any supplemental information that may be present is -reserved for the finest gradation of information. - -There are five values for the first digit of the reply code: - -1yz Positive Preliminary reply - The command has been accepted, but the requested action is being - held in abeyance, pending confirmation of the information in this - reply. The SMTP client should send another command specifying - whether to continue or abort the action. Note: unextended SMTP does - not have any commands that allow this type of reply, and so does not - have continue or abort commands. - -2yz Positive Completion reply - The requested action has been successfully completed. A new request - may be initiated. - -3yz Positive Intermediate reply - The command has been accepted, but the requested action is being - held in abeyance, pending receipt of further information. The SMTP - client should send another command specifying this information. - This reply is used in command sequence groups (i.e., in DATA). - -4yz Transient Negative Completion reply - The command was not accepted, and the requested action did not - occur. However, the error condition is temporary and the action may - be requested again. The sender should return to the beginning of - the command sequence (if any). It is difficult to assign a meaning - to "transient" when two different sites (receiver- and sender- SMTP - agents) must agree on the interpretation. Each reply in this - category might have a different time value, but the SMTP client is - encouraged to try again. A rule of thumb to determine whether a - reply fits into the 4yz or the 5yz category (see below) is that - replies are 4yz if they can be successful if repeated without any - change in command form or in properties of the sender or receiver - (that is, the command is repeated identically and the receiver does - not put up a new implementation.) - -5yz Permanent Negative Completion reply - The command was not accepted and the requested action did not occur. - The SMTP client is discouraged from repeating the exact request (in - the same sequence). Even some "permanent" error conditions can be - corrected, so the human user may want to direct the SMTP client to - reinitiate the command sequence by direct action at some point in - the future (e.g., after the spelling has been changed, or the user - has altered the account status). - -The second digit encodes responses in specific categories: - -x0z Syntax: These replies refer to syntax errors, syntactically - correct commands that do not fit any functional category, and - unimplemented or superfluous commands. - -x1z Information: These are replies to requests for information, such - as status or help. - -x2z Connections: These are replies referring to the transmission - channel. - -x3z Unspecified. - -x4z Unspecified. - -x5z Mail system: These replies indicate the status of the receiver - mail system vis-a-vis the requested transfer or other mail system - action. - -The third digit gives a finer gradation of meaning in each category -specified by the second digit. The list of replies illustrates this. -Each reply text is recommended rather than mandatory, and may even -change according to the command with which it is associated. On the -other hand, the reply codes must strictly follow the specifications in -this section. Receiver implementations should not invent new codes for -slightly different situations from the ones described here, but rather -adapt codes already defined. - -For example, a command such as NOOP, whose successful execution does -not offer the SMTP client any new information, will return a 250 reply. -The reply is 502 when the command requests an unimplemented -non-site-specific action. A refinement of that is the 504 reply for a -command that is implemented, but that requests an unimplemented -parameter. - -The reply text may be longer than a single line; in these cases the -complete text must be marked so the SMTP client knows when it can stop -reading the reply. This requires a special format to indicate a -multiple line reply. - -The format for multiline replies requires that every line, except the -last, begin with the reply code, followed immediately by a hyphen, "-" -(also known as minus), followed by text. The last line will begin with -the reply code, followed immediately by <SP>, optionally some text, and -<CRLF>. As noted above, servers SHOULD send the <SP> if subsequent -text is not sent, but clients MUST be prepared for it to be omitted. - -For example: - 123-First line - 123-Second line - 123-234 text beginning with numbers - 123 The last line - -In many cases the SMTP client then simply needs to search for the reply -code followed by <SP> at the beginning of a line, and ignore all -preceding lines. In a few cases, there is important data for the -client in the reply "text". The client will be able to identify these -cases from the current context. - -4.2.2 Reply Codes by Function Groups - - 500 Syntax error, command unrecognized - (This may include errors such as command line too long) - 501 Syntax error in parameters or arguments - 502 Command not implemented (see section 4.2.4) - 503 Bad sequence of commands - 504 Command parameter not implemented - - 211 System status, or system help reply - 214 Help message - (Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user) - - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 421 <domain> Service not available, closing transmission channel - (This may be a reply to any command if the service knows it - must shut down) - - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - (See section 3.4) - 252 Cannot VRFY user, but will accept message and attempt - delivery - (See section 3.5.3) - 450 Requested mail action not taken: mailbox unavailable - (e.g., mailbox busy) - 550 Requested action not taken: mailbox unavailable - (e.g., mailbox not found, no access, or command rejected - for policy reasons) - 451 Requested action aborted: error in processing - 551 User not local; please try <forward-path> - (See section 3.4) - 452 Requested action not taken: insufficient system storage - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - (e.g., mailbox syntax incorrect) - 354 Start mail input; end with <CRLF>.<CRLF> - 554 Transaction failed (Or, in the case of a connection-opening - response, "No SMTP service here") - -4.2.3 Reply Codes in Numeric Order - - 211 System status, or system help reply - 214 Help message - (Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user) - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - (See section 3.4) - 252 Cannot VRFY user, but will accept message and attempt - delivery - (See section 3.5.3) - - 354 Start mail input; end with <CRLF>.<CRLF> - - 421 <domain> Service not available, closing transmission channel - (This may be a reply to any command if the service knows it - must shut down) - 450 Requested mail action not taken: mailbox unavailable - (e.g., mailbox busy) - 451 Requested action aborted: local error in processing - 452 Requested action not taken: insufficient system storage - - 500 Syntax error, command unrecognized - (This may include errors such as command line too long) - 501 Syntax error in parameters or arguments - 502 Command not implemented (see section 4.2.4) - 503 Bad sequence of commands - 504 Command parameter not implemented - 550 Requested action not taken: mailbox unavailable - (e.g., mailbox not found, no access, or command rejected - for policy reasons) - 551 User not local; please try <forward-path> - (See section 3.4) - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - (e.g., mailbox syntax incorrect) - 554 Transaction failed (Or, in the case of a connection-opening - response, "No SMTP service here") - -4.2.4 Reply Code 502 - -Questions have been raised as to when reply code 502 (Command not -implemented) SHOULD be returned in preference to other codes. 502 -SHOULD be used when the command is actually recognized by the SMTP -server, but not implemented. If the command is not recognized, code -500 SHOULD be returned. Extended SMTP systems MUST NOT list -capabilities in response to EHLO for which they will return 502 (or -500) replies. - -4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> - -When an SMTP server returns a positive completion status (2yz code) -after the DATA command is completed with <CRLF>.<CRLF>, it accepts -responsibility for: - - - delivering the message (if the recipient mailbox exists), or - - - if attempts to deliver the message fail due to transient conditions, - retrying delivery some reasonable number of times at intervals as - specified in section 4.5.4. - - - if attempts to deliver the message fail due to permanent conditions, - or if repeated attempts to deliver the message fail due to transient - conditions, returning appropriate notification to the sender of the - original message (using the address in the SMTP MAIL command). - -When an SMTP server returns a transient error completion status (4yz) -code after the DATA command is completed with <CRLF>.<CRLF>, it MUST -NOT make any further attempt to deliver that message. The SMTP client -retains responsibility for delivery of that message and may either -return it to the user or requeue it for a subsequent attempt (see -section 4.5.4.1). The sending user SHOULD be able to interpret the -return of a transient or permanent failure status as a non-delivery -indication. - -When an SMTP server returns a permanent error status (5yz) code after -the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make any -further attempt to deliver the message. As with temporary error status -codes, the SMTP client retains responsibility for the message, but -SHOULD not again attempt delivery to the same server without user -review and intervention of the message. - -4.3 Sequencing of Commands and Replies - -4.3.1 Sequencing Overview - -The communication between the sender and receiver is an alternating -dialogue, controlled by the sender. As such, the sender issues a -command and the receiver responds with a reply. Unless other -arrangements are negotiated through service extensions, the sender MUST -wait for this response before sending further commands. - -One important reply is the connection greeting. Normally, a receiver -will send a 220 "Service ready" reply when the connection is completed. -The sender SHOULD wait for this greeting message before sending any -commands. - -Note: all the greeting-type replies have the official name (the -fully-qualified primary domain name) of the server host as the first -word following the reply code. Sometimes the host will have no -meaningful name. See 4.1.3 for a discussion of alternatives in these -situations. - -For example, - 220 ISIF.USC.EDU Service ready -or - 220 mail.foo.com SuperSMTP v 6.1.2 Service ready -or - 220 [10.0.0.1] Clueless host service ready - -The table below lists alternative success and failure replies for each -command. These SHOULD be strictly adhered to: a receiver may -substitute text in the replies, but the meaning and action implied by -the code numbers and by the specific command reply sequence cannot be -altered. - -4.3.2 Command-Reply Sequences - -Each command is listed with its usual possible replies. The prefixes -used before the possible replies are "I" for intermediate, "S" for -success, and "E" for error. Since some servers may generate other -replies under special circumstances, and to allow for future extension, -SMTP clients SHOULD, when possible, interpret only the first digit of -the reply and MUST be prepared to deal with unrecognized reply codes by -interpreting the first digit only. Unless extended using the -mechanisms described in section 2.2, SMTP servers MUST NOT transmit -reply codes to an SMTP client that are other than three digits or that -do not start in a digit between 2 and 5 inclusive. - -These sequencing rules and, in principle, the codes themselves, can be -extended or modified by SMTP extensions offered by the server and -accepted (requested) by the client. - -In addition to the codes listed below, any SMTP command can return any -of the following codes if the corresponding unusual circumstances are -encountered: - -500 For the "command line too long" case or if the command name was not - recognized. Note that producing a "command not recognized" error in - response to the required subset of these commands is a violation of - this specification. - -501 Syntax error in command or arguments. In order to provide for - future extensions, commands that are specified in this document as - not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 - message if arguments are supplied in the absence of EHLO-advertised - extensions. - -421 Service shutting down and closing transmission channel - -Specific sequences are: - -CONNECTION ESTABLISHMENT - S: 220 - E: 554 -EHLO or HELO - S: 250 - E: 504, 550 -MAIL - S: 250 - E: 552, 451, 452, 550, 553, 503 -RCPT - S: 250, 251 (but see section 3.4 for discussion of 251) - E: 550, 551, 552, 553, 450, 451, 452, 503, 550 -DATA - I: 354 -> data -> S: 250 - E: 552, 554, 451, 452 - E: 451, 554, 503 -RSET - S: 250 -VRFY - S: 250, 251, 252 - E: 550, 551, 553, 502, 504 -EXPN - S: 250, 252 - E: 550, 500, 502, 504 -HELP - S: 211, 214 - E: 502, 504 -NOOP - S: 250 -QUIT - S: 221 - -4.4 Trace Information - -When an SMTP server receives a message for delivery or further -processing, it MUST insert trace ("time stamp" or "Received") -information at the beginning of the message content, as discussed in -section 4.1.1.4. - -This line MUST be structured as follows: - - - The FROM field, which MUST be supplied in an SMTP environment, - SHOULD contain both (1) the name of the source host as presented in - the EHLO command and (2) an address literal containing the IP - address of the source, determined from the TCP connection. - - - The ID field MAY contain an "@" as suggested in RFC-822, but this is - not required. - - - The FOR field MAY contain a list of <path> entries when multiple - RCPT commands have been given. This may raise some security issues - and is usually not desirable; see section 7.2. - -An Internet mail program MUST NOT change a Received: line that was -previously added to the message header. SMTP servers MUST prepend -Received lines to messages; they MUST NOT change the order of existing -lines or insert Received lines in any other location. - -As the Internet grows, comparability of Received fields is important -for detecting problems, especially slow relays. SMTP servers that -create Received fields SHOULD use explicit offsets in the dates (e.g., --0800), rather than time zone names of any type. Local time (with an -offset) is preferred to UT when feasible. This formulation allows -slightly more information about local circumstances to be specified. -If UT is needed, the receiver need merely do some simple arithmetic to -convert the values. Use of UT loses information about the time -zone-location of the server. If a time zone name is used, it SHOULD be -included in a comment. - -When the delivery SMTP server makes the "final delivery" of a message, -it inserts a return-path line at the beginning of the mail data. This -use of return-path is required; mail systems MUST support it. The -return-path line preserves the information in the <reverse-path> from -the MAIL command. Here, final delivery means the message has left the -SMTP enviroment. Normally, this would mean it had been delivered to -the destination user or an associated mail drop, but in some cases it -may be further processed and transmitted by another mail system. - -It is possible for the mailbox in the return path to be different from -the actual sender's mailbox, for example, if error responses are to be -delivered to a special error handling mailbox rather than to the -message sender. When mailing lists are involved, this arrangement is -common and useful as a means of directing errors to the list maintainer -rather than the message originator. - -The text above implies that the final mail data will begin with a -return path line, followed by one or more time stamp lines. These -lines will be followed by the mail data headers and body [MSGFMT]. - -It is sometimes difficult for an SMTP server to determine whether or -not it is making final delivery since forwarding or other operations -may occur after the message is accepted for delivery. Consequently, -any further (forwarding, gateway, or relay) systems MAY remove the -return path and rebuild the MAIL command as needed to ensure that -exactly one such line appears in a delivered message. - -A message-originating SMTP system SHOULD NOT send a message that -already contains a Return-path header. SMTP servers performing a relay -function MUST NOT inspect the message data, and especially not to the -extent needed to determine if Return-path headers are present. SMTP -servers making final delivery MAY remove Return-path headers before -adding their own. - -The primary purpose of the Return-path is to designate the address to -which messages indicating non-delivery or other mail system failures -are to be sent. For this to be unambiguous, exactly one return path -SHOULD be present when the message is delivered. Systems using RFC 822 -syntax with non-SMTP transports SHOULD designate an unambiguous -address, associated with the transport envelope, to which error reports -(e.g., non-delivery messages) should be sent. - -Historical note: Text in RFC 822 that appears to contradict the use of -the Return-path header (or the envelope reverse path address from the -MAIL command) as the destination for error messages is not applicable -on the Internet. The reverse path address (as copied into the -Return-path) MUST be used as the target of any mail containing delivery -error messages. - -In particular: - - - a gateway from SMTP->elsewhere SHOULD insert a return-path header, - unless it is known that the "elsewhere" transport also uses Internet - domain addresses and maintains the envelope sender address - separately. - - - a gateway from elsewhere->SMTP SHOULD delete any return-path header - present in the message, and either copy that information to the SMTP - envelope or combine it with information present in the envelope of - the other transport system to construct the reverse path argument to - the MAIL command in the SMTP envelope. - -The server must give special treatment to cases in which the processing -following the end of mail data indication is only partially successful. -This could happen if, after accepting several recipients and the mail -data, the SMTP server finds that the mail data could be successfully -delivered to some, but not all, of the recipients. In such cases, the -response to the DATA command MUST be an OK reply. However, the SMTP -server MUST compose and send an "undeliverable mail" notification -message to the originator of the message. - -A single notification listing all of the failed recipients or separate -notification messages MUST be sent for each failed recipient. For -economy of processing by the sender, the former is preferred when -possible. All undeliverable mail notification messages are sent using -the MAIL command (even if they result from processing the obsolete -SEND, SOML, or SAML commands) and use a null return path as discussed -in section 3.7. - -The time stamp line and the return path line are formally defined as -follows: - - Return-path-line = "Return-Path:" FWS Reverse-path <CRLF> - - Time-stamp-line = "Received:" FWS Stamp <CRLF> - - Stamp = From-domain By-domain Opt-info ";" FWS Daytime - - From-domain = "FROM" FWS Extended-Domain CFWS - - By-domain = "BY" FWS Extended-Domain CFWS - - Extended-Domain = Domain / - ( Domain FWS "(" TCP-info ")" ) / - ( Address-literal FWS "(" TCP-info ")" - TCP-info = Address-literal / ( Domain FWS Address-literal ) - ; Information derived by server from TCP connection - not client EHLO. - - Opt-info = [Via] [With] [ID] [For] - - Via = "VIA" FWS Link CFWS - - With = "WITH" FWS Protocol CFWS - - ID = "ID" FWS String / msg-id CFWS - - For = "FOR" FWS 1*( Path / Mailbox ) CFWS - - Link = "TCP" / Addtl-Link - Addtl-Link = Atom ; Additional standard names for links are - registered with the Internet Assigned - Numbers Authority (IANA). "Via" is - primarily of value with non-Internet - transports. - SMTP servers SHOULD NOT use unregistered - names. - Protocol = "ESMTP" / "SMTP" / Attdl-Protocol - Attdl-Protocol = Atom ; Additional standard names for protocols - are registered with the Internet Assigned - Numbers Authority (IANA). SMTP servers - SHOULD NOT use unregistered names. - - Daytime = FWS [ day-of-week "," FWS ] Date FWS Time - - Date = DD FWS Mon FWS YYYY - ; Note that the earlier form, which permits two-digit years, - ; has been deprecated. SMTP systems MUST use four-digit - ; years. - - Time = HH ":" MM ":" SS FWS Zone - - DD = 1*2Digit ; the one or two digit integer day of the - month in the range 1 to 31. - - Mon = "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | - "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" - - YYYY = 4*4Digit ; the four decimal integer year in the range - 0000 to 9999. - - HH = 2*2Digit ; the two decimal digit hour of the day in - the range 00 to 24. - - MM = 2*2Digit ; the two decimal digit integer minute of - the hour in the range 00 to 59. - - SS = 2*2Digit [ "." 1*Digit ] - ; the two decimal digit integer second of - the minute in the range 00 to 60 (to allow - for leap seconds), with optional - fractional seconds. - - Zone = ( "+" / "-" ) 4*4Digit [ <SP> "(" String ")" ] - ; A four digit, signed time zone offset, - such as -0500 for US Eastern Standard - Time. This may be supplemented by a time - zone name in parentheses, e.g., "-0800 - (PDT)". Note that there is no default; - time zone information is required and - MUST be supplied. - -4.5 Additional Implementation Issues - -4.5.1 Minimum Implementation - -In order to make SMTP workable, the following minimum implementation is -required for all receivers. The following commands MUST be supported to -conform to this specification: - - EHLO - HELO - MAIL - RCPT - DATA - RSET - NOOP - QUIT - VRFY - -Any system that includes an SMTP server supporting mail relaying or -delivery MUST support the reserved mailbox "postmaster" as a -case-insensitive local name. This postmaster address is not strictly -necessary if the server always returns 554 on connection opening (as -described in section 3.1). The requirement to accept mail for -postmaster implies that RCPT commands which specify a mailbox for -postmaster at any of the domains for which the SMTP server provides -mail service, as well as the special case of "RCPT TO:<Postmaster>" -(with no domain specification), MUST be supported. This requirement -does not imply that SMTP systems must deliver Postmaster mail in -particular cases (e.g., problematic origin addresses) in which they -have substantive reasons for not doing so. - -4.5.2 Transparency - -Without some provision for data transparency, the character sequence -"<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user. In -general, users are not aware of such "forbidden" sequences. To allow -all user composed text to be transmitted transparently, the following -procedures are used: - - - Before sending a line of mail text, the SMTP client checks the first - character of the line. If it is a period, one additional period is - inserted at the beginning of the line. - - - When a line of mail text is received by the SMTP server, it checks - the line. If the line is composed of a single period, it is treated - as the end of mail indicator. If the first character is a period - and there are other characters on the line, the first character is - deleted. - -The mail data may contain any of the 128 ASCII characters. All -characters are to be delivered to the recipient's mailbox, including -spaces, vertical and horizontal tabs, and other control characters. If -the transmission channel provides an 8-bit byte (octets) data stream, -the 7-bit ASCII codes are transmitted right justified in the octets, -with the high order bits cleared to zero. See 3.7 for special -treatment of these conditions in SMTP systems serving a relay function. - -In some systems it may be necessary to transform the data as it is -received and stored. This may be necessary for hosts that use a -different character set than ASCII as their local character set, that -store data in records rather than strings, or which use special -character sequences as delimiters inside mailboxes. If such -transformations are necessary, they MUST be reversible, especially if -they are applied to mail being relayed. - -4.5.3 Sizes and Timeouts - -4.5.3.1 Size limits and minimums - -There are several objects that have required minimum/maximum sizes. -Every implementation MUST be able to receive objects of at least these -sizes. Objects larger than these sizes SHOULD be avoided when -possible. However, some Internet mail constructs such as encoded X.400 -addresses [RFC-X400] will often require larger objects: clients MAY -attempt to transmit these, but MUST be prepared for a server to reject -them if they cannot be handled by it. To the maximum extent possible, -implementation techniques which impose no limits on the length of these -objects should be used. - -local-part - The maximum total length of a user name or other local-part is 64 - characters. - -domain - The maximum total length of a domain name or number is 255 - characters. - -path - The maximum total length of a reverse-path or forward-path is 256 - characters (including the punctuation and element separators). - -command line - The maximum total length of a command line including the command - word and the <CRLF> is 512 characters. SMTP extensions may be used - to increase this limit. - -reply line - The maximum total length of a reply line including the reply code - and the <CRLF> is 512 characters. More information may be conveyed - through multiple-line replies. - -text line - The maximum total length of a text line including the <CRLF> is 1000 - characters (not counting the leading dot duplicated for - transparency). This number may be increased by the use of SMTP - Service Extensions. - -message content - The maximum total length of a message content (including any message - headers as well as the message body) MUST BE at least 64K octets. - Since the introduction of multimedia mail [RFC-MIME], message - lengths on the Internet have grown dramatically, and message size - restrictions should be avoided if at all possible. SMTP server - systems that must impose restrictions SHOULD implement the "SIZE" - service extension ([RFC-SIZE]), and SMTP client systems that will - send large messages SHOULD utilize it when possible. - -recipients buffer - The minimum total number of recipients that must be buffered is 100 - recipients. Rejection of messages (for excessive recipients) with - fewer than 100 RCPT commands is a violation of this specification. - The general principle that relaying SMTP servers MUST NOT, and - delivery SMTP servers SHOULD NOT, perform validation tests on - message headers suggests that rejecting a message based on the total - number of recipients shown in header fields is to be discouraged. A - server which imposes a limit on the number of recipients MUST behave - in an orderly fashion, such as to reject additional addresses over - its limit rather than silently discarding addresses previously - accepted. A client that needs to deliver a message containing over - 100 RCPT commands SHOULD be prepared to transmit in 100-recipient - "chunks" if the server declines to accept more than 100 recipients - in a single message. - -Errors due to exceeding these limits may be reported by using the reply -codes. Some examples of reply codes are: - - 500 Line too long. -or - 501 Path too long -or - 452 Too many recipients (see below) -or - 552 Too much mail data. - -[RFC-821] incorrectly listed the error where an SMTP server exhausts -its implementation limit on the number of RCPT commands ("too many -recipients") as having reply code 552. The correct reply code for this -condition is 452. Clients SHOULD treat a 552 code in this case as a -temporary, rather than permanent failure so the logic below works. - -When a conforming SMTP server encounters this condition, it has at -least 100 successful RCPT commands in its recipients buffer. If the -server is able to accept the message, then at least these 100 addresses -will be removed from the SMTP client's queue. When the client attempts -retransmission of those addresses which received 452 responses, at -least 100 of these will be able to fit in the SMTP server's recipients -buffer. Each retransmission attempt which is able to deliver anything -will be able to dispose of at least 100 of these recipients. - -If an SMTP server has an implementation limit on the number of RCPT -commands and this limit is exhausted, it MUST use a response code of -452. If the server has a configured site-policy limitation on the -number of RCPT commands, it MAY instead use a 5XX response code. - -In order to interoperate with SMTP servers implementing an older -version of the protocol, SMTP clients MAY treat a 552 code obtained in -response to an RCPT command as if it were a 452 response code, -especially after some RCPT commands have already been accepted in the -same mail transaction. - -4.5.3.2 Timeouts - -An SMTP client MUST provide a timeout mechanism. It MUST use -per-command timeouts rather than somehow trying to time the entire mail -transaction. Timeouts SHOULD be easily reconfigurable, preferably -without recompiling the SMTP code. To implement this, a timer is set -for each SMTP command and for each buffer of the data transfer. The -latter means that the overall timeout is inherently proportional to the -size of the message. - -Based on extensive experience with busy mail-relay hosts, the minimum -per-command timeout values SHOULD be as follows: - -Initial 220 Message: 5 minutes - An SMTP client process needs to distinguish between a failed TCP - connection and a delay in receiving the initial 220 greeting - message. Many SMTP servers accept a TCP connection but delay - delivery of the 220 message until their system load permits more - mail to be processed. - -MAIL Command: 5 minutes - -RCPT Command: 5 minutes - A longer timeout is required if processing of mailing lists and - aliases is not deferred until after the message was accepted. - -DATA Initiation: 2 minutes - This is while awaiting the "354 Start Input" reply to a DATA command. - -Data Block: 3 minutes - This is while awaiting the completion of each TCP SEND call - transmitting a chunk of data. - -DATA Termination: 10 minutes. - This is while awaiting the "250 OK" reply. When the receiver gets - the final period terminating the message data, it typically performs - processing to deliver the message to a user mailbox. A spurious - timeout at this point would be very wasteful and would typically - result in delivery of multiple copies of the message, since it has - been successfully sent and the server has accepted responsibility - for delivery. See section 6.1 for additional discussion. - -An SMTP server SHOULD have a timeout of at least 5 minutes while it is -awaiting the next command from the sender. - -4.5.4 Queuing Strategies - -The common structure of a host SMTP implementation includes user -mailboxes, one or more areas for queuing messages in transit, and one -or more daemon processes for sending and receiving mail. The exact -structure will vary depending on the needs of the users on the host and -the number and size of mailing lists supported by the host. We describe -several optimizations that have proved helpful, particularly for -mailers supporting high traffic levels. - -Any queuing strategy MUST include timeouts on all activities on a -per-command basis. A queuing strategy MUST NOT send error messages in -response to error messages under any circumstances. - -4.5.4.1 Sending Strategy - -The general model for an SMTP client is one or more processes that -periodically attempt to transmit outgoing mail. In a typical system, -the program that composes a message has some method for requesting -immediate attention for a new piece of outgoing mail, while mail that -cannot be transmitted immediately MUST be queued and periodically -retried by the sender. A mail queue entry will include not only the -message itself but also the envelope information. - -The sender MUST delay retrying a particular destination after one -attempt has failed. In general, the retry interval SHOULD be at least -30 minutes; however, more sophisticated and variable strategies will be -beneficial when the SMTP client can determine the reason for -non-delivery. - -Retries continue until the message is transmitted or the sender gives -up; the give-up time generally needs to be at least 4-5 days. The -parameters to the retry algorithm MUST be configurable. - -A client SHOULD keep a list of hosts it cannot reach and corresponding -connection timeouts, rather than just retrying queued mail items. - -Experience suggests that failures are typically transient (the target -system or its connection has crashed), favoring a policy of two -connection attempts in the first hour the message is in the queue, and -then backing off to one every two or three hours. - -The SMTP client can shorten the queuing delay in cooperation with the -SMTP server. For example, if mail is received from a particular -address, it is likely that mail queued for that host can now be sent. -Application of this principle may, in many cases, eliminate the -requirement for an explicit "send queues now" function such as that -discussed in [RFC-ETRN]. - -The strategy may be further modified as a result of multiple addresses -per host (see below) to optimize delivery time vs. resource usage. - -An SMTP client may have a large queue of messages for each unavailable -destination host. If all of these messages were retried in every retry -cycle, there would be excessive Internet overhead and the sending -system would be blocked for a long period. Note that an SMTP client -can generally determine that a delivery attempt has failed only after a -timeout of several minutes and even a one-minute timeout per connection -will result in a very large delay if retries are repeated for dozens, -or even hundreds, of queued messages to the same host. - -At the same time, SMTP clients SHOULD use great care in caching -negative responses from servers. In an extreme case, if EHLO is issued -multiple times during the same SMTP connection, different answers may -be returned by the server. More significantly, 5yz responses to the -MAIL command MUST NOT be cached. - -When a mail message is to be delivered to multiple recipients, and the -SMTP server to which a copy of the message is to be sent is the same -for multiple recipients, then only one copy of the message SHOULD be -transmitted. That is, the SMTP client SHOULD use the command sequence: -MAIL, RCPT, RCPT,... RCPT, DATA instead of the sequence: MAIL, RCPT, -DATA, ..., MAIL, RCPT, DATA. However, if there are very many -addresses, a limit on the number of RCPT commands per MAIL command MAY -be imposed. Implementation of this efficiency feature is strongly -encouraged. - -Similarly, to achieve timely delivery, the SMTP client MAY support -multiple concurrent outgoing mail transactions. However, some limit -may be appropriate to protect the host from devoting all its resources -to mail. - -4.5.4.2 Receiving Strategy - -The SMTP server SHOULD attempt to keep a pending listen on the SMTP -port at all times. This requires the support of multiple incoming TCP -connections for SMTP. Some limit MAY be imposed but servers that -cannot handle more than one SMTP transaction at a time are not in -conformance with the intent of this specification. - -As discussed above, when the SMTP server receives mail from a -particular host address, it could notify the SMTP client to retry any -mail pending for that host address. - -4.5.5 Messages with a null reverse-path - -There are several types of notification messages which are required by -existing and proposed standards to be sent with a null reverse path, -namely non-delivery notifications as discussed in section 3.7, other -kinds of Delivery Status Notifications (DSNs, see [RFC 1894]) and also -Message Disposition Notifications (MDNs, see [RFC 2298]). All of these -kinds of messages are notifications about a previous message, and they -are sent to the reverse-path of the previous mail message. (If the -delivery of such a notification message fails, that usually indicates a -problem with the mail system of the host to which the notification -message is addressed. For this reason, at some hosts the MTA is set up -to forward such failed notification messages to someone who is able to -fix problems with the mail system, e.g. via the postmaster alias.) - -All other types of messages (i.e. any message which is not required by -a standards-track RFC to have a null reverse-path) SHOULD be sent with -with a valid, non-null reverse-path. - -Implementors of automated email processors should be careful to make -sure that the various kinds of messages with null reverse-path are -handled correctly, in particular such systems SHOULD NOT reply to -messages with null reverse-path. - - - -5. Address Resolution and Mail Handling - -Once an SMTP client lexically identifies a domain to which mail will be -delivered for processing (as described in sections 3.6 and 3.7), a DNS -lookup MUST be performed to resolve the domain name (see [RFC-DNS]). -The names are expected to be fully-qualified domain names (FQDNs): -mechanisms for inferring FQDNs from partial names or local aliases are -outside of this specification and, due to a history of problems, are -generally discouraged. The lookup first attempts to locate an MX -record associated with the name. If a CNAME record is found instead, -the resulting name is processed as if it were the initial name. If no -MX records are found, but an A RR is found, the A RR is treated as if -it was associated with an implicit MX RR, with a preference of 0, -pointing to that host. If one or more MX RRs are found for a given -name, SMTP systems MUST NOT utilize any A RRs associated with that name -unless they are located using the MX RRs; the "implicit MX" rule above -applies only if there are no MX records present. If MX records are -present, but none of them are usable, this situation MUST be reported -as an error. - -When the lookup succeeds, the mapping can result in a list of -alternative delivery addresses rather than a single address, because of -multiple MX records, multihoming, or both. To provide reliable mail -transmission, the SMTP client MUST be able to try (and retry) each of -the relevant addresses in this list in order, until a delivery attempt -succeeds. However, there MAY also be a configurable limit on the number -of alternate addresses that can be tried. In any case, a host SHOULD -try at least two addresses. - -Two types of information is used to rank the host addresses: multiple -MX records, and multihomed hosts. - -Multiple MX records contain a preference indication that MUST be used -in sorting (see below). Lower numbers are more preferred than higher -ones. If there are multiple destinations with the same preference and -there is no clear reason to favor one (e.g., by recognition of an -easily-reached address), then the sender-SMTP MUST randomize them to -spread the load across multiple mail exchangers for a specific -organization. - -The destination host (perhaps taken from the preferred MX record) may -be multihomed, in which case the domain name resolver will return a -list of alternative IP addresses. It is the responsibility of the -domain name resolver interface to have ordered this list by decreasing -preference if necessary, and SMTP MUST try them in the order presented. - -Although the capability to try multiple alternative addresses is -required, specific installations may want to limit or disable the use -of alternative addresses. The question of whether a sender should -attempt retries using the different addresses of a multihomed host has -been controversial. The main argument for using the multiple addresses -is that it maximizes the probability of timely delivery, and indeed -sometimes the probability of any delivery; the counter-argument is that -it may result in unnecessary resource use. Note that resource use is -also strongly determined by the sending strategy discussed in section -4.5.4.1. - -If a host receives a message with a destination for which it is a -designated Mail eXchanger, it MAY relay the message (potentially after -having rewritten the addresses), make final delivery of the message, or -hand it off using some mechanism outside the SMTP-provided transport -environment. Of course, neither of the latter require that the list of -MX records be examined further. - -If it determines that it should relay the message without rewriting the -address, it MUST sort the MX records to determine candidates for -delivery. The records are first ordered by preference, with the -lowest-numbered records being most preferred. The relay host MUST then -inspect the list for any of the names or addresses by which it might be -known in mail transactions. If a matching record is found, all records -at that preference level and higher-numbered ones MUST be discarded -from consideration. If there are no records left at that point, it is -an error condition, and the message MUST be returned as undeliverable. -If records do remain, they SHOULD be tried, best preference first, as -described above. - - -6. Problem Detection and Handling - -6.1 Reliable Delivery and Replies by Email - -When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" -message in response to DATA), it is accepting responsibility for -delivering or relaying the message. It must take this responsibility -seriously. It MUST NOT lose the message for frivolous reasons, such as -because the host later crashes or because of a predictable resource -shortage. - -If there is a delivery failure after acceptance of a message, the -receiver-SMTP MUST formulate and mail a notification message. This -notification MUST be sent using a null ("<>") reverse path in the -envelope. The recipient of this notification MUST be the address from -the envelope return path (or the Return-Path: line). However, if this -address is null ("<>"), the receiver-SMTP MUST NOT send a notification. -Obviously, nothing in this section can or should prohibit local -decisions (i.e., as part of the same system environment as the -receiver-SMTP) to log or otherwise transmit information about null -address events locally if that is desired. If the address is an -explicit source route, it MUST be stripped down to its final hop. - -For example, suppose that an error notification must be sent for a -message that arrived with: - - MAIL FROM:<@a,@b:user@d> - -The notification message SHOULD be sent using: - - RCPT TO:<user@d> - -Some delivery failures after the message is accepted by SMTP will be -unavoidable. For example, it may be impossible for the receiving SMTP -server to validate all the delivery addresses in RCPT command(s) due to -a "soft" domain system error, because the target is a mailing list (see -earlier discussion of RCPT), or because the server is acting as a relay -and has no immediate access to the delivering system. - -To avoid receiving duplicate messages as the result of timeouts, a -receiver-SMTP MUST seek to minimize the time required to respond to the -final <CRLF>.<CRLF> end of data indicator. See RFC-1047 [RFC-1047] for -a discussion of this problem. - -6.2 Loop Detection - -Simple counting of the number of "Received:" headers in a message has -proven to be an effective, although rarely optimal, method of detecting -loops in mail systems. SMTP servers using this technique SHOULD use a -large rejection threshold, normally at least 100 Received entries. -Whatever mechanisms are used, servers MUST contain provisions for -detecting and stopping trivial loops. - -6.3 Compensating for Irregularities - -Unfortunately, variations, creative interpretations, and outright -violations of Internet mail protocols do occur; some would suggest that -they occur quite frequently. The debate as to whether a well-behaved -SMTP receiver or relay should reject a malformed message, attempt to -pass it on unchanged, or attempt to repair it to increase the odds of -successful delivery (or subsequent reply) began almost with the dawn of -structured network mail and shows no signs of abating. Advocates of -rejection claim that attempted repairs are rarely completely adequate -and that rejection of bad messages is the only way to get the offending -software repaired. Advocates of "repair" or "deliver no matter what" -argue that users prefer that mail go through it if at all possible and -that there are significant market pressures in that direction. In -practice, these market pressures may be more important to particular -vendors than strict conformance to the standards, regardless of the -preference of the actual developers. - -The problems associated with ill-formed messages were exacerbated by -the introduction of the split-UA mail reading protocols [RFC-POP2, -RFC-POP3, RFC-IMAP2, RFC-PCMAIL]. These protocols have encouraged the -use of SMTP as a posting protocol, and SMTP servers as relay systems -for these client hosts (which are often only intermittently connected -to the Internet). Historically, many of those client machines lacked -some of the mechanisms and information assumed by SMTP (and indeed, by -the mail format protocol [RFC-822]). Some could not keep adequate -track of time; others had no concept of time zones; still others could -not identify their own names or addresses; and, of course, none could -satisfy the assumptions that underlay RFC-822's conception of -authenticated addresses. - -In response to these weak SMTP clients, many SMTP systems now complete -messages that are delivered to them in incomplete or incorrect form. -This strategy is generally considered appropriate when the server can -identify or authenticate the client, and there are prior agreements -between them. By contrast, there is at best great concern about fixes -applied by a relay or delivery SMTP server that has little or no -knowledge of the user or client machine. - -The following changes to a message being processed MAY be applied when -necessary by an originating SMTP server, or one used as the target of -SMTP as an initial posting protocol: - - - Addition of a message-id field when none appears - - - Addition of a date, time or time zone when none appears - - - Correction of addresses to proper FQDN format - -The less information the server has about the client, the less likely -these changes are to be correct and the more caution and conservatism -should be applied when considering whether or not to perform fixes and -how. These changes MUST NOT be applied by an SMTP server that provides -an intermediate relay function. - -In all cases, properly-operating clients supplying correct information -are preferred to corrections by the SMTP server. In all cases, -documentation of actions performed by the servers (in trace fields -and/or header comments) is strongly encouraged. - - -7. Security Considerations - -7.1 Mail Security and Spoofing - -SMTP mail is inherently insecure in that it is feasible for even fairly -casual users to negotiate directly with receiving and relaying SMTP -servers and create messages that will trick a naive recipient into -believing that they came from somewhere else. Constructing such a -message so that the "spoofed" behavior cannot be detected by an expert -is somewhat more difficult, but not sufficiently so as to be a -deterrent to someone who is determined and knowledgeable. Consequently, -as knowledge of Internet mail increases, so does the knowledge that -SMTP mail inherently cannot be authenticated, or integrity checks -provided, at the transport level. Real mail security lies only in -end-to-end methods involving the message bodies, such as those that can -be provided in the MOSS framework [RFC-MOSS]. - -Various protocol extensions and configuration options that provide -authentication at the transport level (e.g., from an SMTP client to an -SMTP server) improve somewhat on the traditional situation described -above. However, unless they are accompanied by careful handoffs of -responsibility in a carefully-designed trust environment, they remain -inherently weaker than end-to-end mechanisms which use digitally signed -messages rather than depending on the integrity of the transport system. - -Efforts to make it more difficult for users to set envelope return path -and header "From" fields to point to valid addresses other than their -own are largely misguided: they frustrate legitimate applications in -which mail is sent by one user on behalf of another or in which error -(or normal) replies should be directed to a special address. (Systems -that provide convenient ways for users to alter these fields on a -per-message basis should attempt to establish a primary and permanent -mailbox address for the user so that Sender fields within the message -data can be generated sensibly.) - -This specification does not further address the authentication issues -associated with SMTP other than to advocate that useful functionality -not be disabled in the hope of providing some small margin of -protection against an ignorant user who is trying to fake mail. - -7.2 "Blind" Copies - -Addresses that do not appear in the message headers may appear in the -RCPT commands to an SMTP server for a number of reasons. The two most -common involve the use of a mailing address as a "list exploder" (a -single address that resolves into multiple addresses) and the -appearance of "blind copies". Especially when more than one RCPT -command is present, and in order to avoid defeating some of the purpose -of these mechanisms, SMTP clients and servers SHOULD NOT copy the full -set of RCPT command arguments into the headers, either as part of trace -headers or as informational or private-extension headers. Since this -rule is often violated in practice, and cannot be enforced, sending -SMTP systems that are aware of "bcc" use MAY find it helpful to send -each blind copy as a separate message transaction containing only a -single RCPT command. - -There is no inherent relationship between either "reverse" (from MAIL, -SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP -transaction ("envelope") and the addresses in the headers. Receiving -systems SHOULD NOT attempt to deduce such relationships and use them to -alter the headers of the message for delivery. The popular -"Apparently-to" header is a violation of this principle as well as a -common source of unintended information disclosure and SHOULD NOT be -used. - -7.3 VRFY, EXPN, and Security - -As discussed in section 3.5, individual sites may want to disable one -or both VRFY or EXPN for security reasons. As a corollary to the -above, implementations that permit this MUST NOT appear to have -verified addresses that are not, in fact, verified. If a site disables -these commands for security reasons, the SMTP server MUST return a 252 -response, rather than a code that could be confused with successful or -unsuccessful verification. - -Returning a 250 reply code with the address listed in the VRFY command -after having checked it only for syntax violates this rule. Of course, -an implementation that "supports" VRFY by always returning 550 whether -or not the address is valid is equally not in conformance. - -Within the last few years, the contents of mailing lists have become -popular as an address information source for so-called "spammers." The -use of EXPN to "harvest" addresses has increased as list administrators -have installed protections against inappropriate uses of the lists -themselves. Implementations SHOULD still provide support for EXPN, but -sites SHOULD carefully evaluate the tradeoffs. As authentication -mechanisms are introduced into SMTP, some sites may choose to make EXPN -available only to authenticated requestors. - -7.4 Information Disclosure in Announcements - -There has been an ongoing debate about the tradeoffs between the -debugging advantages of announcing server type and version (and, -sometimes, even server domain name) in the greeting response or in -response to the HELP command and the disadvantages of exposing useful -information to potential hostile attack. The utility of the debugging -information is beyond doubt. Those who argue for making it available -point out that it is far better to actually secure an SMTP server -rather than hope that trying to conceal known vulnerabilities by hiding -the server's precise identity will provide more protection. Sites are -encouraged to evaluate the tradeoff with that issue in mind; -implementations are strongly encouraged to minimally provide for making -type and version information available in some way to other network -hosts. - -7.5 Information Disclosure in Trace Fields - -In some circumstances, such as when mail originates from within a LAN -whose hosts are not directly from the public Internet, trace -("Received") fields produced in conformance with this specification may -disclose host names and similar information that would not normally be -available. This ordinarily does not pose a problem, but sites with -special concerns about name disclosure should be aware of it. Also, -the optional FOR clause should be supplied with caution or not at all -when multiple recipients are involved lest it inadvertently disclose -the identities of "blind copy" recipients to others. - -7.6 Scope of Operation of SMTP Servers - -It is a well-established principle that an SMTP server may refuse to -accept mail for any operational or technical reason that makes sense to -the site providing the server. However, cooperation among sites and -installations makes the Internet possible. If sites take excessive -advantage of the right to reject traffic, the ubiquity of email -availability (one of the strengths of the Internet) will be threatened; -considerable care should be taken and balance maintained if a site -decides to be selective about the traffic it will accept and process. - -In recent years, use of the relay function through arbitrary sites has -been used as part of hostile efforts to hide the actual origins of -mail. Some sites have decided to limit the use of the relay function -to known or identifiable sources, and implementations SHOULD provide -the capability to perform this type of filtering. When mail is -rejected for these or other policy reasons, a 550 code SHOULD be used -in response to EHLO, MAIL, or RCPT as appropriate. - - -8. IANA Considerations - -IANA will maintain three registries in support of this specification. -The first consists of SMTP service extensions with the associated -keywords, and, as needed, parameters and verbs. As specified in -section 2.2.2, no entry may be made in this registry that starts in an -"X". Entries may be made only for service extensions (and associated -keywords, parameters, or verbs) that are defined in standards-track or -experimental RFCs specifically approved by the IESG for this purpose. - -The second registry consists of "tags" that identify forms of domain -literals other than those for IPv4 addresses (specified in RFC 821 and -in this document) and IPv6 addresses (specified in this document). -Additional literal types require standardization before being used; -none are anticipated at this time. - -The third, established by RFC 821 and renewed by this specification, is -a registry of link and protocol identifiers to be used with the "via" -and "with" subclauses of the time stamp ("Received: header") described -in section 4.4. Link and protocol identifiers in addition to those -specified in this document may be registered only by standardization or -by way of an RFC-documented, IESG-approved, Experimental protocol -extension. - - -9. References - -[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP -Service Extension for 8bit-MIMEtransport", RFC 1652, 07/18/1994. - -[ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax -Specifications: ABNF", RFC 2234, November 1997. - -[IPv6AddrSpec] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing -Architecture", RFC 1884, December 1995. - -[MSGFMT] P. Resnick, Work in progress, draft-ietf-drums-msg-fmt-05.txt, -August, 1998 - -[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text -Messages", RFC 822, Department of Electrical Engineering, University of -Delaware, August 1982. - -[RFC-974] Partridge, C., "Mail routing and the domain system", RFC 974, -01/01/1986 - -[RFC-1047] Partridge, C., "Duplicate messages and SMTP", RFC 1047, -02/01/1988. - -[RFC-1123] Braden, R., "Requirements for Internet hosts - application and -support", 10/01/1989 - -[RFC-BDAT] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large -and Binary MIME Messages", RFC 1830, 08/16/1995. - -[RFC-DNS] Mockapetris, P., "Domain names - implementation and -specification", RFC 1035 and P. Mockapetris, "Domain names - concepts and -facilities", RFC 1034. (STD 13) - -[RFC-ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue -Starting", RFC 1985, 08/14/1996. - -[RFC-IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC -1176, 08/20/1990. - -[RFC-IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", RFC -2060, 12/04/1996. - -[RFC-INTLHDR] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part -Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 12/02/1996. - -[IAB-Firewalls] Freed, N, ed., "Behavior of and Requirements for -Internet Firewalls", Work in progress, draft-iab-firewall-req-01.txt, -Feb 2000. - -[RFC-MIME] Freed, N., N. Borenstein, "Multipurpose Internet Mail Extensions -(MIME) Part One: Format of Internet Message Bodies", RFC 2045, 12/02/1996. - -[RFC-MOSS] Crocker, S., N. Freed, J. Galvin, S. Murphy, "MIME Object -Security Services", RFC 1848, 10/03/1995. - -[RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery Status -Notifications", RFC 1891, 01/15/1996. - -[RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message Format for -Delivery Status Notifications", RFC 1894, 01/15/1996. - -[RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for personal -computers", RFC 1056, 06/01/1988. - -[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension for Command -Pipelining", RFC 1854, 10/04/1995. - -[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J. Reynolds, -"Post Office Protocol - version 2", RFC 937, 02/01/1985 - -[RFC-POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3", RFC 1930, -5/14/96 (Std 53). - -[RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 1893, -01/15/1996. - -[RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension for -Message Size Declaration", RFC 1870, 11/06/1995. (STD 10) - -[RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021 -and RFC 822", RFC 1327, 05/18/1992. - -[SMTPEXT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP -Service Extensions", RFC-1869, 11/06/1995. (STD 10) - -[TCP] Postel, J., ed., "Transmission Control Protocol - DARPA Internet -Program Protocol Specification", RFC 793, USC/Information Sciences -Institute, NTIS AD Number A111091, September 1981. - -[US-ASCII] United States of America Standards Institute (now American -National Standards Institute), X3.4, 1968, "USA Code for Information -Interchange". ANSI X3.4-1968 has been replaced by newer versions with -slight modifications, but the 1968 version remains definitive for the -Internet. - - -10. Editor's Address - -John C. Klensin -AT&T Laboratories -Tel: 617-674-3076 -email: klensin@research.att.com - - - -11. Acknowledgments - -Many people worked long and hard on the many iterations of this document. -There was wide-ranging debate on the mailing list about many technical -issues, and many contributors helped form the wording in this -specification. The hundreds of participants in the many discussions since -RFC 821 was produced are too numerous to mention, but they all helped this -document become what it is. - - - - - APPENDICES - -A. TCP Transport Service - -The TCP connection supports the transmission of 8-bit bytes. The SMTP -data is 7-bit ASCII characters. Each character is transmitted as an -8-bit byte with the high-order bit cleared to zero. Service extensions -may modify this rule to permit transmission of full 8-bit data bytes as -part of the message body, but not in SMTP commands or responses. - - -B. Generating SMTP Commands from RFC 822 Headers - -Some systems use RFC 822 headers (only) in a mail submission protocol, -or otherwise generate SMTP commands from RFC 822 headers when such a -message is handed to an MTA from a UA. While the MTA-UA protocol is a -private matter, not covered by any Internet Standard, there are -problems with this approach. For example, there have been repeated -problems with proper handling of "bcc" copies and redistribution lists -when information that conceptually belongs to a mail envelopes is not -separated early in processing from header information (and kept -separate). - -It is recommended that the UA provide its initial MTA with an envelope -separate from the message itself. However, if the envelope is not -supplied, SMTP commands SHOULD be generated as follows: - -1. Each recipient address from a TO, CC, or BCC header field SHOULD be - copied to a RCPT command (generating multiple message copies if that - is required for queuing or delivery). This includes any addresses - listed in a RFC 822 "group". Any BCC fields SHOULD then be removed - from the headers. Once this process is completed, the remaining - headers SHOULD be checked to verify that at least one To:, Cc:, or - Bcc: header remains. If none do, then a bcc: header with no - additional information SHOULD be inserted as specified in [MSGFMT]. - -2. The return address in the MAIL command SHOULD, if possible, be - derived from the system's identity for the submitting (local) user, - and the "From:" header field otherwise. If there is a system - identity available, it SHOULD also be copied to the Sender header - field if it is different from the address in the From header field. - (Any Sender field that was already there SHOULD be removed.) - Systems may provide a way for submitters to override the envelope - return address, but may want to restrict its use to privileged - users. This will not prevent mail forgery, but may lessen its - incidence; see section 7.1. - -When an MTA is being used in this way, it bears responsibility for -ensuring that the message being transmitted is valid. The mechanisms -for checking that validity, and for handling (or returning) messages -that are not valid at the time of arrival, are part of the MUA-MTA -interface and not covered by this specification. - -A submission protocol based on Standard RFC 822 information alone MUST -NOT be used to gateway a message from a foreign (non-SMTP) mail system -into an SMTP environment. Additional information to construct an -envelope must come from some source in the other environment, whether -supplemental headers or the foreign system's envelope. - -Attempts to gateway messages using only their header "to" and "cc" -fields have repeatedly caused mail loops and other behavior adverse to -the proper functioning of the Internet mail environment. These -problems have been especially common when the message originates from -an Internet mailing list and is distributed into the foreign -environment using envelope information. When these messages are then -processed by a header-only remailer, loops back to the Internet -environment (and the mailing list) are almost inevitable. - - -C. Source Routes - -The <reverse-path> is a reverse source routing list of hosts and a -source mailbox. The first host in the <reverse-path> SHOULD be the -host sending the MAIL command. Similarly, the <forward-path> may be a -source routing lists of hosts and a destination mailbox. However, in -general, the <forward-path> SHOULD contain only a mailbox and domain -name, relying on the domain name system to supply routing information -if required. The use of source routes is deprecated; while servers -MUST be prepared to receive and handle them as discussed in section 3.3 -and F.2, clients SHOULD NOT transmit them. - -For relay purposes, the forward-path may be a source route of the form -"@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE -fully-qualified domain names. This form is used to emphasize the -distinction between an address and a route. The mailbox is an absolute -address, and the route is information about how to get there. The two -concepts should not be confused. - -If source routes are used, RFC 821 and the text below should be -consulted for the mechanisms for constructing and updating the forward- -and reverse-paths. - -The SMTP server transforms the command arguments by moving its own -identifier (its domain name or that of any domain for which it is -acting as a mail exchanger), if it appears, from the forward-path to -the beginning of the reverse-path. - -Notice that the forward-path and reverse-path appear in the SMTP -commands and replies, but not necessarily in the message. That is, -there is no need for these paths and especially this syntax to appear -in the "To:" , "From:", "CC:", etc. fields of the message header. -Conversely, SMTP servers MUST NOT derive final message delivery -information from message header fields. - -When the list of hosts is present, it is a "reverse" source route and -indicates that the mail was relayed through each host on the list (the -first host in the list was the most recent relay). This list is used -as a source route to return non-delivery notices to the sender. As each -relay host adds itself to the beginning of the list, it MUST use its -name as known in the transport environment to which it is relaying the -mail rather than that of the transport environment from which the mail -came (if they are different). - - -D. Scenarios - -This section presents complete scenarios of several types of SMTP -sessions. In the examples, "C:" indicates what is said by the SMTP -client, and "S:" indicates what is said by the SMTP server. - -D.1 A Typical SMTP Transaction Scenario - -This SMTP example shows mail sent by Smith at host bar.com, to Jones, -Green, and Brown at host foo.com. Here we assume that host bar.com -contacts host foo.com directly. The mail is accepted for Jones and -Brown. Green does not have a mailbox at host foo.com. - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<Smith@bar.com> - S: 250 OK - C: RCPT TO:<Jones@foo.com> - S: 250 OK - C: RCPT TO:<Green@foo.com> - S: 550 No such user here - C: RCPT TO:<Brown@foo.com> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.2 Aborted SMTP Transaction Scenario - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<Smith@bar.com> - S: 250 OK - C: RCPT TO:<Jones@foo.com> - S: 250 OK - C: RCPT TO:<Green@foo.com> - S: 550 No such user here - C: RSET - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.3 Relayed Mail Scenario - -Step 1 -- Source Host to Relay Host - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<JQP@bar.com> - S: 250 OK - C: RCPT TO:<@foo.com:Jones@XYZ.COM> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Date: Thu, 21 May 1998 05:33:29 -0700 - C: From: John Q. Public <JQP@bar.com> - C: Subject: The Next Meeting of the Board - C: To: Jones@xyz.com - C: - C: Bill: - C: The next meeting of the board of directors will be - C: on Tuesday. - C: John. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -Step 2 -- Relay Host to Destination Host - - S: 220 xyz.com Simple Mail Transfer Service Ready - C: EHLO foo.com - S: 250 xyz.com is on the air - C: MAIL FROM:<@foo.com:JQP@bar.com> - S: 250 OK - C: RCPT TO:<Jones@XYZ.COM> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Received: from bar.com by foo.com ; Thu, 21 May 1998 - C: 05:33:29 -0700 - C: Date: Thu, 21 May 1998 05:33:22 -0700 - C: From: John Q. Public <JQP@bar.com> - C: Subject: The Next Meeting of the Board - C: To: Jones@xyz.com - C: - C: Bill: - C: The next meeting of the board of directors will be - C: on Tuesday. - C: John. - C: . - S: 250 OK - - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.4 Verifying and Sending Scenario - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: VRFY Crispin - S: 250 Mark Crispin <Admin.MRC@foo.com> - C: SEND FROM:<EAK@bar.com> - S: 250 OK - C: RCPT TO:<Admin.MRC@foo.com> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - - -E. Other Gateway Issues - -In general, gateways between the Internet and other mail systems SHOULD -attempt to preserve any layering semantics across the boundaries -between the two mail systems involved. Gateway-translation approaches -that attempt to take shortcuts by mapping, (such as envelope -information from one system to the message headers or body of another) -have generally proven to be inadequate in important ways. Systems -translating between environments that do not support both envelopes and -headers and Internet mail must be written with the understanding that -some information loss is almost inevitable. - - -F. Deprecated Features of RFC 821 - -A few features of RFC 821 have proven to be problematic and SHOULD NOT -be used in Internet mail. - -F.1 TURN - -This command, described in RFC 821, raises important security issues -since, in the absence of strong authentication of the host requesting -that the client and server switch roles, it can easily be used to -divert mail from its correct destination. Its use is deprecated; SMTP -systems SHOULD NOT use it unless the server can authenticate the client. - -F.2 Source Routing - -RFC 821 utilized the concept of explicit source routing to get mail -from one host to another via a series of relays. The requirement to -utilize source routes in regular mail traffic was eliminated by the -introduction of the domain name system "MX" record and the last -significant justification for them was eliminated by the introduction, -in RFC 1123, of a clear requirement that addresses following an "@" -must all be fully-qualified domain names. Consequently, the only -remaining justifications for the use of source routes are support for -very old SMTP clients or MUAs and in mail system debugging. They can, -however, still be useful in the latter circumstance and for routing -mail around serious, but temporary, problems such as problems with the -relevant DNS records. - -SMTP servers MUST continue to accept source route syntax as specified -in the main body of this document and in RFC 1123. They MAY, if -necessary, ignore the routes and utilize only the target domain in the -address. If they do utilize the source route, the message MUST be sent -to the first domain shown in the address. In particular, a server MUST -NOT guess at shortcuts within the source route. - -Clients SHOULD NOT utilize explicit source routing except under unusual -circumstances, such as debugging or potentially relaying around -firewall or mail system configuration errors. - -F.3 HELO - -As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to -HELO when the server will accept the former. Servers must continue to -accept and process HELO in order to support older clients. - -F.4 #-literals - -RFC 821 provided for specifying an Internet address as a decimal -integer host number prefixed by a pound sign, "#". In practice, that -form has been obsolete since the introduction of TCP/IP. It is -deprecated and MUST NOT be used. - -F.5 Dates and Years - -When dates are inserted into messages by SMTP clients or servers (e.g., -in trace fields), four-digit years MUST BE used. Two-digit years are -deprecated; three-digit years were never permitted in the Internet mail -system. - -F.6 Sending versus Mailing - -In addition to specifying a mechanism for delivering messages to user's -mailboxes, RFC 821 provided additional, optional, commands to deliver -messages directly to the user's terminal screen. These commands (SEND, -SAML, SOML) were rarely implemented, and changes in workstation -technology and the introduction of other protocols may have rendered -them obsolete even where they are implemented. - -Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers -MAY implement them. If they are implemented by servers, the -implementation model specified in RFC 821 MUST be used and the command -names MUST be published in the response to the EHLO command. - - -X. Change Summary and Loose Ends (Temporary) - -X.1 Change summary - -X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and -draft-ietf-drums-smtpupd-01.txt - -(i) Slightly clarified the discussions of rejection and failure of VRFY -requests and the associated response codes. - -(ii) Slightly clarified the discussion of deferred address validation. - -(iii) Removed the IPCE terminology and modified the text in section -4.1.1.2 to explicitly introduce the "mail gateway" terminology and to -begin to distinguish a mail gateway from a conventional relay. - -(iv) Explicitly noted that SMTP clients for things like POP and IMAP -may send everything to a single relay for further processing, rather -than resolving final domain names. - -(v) Tightened the RSET discussion. - -(vi) Deprecation of 251 only for RCPT (still ok for VRFY) - -X.1.2. Substantive changes between draft-ietf-drums-smtpupd-01.txt and -draft-ietf-drums-smtpupd-02.txt. - -Incorporated additional RFC 1123 material; reorganized several sections -for clarity. Added definitions and other previous "loose end" material. - -X.1.3. Substantive changes between draft-ietf-drums-smtpupd-02.txt and -draft-ietf-drums-smtpupd-03.txt. - -(i) Eliminated a number of placeholders and tightened some of the -definitions in section 2. Added a few new placeholders for consistency -checking against other documents. - -(ii) Removed the state diagrams, per direction at IETF Montreal. - -(iii) Added new section 6.3, an attempt to summarize WG discussions on -the "posting" versus "delivery" versus "relay" functions of SMTP and on -whether "fixups" are appropriate in different cases. - -(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of RFC1123. - -(v) Added new text to 3.5.5 to discuss the spammer - EXPN relationship. - -(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat. - -(v) The remaining miscellaneous changes agreed to in Montreal have been -incorporated except as noted below. - -X.1.4. Substantive changes between draft-ietf-drums-smtpupd-03.txt and -draft-ietf-drums-smtpupd-04.txt. - -Many small changes have been made between these two versions; the list -that follows is not exhaustive. - -(i) To clarify some of the text, definitions have been introduced to -distinguish among originating, delivery, relay, and gateway SMTP -systems. - -(ii) The role of LF-terminated lines has been clarified. - -(iii) Several changes have been made to clarify the principle that, no -matter what originating and final delivery systems might do, relay -systems are not permitted to tamper with message content, even to "fix" -headers that are determined to be invalid. If they deem message -content to be seriously unacceptable, they are encouraged to reject the -messages in preference to trying to fix them up, but, in general, the -theme is "don't look/ don't tell". - -(iv) A few more definitions have been added to the terminology section, -and the separate glossary has been eliminated. - -(v) I have taken a shot at text to address some of the controversies -that have raged on the WG mailing list (e.g., sections 7.4 and 7.5). -Since there was no consensus on most of those topics, I expect that the -inserted text will satisfy no one except, perhaps, for agreement that -saying nothing would have been worse. As a mechanism for moving -forward, the text in these controversial areas that now appears will be -considered "base"; alterations will be made only if clear consensus -emerges. - -(vi) Per discussion in Los Angeles, source routes have been further -deprecated. - -(vii) Some of the VRFY/EXPN materials have been moved to "security -considerations", where they appear to belong, some text has been added, -and the conformance statements adjusted to reflect what I perceive to -be WG consensus. - -(viii) New MX resolution material has been added to section 5. While -most of this material is from RFC974, the rules have been further -tightened to reflect current practice and experience (974 is written in -a somewhat speculative fashion for a standard). In particular, the -behavior of trying the target host's A RR when MXs existed but all of -them were eliminated is now prohibited, which seems necessary if -another of other ideas being recommended or considered are to be -feasible. - -X.1.5. Substantive changes between draft-ietf-drums-smtpupd-04.txt and -draft-ietf-drums-smtpupd-05.txt. - -(i) All normative references to RFC 1123 have been removed from the -main body of the text (some still appear in the appendices where they -will remain). - -(ii) Section 3.5 has been renamed slightly to distinguish between -"debugging of SMTP implementations" and "debugging of addresses". -Better terminology would be welcome. - -(iii) Error conditions resulting from the DATA command have been -clarified. - -(iv) Section 4.2 (SMTP replies) has been revised and tightened to -reflect reality and recent discussion on the list. - -(v) Appendix E has been revised a bit and moved into section 4.2.1. -Given the importance of the "check only first digit" rule, it has to be -there. - -(vi) Added new text for "no SMTP service supported" to sections 3.1, -4.2.2, 4.2.3, and 4.3.2. As noted in 3.1, I'd rather add 521 (which -would work perfectly with the model) rather than overloading 554. - -(vii) The Return-path language in section 4.4 has been cleaned up a bit. - -(viii) Tightened the "postmaster" language in 4.5.1, requiring a small -change to 4.1.1.3. - -(ix) I have unilaterally (with a little help from my friends), -increased some of the size limits. 64 was much too short for a domain -name, and the DNS limit of 255 (?) has now been inserted. That leaves -the return path much too short, but I haven't fixed it (maybe that will -cause us to get rid of them). We still have a 64 character limit on -the local-part, which is also *much* too short. Votes for 128 or longer -limits accepted. See X.1.6(I) - -(x) The text on the "recipients buffer" has been rewritten so that (I -hope) it makes sense and gives some explicit guidance for how clients -and servers should proceed if limits are imposed. - -X.1.6. Substantive changes between draft-ietf-drums-smtpupd-05.txt and -draft-ietf-drums-smtpupd-06.txt. - -Most of the changes in this revision have been editorial rather than -substantive. Major substantive changes include: - -(i) The language about maximum sizes of SMTP command lines has been -reworked, per WG mailing list discussion. - -(ii) Several instances of "SHOULD" have been promoted to "MUST" when -the reasons for the weaker rule seemed to have disappeared. In -particular, the requirement that an SMTP implementation support -timeouts has become a MUST. Also, conformance to this specification -requires support of EHLO. Older systems should claim conformance to -the [to-be-historical] 821, not this specification. - -X.1.7. Substantive changes between draft-ietf-drums-smtpupd-06.txt and -draft-ietf-drums-smtpupd-07.txt. - -(i) Removed "implied RSET" text associated with QUIT, as specified at -the December 1997 IETF. - -(ii) Required that servers support EHLO, as specified at the December -1997 IETF. - -X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt and -draft-ietf-drums-smtpupd-08.txt. - -This version involves mostly editorial work and cleanup of loose ends. - -(i) New 7.5 added (old one renumbered) to discuss info disclosure -through Received fields. - -(ii) Some character set and minor syntax issues clarified. - -(iii) Material on code 571 added (thought this had been done long ago; -slipped through the cracks) - -(iv) Many clarifications added as the result of list discussions and -suggestions. - -(v) Error code presentation has been restructured. - -(vi) ABNF conversion done - -(vii) IPv6 address format inserted per RFC 1884, since we could not get -clear agreement on an alternative. - -(viii) Trivial, silly, examples removed. Others not yet renumbered. - -(ix) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes. Eric -may not like the way I've done either of these change very much: the -first now makes the distinction between returning an address and -returning other stuff (which was permitted by -06, but the text wasn't -as clear as it should have been): if it looks like an address, it needs -to be an address. Similarly, with 4.1.1, Eric wanted to explicitly -permit/legitimize "DATA <SP> <CRLF>". I see several disadvantages to -doing that, so have inserted language that encourages receivers to -tolerate trailing white space, which may have the same practical effect. - - -X.1.9. Substantive changes between draft-ietf-drums-smtpupd-08.txt and -draft-ietf-drums-smtpupd-09.txt. - -The first ten of these reflect, in order, minuted items from the -Chicago IETF (IETF 42). - -(i) Clarification of "MUST", etc., in the context of this document -(section 2.3). - -(ii) Altered VRFY text to make implementation a SHOULD (section 3.5.1) -and removed VRFY from the mandatory to implement list (section 4.5.1), -per 42nd IETF (Chicago). - -(iii) Clarified that exploders are expected to not purge sender -addresses from lists (section 3.10). Note that the Chicago conclusion -was that this should be a "MUST". I could not figure out how to do -that without absolutely prohibiting removing addresses to prevent -loops, to guard against spammers, or for similar legitimate purposes. -So I have written this as a "SHOULD", with additional "strongly -discouraged" words. If someone still wants a MUST, suggest text. - -(iv) Altered text to permit clients that sometimes, or even always, -initiate sessions with HELO, rather than EHLO, to be fully-conforming -(section 3.2). [[ Editor's note: I continue to believe that a client -that does not have any service extension support, even to the extent of -being able to send EHLO and parse the response without doing anything -about it, should not be considered fully-conforming to this spec (as -distinct from 821). Consequently, the new text in 3.2 stops well short -of encouraging clients that don't need service extensions from -preferentially using HELO, and the text in 2.2.1 (which specifies that -the extension mechanisms must be supported) has not been changed. - -(v) Per Chicago discussions, the text requiring that QUIT be sent has -not been changed. The text in 4.1.1.10 requiring that the server wait -for QUIT has been changed to a SHOULD. However, the text in 4.1.1.5, -prohibiting close on receipt of RSET and that elsewhere prohibiting -close as a normal response, has not been changed. - -(vi) Text has been inserted in 4.1.1 and the text in 4.3.2 altered -slightly to clarify the handling of parameters to RSET, DATA, and QUIT -and to 4.1.1.9 specify semantics for parameters to NOOP. I have -followed the minutes on this although I personally agree with kre's -mailing list comments that the "servers SHOULD reject" decision leads -to silly states. I recommend that the WG review this. - -(vii) Per discussion in Chicago, no substantive change has been made to -the specification about underscore characters in domain names (section -4.1.2). However, the text has been altered to more accurately reflect -discussion on the mailing list and the source of the requirement. - -(viii) Per discussion in Chicago, no change has been made to the -preference for local time in Received headers. - -(ix) Per discussion in Chicago, code 571 has been removed and policy -rejection is now reflected i a 550 code (section 3.7 and the response -code lists). - -(x) Per discussion in Chicago, no change has been made to the -specification of use of raw CR or LF. - -(xi) In section 4.3, the text has been changed, per comments from Dan -Bernstein and others, to require that clients be able to handle replies -that do not contain text strings. A few other places patched to match. - -(xii) In sections 4.1.1.1 and 8, the placeholders have been removed. - -(xiii) Per discussion on the mailing list (and specifically James -Berriman's concerns), the text has been clarified (sections 4.1.1.2 and -4.1.4) to prohibit MAIL unless no mail transaction is open. This is a -MUST NOT prohibition -- SHOULD NOT makes no sense if this is the -direction we are going to go. 503 has also been added to the list of -valid responses for "MAIL" in 4.3.1 - it can't be issued before -EHLO/HELO in any event. While it is clear that something should be -said, this may not be the desired outcome (I selected it because it was -conservative and easy given the text that was there already); the WG -should check that the text is as intended. - -(xiv) Per discussion on the mailing list, a new section 4.5.5 has been -added to describe null return paths and their handling (forward pointer -from 3.7). The text in 4.5.5 is substantially that suggested by -Norbert Bollow. As with (xiii), there is now clear text, but it may -not be what the WG desires. Please check. - -(xv) "all addresses" substituted for "each...in turn" in 3.10.2. - -(xvi) Requirement for "<" and ">" around paths clarified in section 3.3 -(syntax productions were clear and correct, but not this overview -material). - -(xvii) Clarified text in 3.3 to permit post-DATA bounces on policy -matters. - - -X.1.10. Substantive changes between draft-ietf-drums-smtpupd-09.txt and -draft-ietf-drums-smtpupd-10.txt. - -(i) A large series of typos, most of them caught by Philip Hazel, -corrected. - -(ii) Residual problems with references to mailboxes, forward, and -reverse paths in 4.1.1.2 and 4.1.1.3 corrected and some text, I hope, -clarified. - -(iii) Text added to 4.2.5 to talk about 5yz errors after DATA. This -text should be checked carefully -- it is a proposal and may or may not -reflect WG consensus. - -(iv) Upper bound on "seconds" has been changed to 60 (not 61), per list -discussion. Years are still four-digits and will stay that way unless -the list discussion converges on something else. The increase to 60 -seconds includes an explicit note about leap seconds. - -(v) Text has been inserted to reflect the Orlando consensus about -"QUIT", i.e., the client MUST send a QUIT command and SHOULD wait for -the results before closing the connection. Servers are still not -permitted to close without receiving a QUIT and sending a 221 response -(except, of course, under the usual "unavoidable circumstances", in -which case they should get off a 451 if that is feasible). - -(vi) The EHLO response specification has been changed back to reflect -non-advertisement of VRFY and some text implying that VRFY was optional -to support has been removed (WG consensus seemed to be moving in that -direction at one point, and the editor reacted prematurely). This -makes the text compatible with RFC1869 and restores VRFY to its RFC1123 -status. - -(vii) The text in section 5 has been clarified with regard to what a -relay that receives a message because of its designation as an MX can -do and 3.7 has been slightly modified to point to it. - -(viii) New text has been added to 3.7 to clarify the use of "SMTP -server" relays in "dumb" originating clients. - -(viii) Small wording changes inserted into 4.1.4 (e.g., insertion of ", -if possible," into the first sentence of the fifth paragraph to -eliminate the apparent conflict with the second sentence). - - -X.1.11. Substantive changes between draft-ietf-drums-smtpupd-10.txt and -draft-ietf-drums-smtpupd-11.txt. Note that the most significant change -is the insertion of RFC 2234-conforming ABNF throughout. That material -should be checked carefully. - -(i) Dumb client text revised again, as discussed on the list and using -the text agreed to there. New text simply notes that the submission -issues are outside the scope of the spec/standard. - -(ii) ABNF updated and replaced (thanks, Chris). Some possible issues/ -questions: - - (ii.1) RFC 1869 permits a NUL octet in the greeting (ehlo-greet in - the syntax). Chris proposes to remove that capability on the - grounds that it has no obvious value and will probably not - work with many servers anyway. - - (ii.2) Previous drafts have assumed that the tag to indicate what - is coming in a non-IPv4 address literal will be separated by - the address itself by a space. Chris proposes to change it to - a colon, on the theory that this will cause fewer parsing - problems with existing MTAs and MUAs. - - (ii.3) The full IPv6 address syntax has been transposed from - the prose of RFC2373 into ABNF. It can be left out and 2373 - cited if the WG prefers. - -(iii) Added firewall clarification to section 2.3.8. - -(iv) Small clarifications and tightenings in several sections, notably -the end of 3.7, 3.8.3, 4.5.4.2, 7.2, clarifying editorial changes -elsewhere, slightly improved crossreferences, and some redundant -sections stripped out. Many thanks to Graham Klyne for extensive -and specific comments in these areas. - -(v) The "TO:" in "RCPT TO:" is part of an argument, not part of the -command. Similarly for "FROM:" in "MAIL FROM:". All of these are -believed to be fixed. - -(vi)Section 2.3.5 has been changed to make it clear that restrictions -on the syntax and character set of domain names are part of the mail -system, not an intrinsic limit of the DNS itself. This, and some -other text, are not going to be popular with those working to -internationalize the DNS, but I believe it is important to lay down a -clear baseline and then start making modifications or extensions, -rather than trying to delude ourselves with a DNS equivalent of "just -send 8". - -(vii) Clarified the EHLO-> HELO fallback requirement in 3.2. I think -this is consistent with what the WG wanted; if not, I'm sure I'll hear -about it. - - - - - -Z. Full Copyright Statement - -Copyright (C) The Internet Society (1998-2000). All Rights Reserved. - -This document and translations of it may be copied and furnished to -others, and derivative works that comment on or otherwise explain it or -assist in its implementation may be prepared, copied, published and -distributed, in whole or in part, without restriction of any kind, -provided that the above copyright notice and this paragraph are -included on all such copies and derivative works. However, this -document itself may not be modified in any way, such as by removing the -copyright notice or references to the Internet Society or other -Internet organizations, except as needed for the purpose of developing -Internet standards in which case the procedures for copyrights defined -in the Internet Standards process must be followed, or as required to -translate it into languages other than English. - -The limited permissions granted above are perpetual and will not be -revoked by the Internet Society or its successors or assigns. - -This document and the information contained herein is provided on an -"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING -TASK FORCE DISCLAIMS 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. - -Expires September 9, 2000. diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-12.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-12.txt deleted file mode 100644 index e57ab185..00000000 --- a/Documentation/en/I-D/draft-ietf-drums-smtpupd-12.txt +++ /dev/null @@ -1,4076 +0,0 @@ -INTERNET-DRAFT John C. Klensin, Editor -Expires December 2000 -July 10, 2000 - - - Simple Mail Transfer Protocol - - draft-ietf-drums-smtpupd-12.txt - -Status of this Memo - -This document is an Internet-Draft and is in full conformance with -all provisions of Section 10 of RFC2026. - -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. - -[[Appendix X will be removed before the document is submitted to the -IESG.]] - -[[If consensus is reached on this document, it will be forwarded to the -IESG with the recommendation that it be processed onto the Standards -track.]] - -Copyright Notice - -Copyright (C) The Internet Society (2000). All Rights Reserved. - - Table of Contents - -0. Abstract - -1. Introduction - -2. The SMTP Model -2.1 Basic Structure -2.2 The Extension Model -2.2.1 Background -2.2.2 Definition and Registration of Extensions -2.3 Terminology -2.3.1 Mail Objects -2.3.2 Senders and Receivers -2.3.3 Mail Agents and Message Stores -2.3.4 Host -2.3.5 Domain -2.3.6 Buffer and State Table -2.3.7 Lines -2.3.8 Originator, Delivery, Relay, and Gateway Systems -2.3.9 Message Content and Mail Data -2.3.10 Mailbox and Address -2.3.11 Reply -2.4 General Syntax Principles and Transaction Model - -3. The SMTP Procedures: An Overview -3.1 Session Initiation -3.2 Client Initiation -3.3 Mail Transactions -3.4 Forwarding for Address Correction or Updating -3.5 Commands for Debugging Addresses -3.5.1 Overview -3.5.2 VRFY Normal Response -3.5.3 Meaning of VRFY or EXPN Success Response -3.5.4 Semantics and Applications of EXPN -3.6 Domains -3.7 Relaying -3.8 Mail Gatewaying -3.8.1 Header Fields in Gatewaying -3.8.2 Received Lines in Gatewaying -3.8.3 Addresses in Gatewaying -3.8.4 Other Header Fields in Gatewaying -3.8.5 Envelopes in Gatewaying -3.9 Terminating Sessions and Connections -3.10 Mailing Lists and Aliases -3.10.1 Alias -3.10.2 List - -4. The SMTP Specifications -4.1 SMTP Commands -4.1.1 Command Semantics and Syntax -4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) -4.1.1.2 MAIL (MAIL) -4.1.1.3 RECIPIENT (RCPT) -4.1.1.4 DATA (DATA) -4.1.1.5 RESET (RSET) -4.1.1.6 VERIFY (VRFY) -4.1.1.7 EXPAND (EXPN) -4.1.1.8 HELP (HELP) -4.1.1.9 NOOP (NOOP) -4.1.1.10 QUIT (QUIT) -4.1.2 Command Argument Syntax -4.1.3 Address Literals -4.1.4 Order of Commands -4.1.5 Private-use Commands -4.2 SMTP Replies -4.2.1 Reply Code Severities and Theory -4.2.2 Reply Codes by Function Groups -4.2.3 Reply Codes in Numeric Order -4.2.4 Reply Code 502 -4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> -4.3 Sequencing of Commands and Replies -4.3.1 Sequencing Overview -4.3.2 Command-Reply Sequences -4.4 Trace Information -4.5 Additional Implementation Issues -4.5.1 Minimum Implementation -4.5.2 Transparency -4.5.3 Sizes and Timeouts -4.5.3.1 Size limits and minimums -4.5.3.2 Timeouts -4.5.4 Retry Strategies -4.5.4.1 Sending Strategy -4.5.4.2 Receiving Strategy -4.5.5 Messages with a null reverse-path - -5. Address Resolution and Mail Handling - -6. Problem Detection and Handling -6.1 Reliable Delivery and Replies by Email -6.2 Loop Detection -6.3 Compensating for Irregularities - -7. Security Considerations -7.1 Mail Security and Spoofing -7.2 "Blind" Copies -7.3 VRFY, EXPN, and Security -7.4 Information Disclosure in Announcements -7.5 Information Disclosure in Trace Fields -7.6 Information Disclosure in Message Forwarding -7.7 Scope of Operation of SMTP Servers - -8. IANA Considerations - -9. References - -10. Editors' Addresses - -11. Acknowledgments - -Appendices -A. TCP Transport Service -B. Generating SMTP Commands from RFC 822 Headers -C. Source Routes -D. Scenarios -E. Other Gateway Issues -F. Deprecated Features of RFC 821 -X. Change Summary and Loose Ends (Temporary) - - -0. Abstract - -This document is a self-contained specification of the basic protocol for -the Internet electronic mail transport, consolidating and updating: - - - the original SMTP specification of RFC 821 [RFC-821], - - - domain name system requirements and implications for mail transport from - RFC 1035 [RFC-DNS] and RFC 974 [RFC-974], - - - the clarifications and applicability statements in RFC 1123 [RFC-1123], - and - - - material drawn from the SMTP Extension mechanisms [SMTPEXT]. - -It replaces RFC 821, RFC 974, and the mail transport materials of RFC -1123. However, RFC 821 specifies some features that were not in -significant use in the Internet by the mid-1990s and (in appendices) -some additional transport models. Those sections are omitted here in -the interest of clarity and brevity; readers needing them should -refer to RFC 821. - -It also includes some additional material from RFC 1123 that required -amplification. This material has been identified in multiple ways, mostly -by tracking flaming on various lists and newsgroups and problems of unusual -readings or interpretations that have turned up as the SMTP extensions have -been deployed. Where this specification moves beyond consolidation and -actually differs from earlier documents, it supersedes them technically as -well as textually. - -Although SMTP was designed as a mail transport and delivery protocol, this -specification also contains information that is important to its use as a -'mail submission' protocol, as recommended for POP [RFC-POP2, RFC-POP3] -and IMAP [RFC-IMAP4]. Additional submission issues are discussed in RFC -2476 [SUBMIT]. - -Section 2.3 provides definitions of terms specific to this document. Except -when the historical terminology is necessary for clarity, this document -uses the current 'client' and 'server' terminology to identify the sending -and receiving SMTP processes, respectively. - -A companion document [MSGFMT] discusses message headers, message bodies -and formats and structures for them, and their relationship. - -Comments on this draft should be addressed to the IETF DRUMS Working -Group: - General Discussion:drums@cs.utk.edu - To Subscribe: drums-request@cs.utk.edu - Archive: ftp://cs.utk.edu/pub/drums/mail-archive/ - - - -1. Introduction - -The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer -mail reliably and efficiently. - -SMTP is independent of the particular transmission subsystem and requires -only a reliable ordered data stream channel. While this document -specifically discusses transport over TCP, other transports are possible. -Appendices to RFC 821 describe some of them. - -An important feature of SMTP is its capability to transport mail across -networks, usually referred to as "SMTP mail relaying" (see section 3.8). -A network consists of the mutually-TCP-accessible hosts on the public -Internet, the mutually-TCP-accessible hosts on a firewall-isolated TCP/IP -Intranet, or hosts in some other LAN or WAN environment utilizing a -non-TCP transport-level protocol. Using SMTP, a process can transfer -mail to another process on the same network or to some other network via -a relay or gateway process accessible to both networks. - -In this way, a mail message may pass through a number of intermediate -relay or gateway hosts on its path from sender to ultimate recipient. -The Mail eXchanger mechanisms of the domain name system [RFC-DNS, and -section 5 of this document] are used to identify the appropriate next-hop -destination for a message being transported. - - -2. The SMTP Model - -2.1 Basic Structure - -The SMTP design can be pictured as: - - +----------+ +----------+ - +------+ | | | | - | User |<-->| | SMTP | | - +------+ | Client- |Commands/Replies| Server- | - +------+ | SMTP |<-------------->| SMTP | +------+ - | File |<-->| | and Mail | |<-->| File | - |System| | | | | |System| - +------+ +----------+ +----------+ +------+ - SMTP client SMTP server - -When an SMTP client has a message to transmit, it establishes a two-way -transmission channel to an SMTP server. The responsibility of an SMTP client is to -transfer mail messages to one or more SMTP servers, or report its failure -to do so. - -The means by which a mail message is presented to an SMTP client, and how -that client determines the domain name(s) to which mail messages are to be -transferred is a local matter, and is not addressed by this document. In -some cases, the domain name(s) transferred to, or determined by, an SMTP -client will identify the final destination(s) of the mail message. In other -cases, common with SMTP clients associated with implementations of the POP -[RFC-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the SMTP client -is inside an isolated transport service environment, the domain name -determined will identify an intermediate destination through which all mail -messages are to be relayed. SMTP clients that transfer all traffic, -regardless of the target domain names associated with the individual -messages, or that do not maintain queues for retrying message transmissions -that initially cannot be completed, may otherwise conform to this -specification but are not considered fully-capable. Fully-capable SMTP -implementations, including the relays used by these less capable ones, and -their destinations, are expected to support all of the queuing, retrying, -and alternate address functions discussed in this specification. - -The means by which an SMTP client, once it has determined a target domain -name, determines the identity of an SMTP server to which a copy of a -message is to be transferred, and then performs that transfer, is covered -by this document. To effect a mail transfer to an SMTP server, an SMTP -client establishes a two-way transmission channel to that SMTP server. An -SMTP client determines the address of an appropriate host running an SMTP -server by resolving a destination domain name to either an intermediate -Mail eXchanger host or a final target host. - -An SMTP server may be either the ultimate destination or an intermediate -"relay" (that is, it may assume the role of an SMTP client after receiving -the message) or "gateway" (that is, it may transport the message further -using some protocol other than SMTP). SMTP commands are generated by the -SMTP client and sent to the SMTP server. SMTP replies are sent from the -SMTP server to the SMTP client in response to the commands. - -In other words, message transfer can occur in a single connection between -the original SMTP-sender and the final SMTP-recipient, or can occur in a -series of hops through intermediary systems. In either case, a formal -handoff of responsibility for the message occurs: the protocol requires -that a server accept responsibility for either delivering a message or -properly reporting the failure to do so. - -Once the transmission channel is established and initial handshaking -completed, the SMTP client normally initiates a mail transaction. Such a -transaction consists of a series of commands to specify the originator and -destination of the mail and transmission of the message content (including -any headers or other structure) itself. When the same message is sent to -multiple recipients, this protocol encourages the transmission of only one -copy of the data for all recipients at the same destination (or -intermediate relay) host. - -The server responds to each command with a reply; replies may indicate that -the command was accepted, that additional commands are expected, or that a -temporary or permanent error condition exists. Commands specifying the -sender or recipients may include server-permitted SMTP service extension -requests as discussed in section 2.2. The dialog is purposely lock-step, -one-at-a-time, although this can be modified by mutually-agreed extension -requests such as in [RFC-Pipeline]. - -Once a given mail message has been transmitted, the client may either -request that the connection be shut down or may initiate other mail -transactions. In addition, an SMTP client may use a connection to an SMTP -server for ancillary services such as verification of email addresses or -retrieval of mailing list subscriber addresses. - -As suggested above, this protocol provides mechanisms for the transmission -of mail. This transmission normally occurs directly from the sending -user's host to the receiving user's host when the two hosts are connected -to the same transport service. When they are not connected to the same -transport service, transmission occurs via one or more relay SMTP servers. -An intermediate host that acts as either an SMTP relay or as a gateway into -some other transmission environment is usually selected through the use of -the domain name service (DNS) Mail eXchanger mechanism. - -Usually, intermediate hosts are determined via the DNS MX record, not by -explicit "source" routing (see section 5 and appendices C and F.2). - -2.2 The Extension Model - -2.2.1 Background - -In an effort that started in 1990, approximately a decade after RFC 821 was -completed, the protocol was modified with a "service extensions" model that -permits the client and server to agree to utilize shared functionality -beyond the original SMTP requirements. The SMTP extension mechanism defines -a means whereby an extended SMTP client and server may recognize each -other, and the server can inform the client as to the service extensions -that it supports. - -Contemporary SMTP implementations MUST support the basic extension -mechanisms. For instance, servers MUST support the EHLO command even if -they do not implement any specific extensions and clients SHOULD -preferentially utilize EHLO rather than HELO. (However, for compatibility -with older conforming implementations, SMTP clients and servers MUST -support the original HELO mechanisms as a fallback.) Unless the different -characteristics of HELO must be identified for interoperability purposes, -this document discusses only EHLO. - -SMTP is widely deployed and high-quality implementations have proven to be -very robust. However, the Internet community now considers some services to -be important that were not anticipated when the protocol was first -designed. If support for those services is to be added, it must be done in -a way that permits older implementations to continue working acceptably. -The extension framework consists of: - - - The SMTP command EHLO, superseding the earlier HELO, - - - a registry of SMTP service extensions, - - - additional parameters to the SMTP MAIL and RCPT commands, and - - - optional replacements for commands defined in this protocol, such as for - DATA (see [RFC-BDAT]). - -SMTP's strength comes primarily from its simplicity. Experience with many -protocols has shown that protocols with few options tend towards ubiquity, -whereas protocols with many options tend towards obscurity. - -Each and every extension, regardless of its benefits, must be carefully -scrutinized with respect to its implementation, deployment, and -interoperability costs. In many cases, the cost of extending the SMTP -service will likely outweigh the benefit. - -2.2.2 Definition and Registration of Extensions - -The IANA maintains a registry of SMTP service extensions. A corresponding -EHLO keyword value is associated with each extension. Each service -extension registered with the IANA must be defined in a formal -standards-track or IESG-approved experimental protocol document. The -definition must include: - - - the textual name of the SMTP service extension; - - - the EHLO keyword value associated with the extension; - - - the syntax and possible values of parameters associated with the - EHLO keyword value; - - - any additional SMTP verbs associated with the extension (additional - verbs will usually be, but are not required to be, the same as the - EHLO keyword value); - - - any new parameters the extension associates with the MAIL or RCPT - verbs; - - - a description of how support for the extension affects the behavior - of a server and client SMTP; and, - - - the increment by which the extension is increasing the maximum - length of the commands MAIL and/or RCPT, over that specified - in this standard. - -In addition, any EHLO keyword value starting with an upper or lower case -"X" refers to a local SMTP service extension used exclusively through -bilateral agreement. Keywords beginning with "X" MUST NOT be used in a -registered service extension. Conversely, keyword values presented in the -EHLO response that do not begin with "X" MUST correspond to a standard, -standards-track, or IESG-approved experimental SMTP service extension -registered with IANA. A conforming server MUST NOT offer non-"X"-prefixed -keyword values that are not described in a registered extension. - -Additional verbs and parameter names are bound by the same rules as EHLO -keywords; specifically, verbs beginning with "X" are local extensions that -may not be registered or standardized. Conversely, verbs not beginning -with "X" must always be registered. - -2.3 Terminology - -Most of the terminology in this document is common in the Internet at the -time of its writing. However, the following terms and concepts are used -in special ways here, or represent differences in terminology between RFC -821 and this document, and should be understood before reading further. -These definitions are normative, that is, they contain specifications to -which SMTP implementations are required to conform. - -The terms "MUST" and "SHOULD" (and "MUST NOT" and "SHOULD NOT") are -used in the same general sense here as in the Host Requirements -Standards [RFC-1123]. Specifically, "MUST" or "MUST NOT" identify -absolute requirements for conformance to this specification. -Implementations that do not conform to them lie outside the scope of -this specification and often will not interoperate properly with SMTP -implementations that do conform. Implementations that are fully -conforming also adhere to all "SHOULD" and "SHOULD NOT" requirements. -Implementations that adhere to all "MUST" ("MUST NOT") but not to all -of these are considered to be partially conforming. Such -implementations may interoperate properly with fully conforming ones -and with each other, but this will typically be the case only if great -care is taken. Consequently, an implementation should violate "SHOULD" -("SHOULD NOT") requirements only under exceptional and well-understood -circumstances. "SHOULD" (and sometimes "MUST") requirements are often -imposed by this specification when experience has shown that following -such requirements or restrictions leads, in practice, to better -interoperation, or smoother operation of the Internet email -infrastructure. As a consequence, some of these statements constitute -recommended practices, rather than the statistically most common -practice at the time of this writing. Statements using "MAY" describe -features or styles of doing things that may be followed, or not, at the -discretion of the implementation, normally without causing significant -interoperability problems. - -2.3.1 Mail Objects - -SMTP transports a mail object. A mail object contains an envelope and -content. - -The SMTP envelope is sent as a series of SMTP protocol units (described -in section 3). It consists of an originator address (to which error -reports should be directed); one or more recipient addresses; and optional -protocol extension material. Historically, variations on the recipient -address specification command (RCPT TO) could be used to specify alternate -delivery modes, such as immediate display; those variations have now been -deprecated (see appendix F, section F.6). - -The SMTP content is sent in the SMTP DATA protocol unit and has two -parts: the headers and the body. If the content conforms to other -contemporary standards, the headers form a collection of field/value -pairs structured as described in [MSGFMT]; the body, if structured, is -defined according to MIME [RFC-MIME]. The content is textual in nature, -expressed using the US-ASCII repertoire [US-ASCII]. Although SMTP -extensions (such as [8BitMIME]) may relax this restriction for the -content body, the content headers are always encoded using the US-ASCII -repertoire. The algorithm defined in [RFC-INTLHDR] is used to represent -header values outside the US-ASCII repertoire, while still encoding -them using the US-ASCII repertoire. - -2.3.2 Senders and Receivers - -In RFC 821, the two hosts participating in an SMTP transaction were -described as the "SMTP-sender" and "SMTP-receiver". This document has -been changed to reflect current industry terminology and hence refers -to them as the "SMTP client" (or sometimes just "the client") and "SMTP -server" (or just "the server"), respectively. Since a given host may -act both as server and client in a relay situation, "receiver" and -"sender" terminology is still used where needed for clarity. - -2.3.3 Mail Agents and Message Stores - -Additional mail system terminology became common after RFC 821 was -published and, where convenient, is used in this specification. In -particular, SMTP servers and clients provide a mail transport service -and therefore act as "Mail Transfer Agents" (MTAs). "Mail User Agents" -(MUAs or UAs) are normally thought of as the sources and targets of -mail. At the source, an MUA might collect mail to be transmitted from -a user and hand it off to an MTA; the final ("delivery") MTA would be -thought of as handing the mail off to an MUA (or at least transferring -responsibility to it, e.g., by depositing the message in a "message -store"). However, while these terms are used with at least the -appearance of great precision in other environments, the implied -boundaries between MUAs and MTAs often do not accurately match common, -and conforming, practices with Internet mail. Hence, the reader should -be cautious about inferring the strong relationships and -responsibilities that might be implied if these terms were used -elsewhere. - -2.3.4 Host - -For the purposes of this specification, a host is a computer system -attached to the Internet (or, in some cases, to a private TCP/IP -network) and supporting the SMTP protocol. Hosts are known by names -(see "domain"); identifying them by numerical address is discouraged. - -2.3.5 Domain - -A domain (or domain name) consists of one or more dot-separated -components. These components ("labels" in DNS terminology [RFC-DNS] -are restricted for SMTP purposes to consist of a sequence of letters, -digits, and hyphens drawn from the ASCII character set [US-ASCII]. -Domain names are used as names of hosts and of other entities in the -domain name hierarchy. For example, a domain may refer to an alias -(label of a CNAME RR) or the label of Mail eXchanger records to be used -to deliver mail instead of representing a host name. See [RFC-DNS] and -section 5. - -The domain name, as described in this document and in [RFC-DNS], is the -entire, fully-qualified name (often referred to as an "FQDN"). A -domain name that is not in FQDN form is no more than a local alias. -Local aliases MUST NOT appear in any SMTP transaction. - -2.3.6 Buffer and State Table - -SMTP sessions are stateful, with both parties carefully maintaining a -common view of the current state. In this document we model this state -by a virtual "buffer" and a "state table" on the server which may be -used by the client to, for example, "clear the buffer" or "reset the -state table," causing the information in the buffer to be discarded and -the state to be returned to some previous state. - -2.3.7 Lines - -SMTP commands and, unless altered by a service extension, message data, -are transmitted in "lines". Lines consist of zero or more data -characters terminated by the sequence ASCII character "CR" (hex value -0D) followed immediately by ASCII character "LF" (hex value 0A). This -termination sequence is denoted as <CRLF> in this document. Conforming -implementations MUST NOT recognize or generate any other character or -character sequence as a line terminator. Limits MAY be imposed on line -lengths by servers (see section 4.5.3). - -In addition, the appearance of "bare" "CR" or "LF" characters in text -(i.e., either without the other) has a long history of causing problems in -mail implementations and applications that use the mail system as a tool. -SMTP client implementations MUST NOT transmit these characters except when -they are intended as line terminators and then MUST, as indicated above, -transmit them only as a <CRLF> sequence. - -2.3.8 Originator, Delivery, Relay, and Gateway Systems - -This specification makes a distinction among four types of SMTP -systems, based on the role those systems play in transmitting -electronic mail. An "originating" system (sometimes called an SMTP -originator) introduces mail into the Internet or, more generally, into -a transport service environment. A "delivery" SMTP system is one that -receives mail from a transport service environment and passes it to a -mail user agent or deposits it in a message store which a mail user -agent is expected to subsequently access. A "relay" SMTP system -(usually referred to just as a "relay") receives mail from an SMTP -client and transmits it, without modification to the message data other -than adding trace information, to another SMTP server for further -relaying or for delivery. - -A "gateway" SMTP system (usually referred to just as a "gateway") -receives mail from a client system in one transport environment and -transmits it to a server system in another transport environment. -Differences in protocols or message semantics between the transport -environments on either side of a gateway may require that the gateway -system perform transformations to the message that are not permitted to -SMTP relay systems. For the purposes of this specification, firewalls -that rewrite addresses should be considered as gateways, even if SMTP -is used on both sides of them. (See [IAB-Firewalls].) - -2.3.9 Message Content and Mail Data - -The terms "message content" and "mail data" are used interchangeably in -this document to describe the material transmitted after the DATA -command is accepted and before the end of data indication is -transmitted. Message content includes message headers and the -possibly-structured message body. The MIME specification [RFC-MIME] -provides the standard mechanisms for structured message bodies. - -2.3.10 Mailbox and Address - -As used in this specification, an "address" is a character string that -identifies a user to whom mail will be sent or a location into which -mail will be deposited. The term "mailbox" refers to that depository. -The two terms are typically used interchangeably unless the distinction -between the location in which mail is placed (the mailbox) and a -reference to it (the address) is important. An address normally -consists of user and domain specifications. The standard mailbox -naming convention is defined to be "local-part@domain": contemporary -usage permits a much broader set of applications than simple "user -names". Consequently, and due to a long history of problems when -intermediate hosts have attempted to optimize transport by modifying -them, the local-part MUST be interpreted and assigned semantics only by -the host specified in the domain part of the address. - -2.3.11 Reply - -An SMTP reply is an acknowledgment (positive or negative) sent from -receiver to sender via the transmission channel in response to a -command. The general form of a reply is a numeric completion code -(indicating failure or success) usually followed by a text string. The -codes are for use by programs and the text is usually intended for -human users. Recent work [RFC-Reply] has specified further structuring -of the reply strings, including the use of supplemental and more -specific completion codes. - -2.4 General Syntax Principles and Transaction Model - -SMTP commands and replies have a rigid syntax. All commands begin with -a four letter command verb. All Replies begin with a three digit -numeric code. In some commands and replies, arguments MUST follow the -verb or reply code. Some commands do not accept arguments (after the -verb), and some reply codes are followed, sometimes optionally, by free -form text. In both cases, where text appears, it is separated from the -verb or reply code by a space character. Complete definitions of -commands and replies appear in section 4. - -Verbs and argument values (e.g., "TO:" or "to:" in the MAIL command and -extension name keywords) are not case sensitive, with the sole -exception in this specification of a mailbox local-part (SMTP -Extensions may explicitly specify case-sensitive elements). That is, a -command verb, an argument value other than a mailbox local-part, and -free form text MAY be encoded in upper case, lower case, or any mixture -of upper and lower case with no impact on its meaning. This is NOT -true of a mailbox local-part. The local-part of a mailbox MUST BE -treated as case sensitive. Therefore, SMTP implementations MUST take -care to preserve the case of mailbox local-parts. Mailbox domains are -not case sensitive. In particular, for some hosts the user "smith" is -different from the user "Smith". However, exploiting the case -sensitivity of mailbox local-parts impedes interoperability and is -discouraged. - -A few SMTP servers, in violation of this specification (and RFC 821) -require that command verbs be encoded by clients in upper case. -Implementations MAY wish to employ this encoding to accommodate those -servers. - -The argument field consists of a variable length character string -ending with the end of the line, i.e., with the character sequence -<CRLF>. The receiver will take no action until this sequence is -received. - -The syntax for each command is shown with the discussion of that -command. Common elements and parameters are shown in section 4.1.2. - -Commands and replies are composed of characters from the ASCII -character set [US-ASCII]. When the transport service provides an 8-bit -byte (octet) transmission channel, each 7-bit character is transmitted -right justified in an octet with the high order bit cleared to zero. -More specifically, the unextended SMTP service provides seven bit -transport only. An originating SMTP client which has not successfully -negotiated an appropriate extension with a particular server MUST NOT -transmit messages with information in the high-order bit of octets. If -such messages are transmitted in violation of this rule, receiving SMTP -servers MAY clear the high-order bit or reject the message as invalid. -In general, a relay SMTP SHOULD assume that the message content it has -received is valid and, assuming that the envelope permits doing so, -relay it without inspecting that content. Of course, if the content is -mislabeled and the data path cannot accept the actual content, this may -result in ultimate delivery of a severely garbled message to the -recipient. Delivery SMTP systems MAY reject ("bounce") such messages -rather than deliver them. No sending SMTP system is permitted to send -envelope commands in any character set other than US-ASCII; receiving -systems SHOULD reject such commands, normally using "500 syntax error - -invalid character" replies. - -Eight-bit message content transmission MAY be requested of the server -by a client using extended SMTP facilities, notably the "8BITMIME" -extension [8BITMIME]. 8BITMIME SHOULD be supported by SMTP servers. -However, it MUST not be construed as authorization to transmit -unrestricted eight bit material. 8BITMIME MUST NOT be requested by -senders for material with the high bit on that is not in MIME format -with an appropriate content-transfer encoding; servers MAY reject such -messages. - -The metalinguistic notation used in this document corresponds to the -"Augmented BNF" used in other Internet mail system documents. The -reader who is not familiar with that syntax should consult [ABNF]. -Metalanguage terms used in running text are surrounded by pointed -brackets (e.g., <CRLF>) for clarity. - - -3. The SMTP Procedures: An Overview - -This section contains descriptions of the procedures used in SMTP: -session initiation, the mail transaction, forwarding mail, verifying -mailbox names and expanding mailing lists, and the opening and closing -exchanges. Comments on relaying, a note on mail domains, and a -discussion of changing roles are included at the end of this section. -Several complete scenarios are presented in appendix D. - -3.1 Session Initiation - -An SMTP session is initiated when a client opens a connection to a -server and the server responds with an opening message. - -SMTP server implementations MAY include identification of their -software and version information in the connection greeting reply after -the 220 code, a practice that permits more efficient isolation and -repair of any problems. Implementations MAY make provision for SMTP -servers to disable the software and version announcement where it -causes security concerns. While some systems also identify their -contact point for mail problems, this is not a substitute for -maintaining the required "postmaster" address (see section 4.5.1). - -The SMTP protocol allows a server to formally reject a transaction -while still allowing the initial connection as follows: a 554 response -MAY be given in the initial connection opening message instead of the -220. A server taking this approach MUST still wait for the client to -send a QUIT (see section 4.1.1.10) before closing the connection and -SHOULD respond to any intervening commands with "503 bad sequence of -commands". Since an attempt to make an SMTP connection to such a -system is probably in error, a server returning a 554 response on -connection opening SHOULD provide enough information in the reply text -to facilitate debugging of the sending system. - -3.2 Client Initiation - -Once the server has sent the welcoming message and the client has -received it, the client normally sends the EHLO command to the server, -indicating the client's identity. In addition to opening the session, -use of EHLO indicates that the client is able to process service -extensions and requests that the server provide a list of the -extensions it supports. Older SMTP systems which are unable to support -service extensions and contemporary clients which do not require -service extensions in the mail session being initiated, MAY use HELO -instead of EHLO. Servers MUST NOT return the extended EHLO-style -response to a HELO command. For a particular connection attempt, if -the server returns a "command not recognized" response to EHLO, the -client SHOULD be able to fall back and send HELO. - -In the EHLO command the host sending the command identifies itself; the -command may be interpreted as saying "Hello, I am <domain>" (and, in -the case of EHLO, "and I support service extension requests"). - -3.3 Mail Transactions - -There are three steps to SMTP mail transactions. The transaction -starts with a MAIL command which gives the sender identification. A -series of one or more RCPT commands follows giving the receiver -information. Then a DATA command initiates transfer of the mail data -and is terminated by the "end of mail" data indicator, which also -confirms the transaction. - -The first step in the procedure is the MAIL command. - - MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF> - -This command tells the SMTP-receiver that a new mail transaction is -starting and to reset all its state tables and buffers, including any -recipients or mail data. The <reverse-path> portion of the first or -only argument contains the source mailbox (between "<" and ">" -brackets), which can be used to report errors (see section 4.2 for a -discussion of error reporting). If accepted, the SMTP server returns a -250 OK reply. If the mailbox specification is not acceptable for some -reason, the server MUST return a reply indicating whether the failure -is permanent (i.e., will occur again if the client tries to send the -same address again) or temporary (i.e., the address might be accepted -if the client tries again later). Despite the apparent scope of this -requirement, there are circumstances in which the acceptability of the -reverse-path may not be determined until one or more forward-paths (in -RCPT commands) can be examined. In those cases, the server MAY -reasonably accept the reverse-path (with a 250 reply) and then report -problems after the forward-paths are received and examined. Normally, -failures produce 550 or 553 replies. - -Historically, the <reverse-path> can contain more than just a mailbox, -however, contemporary systems SHOULD NOT use source routing (see -appendix C). - -The optional <mail-parameters> are associated with negotiated SMTP -service extensions (see section 2.2). - -The second step in the procedure is the RCPT command. - - RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF> - -The first or only argument to this command includes a forward-path -(normally a mailbox and domain, always surrounded by "<" and ">" -brackets) identifying one recipient. If accepted, the SMTP server -returns a 250 OK reply and stores the forward-path. If the recipient -is known not to be a deliverable address, the SMTP server returns a 550 -reply, typically with a string such as "no such user - " and the -mailbox name (other circumstances and reply codes are possible). This -step of the procedure can be repeated any number of times. - -The <forward-path> can contain more than just a mailbox. Historically, -the <forward-path> can be a source routing list of hosts and the -destination mailbox, however, contemporary SMTP clients SHOULD NOT -utilize source routes (see appendix C). Servers MUST be prepared to -encounter a list of source routes in the forward path, but SHOULD -ignore the routes or MAY decline to support the relaying they imply. -Similarly, servers MAY decline to accept mail that is destined for -other hosts or systems. These restrictions make a server useless as a -relay for clients that do not support full SMTP functionality. -Consequently, restricted-capability clients MUST NOT assume that any -SMTP server on the Internet can be used as their mail processing -(relaying) site. If a RCPT command appears without a previous MAIL -command, the server MUST return a 503 "Bad sequence of commands" -response. The optional <rcpt-parameters> are associated with negotiated -SMTP service extensions (see section 2.2). - -The third step in the procedure is the DATA command (or some -alternative specified in a service extension). - - DATA <CRLF> - -If accepted, the SMTP server returns a 354 Intermediate reply and -considers all succeeding lines up to but not including the end of mail -data indicator to be the message text. When the end of text is -successfully received and stored the SMTP-receiver sends a 250 OK reply. - -Since the mail data is sent on the transmission channel, the end of -mail data must be indicated so that the command and reply dialog can be -resumed. SMTP indicates the end of the mail data by sending a line -containing only a "." (period or full stop). A transparency procedure -is used to prevent this from interfering with the user's text (see -section 4.5.2). - -The end of mail data indicator also confirms the mail transaction and -tells the SMTP server to now process the stored recipients and mail -data. If accepted, the SMTP server returns a 250 OK reply. The DATA -command can fail at only two points in the protocol exchange: - - - If there was no MAIL, or no RCPT, command, or all such commands - were rejected, the server MAY return a "command out of sequence" - (503) or "no valid recipients" (554) reply in response to the DATA - command. If one of those replies (or any other 5yz reply) is - received, the client MUST NOT send the message data; more generally, - message data MUST NOT be sent unless a 354 reply is received. - - - If the verb is initially accepted and the 354 reply issued, the DATA - command should fail only if the mail transaction was incomplete (for - example, no recipients), or if resources were unavailable - (including, of course, the server unexpectedly becoming - unavailable), or if the server determines that the message should be - rejected for policy or other reasons. - -However, in practice, some servers do not perform recipient -verification until after the message text is received. These servers -SHOULD treat a failure for one or more recipients as a "subsequent -failure" and return a mail message as discussed in section 6. Using a -"550 mailbox not found" (or equivalent) reply code after the data are -accepted makes it difficult or impossible for the client to determine -which recipients failed. - -When RFC 822 format is being used, the mail data include the memo -header items such as Date, Subject, To, Cc, From [MSGFMT]. Server SMTP -systems SHOULD NOT reject messages based on perceived defects in the -RFC 822 or MIME [RFC-MIME] message header or message body. In -particular, they MUST NOT reject messages in which the numbers of -Resent- fields do not match or Resent-to appears without Resent-from -and/or Resent-date. - -Mail transaction commands MUST be used in the order discussed above. - - -3.4 Forwarding for Address Correction or Updating - -Forwarding support is most often required to consolidate and simplify -addresses within, or relative to, some enterprise and less frequently to -establish addresses to link a person's prior address with current one. -Silent forwarding of messages (without server notification to the sender), -for security or non-disclosure purposes, is common in the contemporary -Internet. - -In both the enterprise and the "new address" cases, information hiding (and -sometimes security) considerations argue against exposure of the "final" -address through the SMTP protocol as a side-effect of the forwarding -activity. This may be especially important when the final address may not -even be reachable by the sender. Consequently, the "forwarding" mechanisms -described in section 3.2 of RFC 821, and especially the 251 (corrected -destination) and 551 reply codes from RCPT must be evaluated carefully by -implementers and, when they are available, by those configuring systems. - -In particular: - -* Servers MAY forward messages when they are aware of an address change. - When they do so, they MAY either provide address-updating information - with a 251 code, or may forward "silently" and return a 250 code. But, - if a 251 code is used, they MUST NOT assume that the client will actually - update address information or even return that information to the user. - -Alternately, - -* Servers MAY reject or bounce messages when they are not deliverable when - addressed. When they do so, they MAY either provide address-updating - information with a 551 code, or may reject the message as undeliverable - with a 550 code and no address-specific information. But, if a 551 code - is used, they MUST NOT assume that the client will actually update - address information or even return that information to the user. - -SMTP server implementations that support the 251 and/or 551 reply codes are -strongly encouraged to provide configuration mechanisms so that sites which -conclude that they would undesirably disclose information can disable or -restrict their use. - - -3.5 Commands for Debugging Addresses - -3.5.1 Overview - -SMTP provides commands to verify a user name or obtain the content of a -mailing list. This is done with the VRFY and EXPN commands, which have -character string arguments. Implementations SHOULD support VRFY and -EXPN (however, see section 3.5.2 and 7.3). - -For the VRFY command, the string is a user name or a user name and -domain (see below). If a normal (i.e., 250) response is returned, the -response MAY include the full name of the user and MUST include the -mailbox of the user. It MUST be in either of the following forms: - - User Name <local-part@domain> - local-part@domain - -When a name that is the argument to VRFY could identify more than one -mailbox, the server MAY either note the ambiguity or identify the -alternatives. In other words, any of the following are legitimate -response to VRFY: - - 553 User ambiguous - -or - - 553- Ambiguous; Possibilities are - 553-Joe Smith <jsmith@foo.com> - 553-Harry Smith <hsmith@foo.com> - 553 Melvin Smith <dweep@foo.com> - -or - - 553-Ambiguous; Possibilities - 553- <jsmith@foo.com> - 553- <hsmith@foo.com> - 553 <dweep@foo.com> - -Under normal circumstances, a client receiving a 553 reply would be -expected to expose the result to the user. Use of exactly the forms -given, and the "user ambiguous" or "ambiguous" keywords, possibly -supplemented by extended reply codes such as those described in -[RFC-REPLY], will facilitate automated translation into other languages -as needed. Of course, a client that was highly automated or that was -operating in another language than English, might choose to try to -translate the response, to return some other indication to the user -than the literal text of the reply, or to take some automated action -such as consulting a directory service for additional information -before reporting to the user. - -For the EXPN command, the string identifies a mailing list, and the -successful (i.e., 250) multiline response MAY include the full name of -the users and MUST give the mailboxes on the mailing list. - -In some hosts the distinction between a mailing list and an alias for a -single mailbox is a bit fuzzy, since a common data structure may hold -both types of entries, and it is possible to have mailing lists of one -mailbox. If a request is made to verify a mailing list, a positive -response MAY be given if a message so addressed would be delivered to -everyone on the list, otherwise an error SHOULD be reported (e.g., "550 -That is a mailing list, not a user" or "252 Unable to verify members of -mailing list"). If a request is made to expand a user name, the server -MAY return a positive response consisting of a list containing one -name, or an error MAY be reported (e.g., "550 That is a user name, not -a mailing list"). - -In the case of a successful multiline reply (normal for EXPN) exactly -one mailbox is to be specified on each line of the reply. The case of -an ambiguous request is discussed above. - -"User name" is a fuzzy term and has been used deliberately. An -implementation of the VRFY or EXPN commands MUST include at least -recognition of local mailboxes as "user names". However, since current -Internet practice often results in a single host handling mail for -multiple domains, hosts, especially hosts that provide this -functionality, SHOULD accept the "local-part@domain" form as a "user -name"; hosts MAY also choose to recognize other strings as "user names". - -The case of expanding a mailbox list requires a multiline reply, such -as: - - C: EXPN Example-People - S: 250-Jon Postel <Postel@isi.edu> - S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu> - S: 250 Sam Q. Smith <SQSmith@specific.generic.com> - -or - - C: EXPN Executive-Washroom-List - S: 550 Access Denied to You. - -The character string arguments of the VRFY and EXPN commands cannot be -further restricted due to the variety of implementations of the user -name and mailbox list concepts. On some systems it may be appropriate -for the argument of the EXPN command to be a file name for a file -containing a mailing list, but again there are a variety of file naming -conventions in the Internet. Similarly, historical variations in what -is returned by these commands are such that the response SHOULD be -interpreted very carefully, if at all, and SHOULD generally only be -used for diagnostic purposes. - -3.5.2 VRFY Normal Response - -When normal (2yz or 551) responses are returned from a VRFY or EXPN -request, the reply normally includes the mailbox name, i.e., -"<local-part@domain>", where "domain" is a fully qualified domain name, -MUST appear in the syntax. In circumstances exceptional enough to justify -violating the intent of this specification, free-form text MAY be returned. -In order to facilitate parsing by both computers and people, addresses -SHOULD appear in pointed brackets. When addresses, rather than free-form -debugging information, are returned, EXPN and VRFY MUST return only valid -domain addresses that are usable in SMTP RCPT commands. Consequently, if -an address implies delivery to a program or other system, the mailbox name -used to reach that target MUST be given. Paths (explicit source routes) -MUST NOT be returned by VRFY or EXPN. - -Server implementations SHOULD support both VRFY and EXPN. For security -reasons, implementations MAY provide local installations a way to -disable either or both of these commands through configuration options -or the equivalent. When these commands are supported, they are not -required to work across relays when relaying is supported. Since they -were both optional in RFC 821, they MUST be listed as service -extensions in an EHLO response, if they are supported. - -3.5.3 Meaning of VRFY or EXPN Success Response - -A server MUST NOT return a 220 code in response to a VRFY or EXPN -command unless it has actually verified the address. In particular, a -server MUST NOT return 220 if all it has done is to verify that the -syntax given is valid. In that case, 502 (Command not implemented) or -500 (Syntax error, command unrecognized) SHOULD be returned. As stated -elsewhere, implementation (in the sense of actually validating -addresses and returning information) of VRFY and EXPN are strongly -recommended. Hence, implementations that return 500 or 502 for VRFY -are not in full compliance with this specification. - -There may be circumstances where an address appears to be valid but cannot -reasonably be verified in real time, particularly when a server is acting -as a mail exchanger for another server or domain. "Apparent validity" in -this case would normally involve at least syntax checking and might involve -verification that any domains specified were ones to which the host -expected to be able to relay mail. In these situations, reply code 252 -SHOULD be returned. These cases parallel the discussion of RCPT -verification discussed in section 2.1. Similarly, the discussion in -section 3.4 applies to the use of reply codes 251 and 551 with VRFY (and -EXPN) to indicate addresses that are recognized but that would be forwarded -or bounced were mail received for them. Implementations generally SHOULD -be more aggressive about address verification in the case of VRFY than in -the case of RCPT, even if it takes a little longer to do so. - -3.5.4 Semantics and Applications of EXPN - -EXPN is often very useful in debugging and understanding problems with -mailing lists and multiple-target-address aliases. Some systems have -attempted to use source expansion of mailing lists as a means of -eliminating duplicates. The propagation of aliasing systems with mail -on the Internet, for hosts (typically with MX and CNAME DNS records), -for mailboxes (various types of local host aliases), and in various -proxying arrangements, has made it nearly impossible for these -strategies to work, and mail systems SHOULD NOT attempt them. - -3.6 Domains - -Only resolvable, fully-qualified, domain names (FQDNs) are permitted -when domain names are used in SMTP. In other words, names that can be -resolved to MX RRs or A RRs (as discussed in section 5) are permitted, -as are CNAME RRs whose targets can be resolved, in turn, to MX or A -RRs. Local nicknames or unqualified names MUST NOT be used. There are -two exceptions to the rule requiring FQDNs: - - - The domain name given in the EHLO command MUST BE either a primary - host name (a domain name that resolves to an A RR) or, if the host - has no name, an address literal as described in section 4.1.1.1. - - - The reserved mailbox name "postmaster" may be used in a RCPT command - without domain qualification (see section 4.1.1.3) and MUST be - accepted if so used. - -3.7 Relaying - -In general, the availability of Mail eXchanger records in the domain -name system [RFC-DNS, RFC-974] makes the use of explicit source routes -in the Internet mail system unnecessary. Many historical problems with -their interpretation have made their use undesirable. SMTP clients -SHOULD NOT generate explicit source routes except under unusual -circumstances. SMTP servers MAY decline to act as mail relays or to -accept addresses that specify source routes. When route information is -encountered, SMTP servers are also permitted to ignore the route -information and simply send to the final destination specified as the -last element in the route and SHOULD do so. There has been an invalid -practice of using names that do not appear in the DNS as destination -names, with the senders counting on the intermediate hosts specified in -source routing to resolve any problems. If source routes are stripped, -this practice will cause failures. This is one of several reasons why -SMTP clients MUST NOT generate invalid source routes or depend on -serial resolution of names. - -When source routes are not used, the process described in RFC 821 for -constructing a reverse-path from the forward-path is not applicable and -the reverse-path at the time of delivery will simply be the address -that appeared in the MAIL command. - -A relay SMTP server is usually the target of a DNS MX record that -designates it, rather than the final delivery system. The relay server -may accept or reject the task of relaying the mail in the same way it -accepts or rejects mail for a local user. If it accepts the task, it -then becomes an SMTP client, establishes a transmission channel to the -next SMTP server specified in the DNS (according to the rules in -section 5), and sends it the mail. If it declines to relay mail to a -particular address for policy reasons, a 550 response SHOULD be -returned. - -Many mail-sending clients exist, especially in conjunction with -facilities that receive mail via POP3 or IMAP, that have limited -capability to support some of the requirements of this specification, -such as the ability to queue messages for subsequent delivery attempts. -For these clients, it is common practice to make private arrangements -to send all messages to a single server for processing and subsequent -distribution. SMTP, as specified here, is not ideally suited for this -role, and work is underway on standardized mail submission protocols -that might eventually supercede the current practices. In any event, -because these arrangements are private and fall outside the scope of -this specification, they are not described here. - -It is important to note that MX records can point to SMTP servers which -act as gateways into other environments, not just SMTP relays and final -delivery systems; see sections 3.8 and 5. - -If an SMTP server has accepted the task of relaying the mail and later -finds that the destination is incorrect or that the mail cannot be -delivered for some other reason, then it MUST construct an -"undeliverable mail" notification message and send it to the originator -of the undeliverable mail (as indicated by the reverse-path). Formats -specified for non-delivery reports by other standards (see, for -example, [RFC-NOTARY1]) SHOULD be used if possible. - -This notification message must be from the SMTP server at the relay -host or the host that first determines that delivery cannot be -accomplished. Of course, SMTP servers MUST NOT send notification -messages about problems transporting notification messages. One way to -prevent loops in error reporting is to specify a null reverse-path in -the MAIL command of a notification message. When such a message is -transmitted the reverse-path MUST be set to null (see section 4.5.5 for -additional discussion). A MAIL command with a null reverse-path -appears as follows: - - MAIL FROM:<> - -As discussed in section 2.4.1, a relay SMTP has no need to inspect or -act upon the headers or body of the message data and MUST NOT do so -except to add its own "Received:" header (section 4.4) and, optionally, -to attempt to detect looping in the mail system (see section 6.2). - -3.8 Mail Gatewaying - -While the relay function discussed above operates within the Internet -SMTP transport service environment, MX records or various forms of -explicit routing may require that an intermediate SMTP server perform a -translation function between one transport service and another. As -discussed in section 2.3.8, when such a system is at the boundary -between two transport service environments, we refer to it as a -"gateway" or "gateway SMTP". - -Gatewaying mail between different mail environments, such as different -mail formats and protocols, is complex and does not easily yield to -standardization. However, some general requirements may be given for a -gateway between the Internet and another mail environment. - -3.8.1 Header Fields in Gatewaying - -Header fields MAY be rewritten when necessary as messages are gatewayed -across mail environment boundaries. This may involve inspecting the -message body or interpreting the local-part of the destination address -in spite of the prohibitions in section 2.4.1 - -Other mail systems gatewayed to the Internet often use a subset of -RFC-822 headers or provide similar functionality with a different -syntax, but some of these mail systems do not have an equivalent to the -SMTP envelope. Therefore, when a message leaves the Internet -environment, it may be necessary to fold the SMTP envelope information -into the message header. A possible solution would be to create new -header fields to carry the envelope information (e.g., "X-SMTP-MAIL:" -and "X-SMTP-RCPT:"); however, this would require changes in mail -programs in foreign environments and might risk disclosure of private -information (see section 7.2). - -3.8.2 Received Lines in Gatewaying - -When forwarding a message into or out of the Internet environment, a -gateway MUST prepend a Received: line, but it MUST NOT alter in any way -a Received: line that is already in the header. - -"Received:" fields of messages originating from other environments may -not conform exactly to this specification. However, the most important -use of Received: lines is for debugging mail faults, and this debugging -can be severely hampered by well-meaning gateways that try to "fix" a -Received: line. As another consequence of trace fields arising in -non-SMTP environments, receiving systems MUST NOT reject mail based on -the format of a trace field and SHOULD be extremely robust in the light -of unexpected information or formats in those fields. - -The gateway SHOULD indicate the environment and protocol in the "via" -clauses of Received field(s) that it supplies. - -3.8.3 Addresses in Gatewaying - ->From the Internet side, the gateway SHOULD accept all valid address -formats in SMTP commands and in RFC-822 headers, and all valid RFC-822 -messages. Addresses and headers generated by gateways MUST conform to -applicable Internet standards (including this one and RFC-822). -Gateways are, of course, subject to the same rules for handling source -routes as those described for other SMTP systems in section 3.3. - -3.8.4 Other Header Fields in Gatewaying - -The gateway MUST ensure that all header fields of a message that it -forwards into the Internet mail environment meet the requirements for -Internet mail. In particular, all addresses in "From:", "To:", -"Cc:", etc., fields MUST be transformed (if necessary) to satisfy -RFC-822 syntax, MUST reference only fully-qualified domain names, and -MUST be effective and useful for sending replies. The translation -algorithm used to convert mail from the Internet protocols to another -environment's protocol SHOULD ensure that error messages from the -foreign mail environment are delivered to the return path from the -SMTP envelope, not to the sender listed in the "From:" field (or -other fields) of the RFC-822 message. - -3.8.5 Envelopes in Gatewaying - -Similarly, when forwarding a message from another environment into the -Internet, the gateway SHOULD set the envelope return path in accordance -with an error message return address, if supplied by the foreign -environment. If the foreign environment has no equivalent concept, the -gateway must select and use a best approximation, with the message -originator's address as the default of last resort. - -3.9 Terminating Sessions and Connections - -An SMTP connection is terminated when the client sends a QUIT command. -The server responds with a positive reply code, after which it closes -the connection. - -An SMTP server MUST NOT intentionally close the connection except: - - - After receiving a QUIT command and responding with a 221 reply. - - - After detecting the need to shutdown the SMTP service and returning - a 421 response code. This response code can be issued after the - server receives any command or, if necessary, asynchronously from - command receipt (on the assumption that the client will receive it - after the next command is issued). - -In particular, a server that closes connections in response to commands -that are not understood is in violation of this specification. Servers -are expected to be tolerant of unknown commands, issuing a 500 reply -and awaiting further instructions from the client. - -An SMTP server which is forcibly shut down via external means SHOULD -attempt to send a line containing a 421 response code to the SMTP -client before exiting. The SMTP client will normally read the 421 -response code after sending its next command. - -SMTP clients that experience a connection close, reset, or other -communications failure due to circumstances not under their control (in -violation of the intent of this specification but sometimes -unavoidable) SHOULD, to maintain the robustness of the mail system, -treat the mail transaction as if a 451 response had been received and -act accordingly. - -3.10 Mailing Lists and Aliases - -An SMTP-capable host SHOULD support both the alias and the list models -of address expansion for multiple delivery. When a message is -delivered or forwarded to each address of an expanded list form, the -return address in the envelope ("MAIL FROM:") MUST be changed to be the -address of a person or other entity who administers the list. However, -in this case, the message header (see [MSGFMT]) MUST be left unchanged; -in particular, the "From" field of the message header is unaffected. - -An important mail facility is a mechanism for multi-destination -delivery of a single message, by transforming (or "expanding" or -"exploding") a pseudo-mailbox address into a list of destination -mailbox addresses. When a message is sent to such a pseudo-mailbox -(sometimes called an "exploder"), copies are forwarded or redistributed -to each mailbox in the expanded list. Servers SHOULD simply utilize -the addresses on the list; application of heuristics or other matching -rules to eliminate some addresses, such as that of the originator, is -strongly discouraged. We classify such a pseudo-mailbox as an "alias" -or a "list", depending upon the expansion rules. - -3.10.1 Alias - -To expand an alias, the recipient mailer simply replaces the -pseudo-mailbox address in the envelope with each of the expanded -addresses in turn; the rest of the envelope and the message body are -left unchanged. The message is then delivered or forwarded to each -expanded address. - -3.10.2 List - -A mailing list may be said to operate by "redistribution" rather than -by "forwarding". To expand a list, the recipient mailer replaces the -pseudo-mailbox address in the envelope with all of the expanded -addresses. The return address in the envelope is changed so that all -error messages generated by the final deliveries will be returned to a -list administrator, not to the message originator, who generally has no -control over the contents of the list and will typically find error -messages annoying. - - -4. The SMTP Specifications - -4.1 SMTP Commands - -4.1.1 Command Semantics and Syntax - -The SMTP commands define the mail transfer or the mail system function -requested by the user. SMTP commands are character strings terminated -by <CRLF>. The commands themselves are alphabetic characters -terminated by <SP> if parameters follow and <CRLF> otherwise. (In the -interest of improved interoperability, SMTP receivers are encouraged to -tolerate trailing white space before the terminating <CRLF>.) The -syntax of the local part of a mailbox must conform to receiver site -conventions and the syntax specified in section 4.1.2. The SMTP -commands are discussed below. The SMTP replies are discussed in -section 4.2. - -A mail transaction involves several data objects which are communicated -as arguments to different commands. The reverse-path is the argument -of the MAIL command, the forward-path is the argument of the RCPT -command, and the mail data is the argument of the DATA command. These -arguments or data objects must be transmitted and held pending the -confirmation communicated by the end of mail data indication which -finalizes the transaction. The model for this is that distinct buffers -are provided to hold the types of data objects, that is, there is a -reverse-path buffer, a forward-path buffer, and a mail data buffer. -Specific commands cause information to be appended to a specific -buffer, or cause one or more buffers to be cleared. - -Several commands (RSET, DATA, QUIT) are specified as not permitting -parameters. In the absence of specific extensions offered by the -server and accepted by the client, clients MUST NOT send such -parameters and servers SHOULD reject commands containing them as having -invalid syntax. - -4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) - -These commands are used to identify the SMTP client to the SMTP server. -The argument field contains the fully-qualified domain name of the SMTP -client if one is available. In situations in which the SMTP client -system does not have a meaningful domain name (e.g., when its address -is dynamically allocated and no reverse mapping record is available), -the client SHOULD send an address literal (see section 4.1.3), -optionally followed by information that will help to identify the -client system. - -The SMTP server identifies itself to the SMTP client in the connection -greeting reply and in the response to this command. - -A client SMTP SHOULD start an SMTP session by issuing the EHLO command. -If the SMTP server supports the SMTP service extensions it will give a -successful response, a failure response, or an error response. If the -SMTP server, in violation of this specification, does not support any -SMTP service extensions it will generate an error response. Older -client SMTP systems MAY, as discussed above, use HELO (as specified in -RFC 821) instead of EHLO, and servers MUST support the HELO command and -reply properly to it. In any event, a client MUST issue HELO or EHLO -before starting a mail transaction. - -These commands, and a "250 OK" reply to one of them, confirm that both -the SMTP client and the SMTP server are in the initial state, that is, -there is no transaction in progress and all state tables and buffers -are cleared. - -Syntax: - ehlo = "EHLO" SP Domain CRLF - helo = "HELO" SP Domain CRLF - -Normally, the response to EHLO will be a multiline reply. Each line -of the response contains a keyword and, optionally, one or more -parameters. Following the normal syntax for multiline replies, these -keyworks follow the code (250) and a hyphen for all but the last -line, and the code and a space for the last line. The syntax for a -positive response, using the ABNF notation and terminal symbols of -[ABNF], is: - - ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF ) - / ( "250-" domain [ SP ehlo-greet ] CRLF - *( "250-" ehlo-line CRLF ) - "250" SP ehlo-line CRLF ) - - ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127) - ; string of any characters other than CR or LF - - ehlo-line = ehlo-keyword *( SP ehlo-param ) - - ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") - ; additional syntax of ehlo-params depends on - ; ehlo-keyword - - ehlo-param = 1*(%d33-127) - ; any CHAR excluding <SP> and all - ; control characters (US-ASCII 0-31 inclusive) - -Although EHLO keywords may be specified in upper, lower, or mixed case, -they MUST always be recognized and processed in a case-insensitive -manner. This is simply an extension of practices specified in RFC 821 -and section 2.4.1. - -4.1.1.2 MAIL (MAIL) - -This command is used to initiate a mail transaction in which the mail -data is delivered to an SMTP server which may, in turn, deliver it to -one or more mailboxes or pass it on to another system (possibly using -SMTP). The argument field contains a reverse-path and may contain -optional parameters. In general, the MAIL command may be sent only -when no mail transaction is in progress, see section 4.1.4. - -The reverse-path consists of the sender mailbox. Historically, that -mailbox might optionally have been preceeded by a list of hosts, but that -behavior is now deprecated (see appendix C). In some types of reporting -messages for which a reply is likely to cause a mail loop (for example, -mail delivery and nondelivery notifications), the reverse-path may be null -(see section 3.7). - -This command clears the reverse-path buffer, the forward-path buffer, -and the mail data buffer; and inserts the reverse-path information from -this command into the reverse-path buffer. - -If service extensions were negotiated, the MAIL command may also carry -parameters associated with a particular service extension. - -Syntax: - - "MAIL FROM:" ("<>" / Reverse-Path) - [SP Mail-parameters] CRLF - -4.1.1.3 RECIPIENT (RCPT) - -This command is used to identify an individual recipient of the mail -data; multiple recipients are specified by multiple use of this -command. The argument field contains a forward-path and may contain -optional parameters. - -The forward-path normally consists of the required destination mailbox. -Sending systems SHOULD not generate the optional list of hosts known as -a source route. Receiving systems MUST recognize source route syntax -but SHOULD strip off the source route specification and utilize the -domain name associated with the mailbox as if the source route had not -been provided. - -Similarly, relay hosts SHOULD strip or ignore source routes, and names -MUST NOT be copied into the reverse-path. When mail reaches its -ultimate destination (the forward-path contains only a destination -mailbox), the SMTP server inserts it into the destination mailbox in -accordance with its host mail conventions. - -For example, mail received at relay host xyz.com with envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> - -will normally be sent directly on to host d.bar.org with envelope -commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<userc@d.bar.org> - -As provided in appendix C, xyz.com MAY also choose to relay the message -to hosta.int, using the envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> - -or to jkl.org, using the envelope commands - - MAIL FROM:<userx@y.foo.org> - RCPT TO:<@jkl.org:userc@d.bar.org> - -Of course, since hosts are not required to relay mail at all, xyz.com -may also reject the message entirely when the RCPT command is received, -using a 550 code (since this is a "policy reason"). - -If service extensions were negotiated, the RCPT command may also carry -parameters associated with a particular service extension offered by -the server. The client MUST NOT transmit parameters other than those -associated with a service extension offered by the server in its EHLO -response. - -Syntax: - "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path) - [SP Rcpt-parameters] CRLF - -4.1.1.4 DATA (DATA) - -The receiver normally sends a 354 response to DATA, and then treats the -lines (strings ending in <CRLF> sequences, as described in section 2.3.7) -following the command as mail data from the sender. This command causes the -mail data to be appended to the mail data buffer. The mail data may -contain any of the 128 ASCII character codes, although experience has -indicated that use of control characters other than SP, HT, CR, and LF may -cause problems and SHOULD be avoided when possible. - -The mail data is terminated by a line containing only a period, that -is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2). This -is the end of mail data indication. Note that the first <CRLF> of this -terminating sequence is also the <CRLF> that ends the final line of the -data (message text) or, if there was no data, ends the DATA command -itself. An extra <CRLF> MUST NOT be added, as that would cause an -empty line to be added to the message. The only exception to this rule -would arise if the message body were passed to the originating -SMTP-sender with a final "line" that did not end in <CRLF>; in that -case, the originating SMTP system MUST either reject the message as -invalid or add <CRLF> in order to have the receiving SMTP server -recognize the "end of data" condition. - -The custom of accepting lines ending only in <LF>, as a concession to -non-conforming behavior on the part of some UNIX systems, has proven to -cause more interoperability problems than it solves, and SMTP server -systems MUST NOT do this, even in the name of improved robustness. In -particular, the sequence "<LF>.<LF>" (bare line feeds, without carriage -returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end -of mail data indication. - -Receipt of the end of mail data indication requires the server to process -the stored mail transaction information. This processing consumes the -information in the reverse-path buffer, the forward-path buffer, and the -mail data buffer, and on the completion of this command these buffers are -cleared. If the processing is successful, the receiver MUST send an OK -reply. If the processing fails the receiver MUST send a failure reply. The -SMTP model does not allow for partial failures at this point: either the -message is accepted by the server for delivery and a positive response is -returned or it is not accepted and a failure reply is returned. In sending -a positive completion reply to the end of data indication, the receiver -takes full responsibility for the message (see section 6.1). Errors that -are diagnosed subsequently MUST be reported in a mail message, as discussed -in section 4.4. - -When the SMTP server accepts a message either for relaying or for final -delivery, it inserts a trace record (also referred to interchangeably -as a "time stamp line" or "Received" line) at the top of the mail data. -This trace record indicates the identity of the host that sent the -message, the identity of the host that received the message (and is -inserting this time stamp), and the date and time the message was -received. Relayed messages will have multiple time stamp lines. -Details for formation of these lines, including their syntax, is -specified in section 4.4. - -Additional discussion about the operation of the DATA command appears -in section 3.3. - -Syntax: - "DATA" CRLF - - -4.1.1.5 RESET (RSET) - -This command specifies that the current mail transaction will be aborted. -Any stored sender, recipients, and mail data MUST be discarded, and all -buffers and state tables cleared. The receiver MUST send a "250 OK" reply -to a RSET command with no arguments. A reset command may be issued by the -client at any time. It is effectively equivalent to a NOOP (i.e., if has -no effect) if issued immediately after EHLO, before EHLO is issued in the -session, after an end-of-data indicator has been sent and acknowledged, or -immediately before a QUIT. In other situations, it restores the state to -that immediately after the most recent EHLO. An SMTP server MUST NOT close -the connection as the result of receiving a RSET; that action is reserved -for QUIT (see section 4.1.1.10). - -Since EHLO implies some additional processing and response by the -server, RSET will normally be more efficient than reissuing that -command, even though the formal semantics are the same. - -There are circumstances, contrary to the intent of this specification, -in which an SMTP server may receive an indication that the underlying -TCP connection has been closed or reset. To preserve the robustness of -the mail system, SMTP servers SHOULD be prepared for this condition and -SHOULD treat it as if a QUIT had been received before the connection -disappeared. - -Syntax: - "RSET" CRLF - - -4.1.1.6 VERIFY (VRFY) - -This command asks the receiver to confirm that the argument identifies -a user or mailbox. If it is a user name, information is returned as -specified in section 3.5. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer. - -Syntax: - "VRFY" SP String CRLF - -4.1.1.7 EXPAND (EXPN) - -This command asks the receiver to confirm that the argument identifies -a mailing list, and if so, to return the membership of that list. If -the command is successful, a reply is returned containing information -as described in section 3.5. This reply will have multiple lines -except in the trivial case of a one-member list. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer and may be issued at any time. - -Syntax: - "EXPN" SP String CRLF - -4.1.1.8 HELP (HELP) - -This command causes the server to send helpful information to the -client. The command MAY take an argument (e.g., any command name) and -return more specific information as a response. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer and may be issued at any time. - -SMTP servers SHOULD support HELP without arguments and MAY support it -with arguments. - -Syntax: - "HELP" [ SP String ] CRLF - -4.1.1.9 NOOP (NOOP) - -This command does not affect any parameters or previously entered -commands. It specifies no action other than that the receiver send an -OK reply. - -This command has no effect on the reverse-path buffer, the forward-path -buffer, or the mail data buffer and may be issued at any time. If a -parameter string is specified, servers SHOULD ignore it. - -Syntax: - "NOOP" [ SP String ] CRLF - - -4.1.1.10 QUIT (QUIT) - -This command specifies that the receiver MUST send an OK reply, and -then close the transmission channel. - -The receiver MUST NOT intentionally close the transmission channel -until it receives and replies to a QUIT command (even if there was an -error). The sender MUST NOT intentionally close the transmission -channel until it sends a QUIT command and SHOULD wait until it receives -the reply (even if there was an error response to a previous command). -If the connection is closed prematurely due to violations of the above -or system or network failure, the server MUST cancel any pending -transaction, but not undo any previously completed transaction, and -generally MUST act as if the command or transaction in progress had -received a temporary error (i.e., a 4yz response). - -The QUIT command may be issued at any time. - -Syntax: - "QUIT" CRLF - - -4.1.2 Command Argument Syntax - -The syntax of the argument fields of the above commands (using the -syntax specified in [ABNF] where applicable) is given below. Some of -the productions given below are used only in conjunction with source -routes as described in appendix C. Terminals not defined in this -document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the -"core" syntax (section 6) of [ABNF] or in the syntax of [MSGFMT]. - - Reverse-path = Path - Forward-path = Path - Path = "<" [ A-d-l ":" ] Mailbox ">" - A-d-l = At-domain *( "," A-d-l ) - ; Note that this form, the so-called "source route", - ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be - ; ignored. - At-domain = "@" domain - Mail-parameters = esmtp-param *(SP esmtp-param) - Rcpt-parameters = esmtp-param *(SP esmtp-param) - esmtp-param = esmtp-keyword ["=" esmtp-value] - esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") - esmtp-value = 1*(%d33-60 / %d62-127) - ; any CHAR excluding "=", SP, and control - ; characters - Keyword = Ldh-str - Argument = Atom - Domain = (sub-domain 1*("." sub-domain)) / address-literal - sub-domain = Let-dig [Ldh-str] - - address-literal = "[" IPv4-address-literal / - IPv6-address-literal / - General-address-literal "]" - ; See section 4.1.3 - - Mailbox = Local-part "@" Domain - - Local-part = Dot-string / Quoted-string - ; MAY be case-sensitive - - Dot-string = Atom *("." Atom) - - Atom = 1*atext - - Quoted-string = DQUOTE *qcontent DQUOTE - - String = Atom / Quoted-string - - -While the above definition for Local-part is relatively permissive, for -maximum interoperability, a host that expects to receive mail SHOULD -avoid defining mailboxes where the Local-part requires (or uses) the -Quoted-string form or where the Local-part is case-sensitive. For any -purposes that require generating or comparing Local-parts (e.g., to -specific mailbox names), all quoted forms MUST be treated as equivalent -and the sending system SHOULD transmit the form that uses the minimum -quoting possible. - -Systems MUST NOT define mailboxes in such a way as to require the use -in SMTP of non-ASCII characters (octets with the high order bit set to -one) or ASCII "control characters" (decimal value 0-31 and 127). These -characters MUST NOT be used in MAIL or RCPT commands or other commands -that require mailbox names. - -Note that the backslash, "\", is a quote character, which is used to -indicate that the next character is to be used literally (instead of -its normal interpretation). For example, "Joe\,Smith" indicates a -single nine character user field with the comma being the fourth -character of the field. - -To promote interoperability and consistent with long-standing guidance -about conservative use of the DNS in naming and applications (e.g., see -section 2.3.1 of the base DNS document [RFC-1015]), characters outside -the set of alphas, digits, and hyphen MUST NOT appear in domain name -labels for SMTP clients or servers. In particular, the underscore -character is not permitted. SMTP servers that receive a command in -which invalid character codes have been employed, and for which there -are no other reasons for rejection, MUST reject that command with a 501 -response. - -4.1.3 Address Literals - -Sometimes a host is not known to the domain name system and -communication (and, in particular, communication to report and repair -the error) is blocked. To bypass this barrier a special literal form -of the address is allowed as an alternative to a domain name. For IPv4 -addresses, this form uses four small decimal integers separated by dots -and enclosed by brackets such as [123.255.37.2], which indicates an -(IPv4) Internet Address in sequence-of-octets form. For IPv6 and other -forms of addressing that might eventually be standardized, the form -consists of a standardized "tag" that identifies the address syntax, a -space, and the address itself, in a format specified as part of the -IPv6 standards [IPv6AddrSpec]. - -Specifically: - - IPv4-address-literal = Snum 3("." Snum) - IPv6-address-literal = "IPv6:" IPv6-addr - General-address-literal = Standardized-tag ":" 1*dcontent - Standardized-tag = Ldh-str - ; MUST be specified in a standards-track RFC - ; and registered with IANA - - Snum = 1*3DIGIT ; representing a decimal integer - ; value in the range 0 through 255 - Let-dig = ALPHA / DIGIT - Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig - - IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp - IPv6-hex = 1*4HEXDIG - IPv6-full = IPv6-hex 7(":" IPv6-hex) - IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":" - IPv6-hex)] - ; The "::" represents at least 2 16-bit groups of zeros - ; No more than 6 groups in addition to the "::" may be - ; present - IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal - IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::" - [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal - ; The "::" represents at least 2 16-bit groups of zeros - ; No more than 4 groups in addition to the "::" and - ; IPv4-address-literal may be present - - -4.1.4 Order of Commands - -There are restrictions on the order in which these commands may be used. - -A session that will contain mail transactions MUST first be initialized -by the use of the EHLO command. An SMTP server SHOULD accept commands -for non-mail transactions (e.g., VRFY or EXPN) without this -initialization. - -An EHLO command MAY be issued by a client later in the session. If it -is issued after the session begins, the SMTP server MUST clear all -buffers and reset the state exactly as if a RSET command had been -issued. In other words, the sequence of RSET followed immediately by -EHLO is redundant, but not harmful other than in the performance cost -of executing unnecessary commands. - -If the EHLO command is not acceptable to the SMTP server, 501, 500, or -502 failure replies MUST be returned as appropriate. The SMTP server -MUST stay in the same state after transmitting these replies that it -was in before the EHLO was received. - -The SMTP client MUST, if possible, ensure that the domain parameter to -the EHLO command is a valid principal host name (not a CNAME or MX -name) for its host. If this is not possible (e.g., when the client's -address is dynamically assigned and the client does not have an obvious -name), an address literal SHOULD be substituted for the domain name and -supplemental information provided that will assist in identifying the -client. - -An SMTP server MAY verify that the domain name parameter in the EHLO -command actually corresponds to the IP address of the client. However, -the server MUST NOT refuse to accept a message for this reason if the -verification fails: the information about verification failure is for -logging and tracing only. - -The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time -during a session, or without previously initializing a session. SMTP -servers SHOULD process these normally (that is, not return a 503 code) -even if no EHLO command has yet been received; clients SHOULD open a -session with EHLO before sending these commands. - -If these rules are followed, the example in RFC 821 that shows "550 -access denied to you" in response to an EXPN command is incorrect -unless an EHLO command precedes the EXPN or the denial of access is -based on the client's IP address or other authentication or -authorization-determining mechanisms. - -The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins -a mail transaction. Once started, a mail transaction consists of a -transaction beginning command, one or more RCPT commands, and a DATA -command, in that order. A mail transaction may be aborted by the RSET -(or a new EHLO) command. There may be zero or more transactions in a -session. MAIL (or SEND, SOML, or SAML) MUST NOT be sent if a mail -transaction is already open, i.e., it should be sent only if no mail -transaction had been started in the session, or it the previous one -successfully concluded with a successful DATA command, or if the -previous one was aborted with a RSET. - -If the transaction beginning command argument is not acceptable, a 501 -failure reply MUST be returned and the SMTP server MUST stay in the -same state. If the commands in a transaction are out of order to the -degree that they cannot be processed by the server, a 503 failure reply -MUST be returned and the SMTP server MUST stay in the same state. - -The last command in a session MUST be the QUIT command. The QUIT -command cannot be used at any other time in a session, but SHOULD be -used by the client SMTP to request connection closure, even when no -session opening command was sent and accepted. - -4.1.5 Private-use Commands - -As specified in section 2.2.2, commands starting in "X" may be used by -bilateral agreement between the client (sending) and server (receiving) -SMTP agents. An SMTP server that does not recognize such a command is -expected to reply with "500 Command not recognized". An extended SMTP -server MAY list the feature names associated with these private -commands in the response to the EHLO command. - -Commands sent or accepted by SMTP systems that do not start with "X" -MUST conform to the requirements of section 2.2.2. - - -4.2 SMTP Replies - -Replies to SMTP commands serve to ensure the synchronization of -requests and actions in the process of mail transfer and to guarantee -that the SMTP client always knows the state of the SMTP server. Every -command MUST generate exactly one reply. - -The details of the command-reply sequence are described in section 4.3. - -An SMTP reply consists of a three digit number (transmitted as three -numeric characters) followed by some text unless specified otherwise in -this document. The number is for use by automata to determine what state -to enter next; the text is for the human user. The three digits contain -enough encoded information that the SMTP client need not examine the text -and may either discard it or pass it on to the user, as appropriate. -Exceptions are as noted elsewhere in this document. In particular, the -220, 221, 251, 421, and 551 reply codes are associated with message text -that must be parsed and interpreted by machines. In the general case, the -text may be receiver dependent and context dependent, so there are likely -to be varying texts for each reply code. A discussion of the theory of -reply codes is given in section 4.2.1. Formally, a reply is defined to be -the sequence: a three-digit code, <SP>, one line of text, and <CRLF>, or a -multiline reply (as defined in section 4.2.1). Since, in violation of this -specification, the text is sometimes not sent, clients which do not receive -it SHOULD be prepared to process the code alone (with or without a trailing -space character). Only the EHLO, EXPN, and HELP commands are expected to -result in multiline replies in normal circumstances, however, multiline -replies are allowed for any command. - -In ABNF, server responses are: - - Greeting = "220 " Domain [ SP text ] CRLF - Reply-line = Reply-code [ SP text ] CRLF - -where "Greeting" appears only in the 220 response that announces that -the server is opening its part of the connection. - -An SMTP server SHOULD send only the reply codes listed in this -document. An SMTP server SHOULD use the text shown in the examples -whenever appropriate. - -An SMTP client MUST determine its actions only by the reply code, not by -the text (except for the "change of address" 251 and 551 and, if necessary, -220, 221, and 421 replies); in the general case, any text, including no -text at all (although senders SHOULD NOT send bare codes), MUST be -acceptable. The space (blank) following the reply code is considered part -of the text. Whenever possible, a receiver-SMTP SHOULD test the first -digit (severity indication) of the reply code. - -The list of codes that appears below MUST NOT be construed as -permanent. While the addition of new codes should be a rare and -significant activity, with supplemental information in the textual part -of the response being preferred, new codes may be added as the result -of new Standards or Standards-track specifications. Consequently, a -sender-SMTP MUST be prepared to handle codes not specified in this -document and MUST do so by interpreting the first digit only. - -4.2.1 Reply Code Severities and Theory - -The three digits of the reply each have a special significance. The -first digit denotes whether the response is good, bad or incomplete. An -unsophisticated SMTP client, or one that receives an unexpected code, -will be able to determine its next action (proceed as planned, redo, -retrench, etc.) by examining this first digit. An SMTP client that -wants to know approximately what kind of error occurred (e.g., mail -system error, command syntax error) may examine the second digit. The -third digit and any supplemental information that may be present is -reserved for the finest gradation of information. - -There are five values for the first digit of the reply code: - -1yz Positive Preliminary reply - The command has been accepted, but the requested action is being - held in abeyance, pending confirmation of the information in this - reply. The SMTP client should send another command specifying - whether to continue or abort the action. Note: unextended SMTP does - not have any commands that allow this type of reply, and so does not - have continue or abort commands. - -2yz Positive Completion reply - The requested action has been successfully completed. A new request - may be initiated. - -3yz Positive Intermediate reply - The command has been accepted, but the requested action is being - held in abeyance, pending receipt of further information. The SMTP - client should send another command specifying this information. - This reply is used in command sequence groups (i.e., in DATA). - -4yz Transient Negative Completion reply - The command was not accepted, and the requested action did not - occur. However, the error condition is temporary and the action may - be requested again. The sender should return to the beginning of - the command sequence (if any). It is difficult to assign a meaning - to "transient" when two different sites (receiver- and sender- SMTP - agents) must agree on the interpretation. Each reply in this - category might have a different time value, but the SMTP client is - encouraged to try again. A rule of thumb to determine whether a - reply fits into the 4yz or the 5yz category (see below) is that - replies are 4yz if they can be successful if repeated without any - change in command form or in properties of the sender or receiver - (that is, the command is repeated identically and the receiver does - not put up a new implementation.) - -5yz Permanent Negative Completion reply - The command was not accepted and the requested action did not occur. - The SMTP client is discouraged from repeating the exact request (in - the same sequence). Even some "permanent" error conditions can be - corrected, so the human user may want to direct the SMTP client to - reinitiate the command sequence by direct action at some point in - the future (e.g., after the spelling has been changed, or the user - has altered the account status). - -The second digit encodes responses in specific categories: - -x0z Syntax: These replies refer to syntax errors, syntactically - correct commands that do not fit any functional category, and - unimplemented or superfluous commands. - -x1z Information: These are replies to requests for information, such - as status or help. - -x2z Connections: These are replies referring to the transmission - channel. - -x3z Unspecified. - -x4z Unspecified. - -x5z Mail system: These replies indicate the status of the receiver - mail system vis-a-vis the requested transfer or other mail system - action. - -The third digit gives a finer gradation of meaning in each category -specified by the second digit. The list of replies illustrates this. -Each reply text is recommended rather than mandatory, and may even -change according to the command with which it is associated. On the -other hand, the reply codes must strictly follow the specifications in -this section. Receiver implementations should not invent new codes for -slightly different situations from the ones described here, but rather -adapt codes already defined. - -For example, a command such as NOOP, whose successful execution does -not offer the SMTP client any new information, will return a 250 reply. -The reply is 502 when the command requests an unimplemented -non-site-specific action. A refinement of that is the 504 reply for a -command that is implemented, but that requests an unimplemented -parameter. - -The reply text may be longer than a single line; in these cases the -complete text must be marked so the SMTP client knows when it can stop -reading the reply. This requires a special format to indicate a -multiple line reply. - -The format for multiline replies requires that every line, except the -last, begin with the reply code, followed immediately by a hyphen, "-" -(also known as minus), followed by text. The last line will begin with -the reply code, followed immediately by <SP>, optionally some text, and -<CRLF>. As noted above, servers SHOULD send the <SP> if subsequent -text is not sent, but clients MUST be prepared for it to be omitted. - -For example: - 123-First line - 123-Second line - 123-234 text beginning with numbers - 123 The last line - -In many cases the SMTP client then simply needs to search for the reply -code followed by <SP> at the beginning of a line, and ignore all -preceding lines. In a few cases, there is important data for the -client in the reply "text". The client will be able to identify these -cases from the current context. - -4.2.2 Reply Codes by Function Groups - - 500 Syntax error, command unrecognized - (This may include errors such as command line too long) - 501 Syntax error in parameters or arguments - 502 Command not implemented (see section 4.2.4) - 503 Bad sequence of commands - 504 Command parameter not implemented - - 211 System status, or system help reply - 214 Help message - (Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user) - - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 421 <domain> Service not available, closing transmission channel - (This may be a reply to any command if the service knows it - must shut down) - - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - (See section 3.4) - 252 Cannot VRFY user, but will accept message and attempt - delivery - (See section 3.5.3) - 450 Requested mail action not taken: mailbox unavailable - (e.g., mailbox busy) - 550 Requested action not taken: mailbox unavailable - (e.g., mailbox not found, no access, or command rejected - for policy reasons) - 451 Requested action aborted: error in processing - 551 User not local; please try <forward-path> - (See section 3.4) - 452 Requested action not taken: insufficient system storage - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - (e.g., mailbox syntax incorrect) - 354 Start mail input; end with <CRLF>.<CRLF> - 554 Transaction failed (Or, in the case of a connection-opening - response, "No SMTP service here") - -4.2.3 Reply Codes in Numeric Order - - 211 System status, or system help reply - 214 Help message - (Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user) - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - (See section 3.4) - 252 Cannot VRFY user, but will accept message and attempt - delivery - (See section 3.5.3) - - 354 Start mail input; end with <CRLF>.<CRLF> - - 421 <domain> Service not available, closing transmission channel - (This may be a reply to any command if the service knows it - must shut down) - 450 Requested mail action not taken: mailbox unavailable - (e.g., mailbox busy) - 451 Requested action aborted: local error in processing - 452 Requested action not taken: insufficient system storage - - 500 Syntax error, command unrecognized - (This may include errors such as command line too long) - 501 Syntax error in parameters or arguments - 502 Command not implemented (see section 4.2.4) - 503 Bad sequence of commands - 504 Command parameter not implemented - 550 Requested action not taken: mailbox unavailable - (e.g., mailbox not found, no access, or command rejected - for policy reasons) - 551 User not local; please try <forward-path> - (See section 3.4) - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - (e.g., mailbox syntax incorrect) - 554 Transaction failed (Or, in the case of a connection-opening - response, "No SMTP service here") - -4.2.4 Reply Code 502 - -Questions have been raised as to when reply code 502 (Command not -implemented) SHOULD be returned in preference to other codes. 502 -SHOULD be used when the command is actually recognized by the SMTP -server, but not implemented. If the command is not recognized, code -500 SHOULD be returned. Extended SMTP systems MUST NOT list -capabilities in response to EHLO for which they will return 502 (or -500) replies. - -4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> - -When an SMTP server returns a positive completion status (2yz code) -after the DATA command is completed with <CRLF>.<CRLF>, it accepts -responsibility for: - - - delivering the message (if the recipient mailbox exists), or - - - if attempts to deliver the message fail due to transient conditions, - retrying delivery some reasonable number of times at intervals as - specified in section 4.5.4. - - - if attempts to deliver the message fail due to permanent conditions, - or if repeated attempts to deliver the message fail due to transient - conditions, returning appropriate notification to the sender of the - original message (using the address in the SMTP MAIL command). - -When an SMTP server returns a transient error completion status (4yz) code -after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make -any subsequent attempt to deliver that message. The SMTP client retains -responsibility for delivery of that message and may either return it to the -user or requeue it for a subsequent attempt (see section 4.5.4.1). - -The user who originated the message SHOULD be able to interpret the return -of a transient failure status (by mail message or otherwise) as a -non-delivery indication, just as a permanent failure would be interpreted. -I.e., if the client SMTP successfully handles these conditions, the user -will not receive such a reply. - -When an SMTP server returns a permanent error status (5yz) code after the -DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make any -subsequent attempt to deliver the message. As with temporary error status -codes, the SMTP client retains responsibility for the message, but SHOULD -not again attempt delivery to the same server without user review and -intervention of the message. - -4.3 Sequencing of Commands and Replies - -4.3.1 Sequencing Overview - -The communication between the sender and receiver is an alternating -dialogue, controlled by the sender. As such, the sender issues a -command and the receiver responds with a reply. Unless other -arrangements are negotiated through service extensions, the sender MUST -wait for this response before sending further commands. - -One important reply is the connection greeting. Normally, a receiver -will send a 220 "Service ready" reply when the connection is completed. -The sender SHOULD wait for this greeting message before sending any -commands. - -Note: all the greeting-type replies have the official name (the -fully-qualified primary domain name) of the server host as the first -word following the reply code. Sometimes the host will have no -meaningful name. See 4.1.3 for a discussion of alternatives in these -situations. - -For example, - 220 ISIF.USC.EDU Service ready -or - 220 mail.foo.com SuperSMTP v 6.1.2 Service ready -or - 220 [10.0.0.1] Clueless host service ready - -The table below lists alternative success and failure replies for each -command. These SHOULD be strictly adhered to: a receiver may -substitute text in the replies, but the meaning and action implied by -the code numbers and by the specific command reply sequence cannot be -altered. - -4.3.2 Command-Reply Sequences - -Each command is listed with its usual possible replies. The prefixes -used before the possible replies are "I" for intermediate, "S" for -success, and "E" for error. Since some servers may generate other -replies under special circumstances, and to allow for future extension, -SMTP clients SHOULD, when possible, interpret only the first digit of -the reply and MUST be prepared to deal with unrecognized reply codes by -interpreting the first digit only. Unless extended using the -mechanisms described in section 2.2, SMTP servers MUST NOT transmit -reply codes to an SMTP client that are other than three digits or that -do not start in a digit between 2 and 5 inclusive. - -These sequencing rules and, in principle, the codes themselves, can be -extended or modified by SMTP extensions offered by the server and -accepted (requested) by the client. - -In addition to the codes listed below, any SMTP command can return any -of the following codes if the corresponding unusual circumstances are -encountered: - -500 For the "command line too long" case or if the command name was not - recognized. Note that producing a "command not recognized" error in - response to the required subset of these commands is a violation of - this specification. - -501 Syntax error in command or arguments. In order to provide for - future extensions, commands that are specified in this document as - not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 - message if arguments are supplied in the absence of EHLO-advertised - extensions. - -421 Service shutting down and closing transmission channel - -Specific sequences are: - -CONNECTION ESTABLISHMENT - S: 220 - E: 554 -EHLO or HELO - S: 250 - E: 504, 550 -MAIL - S: 250 - E: 552, 451, 452, 550, 553, 503 -RCPT - S: 250, 251 (but see section 3.4 for discussion of 251 and 551) - E: 550, 551, 552, 553, 450, 451, 452, 503, 550 -DATA - I: 354 -> data -> S: 250 - E: 552, 554, 451, 452 - E: 451, 554, 503 -RSET - S: 250 -VRFY - S: 250, 251, 252 - E: 550, 551, 553, 502, 504 -EXPN - S: 250, 252 - E: 550, 500, 502, 504 -HELP - S: 211, 214 - E: 502, 504 -NOOP - S: 250 -QUIT - S: 221 - -4.4 Trace Information - -When an SMTP server receives a message for delivery or further -processing, it MUST insert trace ("time stamp" or "Received") -information at the beginning of the message content, as discussed in -section 4.1.1.4. - -This line MUST be structured as follows: - - - The FROM field, which MUST be supplied in an SMTP environment, - SHOULD contain both (1) the name of the source host as presented in - the EHLO command and (2) an address literal containing the IP - address of the source, determined from the TCP connection. - - - The ID field MAY contain an "@" as suggested in RFC-822, but this is - not required. - - - The FOR field MAY contain a list of <path> entries when multiple - RCPT commands have been given. This may raise some security issues - and is usually not desirable; see section 7.2. - -An Internet mail program MUST NOT change a Received: line that was -previously added to the message header. SMTP servers MUST prepend -Received lines to messages; they MUST NOT change the order of existing -lines or insert Received lines in any other location. - -As the Internet grows, comparability of Received fields is important -for detecting problems, especially slow relays. SMTP servers that -create Received fields SHOULD use explicit offsets in the dates (e.g., --0800), rather than time zone names of any type. Local time (with an -offset) is preferred to UT when feasible. This formulation allows -slightly more information about local circumstances to be specified. -If UT is needed, the receiver need merely do some simple arithmetic to -convert the values. Use of UT loses information about the time -zone-location of the server. If a time zone name is used, it SHOULD be -included in a comment. - -When the delivery SMTP server makes the "final delivery" of a message, -it inserts a return-path line at the beginning of the mail data. This -use of return-path is required; mail systems MUST support it. The -return-path line preserves the information in the <reverse-path> from -the MAIL command. Here, final delivery means the message has left the -SMTP enviroment. Normally, this would mean it had been delivered to -the destination user or an associated mail drop, but in some cases it -may be further processed and transmitted by another mail system. - -It is possible for the mailbox in the return path to be different from -the actual sender's mailbox, for example, if error responses are to be -delivered to a special error handling mailbox rather than to the -message sender. When mailing lists are involved, this arrangement is -common and useful as a means of directing errors to the list maintainer -rather than the message originator. - -The text above implies that the final mail data will begin with a -return path line, followed by one or more time stamp lines. These -lines will be followed by the mail data headers and body [MSGFMT]. - -It is sometimes difficult for an SMTP server to determine whether or -not it is making final delivery since forwarding or other operations -may occur after the message is accepted for delivery. Consequently, -any further (forwarding, gateway, or relay) systems MAY remove the -return path and rebuild the MAIL command as needed to ensure that -exactly one such line appears in a delivered message. - -A message-originating SMTP system SHOULD NOT send a message that -already contains a Return-path header. SMTP servers performing a relay -function MUST NOT inspect the message data, and especially not to the -extent needed to determine if Return-path headers are present. SMTP -servers making final delivery MAY remove Return-path headers before -adding their own. - -The primary purpose of the Return-path is to designate the address to -which messages indicating non-delivery or other mail system failures -are to be sent. For this to be unambiguous, exactly one return path -SHOULD be present when the message is delivered. Systems using RFC 822 -syntax with non-SMTP transports SHOULD designate an unambiguous -address, associated with the transport envelope, to which error reports -(e.g., non-delivery messages) should be sent. - -Historical note: Text in RFC 822 that appears to contradict the use of -the Return-path header (or the envelope reverse path address from the -MAIL command) as the destination for error messages is not applicable -on the Internet. The reverse path address (as copied into the -Return-path) MUST be used as the target of any mail containing delivery -error messages. - -In particular: - - - a gateway from SMTP->elsewhere SHOULD insert a return-path header, - unless it is known that the "elsewhere" transport also uses Internet - domain addresses and maintains the envelope sender address - separately. - - - a gateway from elsewhere->SMTP SHOULD delete any return-path header - present in the message, and either copy that information to the SMTP - envelope or combine it with information present in the envelope of - the other transport system to construct the reverse path argument to - the MAIL command in the SMTP envelope. - -The server must give special treatment to cases in which the processing -following the end of mail data indication is only partially successful. -This could happen if, after accepting several recipients and the mail -data, the SMTP server finds that the mail data could be successfully -delivered to some, but not all, of the recipients. In such cases, the -response to the DATA command MUST be an OK reply. However, the SMTP -server MUST compose and send an "undeliverable mail" notification -message to the originator of the message. - -A single notification listing all of the failed recipients or separate -notification messages MUST be sent for each failed recipient. For -economy of processing by the sender, the former is preferred when -possible. All undeliverable mail notification messages are sent using -the MAIL command (even if they result from processing the obsolete -SEND, SOML, or SAML commands) and use a null return path as discussed -in section 3.7. - -The time stamp line and the return path line are formally defined as -follows: - - Return-path-line = "Return-Path:" FWS Reverse-path <CRLF> - - Time-stamp-line = "Received:" FWS Stamp <CRLF> - - Stamp = From-domain By-domain Opt-info ";" FWS date-time - - ; where "date-time" is as defined in [MSGFMT] - but the "obs-" forms, especially two-digit - years, are prohibited in SMTP and MUST NOT be - used. - - From-domain = "FROM" FWS Extended-Domain CFWS - - By-domain = "BY" FWS Extended-Domain CFWS - - Extended-Domain = Domain / - ( Domain FWS "(" TCP-info ")" ) / - ( Address-literal FWS "(" TCP-info ")" - TCP-info = Address-literal / ( Domain FWS Address-literal ) - ; Information derived by server from TCP connection - not client EHLO. - - Opt-info = [Via] [With] [ID] [For] - - Via = "VIA" FWS Link CFWS - - With = "WITH" FWS Protocol CFWS - - ID = "ID" FWS String / msg-id CFWS - - For = "FOR" FWS 1*( Path / Mailbox ) CFWS - - Link = "TCP" / Addtl-Link - Addtl-Link = Atom ; Additional standard names for links are - registered with the Internet Assigned - Numbers Authority (IANA). "Via" is - primarily of value with non-Internet - transports. - SMTP servers SHOULD NOT use unregistered - names. - Protocol = "ESMTP" / "SMTP" / Attdl-Protocol - Attdl-Protocol = Atom ; Additional standard names for protocols - are registered with the Internet Assigned - Numbers Authority (IANA). SMTP servers - SHOULD NOT use unregistered names. - - -4.5 Additional Implementation Issues - -4.5.1 Minimum Implementation - -In order to make SMTP workable, the following minimum implementation is -required for all receivers. The following commands MUST be supported to -conform to this specification: - - EHLO - HELO - MAIL - RCPT - DATA - RSET - NOOP - QUIT - VRFY - -Any system that includes an SMTP server supporting mail relaying or -delivery MUST support the reserved mailbox "postmaster" as a -case-insensitive local name. This postmaster address is not strictly -necessary if the server always returns 554 on connection opening (as -described in section 3.1). The requirement to accept mail for postmaster -implies that RCPT commands which specify a mailbox for postmaster at any of -the domains for which the SMTP s erver provides mail service, as well as -the special case of "RCPT TO:<Postmaster>" (with no domain specification), -MUST be supported. - -SMTP systems are expected to make every reasonable effort to accept mail -directed to Postmaster from any other system on the Internet. In extreme -cases --such as to contain a denial of service attack or other breach of -security-- an SMTP server may block mail directed to Postmaster. However, -such arrangements SHOULD be narrowly tailored so as to avoid blocking -messages which are not part of such attacks. - - -4.5.2 Transparency - -Without some provision for data transparency, the character sequence -"<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user. In -general, users are not aware of such "forbidden" sequences. To allow -all user composed text to be transmitted transparently, the following -procedures are used: - - - Before sending a line of mail text, the SMTP client checks the first - character of the line. If it is a period, one additional period is - inserted at the beginning of the line. - - - When a line of mail text is received by the SMTP server, it checks - the line. If the line is composed of a single period, it is treated - as the end of mail indicator. If the first character is a period - and there are other characters on the line, the first character is - deleted. - -The mail data may contain any of the 128 ASCII characters. All characters -are to be delivered to the recipient's mailbox, including spaces, vertical -and horizontal tabs, and other control characters. If the transmission -channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes -are transmitted right justified in the octets, with the high order bits -cleared to zero. See 3.7 for special treatment of these conditions in SMTP -systems serving a relay function. - -In some systems it may be necessary to transform the data as it is -received and stored. This may be necessary for hosts that use a -different character set than ASCII as their local character set, that -store data in records rather than strings, or which use special -character sequences as delimiters inside mailboxes. If such -transformations are necessary, they MUST be reversible, especially if -they are applied to mail being relayed. - -4.5.3 Sizes and Timeouts - -4.5.3.1 Size limits and minimums - -There are several objects that have required minimum/maximum sizes. -Every implementation MUST be able to receive objects of at least these -sizes. Objects larger than these sizes SHOULD be avoided when -possible. However, some Internet mail constructs such as encoded X.400 -addresses [RFC-X400] will often require larger objects: clients MAY -attempt to transmit these, but MUST be prepared for a server to reject -them if they cannot be handled by it. To the maximum extent possible, -implementation techniques which impose no limits on the length of these -objects should be used. - -local-part - The maximum total length of a user name or other local-part is 64 - characters. - -domain - The maximum total length of a domain name or number is 255 - characters. - -path - The maximum total length of a reverse-path or forward-path is 256 - characters (including the punctuation and element separators). - -command line - The maximum total length of a command line including the command - word and the <CRLF> is 512 characters. SMTP extensions may be used - to increase this limit. - -reply line - The maximum total length of a reply line including the reply code - and the <CRLF> is 512 characters. More information may be conveyed - through multiple-line replies. - -text line - The maximum total length of a text line including the <CRLF> is 1000 - characters (not counting the leading dot duplicated for - transparency). This number may be increased by the use of SMTP - Service Extensions. - -message content - The maximum total length of a message content (including any message - headers as well as the message body) MUST BE at least 64K octets. - Since the introduction of multimedia mail [RFC-MIME], message - lengths on the Internet have grown dramatically, and message size - restrictions should be avoided if at all possible. SMTP server - systems that must impose restrictions SHOULD implement the "SIZE" - service extension ([RFC-SIZE]), and SMTP client systems that will - send large messages SHOULD utilize it when possible. - -recipients buffer - The minimum total number of recipients that must be buffered is 100 - recipients. Rejection of messages (for excessive recipients) with - fewer than 100 RCPT commands is a violation of this specification. - The general principle that relaying SMTP servers MUST NOT, and - delivery SMTP servers SHOULD NOT, perform validation tests on - message headers suggests that rejecting a message based on the total - number of recipients shown in header fields is to be discouraged. A - server which imposes a limit on the number of recipients MUST behave - in an orderly fashion, such as to reject additional addresses over - its limit rather than silently discarding addresses previously - accepted. A client that needs to deliver a message containing over - 100 RCPT commands SHOULD be prepared to transmit in 100-recipient - "chunks" if the server declines to accept more than 100 recipients - in a single message. - -Errors due to exceeding these limits may be reported by using the reply -codes. Some examples of reply codes are: - - 500 Line too long. -or - 501 Path too long -or - 452 Too many recipients (see below) -or - 552 Too much mail data. - -[RFC-821] incorrectly listed the error where an SMTP server exhausts -its implementation limit on the number of RCPT commands ("too many -recipients") as having reply code 552. The correct reply code for this -condition is 452. Clients SHOULD treat a 552 code in this case as a -temporary, rather than permanent, failure so the logic below works. - -When a conforming SMTP server encounters this condition, it has at -least 100 successful RCPT commands in its recipients buffer. If the -server is able to accept the message, then at least these 100 addresses -will be removed from the SMTP client's queue. When the client attempts -retransmission of those addresses which received 452 responses, at -least 100 of these will be able to fit in the SMTP server's recipients -buffer. Each retransmission attempt which is able to deliver anything -will be able to dispose of at least 100 of these recipients. - -If an SMTP server has an implementation limit on the number of RCPT -commands and this limit is exhausted, it MUST use a response code of 452 -(but the client SHOULD also be prepared for a 552, as noted above). If the -server has a configured site-policy limitation on the number of RCPT -commands, it MAY instead use a 5XX response code. This would be most -appropriate if the policy limitation was intended to apply if the total -recipient count for a particular message body were enforced even if that -message body was sent in multiple mail transactions. - -4.5.3.2 Timeouts - -An SMTP client MUST provide a timeout mechanism. It MUST use -per-command timeouts rather than somehow trying to time the entire mail -transaction. Timeouts SHOULD be easily reconfigurable, preferably -without recompiling the SMTP code. To implement this, a timer is set -for each SMTP command and for each buffer of the data transfer. The -latter means that the overall timeout is inherently proportional to the -size of the message. - -Based on extensive experience with busy mail-relay hosts, the minimum -per-command timeout values SHOULD be as follows: - -Initial 220 Message: 5 minutes - An SMTP client process needs to distinguish between a failed TCP - connection and a delay in receiving the initial 220 greeting - message. Many SMTP servers accept a TCP connection but delay - delivery of the 220 message until their system load permits more - mail to be processed. - -MAIL Command: 5 minutes - -RCPT Command: 5 minutes - A longer timeout is required if processing of mailing lists and - aliases is not deferred until after the message was accepted. - -DATA Initiation: 2 minutes - This is while awaiting the "354 Start Input" reply to a DATA command. - -Data Block: 3 minutes - This is while awaiting the completion of each TCP SEND call - transmitting a chunk of data. - -DATA Termination: 10 minutes. - This is while awaiting the "250 OK" reply. When the receiver gets - the final period terminating the message data, it typically performs - processing to deliver the message to a user mailbox. A spurious - timeout at this point would be very wasteful and would typically - result in delivery of multiple copies of the message, since it has - been successfully sent and the server has accepted responsibility - for delivery. See section 6.1 for additional discussion. - -An SMTP server SHOULD have a timeout of at least 5 minutes while it is -awaiting the next command from the sender. - -4.5.4 Retry Strategies - -The common structure of a host SMTP implementation includes user -mailboxes, one or more areas for queuing messages in transit, and one -or more daemon processes for sending and receiving mail. The exact -structure will vary depending on the needs of the users on the host and -the number and size of mailing lists supported by the host. We describe -several optimizations that have proved helpful, particularly for -mailers supporting high traffic levels. - -Any queuing strategy MUST include timeouts on all activities on a -per-command basis. A queuing strategy MUST NOT send error messages in -response to error messages under any circumstances. - -4.5.4.1 Sending Strategy - -The general model for an SMTP client is one or more processes that -periodically attempt to transmit outgoing mail. In a typical system, -the program that composes a message has some method for requesting -immediate attention for a new piece of outgoing mail, while mail that -cannot be transmitted immediately MUST be queued and periodically -retried by the sender. A mail queue entry will include not only the -message itself but also the envelope information. - -The sender MUST delay retrying a particular destination after one -attempt has failed. In general, the retry interval SHOULD be at least -30 minutes; however, more sophisticated and variable strategies will be -beneficial when the SMTP client can determine the reason for -non-delivery. - -Retries continue until the message is transmitted or the sender gives -up; the give-up time generally needs to be at least 4-5 days. The -parameters to the retry algorithm MUST be configurable. - -A client SHOULD keep a list of hosts it cannot reach and corresponding -connection timeouts, rather than just retrying queued mail items. - -Experience suggests that failures are typically transient (the target -system or its connection has crashed), favoring a policy of two -connection attempts in the first hour the message is in the queue, and -then backing off to one every two or three hours. - -The SMTP client can shorten the queuing delay in cooperation with the -SMTP server. For example, if mail is received from a particular -address, it is likely that mail queued for that host can now be sent. -Application of this principle may, in many cases, eliminate the -requirement for an explicit "send queues now" function such as that -discussed in [RFC-ETRN]. - -The strategy may be further modified as a result of multiple addresses -per host (see below) to optimize delivery time vs. resource usage. - -An SMTP client may have a large queue of messages for each unavailable -destination host. If all of these messages were retried in every retry -cycle, there would be excessive Internet overhead and the sending -system would be blocked for a long period. Note that an SMTP client -can generally determine that a delivery attempt has failed only after a -timeout of several minutes and even a one-minute timeout per connection -will result in a very large delay if retries are repeated for dozens, -or even hundreds, of queued messages to the same host. - -At the same time, SMTP clients SHOULD use great care in caching -negative responses from servers. In an extreme case, if EHLO is issued -multiple times during the same SMTP connection, different answers may -be returned by the server. More significantly, 5yz responses to the -MAIL command MUST NOT be cached. - -When a mail message is to be delivered to multiple recipients, and the -SMTP server to which a copy of the message is to be sent is the same -for multiple recipients, then only one copy of the message SHOULD be -transmitted. That is, the SMTP client SHOULD use the command sequence: -MAIL, RCPT, RCPT,... RCPT, DATA instead of the sequence: MAIL, RCPT, -DATA, ..., MAIL, RCPT, DATA. However, if there are very many -addresses, a limit on the number of RCPT commands per MAIL command MAY -be imposed. Implementation of this efficiency feature is strongly -encouraged. - -Similarly, to achieve timely delivery, the SMTP client MAY support -multiple concurrent outgoing mail transactions. However, some limit -may be appropriate to protect the host from devoting all its resources -to mail. - -4.5.4.2 Receiving Strategy - -The SMTP server SHOULD attempt to keep a pending listen on the SMTP -port at all times. This requires the support of multiple incoming TCP -connections for SMTP. Some limit MAY be imposed but servers that -cannot handle more than one SMTP transaction at a time are not in -conformance with the intent of this specification. - -As discussed above, when the SMTP server receives mail from a -particular host address, it could notify the SMTP client to retry any -mail pending for that host address. - -4.5.5 Messages with a null reverse-path - -There are several types of notification messages which are required by -existing and proposed standards to be sent with a null reverse path, -namely non-delivery notifications as discussed in section 3.7, other -kinds of Delivery Status Notifications (DSNs, see [RFC 1894]) and also -Message Disposition Notifications (MDNs, see [RFC 2298]). All of these -kinds of messages are notifications about a previous message, and they -are sent to the reverse-path of the previous mail message. (If the -delivery of such a notification message fails, that usually indicates a -problem with the mail system of the host to which the notification -message is addressed. For this reason, at some hosts the MTA is set up -to forward such failed notification messages to someone who is able to -fix problems with the mail system, e.g. via the postmaster alias.) - -All other types of messages (i.e. any message which is not required by -a standards-track RFC to have a null reverse-path) SHOULD be sent with -with a valid, non-null reverse-path. - -Implementors of automated email processors should be careful to make -sure that the various kinds of messages with null reverse-path are -handled correctly, in particular such systems SHOULD NOT reply to -messages with null reverse-path. - - - -5. Address Resolution and Mail Handling - -Once an SMTP client lexically identifies a domain to which mail will be -delivered for processing (as described in sections 3.6 and 3.7), a DNS -lookup MUST be performed to resolve the domain name (see [RFC-DNS]). -The names are expected to be fully-qualified domain names (FQDNs): -mechanisms for inferring FQDNs from partial names or local aliases are -outside of this specification and, due to a history of problems, are -generally discouraged. The lookup first attempts to locate an MX -record associated with the name. If a CNAME record is found instead, -the resulting name is processed as if it were the initial name. If no -MX records are found, but an A RR is found, the A RR is treated as if -it was associated with an implicit MX RR, with a preference of 0, -pointing to that host. If one or more MX RRs are found for a given -name, SMTP systems MUST NOT utilize any A RRs associated with that name -unless they are located using the MX RRs; the "implicit MX" rule above -applies only if there are no MX records present. If MX records are -present, but none of them are usable, this situation MUST be reported -as an error. - -When the lookup succeeds, the mapping can result in a list of alternative -delivery addresses rather than a single address, because of multiple MX -records, multihoming, or both. To provide reliable mail transmission, the -SMTP client MUST be able to try (and retry) each of the relevant addresses -in this list in order, until a delivery attempt succeeds. However, there -MAY also be a configurable limit on the number of alternate addresses that -can be tried. In any case, the SMTP client SHOULD try at least two -addresses. - -Two types of information is used to rank the host addresses: multiple -MX records, and multihomed hosts. - -Multiple MX records contain a preference indication that MUST be used -in sorting (see below). Lower numbers are more preferred than higher -ones. If there are multiple destinations with the same preference and -there is no clear reason to favor one (e.g., by recognition of an -easily-reached address), then the sender-SMTP MUST randomize them to -spread the load across multiple mail exchangers for a specific -organization. - -The destination host (perhaps taken from the preferred MX record) may -be multihomed, in which case the domain name resolver will return a -list of alternative IP addresses. It is the responsibility of the -domain name resolver interface to have ordered this list by decreasing -preference if necessary, and SMTP MUST try them in the order presented. - -Although the capability to try multiple alternative addresses is -required, specific installations may want to limit or disable the use -of alternative addresses. The question of whether a sender should -attempt retries using the different addresses of a multihomed host has -been controversial. The main argument for using the multiple addresses -is that it maximizes the probability of timely delivery, and indeed -sometimes the probability of any delivery; the counter-argument is that -it may result in unnecessary resource use. Note that resource use is -also strongly determined by the sending strategy discussed in section -4.5.4.1. - -If an SMTP server receives a message with a destination for which it is a -designated Mail eXchanger, it MAY relay the message (potentially after -having rewritten the MAIL FROM and/or RCPT TO addresses), make final -delivery of the message, or hand it off using some mechanism outside the -SMTP-provided transport environment. Of course, neither of the latter -require that the list of MX records be examined further. - -If it determines that it should relay the message without rewriting the -address, it MUST sort the MX records to determine candidates for -delivery. The records are first ordered by preference, with the -lowest-numbered records being most preferred. The relay host MUST then -inspect the list for any of the names or addresses by which it might be -known in mail transactions. If a matching record is found, all records -at that preference level and higher-numbered ones MUST be discarded -from consideration. If there are no records left at that point, it is -an error condition, and the message MUST be returned as undeliverable. -If records do remain, they SHOULD be tried, best preference first, as -described above. - - -6. Problem Detection and Handling - -6.1 Reliable Delivery and Replies by Email - -When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" -message in response to DATA), it is accepting responsibility for -delivering or relaying the message. It must take this responsibility -seriously. It MUST NOT lose the message for frivolous reasons, such as -because the host later crashes or because of a predictable resource -shortage. - -If there is a delivery failure after acceptance of a message, the -receiver-SMTP MUST formulate and mail a notification message. This -notification MUST be sent using a null ("<>") reverse path in the -envelope. The recipient of this notification MUST be the address from -the envelope return path (or the Return-Path: line). However, if this -address is null ("<>"), the receiver-SMTP MUST NOT send a notification. -Obviously, nothing in this section can or should prohibit local -decisions (i.e., as part of the same system environment as the -receiver-SMTP) to log or otherwise transmit information about null -address events locally if that is desired. If the address is an -explicit source route, it MUST be stripped down to its final hop. - -For example, suppose that an error notification must be sent for a -message that arrived with: - - MAIL FROM:<@a,@b:user@d> - -The notification message MUST be sent using: - - RCPT TO:<user@d> - -Some delivery failures after the message is accepted by SMTP will be -unavoidable. For example, it may be impossible for the receiving SMTP -server to validate all the delivery addresses in RCPT command(s) due to -a "soft" domain system error, because the target is a mailing list (see -earlier discussion of RCPT), or because the server is acting as a relay -and has no immediate access to the delivering system. - -To avoid receiving duplicate messages as the result of timeouts, a -receiver-SMTP MUST seek to minimize the time required to respond to the -final <CRLF>.<CRLF> end of data indicator. See RFC-1047 [RFC-1047] for -a discussion of this problem. - -6.2 Loop Detection - -Simple counting of the number of "Received:" headers in a message has -proven to be an effective, although rarely optimal, method of detecting -loops in mail systems. SMTP servers using this technique SHOULD use a -large rejection threshold, normally at least 100 Received entries. -Whatever mechanisms are used, servers MUST contain provisions for -detecting and stopping trivial loops. - -6.3 Compensating for Irregularities - -Unfortunately, variations, creative interpretations, and outright -violations of Internet mail protocols do occur; some would suggest that -they occur quite frequently. The debate as to whether a well-behaved -SMTP receiver or relay should reject a malformed message, attempt to -pass it on unchanged, or attempt to repair it to increase the odds of -successful delivery (or subsequent reply) began almost with the dawn of -structured network mail and shows no signs of abating. Advocates of -rejection claim that attempted repairs are rarely completely adequate -and that rejection of bad messages is the only way to get the offending -software repaired. Advocates of "repair" or "deliver no matter what" -argue that users prefer that mail go through it if at all possible and -that there are significant market pressures in that direction. In -practice, these market pressures may be more important to particular -vendors than strict conformance to the standards, regardless of the -preference of the actual developers. - -The problems associated with ill-formed messages were exacerbated by -the introduction of the split-UA mail reading protocols [RFC-POP2, -RFC-POP3, RFC-IMAP2, RFC-PCMAIL]. These protocols have encouraged the -use of SMTP as a posting protocol, and SMTP servers as relay systems -for these client hosts (which are often only intermittently connected -to the Internet). Historically, many of those client machines lacked -some of the mechanisms and information assumed by SMTP (and indeed, by -the mail format protocol [RFC-822]). Some could not keep adequate -track of time; others had no concept of time zones; still others could -not identify their own names or addresses; and, of course, none could -satisfy the assumptions that underlay RFC-822's conception of -authenticated addresses. - -In response to these weak SMTP clients, many SMTP systems now complete -messages that are delivered to them in incomplete or incorrect form. -This strategy is generally considered appropriate when the server can -identify or authenticate the client, and there are prior agreements -between them. By contrast, there is at best great concern about fixes -applied by a relay or delivery SMTP server that has little or no -knowledge of the user or client machine. - -The following changes to a message being processed MAY be applied when -necessary by an originating SMTP server, or one used as the target of -SMTP as an initial posting protocol: - - - Addition of a message-id field when none appears - - - Addition of a date, time or time zone when none appears - - - Correction of addresses to proper FQDN format - -The less information the server has about the client, the less likely -these changes are to be correct and the more caution and conservatism -should be applied when considering whether or not to perform fixes and -how. These changes MUST NOT be applied by an SMTP server that provides -an intermediate relay function. - -In all cases, properly-operating clients supplying correct information -are preferred to corrections by the SMTP server. In all cases, -documentation of actions performed by the servers (in trace fields -and/or header comments) is strongly encouraged. - - -7. Security Considerations - -7.1 Mail Security and Spoofing - -SMTP mail is inherently insecure in that it is feasible for even fairly -casual users to negotiate directly with receiving and relaying SMTP -servers and create messages that will trick a naive recipient into -believing that they came from somewhere else. Constructing such a -message so that the "spoofed" behavior cannot be detected by an expert -is somewhat more difficult, but not sufficiently so as to be a -deterrent to someone who is determined and knowledgeable. Consequently, -as knowledge of Internet mail increases, so does the knowledge that -SMTP mail inherently cannot be authenticated, or integrity checks -provided, at the transport level. Real mail security lies only in -end-to-end methods involving the message bodies, such as those which use -digital signatures (see [RFC-1847] and, e.g., [RFC-PGP] or [RFC-SMIME]). - -Various protocol extensions and configuration options that provide -authentication at the transport level (e.g., from an SMTP client to an -SMTP server) improve somewhat on the traditional situation described -above. However, unless they are accompanied by careful handoffs of -responsibility in a carefully-designed trust environment, they remain -inherently weaker than end-to-end mechanisms which use digitally signed -messages rather than depending on the integrity of the transport system. - -Efforts to make it more difficult for users to set envelope return path -and header "From" fields to point to valid addresses other than their -own are largely misguided: they frustrate legitimate applications in -which mail is sent by one user on behalf of another or in which error -(or normal) replies should be directed to a special address. (Systems -that provide convenient ways for users to alter these fields on a -per-message basis should attempt to establish a primary and permanent -mailbox address for the user so that Sender fields within the message -data can be generated sensibly.) - -This specification does not further address the authentication issues -associated with SMTP other than to advocate that useful functionality -not be disabled in the hope of providing some small margin of -protection against an ignorant user who is trying to fake mail. - -7.2 "Blind" Copies - -Addresses that do not appear in the message headers may appear in the -RCPT commands to an SMTP server for a number of reasons. The two most -common involve the use of a mailing address as a "list exploder" (a -single address that resolves into multiple addresses) and the -appearance of "blind copies". Especially when more than one RCPT -command is present, and in order to avoid defeating some of the purpose -of these mechanisms, SMTP clients and servers SHOULD NOT copy the full -set of RCPT command arguments into the headers, either as part of trace -headers or as informational or private-extension headers. Since this -rule is often violated in practice, and cannot be enforced, sending -SMTP systems that are aware of "bcc" use MAY find it helpful to send -each blind copy as a separate message transaction containing only a -single RCPT command. - -There is no inherent relationship between either "reverse" (from MAIL, -SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP -transaction ("envelope") and the addresses in the headers. Receiving -systems SHOULD NOT attempt to deduce such relationships and use them to -alter the headers of the message for delivery. The popular -"Apparently-to" header is a violation of this principle as well as a -common source of unintended information disclosure and SHOULD NOT be -used. - -7.3 VRFY, EXPN, and Security - -As discussed in section 3.5, individual sites may want to disable one -or both VRFY or EXPN for security reasons. As a corollary to the -above, implementations that permit this MUST NOT appear to have -verified addresses that are not, in fact, verified. If a site disables -these commands for security reasons, the SMTP server MUST return a 252 -response, rather than a code that could be confused with successful or -unsuccessful verification. - -Returning a 250 reply code with the address listed in the VRFY command -after having checked it only for syntax violates this rule. Of course, -an implementation that "supports" VRFY by always returning 550 whether -or not the address is valid is equally not in conformance. - -Within the last few years, the contents of mailing lists have become -popular as an address information source for so-called "spammers." The -use of EXPN to "harvest" addresses has increased as list administrators -have installed protections against inappropriate uses of the lists -themselves. Implementations SHOULD still provide support for EXPN, but -sites SHOULD carefully evaluate the tradeoffs. As authentication -mechanisms are introduced into SMTP, some sites may choose to make EXPN -available only to authenticated requestors. - -7.4 Information Disclosure in Announcements - -There has been an ongoing debate about the tradeoffs between the -debugging advantages of announcing server type and version (and, -sometimes, even server domain name) in the greeting response or in -response to the HELP command and the disadvantages of exposing useful -information to potential hostile attack. The utility of the debugging -information is beyond doubt. Those who argue for making it available -point out that it is far better to actually secure an SMTP server -rather than hope that trying to conceal known vulnerabilities by hiding -the server's precise identity will provide more protection. Sites are -encouraged to evaluate the tradeoff with that issue in mind; -implementations are strongly encouraged to minimally provide for making -type and version information available in some way to other network -hosts. - -7.5 Information Disclosure in Trace Fields - -In some circumstances, such as when mail originates from within a LAN -whose hosts are not directly from the public Internet, trace -("Received") fields produced in conformance with this specification may -disclose host names and similar information that would not normally be -available. This ordinarily does not pose a problem, but sites with -special concerns about name disclosure should be aware of it. Also, -the optional FOR clause should be supplied with caution or not at all -when multiple recipients are involved lest it inadvertently disclose -the identities of "blind copy" recipients to others. - - -7.6 Information Disclosure in Message Forwarding - -As discussed in section 3.4, use of the 251 or 551 reply codes to identify -the replacement address associated with a mailbox may inadvertently -disclose sensitive information. Sites that are concerned about those -issues should ensure that they select and configure servers appropriately. - - -7.7 Scope of Operation of SMTP Servers - -It is a well-established principle that an SMTP server may refuse to -accept mail for any operational or technical reason that makes sense to -the site providing the server. However, cooperation among sites and -installations makes the Internet possible. If sites take excessive -advantage of the right to reject traffic, the ubiquity of email -availability (one of the strengths of the Internet) will be threatened; -considerable care should be taken and balance maintained if a site -decides to be selective about the traffic it will accept and process. - -In recent years, use of the relay function through arbitrary sites has -been used as part of hostile efforts to hide the actual origins of -mail. Some sites have decided to limit the use of the relay function -to known or identifiable sources, and implementations SHOULD provide -the capability to perform this type of filtering. When mail is -rejected for these or other policy reasons, a 550 code SHOULD be used -in response to EHLO, MAIL, or RCPT as appropriate. - - -8. IANA Considerations - -IANA will maintain three registries in support of this specification. -The first consists of SMTP service extensions with the associated -keywords, and, as needed, parameters and verbs. As specified in -section 2.2.2, no entry may be made in this registry that starts in an -"X". Entries may be made only for service extensions (and associated -keywords, parameters, or verbs) that are defined in standards-track or -experimental RFCs specifically approved by the IESG for this purpose. - -The second registry consists of "tags" that identify forms of domain -literals other than those for IPv4 addresses (specified in RFC 821 and -in this document) and IPv6 addresses (specified in this document). -Additional literal types require standardization before being used; -none are anticipated at this time. - -The third, established by RFC 821 and renewed by this specification, is -a registry of link and protocol identifiers to be used with the "via" -and "with" subclauses of the time stamp ("Received: header") described -in section 4.4. Link and protocol identifiers in addition to those -specified in this document may be registered only by standardization or -by way of an RFC-documented, IESG-approved, Experimental protocol -extension. - - -9. References - -[US-ASCII] American National Standards Institute (formerly United States of -America Standards Institute), X3.4, 1968, "USA Code for Information -Interchange". ANSI X3.4-1968 has been replaced by newer versions with -slight modifications, but the 1968 version remains definitive for the -Internet. - -[RFC-1123] Braden, R., "Requirements for Internet hosts - application and -support", 10/01/1989 - -[RFC-POP2] Butler, M., D. Chase, J. Goldberger, J. Postel, J. Reynolds, -"Post Office Protocol - version 2", RFC 937, 02/01/1985 - -[RFC-PGP] Callas, J., L. Donnerhacke, H. Finney, R. Thayer, "OpenPGP -Message Format", RFC 2440, November 1998. - -[RFC-IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC -1176, 08/20/1990. - -[RFC-IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", RFC -2060, 12/04/1996. - -[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text -Messages", RFC 822, Department of Electrical Engineering, University of -Delaware, August 1982. - -[ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax -Specifications: ABNF", RFC 2234, November 1997. - -[RFC-ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue -Starting", RFC 1985, 08/14/1996. - -[IAB-Firewalls] Freed, N, ed., "Behavior of and Requirements for -Internet Firewalls", Work in progress, draft-iab-firewall-req-02.txt, -June 2000. - -[RFC-MIME] Freed, N., N. Borenstein, "Multipurpose Internet Mail Extensions -(MIME) Part One: Format of Internet Message Bodies", RFC 2045, 12/02/1996. - -[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension for Command -Pipelining", RFC 1854, 10/04/1995. - -[RFC-1847] Galvin, J., S. Murphy, S. Crocker, N. Freed. "Security -Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, -October 1995. - -[SUBMIT] R. Gellens, J. Klensin, "Message Submission", RFC 2476, December -1998. - -[RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021 -and RFC 822", RFC 1327, 05/18/1992. - -[IPv6AddrSpec] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing -Architecture", RFC 1884, December 1995. - -[RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension for -Message Size Declaration", RFC 1870, 11/06/1995. (STD 10) - -[SMTPEXT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP -Service Extensions", RFC-1869, 11/06/1995. (STD 10) - -[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP -Service Extension for 8bit-MIMEtransport", RFC 1652, 07/18/1994. - -[RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for personal -computers", RFC 1056, 06/01/1988. - -[RFC-DNS] Mockapetris, P., "Domain names - implementation and -specification", RFC 1035 and P. Mockapetris, "Domain names - concepts and -facilities", RFC 1034. (STD 13) - -[RFC-INTLHDR] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part -Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 12/02/1996. - -[RFC-NOTARY1] Moore, K., "SMTP Service Extension for Delivery Status -Notifications", RFC 1891, 01/15/1996. - -[RFC-NOTARY2] Moore, K., G. Vaudreuil, "An Extensible Message Format for -Delivery Status Notifications", RFC 1894, 01/15/1996. - -[RFC-POP3] Myers, J., M. Rose, "Post Office Protocol - Version 3", RFC 1930, -5/14/96 (Std 53). - -[RFC-974] Partridge, C., "Mail routing and the domain system", RFC 974, -01/01/1986 - -[RFC-1047] Partridge, C., "Duplicate messages and SMTP", RFC 1047, -02/01/1988. - -[TCP] Postel, J., ed., "Transmission Control Protocol - DARPA Internet -Program Protocol Specification", RFC 793, USC/Information Sciences -Institute, NTIS AD Number A111091, September 1981. - -[RFC-821] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 1, -1982. - -[RFC-SMIME] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC -2633, June 1999. - -[MSGFMT] Resnick, P., Work in progress, draft-ietf-drums-msg-fmt-08.txt, -January 2000. - -[RFC-BDAT] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large -and Binary MIME Messages", RFC 1830, 08/16/1995. - -[RFC-REPLY] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, -01/15/1996. - - -10. Editor's Address - -John C. Klensin -AT&T Laboratories -Tel: 617-574-3076 -email: klensin@research.att.com - - - -11. Acknowledgments - -Many people worked long and hard on the many iterations of this document. -There was wide-ranging debate on the mailing list about many technical -issues, and many contributors helped form the wording in this -specification. The hundreds of participants in the many discussions since -RFC 821 was produced are too numerous to mention, but they all helped this -document become what it is. - - - - - APPENDICES - -A. TCP Transport Service - -The TCP connection supports the transmission of 8-bit bytes. The SMTP -data is 7-bit ASCII characters. Each character is transmitted as an -8-bit byte with the high-order bit cleared to zero. Service extensions -may modify this rule to permit transmission of full 8-bit data bytes as -part of the message body, but not in SMTP commands or responses. - - -B. Generating SMTP Commands from RFC 822 Headers - -Some systems use RFC 822 headers (only) in a mail submission protocol, -or otherwise generate SMTP commands from RFC 822 headers when such a -message is handed to an MTA from a UA. While the MTA-UA protocol is a -private matter, not covered by any Internet Standard, there are -problems with this approach. For example, there have been repeated -problems with proper handling of "bcc" copies and redistribution lists -when information that conceptually belongs to a mail envelopes is not -separated early in processing from header information (and kept -separate). - -It is recommended that the UA provide its initial MTA with an envelope -separate from the message itself. However, if the envelope is not -supplied, SMTP commands SHOULD be generated as follows: - -1. Each recipient address from a TO, CC, or BCC header field SHOULD be - copied to a RCPT command (generating multiple message copies if that - is required for queuing or delivery). This includes any addresses - listed in a RFC 822 "group". Any BCC fields SHOULD then be removed - from the headers. Once this process is completed, the remaining - headers SHOULD be checked to verify that at least one To:, Cc:, or - Bcc: header remains. If none do, then a bcc: header with no - additional information SHOULD be inserted as specified in [MSGFMT]. - -2. The return address in the MAIL command SHOULD, if possible, be - derived from the system's identity for the submitting (local) user, - and the "From:" header field otherwise. If there is a system - identity available, it SHOULD also be copied to the Sender header - field if it is different from the address in the From header field. - (Any Sender field that was already there SHOULD be removed.) - Systems may provide a way for submitters to override the envelope - return address, but may want to restrict its use to privileged - users. This will not prevent mail forgery, but may lessen its - incidence; see section 7.1. - -When an MTA is being used in this way, it bears responsibility for -ensuring that the message being transmitted is valid. The mechanisms -for checking that validity, and for handling (or returning) messages -that are not valid at the time of arrival, are part of the MUA-MTA -interface and not covered by this specification. - -A submission protocol based on Standard RFC 822 information alone MUST -NOT be used to gateway a message from a foreign (non-SMTP) mail system -into an SMTP environment. Additional information to construct an -envelope must come from some source in the other environment, whether -supplemental headers or the foreign system's envelope. - -Attempts to gateway messages using only their header "to" and "cc" -fields have repeatedly caused mail loops and other behavior adverse to -the proper functioning of the Internet mail environment. These -problems have been especially common when the message originates from -an Internet mailing list and is distributed into the foreign -environment using envelope information. When these messages are then -processed by a header-only remailer, loops back to the Internet -environment (and the mailing list) are almost inevitable. - - -C. Source Routes - -The <reverse-path> is a reverse source routing list of hosts and a -source mailbox. The first host in the <reverse-path> SHOULD be the -host sending the MAIL command. Similarly, the <forward-path> may be a -source routing lists of hosts and a destination mailbox. However, in -general, the <forward-path> SHOULD contain only a mailbox and domain -name, relying on the domain name system to supply routing information -if required. The use of source routes is deprecated; while servers -MUST be prepared to receive and handle them as discussed in section 3.3 -and F.2, clients SHOULD NOT transmit them. - -For relay purposes, the forward-path may be a source route of the form -"@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE -fully-qualified domain names. This form is used to emphasize the -distinction between an address and a route. The mailbox is an absolute -address, and the route is information about how to get there. The two -concepts should not be confused. - -If source routes are used, RFC 821 and the text below should be -consulted for the mechanisms for constructing and updating the forward- -and reverse-paths. - -The SMTP server transforms the command arguments by moving its own -identifier (its domain name or that of any domain for which it is -acting as a mail exchanger), if it appears, from the forward-path to -the beginning of the reverse-path. - -Notice that the forward-path and reverse-path appear in the SMTP -commands and replies, but not necessarily in the message. That is, -there is no need for these paths and especially this syntax to appear -in the "To:" , "From:", "CC:", etc. fields of the message header. -Conversely, SMTP servers MUST NOT derive final message delivery -information from message header fields. - -When the list of hosts is present, it is a "reverse" source route and -indicates that the mail was relayed through each host on the list (the -first host in the list was the most recent relay). This list is used -as a source route to return non-delivery notices to the sender. As each -relay host adds itself to the beginning of the list, it MUST use its -name as known in the transport environment to which it is relaying the -mail rather than that of the transport environment from which the mail -came (if they are different). - - -D. Scenarios - -This section presents complete scenarios of several types of SMTP -sessions. In the examples, "C:" indicates what is said by the SMTP -client, and "S:" indicates what is said by the SMTP server. - -D.1 A Typical SMTP Transaction Scenario - -This SMTP example shows mail sent by Smith at host bar.com, to Jones, -Green, and Brown at host foo.com. Here we assume that host bar.com -contacts host foo.com directly. The mail is accepted for Jones and -Brown. Green does not have a mailbox at host foo.com. - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<Smith@bar.com> - S: 250 OK - C: RCPT TO:<Jones@foo.com> - S: 250 OK - C: RCPT TO:<Green@foo.com> - S: 550 No such user here - C: RCPT TO:<Brown@foo.com> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.2 Aborted SMTP Transaction Scenario - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<Smith@bar.com> - S: 250 OK - C: RCPT TO:<Jones@foo.com> - S: 250 OK - C: RCPT TO:<Green@foo.com> - S: 550 No such user here - C: RSET - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.3 Relayed Mail Scenario - -Step 1 -- Source Host to Relay Host - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: MAIL FROM:<JQP@bar.com> - S: 250 OK - C: RCPT TO:<@foo.com:Jones@XYZ.COM> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Date: Thu, 21 May 1998 05:33:29 -0700 - C: From: John Q. Public <JQP@bar.com> - C: Subject: The Next Meeting of the Board - C: To: Jones@xyz.com - C: - C: Bill: - C: The next meeting of the board of directors will be - C: on Tuesday. - C: John. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - -Step 2 -- Relay Host to Destination Host - - S: 220 xyz.com Simple Mail Transfer Service Ready - C: EHLO foo.com - S: 250 xyz.com is on the air - C: MAIL FROM:<@foo.com:JQP@bar.com> - S: 250 OK - C: RCPT TO:<Jones@XYZ.COM> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Received: from bar.com by foo.com ; Thu, 21 May 1998 - C: 05:33:29 -0700 - C: Date: Thu, 21 May 1998 05:33:22 -0700 - C: From: John Q. Public <JQP@bar.com> - C: Subject: The Next Meeting of the Board - C: To: Jones@xyz.com - C: - C: Bill: - C: The next meeting of the board of directors will be - C: on Tuesday. - C: John. - C: . - S: 250 OK - - C: QUIT - S: 221 foo.com Service closing transmission channel - -D.4 Verifying and Sending Scenario - - S: 220 foo.com Simple Mail Transfer Service Ready - C: EHLO bar.com - S: 250-foo.com greets bar.com - S: 250-8BITMIME - S: 250-SIZE - S: 250-DSN - S: 250 HELP - C: VRFY Crispin - S: 250 Mark Crispin <Admin.MRC@foo.com> - C: SEND FROM:<EAK@bar.com> - S: 250 OK - C: RCPT TO:<Admin.MRC@foo.com> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - C: QUIT - S: 221 foo.com Service closing transmission channel - - -E. Other Gateway Issues - -In general, gateways between the Internet and other mail systems SHOULD -attempt to preserve any layering semantics across the boundaries -between the two mail systems involved. Gateway-translation approaches -that attempt to take shortcuts by mapping, (such as envelope -information from one system to the message headers or body of another) -have generally proven to be inadequate in important ways. Systems -translating between environments that do not support both envelopes and -headers and Internet mail must be written with the understanding that -some information loss is almost inevitable. - - -F. Deprecated Features of RFC 821 - -A few features of RFC 821 have proven to be problematic and SHOULD NOT -be used in Internet mail. - -F.1 TURN - -This command, described in RFC 821, raises important security issues -since, in the absence of strong authentication of the host requesting -that the client and server switch roles, it can easily be used to -divert mail from its correct destination. Its use is deprecated; SMTP -systems SHOULD NOT use it unless the server can authenticate the client. - -F.2 Source Routing - -RFC 821 utilized the concept of explicit source routing to get mail -from one host to another via a series of relays. The requirement to -utilize source routes in regular mail traffic was eliminated by the -introduction of the domain name system "MX" record and the last -significant justification for them was eliminated by the introduction, -in RFC 1123, of a clear requirement that addresses following an "@" -must all be fully-qualified domain names. Consequently, the only -remaining justifications for the use of source routes are support for -very old SMTP clients or MUAs and in mail system debugging. They can, -however, still be useful in the latter circumstance and for routing -mail around serious, but temporary, problems such as problems with the -relevant DNS records. - -SMTP servers MUST continue to accept source route syntax as specified -in the main body of this document and in RFC 1123. They MAY, if -necessary, ignore the routes and utilize only the target domain in the -address. If they do utilize the source route, the message MUST be sent -to the first domain shown in the address. In particular, a server MUST -NOT guess at shortcuts within the source route. - -Clients SHOULD NOT utilize explicit source routing except under unusual -circumstances, such as debugging or potentially relaying around -firewall or mail system configuration errors. - -F.3 HELO - -As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to -HELO when the server will accept the former. Servers must continue to -accept and process HELO in order to support older clients. - -F.4 #-literals - -RFC 821 provided for specifying an Internet address as a decimal -integer host number prefixed by a pound sign, "#". In practice, that -form has been obsolete since the introduction of TCP/IP. It is -deprecated and MUST NOT be used. - -F.5 Dates and Years - -When dates are inserted into messages by SMTP clients or servers (e.g., -in trace fields), four-digit years MUST BE used. Two-digit years are -deprecated; three-digit years were never permitted in the Internet mail -system. - -F.6 Sending versus Mailing - -In addition to specifying a mechanism for delivering messages to user's -mailboxes, RFC 821 provided additional, optional, commands to deliver -messages directly to the user's terminal screen. These commands (SEND, -SAML, SOML) were rarely implemented, and changes in workstation -technology and the introduction of other protocols may have rendered -them obsolete even where they are implemented. - -Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers -MAY implement them. If they are implemented by servers, the -implementation model specified in RFC 821 MUST be used and the command -names MUST be published in the response to the EHLO command. - - -X. Change Summary and Loose Ends (Temporary) - -X.1 Change summary - -X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and -draft-ietf-drums-smtpupd-01.txt - -(i) Slightly clarified the discussions of rejection and failure of VRFY -requests and the associated response codes. - -(ii) Slightly clarified the discussion of deferred address validation. - -(iii) Removed the IPCE terminology and modified the text in section -4.1.1.2 to explicitly introduce the "mail gateway" terminology and to -begin to distinguish a mail gateway from a conventional relay. - -(iv) Explicitly noted that SMTP clients for things like POP and IMAP -may send everything to a single relay for further processing, rather -than resolving final domain names. - -(v) Tightened the RSET discussion. - -(vi) Deprecation of 251 only for RCPT (still ok for VRFY) - -X.1.2. Substantive changes between draft-ietf-drums-smtpupd-01.txt and -draft-ietf-drums-smtpupd-02.txt. - -Incorporated additional RFC 1123 material; reorganized several sections -for clarity. Added definitions and other previous "loose end" material. - -X.1.3. Substantive changes between draft-ietf-drums-smtpupd-02.txt and -draft-ietf-drums-smtpupd-03.txt. - -(i) Eliminated a number of placeholders and tightened some of the -definitions in section 2. Added a few new placeholders for consistency -checking against other documents. - -(ii) Removed the state diagrams, per direction at IETF Montreal. - -(iii) Added new section 6.3, an attempt to summarize WG discussions on -the "posting" versus "delivery" versus "relay" functions of SMTP and on -whether "fixups" are appropriate in different cases. - -(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of RFC1123. - -(v) Added new text to 3.5.5 to discuss the spammer - EXPN relationship. - -(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat. - -(v) The remaining miscellaneous changes agreed to in Montreal have been -incorporated except as noted below. - -X.1.4. Substantive changes between draft-ietf-drums-smtpupd-03.txt and -draft-ietf-drums-smtpupd-04.txt. - -Many small changes have been made between these two versions; the list -that follows is not exhaustive. - -(i) To clarify some of the text, definitions have been introduced to -distinguish among originating, delivery, relay, and gateway SMTP -systems. - -(ii) The role of LF-terminated lines has been clarified. - -(iii) Several changes have been made to clarify the principle that, no -matter what originating and final delivery systems might do, relay -systems are not permitted to tamper with message content, even to "fix" -headers that are determined to be invalid. If they deem message -content to be seriously unacceptable, they are encouraged to reject the -messages in preference to trying to fix them up, but, in general, the -theme is "don't look/ don't tell". - -(iv) A few more definitions have been added to the terminology section, -and the separate glossary has been eliminated. - -(v) I have taken a shot at text to address some of the controversies -that have raged on the WG mailing list (e.g., sections 7.4 and 7.5). -Since there was no consensus on most of those topics, I expect that the -inserted text will satisfy no one except, perhaps, for agreement that -saying nothing would have been worse. As a mechanism for moving -forward, the text in these controversial areas that now appears will be -considered "base"; alterations will be made only if clear consensus -emerges. - -(vi) Per discussion in Los Angeles, source routes have been further -deprecated. - -(vii) Some of the VRFY/EXPN materials have been moved to "security -considerations", where they appear to belong, some text has been added, -and the conformance statements adjusted to reflect what I perceive to -be WG consensus. - -(viii) New MX resolution material has been added to section 5. While -most of this material is from RFC974, the rules have been further -tightened to reflect current practice and experience (974 is written in -a somewhat speculative fashion for a standard). In particular, the -behavior of trying the target host's A RR when MXs existed but all of -them were eliminated is now prohibited, which seems necessary if -another of other ideas being recommended or considered are to be -feasible. - -X.1.5. Substantive changes between draft-ietf-drums-smtpupd-04.txt and -draft-ietf-drums-smtpupd-05.txt. - -(i) All normative references to RFC 1123 have been removed from the -main body of the text (some still appear in the appendices where they -will remain). - -(ii) Section 3.5 has been renamed slightly to distinguish between -"debugging of SMTP implementations" and "debugging of addresses". -Better terminology would be welcome. - -(iii) Error conditions resulting from the DATA command have been -clarified. - -(iv) Section 4.2 (SMTP replies) has been revised and tightened to -reflect reality and recent discussion on the list. - -(v) Appendix E has been revised a bit and moved into section 4.2.1. -Given the importance of the "check only first digit" rule, it has to be -there. - -(vi) Added new text for "no SMTP service supported" to sections 3.1, -4.2.2, 4.2.3, and 4.3.2. As noted in 3.1, I'd rather add 521 (which -would work perfectly with the model) rather than overloading 554. - -(vii) The Return-path language in section 4.4 has been cleaned up a bit. - -(viii) Tightened the "postmaster" language in 4.5.1, requiring a small -change to 4.1.1.3. - -(ix) I have unilaterally (with a little help from my friends), -increased some of the size limits. 64 was much too short for a domain -name, and the DNS limit of 255 (?) has now been inserted. That leaves -the return path much too short, but I haven't fixed it (maybe that will -cause us to get rid of them). We still have a 64 character limit on -the local-part, which is also *much* too short. Votes for 128 or longer -limits accepted. See X.1.6(I) - -(x) The text on the "recipients buffer" has been rewritten so that (I -hope) it makes sense and gives some explicit guidance for how clients -and servers should proceed if limits are imposed. - -X.1.6. Substantive changes between draft-ietf-drums-smtpupd-05.txt and -draft-ietf-drums-smtpupd-06.txt. - -Most of the changes in this revision have been editorial rather than -substantive. Major substantive changes include: - -(i) The language about maximum sizes of SMTP command lines has been -reworked, per WG mailing list discussion. - -(ii) Several instances of "SHOULD" have been promoted to "MUST" when -the reasons for the weaker rule seemed to have disappeared. In -particular, the requirement that an SMTP implementation support -timeouts has become a MUST. Also, conformance to this specification -requires support of EHLO. Older systems should claim conformance to -the [to-be-historical] 821, not this specification. - -X.1.7. Substantive changes between draft-ietf-drums-smtpupd-06.txt and -draft-ietf-drums-smtpupd-07.txt. - -(i) Removed "implied RSET" text associated with QUIT, as specified at -the December 1997 IETF. - -(ii) Required that servers support EHLO, as specified at the December -1997 IETF. - -X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt and -draft-ietf-drums-smtpupd-08.txt. - -This version involves mostly editorial work and cleanup of loose ends. - -(i) New 7.5 added (old one renumbered) to discuss info disclosure -through Received fields. - -(ii) Some character set and minor syntax issues clarified. - -(iii) Material on code 571 added (thought this had been done long ago; -slipped through the cracks) - -(iv) Many clarifications added as the result of list discussions and -suggestions. - -(v) Error code presentation has been restructured. - -(vi) ABNF conversion done - -(vii) IPv6 address format inserted per RFC 1884, since we could not get -clear agreement on an alternative. - -(viii) Trivial, silly, examples removed. Others not yet renumbered. - -(ix) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes. Eric -may not like the way I've done either of these change very much: the -first now makes the distinction between returning an address and -returning other stuff (which was permitted by -06, but the text wasn't -as clear as it should have been): if it looks like an address, it needs -to be an address. Similarly, with 4.1.1, Eric wanted to explicitly -permit/legitimize "DATA <SP> <CRLF>". I see several disadvantages to -doing that, so have inserted language that encourages receivers to -tolerate trailing white space, which may have the same practical effect. - - -X.1.9. Substantive changes between draft-ietf-drums-smtpupd-08.txt and -draft-ietf-drums-smtpupd-09.txt. - -The first ten of these reflect, in order, minuted items from the -Chicago IETF (IETF 42). - -(i) Clarification of "MUST", etc., in the context of this document -(section 2.3). - -(ii) Altered VRFY text to make implementation a SHOULD (section 3.5.1) -and removed VRFY from the mandatory to implement list (section 4.5.1), -per 42nd IETF (Chicago). - -(iii) Clarified that exploders are expected to not purge sender -addresses from lists (section 3.10). Note that the Chicago conclusion -was that this should be a "MUST". I could not figure out how to do -that without absolutely prohibiting removing addresses to prevent -loops, to guard against spammers, or for similar legitimate purposes. -So I have written this as a "SHOULD", with additional "strongly -discouraged" words. If someone still wants a MUST, suggest text. - -(iv) Altered text to permit clients that sometimes, or even always, -initiate sessions with HELO, rather than EHLO, to be fully-conforming -(section 3.2). [[ Editor's note: I continue to believe that a client -that does not have any service extension support, even to the extent of -being able to send EHLO and parse the response without doing anything -about it, should not be considered fully-conforming to this spec (as -distinct from 821). Consequently, the new text in 3.2 stops well short -of encouraging clients that don't need service extensions from -preferentially using HELO, and the text in 2.2.1 (which specifies that -the extension mechanisms must be supported) has not been changed. - -(v) Per Chicago discussions, the text requiring that QUIT be sent has -not been changed. The text in 4.1.1.10 requiring that the server wait -for QUIT has been changed to a SHOULD. However, the text in 4.1.1.5, -prohibiting close on receipt of RSET and that elsewhere prohibiting -close as a normal response, has not been changed. - -(vi) Text has been inserted in 4.1.1 and the text in 4.3.2 altered -slightly to clarify the handling of parameters to RSET, DATA, and QUIT -and to 4.1.1.9 specify semantics for parameters to NOOP. I have -followed the minutes on this although I personally agree with kre's -mailing list comments that the "servers SHOULD reject" decision leads -to silly states. I recommend that the WG review this. - -(vii) Per discussion in Chicago, no substantive change has been made to -the specification about underscore characters in domain names (section -4.1.2). However, the text has been altered to more accurately reflect -discussion on the mailing list and the source of the requirement. - -(viii) Per discussion in Chicago, no change has been made to the -preference for local time in Received headers. - -(ix) Per discussion in Chicago, code 571 has been removed and policy -rejection is now reflected i a 550 code (section 3.7 and the response -code lists). - -(x) Per discussion in Chicago, no change has been made to the -specification of use of raw CR or LF. - -(xi) In section 4.3, the text has been changed, per comments from Dan -Bernstein and others, to require that clients be able to handle replies -that do not contain text strings. A few other places patched to match. - -(xii) In sections 4.1.1.1 and 8, the placeholders have been removed. - -(xiii) Per discussion on the mailing list (and specifically James -Berriman's concerns), the text has been clarified (sections 4.1.1.2 and -4.1.4) to prohibit MAIL unless no mail transaction is open. This is a -MUST NOT prohibition -- SHOULD NOT makes no sense if this is the -direction we are going to go. 503 has also been added to the list of -valid responses for "MAIL" in 4.3.1 - it can't be issued before -EHLO/HELO in any event. While it is clear that something should be -said, this may not be the desired outcome (I selected it because it was -conservative and easy given the text that was there already); the WG -should check that the text is as intended. - -(xiv) Per discussion on the mailing list, a new section 4.5.5 has been -added to describe null return paths and their handling (forward pointer -from 3.7). The text in 4.5.5 is substantially that suggested by -Norbert Bollow. As with (xiii), there is now clear text, but it may -not be what the WG desires. Please check. - -(xv) "all addresses" substituted for "each...in turn" in 3.10.2. - -(xvi) Requirement for "<" and ">" around paths clarified in section 3.3 -(syntax productions were clear and correct, but not this overview -material). - -(xvii) Clarified text in 3.3 to permit post-DATA bounces on policy -matters. - - -X.1.10. Substantive changes between draft-ietf-drums-smtpupd-09.txt and -draft-ietf-drums-smtpupd-10.txt. - -(i) A large series of typos, most of them caught by Philip Hazel, -corrected. - -(ii) Residual problems with references to mailboxes, forward, and -reverse paths in 4.1.1.2 and 4.1.1.3 corrected and some text, I hope, -clarified. - -(iii) Text added to 4.2.5 to talk about 5yz errors after DATA. This -text should be checked carefully -- it is a proposal and may or may not -reflect WG consensus. - -(iv) Upper bound on "seconds" has been changed to 60 (not 61), per list -discussion. Years are still four-digits and will stay that way unless -the list discussion converges on something else. The increase to 60 -seconds includes an explicit note about leap seconds. - -(v) Text has been inserted to reflect the Orlando consensus about -"QUIT", i.e., the client MUST send a QUIT command and SHOULD wait for -the results before closing the connection. Servers are still not -permitted to close without receiving a QUIT and sending a 221 response -(except, of course, under the usual "unavoidable circumstances", in -which case they should get off a 451 if that is feasible). - -(vi) The EHLO response specification has been changed back to reflect -non-advertisement of VRFY and some text implying that VRFY was optional -to support has been removed (WG consensus seemed to be moving in that -direction at one point, and the editor reacted prematurely). This -makes the text compatible with RFC1869 and restores VRFY to its RFC1123 -status. - -(vii) The text in section 5 has been clarified with regard to what a -relay that receives a message because of its designation as an MX can -do and 3.7 has been slightly modified to point to it. - -(viii) New text has been added to 3.7 to clarify the use of "SMTP -server" relays in "dumb" originating clients. - -(viii) Small wording changes inserted into 4.1.4 (e.g., insertion of ", -if possible," into the first sentence of the fifth paragraph to -eliminate the apparent conflict with the second sentence). - - -X.1.11. Substantive changes between draft-ietf-drums-smtpupd-10.txt and -draft-ietf-drums-smtpupd-11.txt. Note that the most significant change -is the insertion of RFC 2234-conforming ABNF throughout. That material -should be checked carefully. - -(i) Dumb client text revised again, as discussed on the list and using -the text agreed to there. New text simply notes that the submission -issues are outside the scope of the spec/standard. - -(ii) ABNF updated and replaced (thanks, Chris). Some possible issues/ -questions: - - (ii.1) RFC 1869 permits a NUL octet in the greeting (ehlo-greet in - the syntax). Chris proposes to remove that capability on the - grounds that it has no obvious value and will probably not - work with many servers anyway. - - (ii.2) Previous drafts have assumed that the tag to indicate what - is coming in a non-IPv4 address literal will be separated by - the address itself by a space. Chris proposes to change it to - a colon, on the theory that this will cause fewer parsing - problems with existing MTAs and MUAs. - - (ii.3) The full IPv6 address syntax has been transposed from - the prose of RFC2373 into ABNF. It can be left out and 2373 - cited if the WG prefers. - -(iii) Added firewall clarification to section 2.3.8. - -(iv) Small clarifications and tightenings in several sections, notably -the end of 3.7, 3.8.3, 4.5.4.2, 7.2, clarifying editorial changes -elsewhere, slightly improved crossreferences, and some redundant -sections stripped out. Many thanks to Graham Klyne for extensive -and specific comments in these areas. - -(v) The "TO:" in "RCPT TO:" is part of an argument, not part of the -command. Similarly for "FROM:" in "MAIL FROM:". All of these are -believed to be fixed. - -(vi)Section 2.3.5 has been changed to make it clear that restrictions -on the syntax and character set of domain names are part of the mail -system, not an intrinsic limit of the DNS itself. This, and some -other text, are not going to be popular with those working to -internationalize the DNS, but I believe it is important to lay down a -clear baseline and then start making modifications or extensions, -rather than trying to delude ourselves with a DNS equivalent of "just -send 8". - -(vii) Clarified the EHLO-> HELO fallback requirement in 3.2. I think -this is consistent with what the WG wanted; if not, I'm sure I'll hear -about it. - - -X.1.12. Substantive changes between draft-ietf-drums-smtpupd-11.txt and -draft-ietf-drums-smtpupd-12.txt. - -(i) DATA failure text in section 3.3 has been corrected and clarified. - -(ii) "Daytime" and supporting productions removed and replaced by a -reference to 822bis. The new text prohibits use of the "obs-" forms in -822bis, which have been deprecated in SMTP since RFC1123. Note that -this change creates what I think is the first substantive normative -reference between the two documents in order to gain consistency. We -had earlier tried to not bind the two of them together in this way, but -probably it is worth it. - -(iii) Conditions under which mail to Postmaster may be dropped or bounced -have been clarified in section 4.5.1. - -(iv) Revised the treatment of 251 and 551. Both are now permitted (again), -but the text has been revised to clarify the restritions and clarifications -on using them. See section 3.4. - -(v) A lot of small editorial improvements have been made, including -changing of some section titles for clarity and removal of a few more -redundant paragraphs. - - -Z. Full Copyright Statement - -Copyright (C) The Internet Society (1998-2000). All Rights Reserved. - -This document and translations of it may be copied and furnished to -others, and derivative works that comment on or otherwise explain it or -assist in its implementation may be prepared, copied, published and -distributed, in whole or in part, without restriction of any kind, -provided that the above copyright notice and this paragraph are -included on all such copies and derivative works. However, this -document itself may not be modified in any way, such as by removing the -copyright notice or references to the Internet Society or other -Internet organizations, except as needed for the purpose of developing -Internet standards in which case the procedures for copyrights defined -in the Internet Standards process must be followed, or as required to -translate it into languages other than English. - -The limited permissions granted above are perpetual and will not be -revoked by the Internet Society or its successors or assigns. - -This document and the information contained herein is provided on an -"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING -TASK FORCE DISCLAIMS 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. - -Expires December 2000. diff --git a/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-00.txt b/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-00.txt deleted file mode 100644 index 9aef36f2..00000000 --- a/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-00.txt +++ /dev/null @@ -1,354 +0,0 @@ -Internet Engineering Task Force Motonori Nakamura -INTERNET-DRAFT Kyoto University -Expires: October 11, 2001 Jun-ichiro itojun Hagino - IIJ Research Laboratory - April 11, 2001 - - - IPv6 SMTP operational requirements - draft-ietf-ngtrans-ipv6-smtp-requirement-00.txt - -Status of this Memo - - -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. - -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/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Distribution of this memo is unlimited. - -The internet-draft will expire in 6 months. The date of expiration will -be October 11, 2001. - - -Abstract - -The memo lists operational requirements for IPv6 SMTP, and IPv6-capable -MX DNS records. As we deploy IPv6 SMTP servers, it became apparent that -we need certain configuration in IPv6-capable MX DNS record, for stable -dual-stack (IPv4 and IPv6) SMTP operations. The document tries to -clarify the problems we have in transition period between IPv4 SMTP and -IPv6 SMTP, and operational requirements for stable IPv4/v6 SMTP -operation. - -The document does not try to define any new protocol. - - -1. Summary of IPv4 MX operation - -For reference purpose, the section outlines how mail message delivery is -performed in IPv4-only environment [Partridge, 1986] . - - - -NAKAMURA, HAGINO Expires: October 11, 2001 [Page 1] - - -DRAFT IPv6 SMTP operational requirements April 2001 - -In IPv4 SMTP operation, we register MX records like below, for -"sample.org." domain: - - sample.org. IN MX 1 mx1.sample.org. - IN MX 10 mx10.sample.org. - mx1.sample.org. IN A 1.0.0.1 - mx10.sample.org. IN A 1.0.0.2 - -When an MTA delivers a message to a particular destination (say it is to -foo@sample.org), the MTA would send DNS queries to lookup DNS database -in the following order: - -o Lookup MX record for "sample.org.". - - o If an MX record is returned, try to lookup A record on the righthand - side of the MX record. - - o If a CNAME record is returned, try to chase the CNAME chain. - Eventually we will reach some A record. - - o If MX lookup failed with NO_DATA, it means that there is no MX - record but there can be other record for "sample.org.". Lookup A - record for "sample.org.". - - o If MX lookup failed with HOST_NOT_FOUND, it means that there is no - record at all for "sample.org.". This means a delivery failure. - - -2. MX records and IPv6 SMTP operation - -The following sections talk about how to make IPv4 SMTP and IPv6 SMTP -coexist, under dual-stack environment during the transition period -between IPv4 to IPv6. In the future, when we have completely migrated -to IPv6-only network, we can forget about IPv4/v6 SMTP interaction. - -As IPv6 DNS lookup RFCs [Thomson, 1995; Crawford, 2000] use IN class for -both IPv4 and IPv6, we will use IN MX records for both IPv4 and IPv6. - -For simplicity, the document lists DNS records for IPv6 address as AAAA -records, not as A6 records [Crawford, 2000] . In reality, we can use a -chain of A6 records, instead of AAAA records. - -There are couple of technologies defined for IPv4 and IPv6 transition. -The document concentrates on issues with dual stack environment. -Translators do not need special consideration from SMTP point of view; -If we have SMTP traffic from IPv6 MTA to IPv4 MTA over an IPv6-to-IPv4 -translator, the traffic will be considered as a normal IPv4 SMTP -traffic, from the IPv4 MTA point of view. We may, however, need some -consideration on translators for protocols like IDENT [StJohns, 1993] . - - - - - -NAKAMURA, HAGINO Expires: October 11, 2001 [Page 2] - - -DRAFT IPv6 SMTP operational requirements April 2001 - -3. SMTP sender algorithm in dual stack environment - -When we lookup MX records for the domain in IPv4/v6 dual stack -environment, we will see records like below: - - sample.org. IN MX 1 mx1.sample.org. - IN MX 10 mx10.sample.org. - mx1.sample.org. IN A 1.0.0.1 ; IPv4/v6 dual stack - IN AAAA 3ffe:501:ffff::1 - mx10.sample.org. IN AAAA 3ffe:501:ffff::2 ; IPv6 only - -For single MX record, we have many possibility for the final lookup -result, including: (a) single, or multiple A records for IPv4 -destination, (b) single, or multiple AAAA records for IPv6 destination, -(c) mixture of A and AAAA records. As we can define multiple MX records -with different preference value, we also need to go through multiple -addresses based on multiple MXes. We need to cope with domains without -MX records, and failure recovery cases too. - -The algorithm for a SMTP sender would be like this. - -(1) Lookup MX record for the destination domain. If a CNAME record is - returned, go back to step (1) with the queried result. If MX - records are returned, go to step (2) with the result. If NO_DATA - is returned, go to step (3) as there is no MX record. If - HOST_NOT_FOUND is returned, there is no domain, raise permanent - email delivery failure (finish). - -(2) We have multiple MX records with us. Loop steps from (3) to (8), - based on MX preference values, in ascending order. - -(3) If the source MTA has IPv4 capability, lookup A record. Keep the - resulting address till step (5). - -(4) If the source MTA has IPv6 capability, lookup AAAA record. - -(5) Reorder queried result based on implementation-dependent preference - between A and AAAA records. - -(6) Loop steps from (7) to (8), for all the addresses (or part of the - list of addresses) we have. If no reachable destination is found, - and if we are going through a list of MX records, go back to (3) - and try the next MX record. If we do not have a list of MX - records, or we have reached the end of the list of MX records, - raise temporary delivery failure (finish). - -(7) Try to make a TCP connection to the destination. If it fails, try - the next address we have. If it succeeds, go to step (8). - -(8) Try a SMTP protocol negotiation. If SMTP protocol negotiation - fails with TEMPFAIL (4xx), go back to (3) and try the next MX - record. If it succeeds, SMTP delivery was successful (finish). - - -NAKAMURA, HAGINO Expires: October 11, 2001 [Page 3] - - -DRAFT IPv6 SMTP operational requirements April 2001 - -4. MX configuration in receipient domain - -4.1. Ensuring reachability for both protocol versions - -If a site has IPv4/v6 dual stack reachability, the site SHOULD configure -both A and AAAA records onto its MX hosts. It will help both IPv4 and -IPv6 senders to reach the site efficienlty. - -4.2. Reachability between primary and secondary MX - -When we configure MX records onto DNS database in dual-stack -environment, we need to be careful about reachability between MX hosts. -Suppose we try to gather all inbound email to primary MX host, -mx1.sample.org. - - sample.org. IN MX 1 mx1.sample.org. - IN MX 10 mx10.sample.org. - IN MX 100 mx100.sample.org. - -If mx1.sample.org is an IPv6 only node and the rest are IPv4 only node, -we have no reachability between primary MX host and the rest. Once an -email reaches one of secondary MX host, the email will never reach the -primary MX. - - ; the configuration is troublesome. - ; no secondary MX can reach mx1.sample.org. - sample.org. IN MX 1 mx1.sample.org. ; IPv6 only - IN MX 10 mx10.sample.org. ; IPv4 only - IN MX 100 mx100.sample.org. ; IPv4 only - -The easiest possible configuration is to configure the primary MX host -as an IPv4/v6 dual stack node. By doing so, secondaries will have no -problem reaching the primary MX host. - - ; the configuration works just fine. - ; emails reaches from secondary MX to primary with no trouble. - sample.org. IN MX 1 mx1.sample.org. ; IPv4/v6 dual stack - IN MX 10 mx10.sample.org. ; IPv4 only - IN MX 100 mx100.sample.org. ; IPv6 only - -There are many other ways to ensure the reachability between secondary -MX and primary MX. For example, we could configure secondary MX to -route emails statically, without considering DNS MX configuration. Or -we could estalish alternative email routing path (i.e. UUCP, or via -IPv4/v6 translator) between secondary MX and the primary MX. - - -5. Open issues - -o How to interpret scoped address on MTAs. As we relay emails between - MTAs, interpretation of scoped address can be different between MTAs, - as intermediate MTAs may be in different scope zone as the originator. - - -NAKAMURA, HAGINO Expires: October 11, 2001 [Page 4] - - -DRAFT IPv6 SMTP operational requirements April 2001 - - If we get scoped IPv6 address as a result of DNS lookups, how MTAs - should behave? If we consider scoped address in ``route-addr'' - specification [Crocker, 1982] like - - <itojun@kame.net@[fec0::1]@itojun.org> - - it gets more trickier. - - -6. Security consideration - -As presented in ``Open issues'' section, it could be problematical if -route-addr email address format is used across multiple scope zones. -MTAs would need to reject emails with improper route-addr email address -formats. - - -References - -Partridge, 1986. -C. Partridge, "Mail routing and the domain system" in RFC974 (January -1986). ftp://ftp.isi.edu/in-notes/rfc974.txt. - -Thomson, 1995. -S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in -RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt. - -Crawford, 2000. -M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6 -Address Aggregation and Renumbering" in RFC2874 (July 2000). -ftp://ftp.isi.edu/in-notes/rfc2874.txt. - -StJohns, 1993. -M. StJohns, "Identification Protocol" in RFC1413 (January 1993). -ftp://ftp.isi.edu/in-notes/rfc1413.txt. - -Crocker, 1982. -D. Crocker, "Standard for the format of ARPA Internet text messages" in -RFC822 (August 1982). ftp://ftp.isi.edu/in-notes/rfc822.txt. - - -Change history - -None. - - -Acknowledgements - -The draft was written based on discussions with Japanese IPv6 users, and -help from WIDE research group. - - - - -NAKAMURA, HAGINO Expires: October 11, 2001 [Page 5] - - -DRAFT IPv6 SMTP operational requirements April 2001 - -Author's address - - Motonori NAKAMURA - Center for Information and Multimedia Studies, Kyoto University - Yoshida-nihonmatsu-cho, Sakyo, Kyoto 606-8501, JAPAN - Tel: +81-75-753-9063 - Fax: +81-75-753-9056 - Email: motonori@media.kyoto-u.ac.jp - - Jun-ichiro itojun HAGINO - Research Laboratory, Internet Initiative Japan Inc. - Takebashi Yasuda Bldg., - 3-13 Kanda Nishiki-cho, - Chiyoda-ku,Tokyo 101-0054, JAPAN - Tel: +81-3-5259-6350 - Fax: +81-3-5259-6351 - Email: itojun@iijlab.net - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -NAKAMURA, HAGINO Expires: October 11, 2001 [Page 6] - diff --git a/Documentation/en/I-D/draft-varshavchik-verp-smtpext-01.txt b/Documentation/en/I-D/draft-varshavchik-verp-smtpext-01.txt deleted file mode 100644 index 4185755d..00000000 --- a/Documentation/en/I-D/draft-varshavchik-verp-smtpext-01.txt +++ /dev/null @@ -1,538 +0,0 @@ -INTERNET-DRAFT S. Varshavchik -Expires Jan 26, 2000 Double Precision, Inc. - Jul 26, 1999 - - Variable Envelope Return Path SMTP Extension - draft-varshavchik-verp-smtpext-01.txt - -Status Of This Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - 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. - -0. Revision history - - 01 - added additional comments on DSNs not being very successful in - automatically handling mailing list functions. Additional section - added with comments regarding vacation autoresponders. - -1. Abstract - - This document describes an extension to the SMTP service [1], called - Variable Envelope Return Path (VERP). The VERP extension implements - a way of automatically identifying undeliverable mail recipients, - even when non-delivery reports originate from mail systems that do - not implement delivery status notifications, as specified in [2] and - [3]. - -2. Introduction - - All E-mail software can expect to deal with undeliverable mail. [2] - and [3] specify a machine-readable format for delivery status - -S. Varshavchik Expires Jan 26, 2000 [Page 1] - -VERP SMTP Extension S. Varshavchik Jul 26, 2000 - - notifications (DSNs, or non-delivery reports). DSNs allow - undeliverable mail to be handled in a totally automatic fashion, - without requiring manual intervention. For example, mailing list - managers can automatically identify addresses that are no longer - deliverable, and remove them from the mailing list. - - Although [2] and [3] are now widely implemented, there are still many - systems that do not use them. This makes it impractical to - completely rely on DSNs for automatic mailing list management. - Undeliverable addresses accumulate quickly even from a very small - percentage of non-DSN systems. This results in a non-trivial amount - of manual work to identify undeliverable addresses and purge them - from the mailing list. - - Mailing list software began to use VERPs (the acronym stands for - Variable Envelope Return Path) after DSNs were found to be - impractical for totally automatic mailing list management. VERPs are - an alternative way to handle non-delivery notices. The advantage of - VERPs is that they can be made to work automatically, even when non- - delivery notices are not in the format specified by [2]. - - Unfortunately, VERPs require much more bandwidth and network - resources than DSNs because VERPs cannot be used to send one copy of - a mailing list message addressed to all the recipients in the same E- - mail domain. - - This SMTP service extension allows E-mail software to send a single - VERP message to all addresses in the same mail domain, for as long as - mail servers, which relay the message, support the VERP SMTP - extension. - - The VERP message may be eventually relayed to a mail server that does - not support this extension. Separate messages - with variable - envelope return paths - will be sent when this happens. - - So the worst case scenario results in the same situation where - traditional VERPs are used right from the start. The best case - scenario results in significant savings of network resources and - bandwidth, from eliminating hundreds (or more) copies of the same - message. - - Essentially, the VERP extension postpones the generation of multiple - messages with different return paths as much as possible, until it is - absolutely required. - -2.1 VERP overview - - The traditional VERP message encodes the recipient address as a - -S. Varshavchik Expires Jan 26, 2000 [Page 2] - -VERP SMTP Extension S. Varshavchik Jul 26, 2000 - - portion of the return address. When undeliverable mail comes back, - the mail software decodes the return address (now the recipient - address) and obtains the address responsible for the non-delivery - notice. - - For example: mail sent by a mailing list manager to the address - <john@example.org> carries a return address of <mlist-return- - john=example.org@domain.com>. The mailing list software at - domain.com handles all mail with the local portion of the address - starting with "mlist-return-". If a non-delivery notice is generated - because the address is not deliverable, the mailing list software - takes the address where the non-delivery report was sent, retrieves - the remaining portion of the local address, "john=example.org", and - determines that the undeliverable address was <john@example.org>. - - This does not rely on RFC 1894, and will work for all non-delivery - notices. - -3. Framework for the VERP SMTP transport extension - - This SMTP transport extension [1] is laid out as follows. - - (1) The name of the SMTP transport extension defined here is - Variable Envelope Return Path. - - (2) The EHLO keyword associated with this extension is VERP. - - (3) The VERP EHLO keyword takes no parameters. - - (4) One optional ESMTP keyword VERP is associated with the MAIL - FROM command. This parameter takes no values. - - (5) No additional ESMTP verbs are defined by this extension. - - (6) The next section specifies how support for this extension - affects the behavior of a server and client SMTP. - -4. The VERP SMTP extension - - When a VERP keyword is present in the MAIL FROM command, [4], some - additional restrictions are imposed on the RFC 822 address [5], - specified by that MAIL FROM command, and on all RFC 822 addresses in - the subsequent RCPT TO commands that refer to the same message (that - is, until the next DATA, RSET, or QUIT command). The term "VERP - message" refers to any E-mail message whose MAIL FROM command - includes the VERP keyword. The term "VERP-compliant server" refers - to any E-mail server that supports the Variable Envelope Return Path - SMTP extension. When a VERP keyword is present in the MAIL FROM - -S. Varshavchik Expires Jan 26, 2000 [Page 3] - -VERP SMTP Extension S. Varshavchik Jul 26, 2000 - - command: - - (1) The address specified by the MAIL FROM verb MUST contain at - least one @ character. - - (2) The address in every RCPT TO verb referring to the same - message MUST contain at least one @ character. - - (3) The domain portion of the address in the MAIL FROM and RCPT - TO verbs MUST be compliant with the definition of <domain> in - [6]. That is, it MUST contain only letters, digits, hyphens, - and periods. The domain portion of the address is the one - that follows the last @ character, - -4.1 Delivery failures - - When a VERP-compliant server is unable to deliver a VERP message to - one or more recipients, the VERP server MUST do one of the following: - - 1) Return an RFC 1891 delivery status notification to the return - address, or: - - 2) Transmit a separate non-delivery notice for each failed - recipient. The return address for each non-delivery notice - MUST be the address that's formed by applying the procedure - described in section 7 of this document to the return address - of the message and the failed recipient's address. If more - than one recipient was undeliverable a separate notice MUST - be sent for each undeliverable address. - -5. Final delivery - - Section 4.3.1 of [5] specifies that the mail server performing final - delivery of a message will generate a Return-Path: header containing - the return address of the message. - - This return address MUST be formed by applying the procedure - described in section 7 of this document to the return address and the - recipient's address. - - This also applies if the mail server invokes some other external - process to handle final delivery, instead of placing the message into - the recipient's mailbox. In all cases, the return address specified - by the mail server to any external environment or process MUST be - derived by applying the procedure in section 7 to the return address - and the recipient's address. - -6. Relaying - -S. Varshavchik Expires Jan 26, 2000 [Page 4] - -VERP SMTP Extension S. Varshavchik Jul 26, 2000 - - When a VERP-compliant server determines that a recipient of a VERP - message is not a local mailbox, and the message must be relayed to - another server, the VERP-compliant server MUST: - - (1) If the VERP-compliant server's local policies require the - return and/or recipient addresses MUST comply with the - restrictions specified in section 4 of this document. - - (2) If the VERP-compliant server determines that the remote - server is also a VERP compliant server, the VERP keyword MUST - be included in the MAIL FROM command used to relay the VERP - message to the remote server. - - (3) If the remote server is not a VERP compliant server, The VERP - compliant server SHOULD send a separate copy of the message - for every recipient. The return address of each copy of the - message MUST be formed by applying the procedure described in - section 7 of this document to the original return address, - and the address of each individual recipient. Although the - message SHOULD NOT be returned as undeliverable, if it is - then the rules defined in section 4.1 MUST be applied. - - These rules also apply if the SMTP-compliant server - determines that the VERP message must be forwarded via some - other protocol to a non-SMTP gateway, unless the non-SMTP - protocol has equivalent features that are completely - identical in function to Variable Envelope Return Path SMTP - service extension (including any translations of E-mail - addresses to and from the non-RFC822 format). - -7. Variable envelope return path encoding - - This encoding method starts with a return address and one recipient - address. As mentioned previously, both addresses MUST be valid - RFC822 addresses, [5], and MUST contain at least one @ character. - The portion of each address following the last @ character MUST be - compliant with [6]. - - Let "sdomain" represent the portion of the return address that - follows the last @ character. - - Let "slocal" represent the portion of the return address that - precedes the last @ character. - - Let "rdomain" represent the portion of the recipient address that - follows the last @ character. - - Let "rlocal" represent the portion of the recipient address that - -S. Varshavchik Expires Jan 26, 2000 [Page 5] - -VERP SMTP Extension S. Varshavchik Jul 26, 2000 - - precedes the last @ character. - - To encode the recipient address within the envelope sender address, - create an address of the following form: - - slocal-encodedrlocal=rdomain@sdomain - - Where "encodedrlocal" is formed by taking rlocal and encoding it as - follows: - - 1) Each @, :, %, !, and + character in rlocal is replaced by a - single '+' character followed by two uppercase hexadecimal - characters whose value is the ASCII code of the replaced - character. - - 2) All other characters are unchanged. Other characters MAY, - but SHOULD NOT be also encoded in the same fashion. - - This can be represented using BNF as follows: - - encodedverp: slocal "-" encodedrlocal "=" rdomain "@" sdomain - - encodedrlocal: * (char-literal / char-encoded ) - - char-literal: any character valid in an RFC821 address [4], - except @, :, %, !, and + - - char-encoded: "+" hexdigit hexdigit - - hexdigit: ("0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / - "9" / "A" / "B" / "C" / "D" / "E" / "F" ) - -8. Variable envelope return path decoding - - Non-delivery notices for VERP messages will be sent to either the - original address, <slocal@sdomain>, or to the VERP-encoded address, - <slocal-encodedrlocal=rdomain@sdomain>. - - Messages sent to <slocal@sdomain> will be RFC 1891-compliant delivery - status notifications. These messages will be machine-readable, and - the mail software will be able to identify failed addresses from the - RFC 1891 delivery report. - - Non-delivery notices will also be sent to the VERP-encoded address, - and the mail software will be able to reconstruct the failed address - from the VERP-encoded address by simply reversing the steps used in - encoding: - -S. Varshavchik Expires Jan 26, 2000 [Page 6] - -VERP SMTP Extension S. Varshavchik Jul 26, 2000 - - 1) Extracting encodedrlocal and rdomain from the recipient - address. There will be at least one = character in the - encoded portion of the return address. encodedrlocal is - everything up to the last = character. Everything following - the last = character is rdomain. - - 2) Replacing all occurrences of "+" followed by two hexadecimal - digits in encodedrlocal with the equivalent ASCII character. - - 3) Using the decoded rlocal, @, then rdomain. - -9. Examples - - Suppose that a VERP-compliant server named "example.com" receives a - message via the following SMTP conversation (for brevity, non- - relevant headers have been omitted): - - 250 example.com ESMTP - EHLO domain.com - 250-example.com ESMTP - 250-SIZE - 250-DSN - 250-VERP - 250 HELP - MAIL FROM:<itny-out@domain.com> VERP SIZE=100 - 250 Ok - RCPT TO:<alex@example.com> - 250 Ok - RCPT TO:<node42!ann@old.example.com> - 250 Ok - RCPT TO:<tom@old.example.com> - 250 Ok - RCPT TO:<lisa@new.example.com> - 250 Ok - RCPT TO:<dave+priority@new.example.com> - 250 Ok - DATA - 250 Ok - From: "John" <john@domain.com> - Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST) - Subject: Meeting canceled. - - Today's 2pm meeting has been rescheduled for tomorrow, 9am, due - to a scheduling conflict. - . - - The message is delivered to the local mailbox for <alex@example.com>. - The message looks like this: - -S. Varshavchik Expires Jan 26, 2000 [Page 7] - -VERP SMTP Extension S. Varshavchik Jul 26, 2000 - - Return-Path: <itny-out-alex=example.com@domain.com> - From: "John" <john@domain.com> - Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST) - Subject: Meeting canceled. - - Today's 2pm meeting has been rescheduled for tomorrow, 9am, due - to a scheduling conflict. - - The VERP-compliant server at example.com connects to the mail server - for old.example.com. old.example.com does not support the Variable - Envelope Return Path extension. Therefore, old.example.com receives - two messages. The SMTP conversation for the first message is as - follows: - - 250 old.example.com ESMTP - EHLO example.com - 250-old.example.com ESMTP - 250-SIZE - 250-DSN - 250 HELP - MAIL FROM:<itny-out-node42+21ann=old.example.com@domain.com> - 250 Ok - RCPT TO:<node42!ann@old.example.com> - 250 Ok - DATA - 250 Ok - From: "John" <john@domain.com> - Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST) - Subject: Meeting canceled. - - Today's 2pm meeting has been rescheduled for tomorrow, 9am, due - to a scheduling conflict. - . - - The SMTP conversation for the second message is as follows: - - MAIL FROM:<itny-out-tom=old.example.com@domain.com> - 250 Ok - RCPT TO:<tom@old.example.com> - 250 Ok - DATA - 250 Ok - From: "John" <john@domain.com> - Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST) - Subject: Meeting canceled. - - Today's 2pm meeting has been rescheduled for tomorrow, 9am, due - to a scheduling conflict. - -S. Varshavchik Expires Jan 26, 2000 [Page 8] - -VERP SMTP Extension S. Varshavchik Jul 26, 2000 - - . - - example.com connects to new.example.com and determines that - new.example.com runs a modern ESMTP server that supports the VERP - keyword. The SMTP conversation then goes like this: - - 250 new.example.com ESMTP - EHLO example.com - 250-new.example.com ESMTP - 250-SIZE - 250-DSN - 250-VERP - 250 HELP - MAIL FROM:<itny-out@domain.com> VERP SIZE=100 - 250 Ok - RCPT TO:<lisa@new.example.com> - 250 Ok - RCPT TO:<dave+priority@new.example.com> - 250 Ok - DATA - 250 Ok - From: "John" <john@domain.com> - Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST) - Subject: Meeting canceled. - - Today's 2pm meeting has been rescheduled for tomorrow, 9am, due - to a scheduling conflict. - . - -10. Security concerns - - All the usual security considerations applicable to SMTP are also - applicable to this extension. Relay of VERP messages to non-VERP - servers requires a single message with many recipients to be exploded - into many messages with one recipient. In all cases, however, there - will never be any additional overhead beyond the resources that are - required when VERPs are manually implemented by the mail sender, - instead of the VERP SMTP extension. - - Mail systems which support the VERP extension SHOULD have adequate - security measures, including blocks against unauthorized access and - relaying. - -10.1 Vacation programs, and other autoresponders - - "Vacation" type autoresponders are often used in practice. A - vacation autoresponder is a program that automatically replies to - every message, informing the sender that the recipient is on - -S. Varshavchik Expires Jan 26, 2000 [Page 9] - -VERP SMTP Extension S. Varshavchik Jul 26, 2000 - - vacation, or is generally unavailable at this time. - - Vacation autoresponders MUST NOT generate autoresponses to mailing - list messages, but people often forget to do set them up to do so. - Because autoresponses are sent to the same address that's used to - receive non-delivery reports, malfunctioning autoresponders result in - the recipient being removed from mailing lists. - - Advanced autoresponders send automatic replies in the format - specified by [2], as a "delayed" notification. DSN-aware software - will not remove addresses from mailing lists due to delayed - notifications. - - Section 5 of this document specifies that the mail server MUST - replace the original return address with a VERP-modified address when - delivering the message to a mailbox or an external process. - - Therefore it is possible that RFC 1891 reports may also be sent to a - VERP-encoded address, as specified by sections 5 and 7 of this - document. Mail software SHOULD ignore any RFC 1891 "delayed" or - "success" reports that sent to a VERP-encoded address. If it is a - "failed" report, note that the VERP address will be more reliable - than the address specified in the report itself. - -S. Varshavchik Expires Jan 26, 2000 [Page 10] - -VERP SMTP Extension S. Varshavchik Jul 26, 2000 - -11. References - - [1] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D. - "SMTP Service Extensions", RFC 1425, United Nations - University, Innosoft International, Inc., Dover Beach - Consulting, Inc., Network Management Associates, Inc., The - Branch Office, February 1993 - - [2] Moore, K., and G. Vaudreuil, "An Extensible Message Format - for Delivery Status Notifications", RFC 1894, University of - Tennessee, Octel Network Services, January 1996. - - [3] Moore, K. "SMTP Service Extension for Delivery Status - Notifications", RFC 1891, University of Tennessee, January - 1996. - - [4] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, - USC/Information Sciences Institute, August 1982. - - [5] Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", STD 11, RFC 822, UDEL, August 1982. - - [6] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, ISI, November 1987 - -12. Author's address - - Sam Varshavchik - Double Precision, Inc. - PO Box 668 - Greenwood Lake, NY 10925 - <mrsam@concentric.net> - -S. Varshavchik Expires Jan 26, 2000 [Page 11] diff --git a/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-00.txt b/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-00.txt deleted file mode 100644 index ca632b75..00000000 --- a/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-00.txt +++ /dev/null @@ -1,679 +0,0 @@ - Internet Draft Greg Vaudreuil - Expires in six months Lucent Technologies - December 1, 1999 - - - SMTP Service Extensions - for Transmission of Large - and Binary MIME Messages - - draft-vaudreuil-esmtp-binary2-00.txt - - - - Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC 2026. - - This document is an Internet Draft. 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 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 a "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. - - - To learn the current status of any Internet-Draft, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), - munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or - ftp.isi.edu (US West Coast). - - - - Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This Internet-Draft is in conformance with Section 10 of RFC 2026. - - Abstract - - This memo defines two extensions to the SMTP service. The first - service enables a SMTP client and server to negotiate the use of an - alternative to the DATA command, called "BDAT" for efficiently sending - large MIME messages. The second extension takes advantage of the BDAT - command to permit the negotiated sending of binary contents wrapped in - MIME but without a transport encoding. This document is intended to - update and obsolete RFC1830. - - - - Internet Draft Binary ESMTP December 1, 1999 - - - Working Group Summary - - This protocol is not the product of an IETF working group, however the - specification resulted from discussions within the ESMTP working - group. The resulting protocol documented in RFC1830 was classified as - experimental at that time due to questions about the robustness of the - Binary Content-Transport-Encoding deployed in then existent MIME - implementations. As MIME has matured and other uses of the Binary - Content-Transport-Encoding have been deployed, these concerns have - been allayed. With this document, Binary ESMTP is expected to become - standards-track. - - Table of Contents - - 1. OVERVIEW ..........................................................2 - 2. FRAMEWORK FOR THE LARGE MESSAGE EXTENSIONS ........................3 - 3. FRAMEWORK FOR THE BINARY SERVICE EXTENSION ........................5 - 4. EXAMPLES ..........................................................7 - 4.1 Simple Chunking .................................................7 - 4.2 Pipelining Binarymime ...........................................8 - 5. SECURITY CONSIDERATIONS ...........................................9 - 6. ACKNOWLEDGMENTS ...................................................9 - 7. REFERENCES ........................................................9 - 8. COPYRIGHT NOTICE ..................................................9 - 9. AUTHOR'S ADDRESS .................................................10 - 10. APPENDIX A - CHANGES FROM RFC1830 ................................11 - - - 1. Overview - - The MIME extensions to the Internet message protocol provides for the - transmission of many kinds of data that was previously unsupported in - Internet mail. Anticipating the need to more efficiently transport - the new media made possible with MIME, the SMTP protocol has been - extended to provide transport for new message types. RFC 1426 defines - one such extension for the transmission of unencoded 8-bit MIME - messages [8BIT]. This service extension permits the receiver SMTP to - declare support for 8-bit body parts and the sender to request 8-bit - transmission of a particular message. - - One expected result of the use of MIME is that the Internet mail - system will be expected to carry very large mail messages. In such - transactions, there is a performance-based desire to eliminate the - requirement that the message be scanned for "CR LF . CR LF" sequences - upon sending and receiving to detect the end of message. - - Independent of the need to send large messages, Internet mail is - increasingly multi-media. There is a need to avoid the overhead of - base64 and quoted-printable encoding of binary objects sent using the - MIME message format over SMTP between hosts that support binary - message processing. - - This memo uses the mechanism defined in [ESMTP] to define two - extensions to the SMTP service whereby a client ("sender-SMTP") may - - Vaudreuil Expires 5/1/00 [Page 2] - - - - Internet Draft Binary ESMTP December 1, 1999 - - - declare support for the message chunking transmission mode and support - for the receiption of Binary messages. - - 2. Framework for the Large Message Extensions - - The following service extension is hereby defined: - - The name of the data chunking service extension is "CHUNKING". - - The EHLO keyword value associated with this extension is "CHUNKING". - - A new SMTP verb is defined "BDAT" as an alternative to the "DATA" - command of [RFC821]. The BDAT verb takes two arguments. The first - argument indicates the length, in octets, of the binary data chunk. - The second optional argument indicates that the data packet is the - last. - - bdat-cmd ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF - chunk-size ::= 1*DIGIT - end-marker ::= "LAST" - - The CHUNKING service extension enables the use of the BDAT alternative - to the DATA command. This extension can be used for any message, - whether 7 bit, 8BITMIME or BINARYMIME. - - When a client SMTP wishes to submit (using the MAIL command) a large - message using the CHUNKING extension, it first issues the EHLO command - to the server SMTP. If the server SMTP responds with code 250 to the - EHLO command and the response includes the EHLO keyword value - CHUNKING, then the server SMTP is indicating that it supports the BDAT - command and will accept the sending of messages in chunks. - - After all MAIL FROM and RCPT TO responses are collected and processed, - the message is sent using a series of BDAT commands. The BDAT command - takes one required argument, the exact length of the data segment in - octets. The message data is sent immediately after the trailing <CR> - <LF> of the BDAT command line. Once the receiver-SMTP receives the - specified number of octets, it will return a 250 reply code. - - The optional LAST parameter on the BDAT command indicates that this is - the last chunk of message data to be sent. Any BDAT command sent - after the BDAT LAST is illegal and must be replied to with a 503 "Bad - sequence of commands" reply code. The state resulting from this error - is indeterminate. A RSET command must be sent to clear the - transaction before continuing. - - A 250 response should be sent to each BDAT data block. If a failure - ocures after a BDAT command is received, the receiver-SMTP must accept - and discard the associated message data before sending the 5XX code. - If a 5XX code is received by the sender-SMTP in response to a BDAT - chunk, the message should be considered failed and the sender SMTP - must not send any additional BDAT segments. If the receiver-SMTP has - declared support for streaming, the receiver SMTP must be prepared to - - - Vaudreuil Expires 5/1/00 [Page 3] - - - - Internet Draft Binary ESMTP December 1, 1999 - - - accept and discard additional BDAT chunks already in the pipeline - after the failed BDAT. - - Note: An error on the receiver-SMTP such as disk full or imminent - shutdown can only be reported after the BDAT segment has been - received. It is therefore important to choose a reasonable chunk - size given the expected end-to-end bandwidth. - - Note: Because the receiver-SMTP does not acknowledge the BDAT - command before the messafge data is sent, it is important to send - the BDAT only to systems that have declared their capability to - accept BDAT commands. Illegally sending a BDAT command and - associated message data to a non-chunking capable system will - result in the receiver-SMTP parsing the associated message data - as if it were a potentially very long, binary-data containing - E/SMTP command line. - - The resulting state from a failed BDAT command is indeterminate. A - RSET command must be issued to clear the transaction before additional - commands may be sent. The RSET command, when issued after the first - BDAT and before the BDAT LAST, clears all segments sent during that - transaction and resets the session. - - DATA and BDAT commands cannot be used in the same transaction. If a - DATA statement is issued after a BDAT for the current transaction, a - 503 "Bad sequence of commands" must be issued. The state resulting - from this error is indeterminate. A RSET command must be sent to - clear the transaction before continuing. There is no prohibition on - using DATA and BDAT in the same session, so long as they are not mixed - in the same transaction. - - The local storage size of a message may not accurately reflect the - actual size of the message sent due to local storage conventions. In - particular, text messages sent with the BDAT command MUST be sent in - the canonical MIME format with lines delimited with a <CR><LF>. It - may not be possible to convert the entire message to the canonical - format at once. Chunking provides a mechanism to convert the message - to canonical form, accurately count the bytes, and send the message a - single chunk at a time. - - Note that correct byte counting is essential. If the sender - SMTP indicates a chunk-size larger than the actual chunnk-size, - the receiver SMTP will continue to wait for the remainder of the - data or when using streaming, will read the subsequent command - as additional message data. In the case where a portion of the - previous command was read as data, the parser will return a - syntax error when the incomplete command is read. - - If the sender SMTP indicates a chunk-size smaller than the - actual chunk-size, the receiver SMTP will interpret the - remainder of the message data as invalid commands. Note that - the remainder of the message data may be binary and as such - lexicographical parsers must be prepared to receive, process, - and reject lines of arbitrary octets. - - Vaudreuil Expires 5/1/00 [Page 4] - - - - Internet Draft Binary ESMTP December 1, 1999 - - - 3. Framework for the Binary Service Extension - - The following service extension is hereby defined: - - 1) The name of the binary service extension is "BINARYMIME". - - 2) The EHLO keyword value associated with this extension is - "BINARYMIME". - - 3) The BINARYMIME service extension can only be used with the - "CHUNKING" service extension. - - 4) No parameter is used with the BINARYMIME keyword. - - 5) [8BIT] defines the BODY parameter for the MAIL command. This - extension defines an additional value for the BODY parameter, - "BINARYMIME". The value "BINARYMIME" associated with this parameter - indicates that this message is a Binary MIME message (in strict - compliance with [MIME]) with arbitrary octet content being sent. The - revised syntax of the value is as follows, using the ABNF notation of - [RFC822]: - - body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME" - - 6) No new verbs are defined for the BINARYMIME extension. - - A sender SMTP may request that a binary MIME message be sent without - transport encoding by sending a BINARYMIME parameter with the MAIL - command. When the receiver SMTP accepts a MAIL FROM command with the - BINARYMIME body type requested, it agrees to preserve all bits in each - octet passed using the BDAT command. - - BINARYMIME cannot be used with the DATA command. If a DATA command is - issued after a MAIL command containing the body-value of "BINARYMIME", - a 501 response should be sent. The resulting state from this error - condition is indeterminate and the transaction should be reset with - the RSET command. - - It is important to note that when using BINARYMIME, it is especially - important to ensure that the MIME message itself is properly formed. - In particular, it is essential that text be canonically encoded with - each line properly terminated with <CR> <LF>. Any transformation of - text into non-canonical MIME to observe local storage conventions must - be reversed before sending as BINARYMIME. Some line-oriented - shortcuts will break if used with BINARYMIME. - - The syntax of the extended MAIL command is identical to the MAIL - command in [RFC821], except that a BODY parameter must appear after - the address. The complete syntax of this extended command is defined - in [ESMTP]. The ESMTP-keyword is BODY and the syntax for ESMTP-value - is given by the syntax for body-value in [ESMTP]. - - - - - Vaudreuil Expires 5/1/00 [Page 5] - - - - Internet Draft Binary ESMTP December 1, 1999 - - - If a receiver-SMTP does not indicate support the BINARYMIME message - format then the client SMTP must not, under any circumstances, send - binary data using the BDAT command. - - If the receiver-SMTP does not support BINARYMIME and the message - content is a MIME object with a binary encoding, a client SMTP has two - options with which to forward the message. First, it may implement a - gateway transformation to convert the message into valid 7bit-encoded - MIME. Second, it may treat this as a permanent error and handle it in - the usual manner for delivery failures. The specifics of the - transformation from Binary MIME to 7bit MIME are not described by this - RFC; the conversion is nevertheless constrained in the following ways: - - 1. The conversion must cause no loss of information; MIME transport - encodings must be employed as needed to insure this is the case. - - 2. The resulting message must be valid 7bit MIME. In particular, the - transformation may not result in nested Base-64 or Quoted-Printable - content-transfer-encodings. - - As of present there are no mechanisms for converting a binary MIME - object into an 8-bit MIME object. Such a transformation will require - the specification of a new MIME content-transfer-encoding, the - standardization of which is discouraged by [MIME]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Vaudreuil Expires 5/1/00 [Page 6] - - - - Internet Draft Binary ESMTP December 1, 1999 - - - 4. Examples - - 4.1 Simple Chunking - - The following simple dialogue illustrates the use of the large message - extension to send a short psudo-RFC822 message to one recipient using - the CHUNKING extension: - - R: <wait for connection on TCP port 25> - S: <open connection to server> - R: 220 cnri.reston.va.us SMTP service ready - S: EHLO ymir.claremont.edu - R: 250-cnri.reston.va.us says hello - R: 250 CHUNKING - S: MAIL FROM:<Sam@Random.com> - R: 250 <Sam@Random.com> Sender ok - S: RCPT TO:<Susan@Random.com> - R: 250 <Susan@random.com> Recipient ok - S: BDAT 86 LAST - S: To: Susan@random.com<CR><LF> - S: From: Sam@random.com<CR><LF> - S: Subject: This is a bodyless test message<CR><LF> - R: 250 Message OK, 86 octets received - S: QUIT - R: 221 Goodbye - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Vaudreuil Expires 5/1/00 [Page 7] - - - - Internet Draft Binary ESMTP December 1, 1999 - - - 4.2 Pipelining Binarymime - - The following dialogue illustrates the use of the large message - extension to send a BINARYMIME object to two recipients using the - CHUNKING and PIPELINING extensions: - - R: <wait for connection on TCP port - S: <open connection to server> - R: 220 cnri.reston.va.us SMTP service ready - S: EHLO ymir.claremont.edu - R: 250-cnri.reston.va.us says hello - R: 250-PIPELINING - R: 250-BINARYMIME - R: 250 CHUNKING - S: MAIL FROM:<ned@ymir.claremont.edu> BODY=BINARYMIME - S: RCPT TO:<gvaudre@cnri.reston.va.us> - S: RCPT TO:<jstewart@cnri.reston.va.us> - R: 250 <ned@ymir.claremont.edu>... Sender and BINARYMIME ok - R: 250 <gvaudre@cnri.reston.va.us>... Recipient ok - R: 250 <jstewart@cnri.reston.va.us>... Recipient ok - S: BDAT 100000 - S: (First 10000 octets of canonical MIME message data) - S: BDAT 324 LAST - S: (Remaining 324 octets of canonical MIME message data) - R: 250 100000 bytes received - R: 250 Message OK, 100324 octets received - S: QUIT - R: 221 Goodbye - - - - - - - - - - - - - - - - - - - - - - - - - - - - Vaudreuil Expires 5/1/00 [Page 8] - - - - Internet Draft Binary ESMTP December 1, 1999 - - - 5. Security Considerations - - This extension is not known to present any security issues already - endemic in electronic mail and present in fully conforming - implementations of [RFC821], or otherwise made possible by [MIME]. - - 6. Acknowledgments - - This protocol is the result of numerous discussions in the IETF SMTP - Extensions Working Group and in particular due to the continued - advocacy of "chunking" by Neil Katin. - - 7. References - - [BINARY] Vaudreuil, G, " SMTP Service Extensions for Transmission of - Large and Binary MIME Messages", RFC 1830, August 1995. - - [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, - USC/Information Sciences Institute, August 1982. - - [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", STD 11, RFC 822, UDEL, August 1982. - - [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message Bodies", RFC - 2045, Bellcore, Innosoft, November 1996. - - [ESMTP] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, - E., and D. Crocker, "SMTP Service Extensions" RFC 1869, United Nations - University, Innosoft International, Inc., Dover Beach Consulting, - Inc., Network Management Associates, Inc., The Branch Office, November - 1995. - - [8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, - E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport" - RFC 1652, United Nations University, Innosoft International, Inc., - Dover Beach Consulting, Inc., Network Management Associates, Inc., The - Branch Office, July 1994. - - [PIPE] Freed, N., "SMTP Service Extensions for Command Pipelining", - RFC 1854, Innosoft International, October 1995. - - 8. Copyright Notice - - "Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - - Vaudreuil Expires 5/1/00 [Page 9] - - - - Internet Draft Binary ESMTP December 1, 1999 - - - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be followed, - or as required to translate it into languages other than English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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." - - 9. Author's Address - - Gregory M. Vaudreuil - Lucent Technologies - Communications Application Group - 17080 Dallas Parkway - Dallas, TX 75248-1905 - Voice/Fax: +1-972-733-2722 - - GregV@Lucent.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Vaudreuil Expires 5/1/00 [Page 10] - - - - Internet Draft Binary ESMTP December 1, 1999 - - - 10. Appendix A - Changes from RFC1830 - - Numerous editorial changes including required intellectual property - boilerplate and revised authors contact information - - Corrected the simple chunking example to use the correct number of - bytes. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Vaudreuil Expires 5/1/00 [Page 11] -
\ No newline at end of file diff --git a/Documentation/en/I-D/draft-ward-esmtp-slide-03.txt b/Documentation/en/I-D/draft-ward-esmtp-slide-03.txt deleted file mode 100644 index 065f9c60..00000000 --- a/Documentation/en/I-D/draft-ward-esmtp-slide-03.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - - A. Ward -INTERNET-DRAFT -Category: Experimental 15 June 2000 -draft-ward-esmtp-slide-03.txt Exprires: 15 December 2000 - - - - SMTP Service Extension for Slightly Differing - Multicast Messages (SLIDE) - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - 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. - -i. Revision History - - The first version (-00) of this document was unleashed on 9 March - 2000. - - (-01) Added section (5.1), regarding the impact of the SLIDE - extension to signed or encrypted messages. Modified the first - example in section (4.) to make the impact of SLIDE more explicit. (7 - April 2000) - - (-02) Added examples to section (5.1.1) and section (5.1.2). (4 May - 2000) - - (-03) Minor formatting changes to comply with RFC 2223. (15 June - 2000) - - - -Ward [Page 1] - -INTERNET-DRAFT SMTP Service Extension SLIDE 15 June 2000 - - -Abstract - - This memo defines an extension to the SMTP service [Klensin, et al - 1995] to realize efficiency improvements in the relaying and delivery - of slightly differing messages bound for more than one recipient, as - specified by multiple RCPT TO commands [Postel 1982]. - -0. Conventions Used in this Document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [Bradner - 1997]. - -1. Introduction - - SMTP is an Internet message protocol that is used to send messages to - one or more recipients. To realize any efficiency when sending a - message to multiple recipients, the message body and all headers must - be identical. It is desirable, under some circumstances, to send - messages to multiple recipients that differ only slightly in their - body and/or headers. - - Under SMTP [Postel 1982] such a scenario would result in a different - message being sent from the initial client SMTP through each relay - server until the final server SMTP is reached. In situations where - more that one of the multiple recipients have mail handled by the - same server SMTP, a significant bandwidth reduction can be realized - with the SLIDE service extension. - -2. Framework for the Slightly Differing Multicast Message Extension - - The slightly differing multicast message extension is as follows: - - (1) the name of the SMTP service extension defined here is slightly- - differing-multicast-message; - - (2) the EHLO keyword value associated with the extension is SLIDE; - - (3) no parameter is used with the SLIDE EHLO keyword; - - (4) no additional SMTP verbs are defined by this extension - - (5) one optional parameter using the keyword SLIDERANGE is added to - the RCPT TO command. The value associated with this parameter is a - comma-delimited list of octet ranges indicating which pieces of the - overall message SHOULD be delivered to the specified recipient. The - syntax for the value follows, using the ABNF notation of [Crocker - - - -Ward [Page 2] - -INTERNET-DRAFT SMTP Service Extension SLIDE 15 June 2000 - - - 1982]: - - sliderange-value ::= octet-range *( "," octet-range ) - - octet-range ::= octet-address [ "-" octet-address ] - - octet-address ::= DIGIT *(DIGIT) - - DIGIT ::= <any one of the 10 numeric characters (0 through 9)> - - (6) the next section specifies how support for the extension affects - the behaviour of a server and client SMTP; and, - - (7) the maximum length of a RCPT TO command line is increased by 256 - characters by the possible addition of the SLIDERANGE keyword and - value. Of course, since the value could conceivably be longer than - 256 characters, implementations are welcome to allot more space for - this purpose. - -3. The slightly-differing-multicast-message Service Extension - - 3.1 Effects on the Client SMTP - - When a client SMTP wishes to submit (using the MAIL command) - messages with slightly different content to recipients at the same - server SMTP, it first issues the EHLO command to the server SMTP. - If the server SMTP responds with code 250 to the EHLO command, and - the response includes the EHLO keyword value SLIDE, then the - server SMTP is indicating that it supports the extended RCPT - command. Such a server SMTP will accept a message containing the - combined contents of the slightly differing messages addressed to - all of the recipients for delivery. The method for combining the - various message bodies (and interpreting combined message bodies) - is described in the next section. - - The extended RCPT command is issued by a client SMTP when it - wishes to transmit part of a combined message body to the - specified recipient. The syntax for this command is identical to - the RCPT command in [Postel 1982], except that a SLIDERANGE - parameter must appear after the address. Multiple SLIDERANGE - parameters may be used in a single RCPT command; however, in such - a case, the values of the several parameters SHOULD be combined - into a single, continuous, comma-delimited list of octet ranges. - - The value associated with the SLIDERANGE parameter lists which - octets in the impending DATA command are to be sent to the - specified recipient. - - - - -Ward [Page 3] - -INTERNET-DRAFT SMTP Service Extension SLIDE 15 June 2000 - - - 3.2 Effects on the Server SMTP - - A server SMTP which supports the slightly differing multicast - message service extension SHOULD relay only those octets bound for - recipients at a particular domain to the mail exchange for that - domain. If this suggested message trimming occurs, the octets - specified in the SLIDERANGE parameter for each recipient MUST be - adjusted to correspond with the changes to the message DATA. - - The final 5 octets of the message DATA (<CR><LF>.<CR><LF>) MUST - always be relayed, even if not explicitly specified in the - SLIDERANGE parameter value. - - Once a server SMTP supporting the slightly differing multicast - message service extension accepts a message for which any - recipient has a non-trivial SLIDERANGE parameter value, the server - SMTP MUST deliver or relay the message in such a way as to ensure - that only the octets specified for a particular recipient will be - received by that recipient. As well, when the server SMTP is - relaying the message, it SHOULD attempt to minimize the number of - octets that are relayed to each downstream server SMTP. - -4. Usage Examples - - The following dialogue illustrates the use of the slightly differing - multicast message service extension: - - S: <wait for connection> - C: <open connection to server> - S: 220 anstruther.elsewhere.com SMTP ready - C: EHLO burleigh.uwaterloo.ca - S: 250-hello burleigh.uwaterloo.ca - S: 250 SLIDE - C: MAIL FROM:<andrew@burleigh.uwaterloo.ca> - S: 250 <andrew@burleigh.uwaterloo.ca>... sender okay - C: RCPT TO:<ed@elsewhere.com> SLIDERANGE=0-148,180-322 - S: 250 <ed@elsewhere.com>... recipient and SLIDERANGE okay - C: RCPT TO:<doug@elsewhere.com> SLIDERANGE=0-121,149-272,320-322 - S: 250 <doug@elsewhere.com>... recipient and SLIDERANGE okay - C: DATA - S: 354 octets beyond 323 will not be relayed, end with CRLF.CRLF - C: Message-ID: <1234.abcd@uwaterloo.ca> - C: Date: Mon, 03 Apr 2000 12:05:10 -0400 - C: From: Andrew <andrew@burleigh.uwaterloo.ca> - C: To: Ed <ed@elsewhere.com> - C: To: Doug <doug@elsewhere.com> - C: Subject: special message - C: - - - -Ward [Page 4] - -INTERNET-DRAFT SMTP Service Extension SLIDE 15 June 2000 - - - C: this is the message body for a special message - C: - C: enjoy, andrew - C: - C: ps. this is a secret that Doug doesn't know - C: . - S: 250 okay - C: QUIT - S: 250 bye bye - - This transaction would result in ed@elsewhere.com receiving the - message: - - Message-ID: <1234.abcd@uwaterloo.ca> - Date: Mon, 03 Apr 2000 12:05:10 -0400 - From: Andrew <andrew@burleigh.uwaterloo.ca> - To: Ed <ed@elsewhere.com> - Subject: special message - - this is the message body for a special message - - enjoy, andrew - - ps. this is a secret that Doug doesn't know - . - - while doug@elsewhere.com would receive: - - Message-ID: <1234.abcd@uwaterloo.ca> - Date: Mon, 03 Apr 2000 12:05:10 -0400 - From: Andrew <andrew@burleigh.uwaterloo.ca> - To: Doug <doug@elsewhere.com> - Subject: special message - - this is the message body for a special message - - enjoy, andrew - . - - The following dialogue illustrates the efficiencies that can be - realized in a relaying scenario: - - S1: 220 one.there.com SMTP ready - C0: EHLO zero.here.com - S1: 250-hello zero.here.com - S1: 250 SLIDE - C0: MAIL FROM:<me@here.com> - S1: 250 <me@here.com>... sender okay - - - -Ward [Page 5] - -INTERNET-DRAFT SMTP Service Extension SLIDE 15 June 2000 - - - C0: RCPT TO:<ed@everywhere.com> SLIDERANGE=0-150,200-250 - S1: 250 <ed@everywhere.com>... recipient and SLIDERANGE okay - C0: RCPT TO:<doug@everywhere.com> SLIDERANGE=0-199 - S1: 250 <doug@everywhere.com>... recipient and SLIDERANGE okay - C0: RCPT TO:<laurene@everywhere.com> SLIDERANGE=0-250 - S1: 250 <laurene@everywhere.com>... recipient and SLIDERANGE okay - C0: RCPT TO:<rachael@elsewhere.com> - S1: 250 <rachael@elsewhere.com>... recipient okay - C0: DATA - S1: 354 okay, send message body, end with CRLF.CRLF - C0: ...<1000 octets of message>... - C0: . - S1: 250 okay - C0: QUIT - S1: 250 bye bye - ... - S2: 220 two.everywhere.com SMTP ready - C1: EHLO one.there.com - S2: 250-hello one.there.com - S2: 250 SLIDE - C1: MAIL FROM:<me@here.com> - S2: 250 <me@here.com>... sender okay - C1: RCPT TO:<ed@everywhere.com> SLIDERANGE=0-150,200-250 - S2: 250 <ed@everywhere.com>... recipient and SLIDERANGE okay - C1: RCPT TO:<doug@everywhere.com> SLIDERANGE=0-199 - S2: 250 <doug@everywhere.com>... recipient and SLIDERANGE okay - C1: RCPT TO:<laurene@everywhere.com> - S2: 250 <laurene@everywhere.com>... recipient okay - C1: DATA - S2: 354 okay, send message body, end with CRLF.CRLF - C1: ...<octets 0 to 250 of message>... - C1: . - S2: 250 okay - C1: QUIT - S2: 250 bye bye - ... - S3: 220 three.elsewhere.com SMTP ready - C1: EHLO one.there.com - S3: 250-hello one.there.com - S3: 250 SLIDE - C1: MAIL FROM:<me@here.com> - S3: 250 <me@here.com>... sender okay - C1: RCPT TO:<rachael@elsewhere.com> - S3: 250 <rachael@elsewhere.com>... recipient okay - C1: DATA - S3: 354 okay, send message body, end with CRLF.CRLF - C1: ...<all octets of message>... - C1: . - - - -Ward [Page 6] - -INTERNET-DRAFT SMTP Service Extension SLIDE 15 June 2000 - - - S3: 250 okay - C1: QUIT - S3: 250 bye bye - -5. Security Considerations - - This extension takes some of the "final control" over the message - body out of the hands of the client, and places it on the server - SMTPs that are charged with relaying and delivering the message. - While any server SMTP has access to change the content of a message - that it relays or delivers, a server SMTP that supports the slightly - differing multicast message service extension is obliged to be able - to alter a message that takes advantage of this extension. As a - result of the increased handling by the server SMTP, there is more - room for error in the message transmission. - - 5.1 Impact on Signed and Encrypted Messages - - Messages that are transferred between a client SMTP and a server - SMTP over a secure channel such as SSL or TLS should not be - adversely affected by the SLIDE extension. - - Things get messy when it comes to signing or encrypting the - message data (all or part of the information sent to the server - SMTP following a 354 response to the DATA command). Two - alternatives are suggested in section (5.1.1) and section (5.1.2). - A client SMTP may implement either method, as both methods can be - used transparently to all other nodes in the chain of relays - (including the final server SMTP node). - - 5.1.1 Piecewise Signing and Encryption - - With this method, the initial client SMTP may sign or encrypt - each separate range of bytes (or part thereof), as defined by - the various SLIDERANGE values. - - As an example, consider the piecewise approach as applied to - the first usage example presented in section 4. - - S: <wait for connection> - C: <open connection to server> - S: 220 anstruther.elsewhere.com SMTP ready - C: EHLO burleigh.uwaterloo.ca - S: 250-hello burleigh.uwaterloo.ca - S: 250 SLIDE - C: MAIL FROM:<andrew@burleigh.uwaterloo.ca> - S: 250 <andrew@burleigh.uwaterloo.ca>... sender okay - C: RCPT TO:<ed@elsewhere.com> SLIDERANGE=0-148,180-727 - - - -Ward [Page 7] - -INTERNET-DRAFT SMTP Service Extension SLIDE 15 June 2000 - - - S: 250 <ed@elsewhere.com>... recipient and SLIDERANGE okay - C: RCPT TO:<doug@elsewhere.com> SLIDERANGE=0-121,149-483,725-727 - S: 250 <doug@elsewhere.com>... recipient and SLIDERANGE okay - C: DATA - S: 354 octets beyond 728 will not be relayed, end with CRLF.CRLF - C: Message-ID: <1234.abcd@uwaterloo.ca> - C: Date: Mon, 03 Apr 2000 12:05:10 -0400 - C: From: Andrew <andrew@burleigh.uwaterloo.ca> - C: To: Ed <ed@elsewhere.com> - C: To: Doug <doug@elsewhere.com> - C: Subject: special message - C: - C: -----BEGIN PGP SIGNED MESSAGE----- - C: Hash: SHA1 - C: - C: this is the message body for a special message - C: - C: enjoy, andrew - C: -----BEGIN PGP SIGNATURE----- - C: Version: fakePGP v0.0 - C: - C: aefiuh98ar7ehfpo34h9q83h4fp9q34h9a8efha9348hao - C: 98h5nbq3rub9a08ahfoi4no34= - C: -----END PGP SIGNATURE----- - C: - C: -----BEGIN PGP SIGNED MESSAGE----- - C: Hash: SHA1 - C: - C: ps. this is a secret that Doug doesn't know - C: -----BEGIN PGP SIGNATURE----- - C: Version: fakePGP v0.0 - C: - C: 98sdu9bd9fu4eiob3iovb9eb93buiou908fhv9sf - C: jlknsdfi0h93un= - C: -----END PGP SIGNATURE----- - C: . - S: 250 okay - C: QUIT - S: 250 bye bye - - - 5.1.2 Component Message Signing - - This method creates a single signature for each distinct - message contained in a set of messages encoded using the SLIDE - extension. During encoding of the SLIDE message, each - component message that needs to be signed can have a signature - generated for it before the component messages are SLIDE - - - -Ward [Page 8] - -INTERNET-DRAFT SMTP Service Extension SLIDE 15 June 2000 - - - encoded. - - It is important to note that in most (if not all) cases this - will not work for encryption, as the same text in the - unencrypted component messages will not generate the same - encrypted group of octets. - - As an example, consider the component message approach as - applied to the first usage example presented in section 4. - - S: <wait for connection> - C: <open connection to server> - S: 220 anstruther.elsewhere.com SMTP ready - C: EHLO burleigh.uwaterloo.ca - S: 250-hello burleigh.uwaterloo.ca - S: 250 SLIDE - C: MAIL FROM:<andrew@burleigh.uwaterloo.ca> - S: 250 <andrew@burleigh.uwaterloo.ca>... sender okay - C: RCPT TO:<ed@elsewhere.com> SLIDERANGE=0-148,180-322,484-677 - S: 250 <ed@elsewhere.com>... recipient and SLIDERANGE okay - C: RCPT TO:<doug@elsewhere.com> SLIDERANGE=0-121,149-483,675-677 - S: 250 <doug@elsewhere.com>... recipient and SLIDERANGE okay - C: DATA - S: 354 octets beyond 678 will not be relayed, end with CRLF.CRLF - C: Message-ID: <1234.abcd@uwaterloo.ca> - C: Date: Mon, 03 Apr 2000 12:05:10 -0400 - C: From: Andrew <andrew@burleigh.uwaterloo.ca> - C: To: Ed <ed@elsewhere.com> - C: To: Doug <doug@elsewhere.com> - C: Subject: special message - C: - C: -----BEGIN PGP SIGNED MESSAGE----- - C: Hash: SHA1 - C: - C: this is the message body for a special message - C: - C: enjoy, andrew - C: -----BEGIN PGP SIGNATURE----- - C: Version: fakePGP v0.0 - C: - C: nsdf9n934nioq3j4un9ua9fvuerh98h43n9ae8u85 - C: 34kjfbna9ea9e8rb8d9sd0ge3= - C: -----END PGP SIGNATURE----- - C: - C: ps. this is a secret that Doug doesn't know - C: -----BEGIN PGP SIGNATURE----- - C: Version: fakePGP v0.0 - C: - - - -Ward [Page 9] - -INTERNET-DRAFT SMTP Service Extension SLIDE 15 June 2000 - - - C: ikbdfv98u4bka8rhi34ubkq3828756bkjai7rf7 - C: 1kj3k4jnkj3kjk3= - C: -----END PGP SIGNATURE----- - C: . - S: 250 okay - C: QUIT - S: 250 bye bye - - -6. Acknowledgements - - Thanks to Ed, Doug, Laurene and Rachael for their (unwilling) - participation in the usage examples. Thanks to Dan Wing for his - suggested improvements in usage examples and security considerations. - -7. References - - [Bradner 1997] Bradner, S. "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119. March 1997. - - [Crocker 1982] Crocker, D. "Standard for the Format of ARPA - Internet Text Messages", STD 11, RFC 822. UDEL, August 1982. - - [Klensin, et al 1995] Klensin, J., N. Freed, M. Rose, E. Stefferud, - and D. Crocker. "SMTP Service Extensions", STD 10, RFC 1869. - November 1995. - - [Postel 1982] Postel, J. "Simple Mail Transfer Protocol", STD 10, - RFC 821. USC/Information Sciences Institute, August 1982. - -8. Author's Address - - Andrew Ward - 70 Gruhn Street - Kitchener, ON N2G 1S6 - CANADA - - Phone: +1 519 581 1201 - EMail: amward@uwaterloo.ca - - - - EXPIRES: 15 December 2000 - - - - - - - - -Ward [Page 10] - |