RFC788
`
`SIMPLE MAIL TRANSFER PROTOCOL
`
`Jonathan B. Postel
`
`November 1981
`
`Information Sciences Institute
`University of Southern California
`4676 Admiralty Way
`Marina del Rey, California 90291
`
`(213) 822-1511
`
`RFC 788
`
`November 1981
`Simple Mail Transfer Protocol
`
`TABLE OF CONTENTS
`
`Juniper Ex. 1056-p. 1
`Juniper v Implicit
`
`

`

` 1. INTRODUCTION .................................................. 1
`
` 2. THE SMTP MODEL ................................................ 2
`
` 3. THE SMTP PROCEDURE ............................................ 4
`
` 3.1. Mail ..................................................... 4
` 3.2. Forwarding ............................................... 7
` 3.3. Verifying and Expanding .................................. 8
` 3.4. Sending and Mailing ..................................... 10
` 3.5. Opening and Closing ..................................... 12
` 3.6. Relaying ................................................ 13
` 3.7. Domains ................................................. 15
`
` 4. THE SMTP SPECIFICATIONS ...................................... 16
`
` 4.1. SMTP Commands ........................................... 16
` 4.1.1. Command Semantics ..................................... 16
` 4.1.2. Command Syntax ........................................ 23
` 4.2. SMTP Replies ............................................ 28
` 4.2.1. Reply Codes by Function Group ......................... 29
` 4.2.2. Reply Codes in Numeric Order .......................... 30
` 4.3. Sequencing of Commands and Replies ...................... 31
` 4.4. State Diagrams .......................................... 33
` 4.5. Details ................................................. 35
` 4.5.1. Minimum Implementation ................................ 35
` 4.5.2. Transparency .......................................... 35
` 4.5.3. Sizes ................................................. 36
`
` APPENDIX A: TCP ................................................. 38
` APPENDIX B: NCP ................................................. 39
` APPENDIX C: NITS ................................................ 40
` APPENDIX D: X.25 ................................................ 41
` APPENDIX E: Theory of Reply Codes ............................... 42
` APPENDIX F: Scenarios ........................................... 45
`
` GLOSSARY ......................................................... 58
`
` REFERENCES ....................................................... 61
`
`Network Working Group J. Postel
`Request for Comments: 788 ISI
`Replaces: RFC 780, 772 November 1981
`
` SIMPLE MAIL TRANSFER PROTOCOL
`
`1. INTRODUCTION
`
` The objective of 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. Appendices A,
` B, C, and D describe the use of SMTP with various transport services.
` A Glossary provides the definitions of terms as used in this
` document.
`
` An important feature of SMTP is its capability to relay mail across
`
`Juniper Ex. 1056-p. 2
`Juniper v Implicit
`
`

`

` transport service environments. A transport service provides an
` interprocess communication environment (IPCE). An IPCE may cover one
` network, several networks, or a subset of a network. It is important
` to realize that transport systems (or IPCEs) are not one-to-one with
` networks. A process can communicate directly with another process
` through any mutually known IPCE. Mail is an application or use of
` interprocess communication. Mail can be communicated between
` processes in different IPCEs by relaying through a process connected
` to two (or more) IPCEs. More specifically, mail can be relayed
` between hosts on different transport systems by a host on both
` transport systems.
`
`Postel [Page 1]
`
`Juniper Ex. 1056-p. 3
`Juniper v Implicit
`
`

`

`
`November 1981 RFC 788
`Simple Mail Transfer Protocol
`
`2. THE SMTP MODEL
`
` The SMTP design is based on the following model of communication: as
` the result of a user mail request, the sender-SMTP establishes a
` full-duplex transmission channel to a receiver-SMTP. The
` receiver-SMTP may be either the ultimate destination or an
` intermediate. SMTP commands are generated by the sender-SMTP and
` sent to the receiver-SMTP. SMTP replies are sent from the
` receiver-SMTP to the sender-SMTP in response to the commands.
`
` Once the transmission channel is established, the SMTP-sender sends a
` MAIL command indicating the sender of the mail. If the SMTP-receiver
` can accept mail it responds with an OK reply. The SMTP-sender then
` sends a RCPT command identifying a recipient of the mail. If the
` SMTP-receiver can accept mail for that recipient it responds with an
` OK reply; if not, it responds with a reply rejecting that recipient
` (but not the whole mail transaction). The SMTP-sender and
` SMTP-receiver may negotiate several recipients. When the recipients
` have been negotiated the SMTP-sender sends the mail data, terminating
` with a special sequence. If the SMTP-receiver successfully processes
` the mail data it responds with an OK reply. The dialog is purposely
` lock-step, one-at-a-time.
`
` -------------------------------------------------------------
`
` +----------+ +----------+
` +------+ | | | |
` | User |<-->| | SMTP | |
` +------+ | Sender- |Commands/Replies| Receiver-|
` +------+ | SMTP |<-------------->| SMTP | +------+
` | File |<-->| | and Mail | |<-->| File |
` |System| | | | | |System|
` +------+ +----------+ +----------+ +------+
`
` Sender-SMTP Receiver-SMTP
`
` Model for SMTP Use
`
` Figure 1
`
` -------------------------------------------------------------
`
` The SMTP provides mechanisms for the transmission of mail; directly
` from the sending user’s host to the receiving user’s host when the
`
`[Page 2] Postel
`
`RFC 788 November 1981
` Simple Mail Transfer Protocol
`
`Juniper Ex. 1056-p. 4
`Juniper v Implicit
`
`

`

` two host are connected to the same transport service, or via one or
` more relay SMTP-servers when the source and destination hosts are not
` connected to the same transport service.
`
` To be able to provide the relay capability the SMTP-server must be
` supplied with the name of the ultimate destination host as well as
` the destination mailbox name.
`
` The argument to the MAIL command is a reverse-path, which specifies
` who the mail is from. The argument to the RCPT command is a
` forward-path, which specifies who the mail is to. The forward-path
` is a source route while the reverse-path, is a return route (which
` may be used to return a message to the sender when an error occurs
` with a relayed message).
`
` When the same message is sent to multiple recipients the SMTP
` encourages the transmission of only one copy of the data for all the
` recipients at the same destination host.
`
` The mail commands and replies have a rigid syntax. Replies also have
` a numeric code. In the following, examples appear which use actual
` commands and replies. The complete lists of commands and replies
` appears in Section 4 on specifications.
`
` 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, and SMTP implementations
` must take case to preserve the case of user names as they appear in
` mailbox arguments. Host names are not case sensitive.
`
` Commands and replies are composed of characters from the ASCII
` character set [1]. Each 7-bit character is transmitted right
` justified in an 8-bit byte (or octet) with the high order bit cleared
` to zero.
`
` When specifying the general form of a command or reply, an argument
` (or special symbol) will be denoted by a meta-linguistic variable (or
` constant), for example, "<string>" or "<reverse-path>". Here the
` angle brackets indicate these are a meta-linguistic variables.
` However, some arguments use the angle brackets literally. For
` example, an actual reverse-path is enclosed in angle brackets, i.e.,
` "<Smith@ISIA>" is an instance of <reverse-path> (the angle brackets
` are actually transmitted in the command or reply).
`
`Postel [Page 3]
`
`Juniper Ex. 1056-p. 5
`Juniper v Implicit
`
`

`

`
`November 1981 RFC 788
`Simple Mail Transfer Protocol
`
`3. THE SMTP PROCEDURES
`
` This section presents the procedures used in SMTP in several parts.
` First comes the basic mail procedure defined as a mail transaction.
` Following this are descriptions of forwarding mail, verifying mailbox
` names and expanding mailing lists, sending to terminals instead of or
` in combination with mailboxes, and the opening and closing exchanges.
` At the end of this section are comments on relaying, and a note on
` mail domains. Throughout this section are examples of partial
` command and reply sequences, several complete scenarios are presented
` in Appendix F.
`
` 3.1. MAIL
`
` There are three steps to a SMTP mail transaction. The transaction
` is started with a MAIL command which gives the sender
` identification. A series of one or more RCPT commands follow
` giving the receiver information. Then a DATA command gives the
` mail data. And finally, the end of mail data indicator confirms
` the transaction.
`
` The first step in the procedure is the MAIL command. The
` <reverse-path> contains the source mailbox.
`
` MAIL <SP> FROM:<reverse-path> <CRLF>
`
` This command tells the 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. It gives the
` reverse-path which can be used to report errors. If accepted,
` the receiver-SMTP returns a 250 OK reply.
`
` The <reverse-path> can contain more than just a mailbox. The
` <reverse-path> is a reverse source routing list of hosts and
` source mailbox. The first host in the <reverse-path> should be
` the host sending this command.
`
` The second step in the procedure is the RCPT command.
`
` RCPT <SP> TO:<forward-path> <CRLF>
`
` This command gives a forward-path identifying one recipient.
` If accepted, the receiver-SMTP returns a 250 OK reply, and
` stores the forward-path. If the recipient is unknown the
` receiver-SMTP returns a 550 Failure reply. This second step of
` the procedure can be repeated any number of times.
`
`[Page 4] Postel
`
`RFC 788 November 1981
` Simple Mail Transfer Protocol
`
`Juniper Ex. 1056-p. 6
`Juniper v Implicit
`
`

`

` The <forward-path> can contain more than just a mailbox. The
` <forward-path> is a source routing list of hosts and
` destination mailbox. The first host in the <forward-path>
` should be the host receiving this command.
`
` The third step in the procedure is the DATA command.
`
` DATA <CRLF>
`
` If accepted, the receiver-SMTP returns a 354 Intermediate reply
` and considers all succeeding lines 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 the 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. A
` transparency procedure is used to prevent this interfering with
` the user’s text (see Section 4.5.2).
`
` Please note that the mail data includes the memo header
` items such as Date, Subject, To, Cc, From [2].
`
` The end of mail data indicator also confirms the mail
` transaction and tells the receiver-SMTP to now process the
` stored recipients and mail data. If accepted, the
` receiver-SMTP returns a 250 OK reply. The DATA command should
` fail only if the mail transaction was incomplete (for example,
` no recipients), or if resources are not available.
`
` The above procedure is an example of a SMTP mail transaction.
` These commands must be used only in the order discussed above.
` Example 1 (below) illustrates the use of these commands in a mail
` transaction.
`
`Postel [Page 5]
`
`Juniper Ex. 1056-p. 7
`Juniper v Implicit
`
`

`

`
`November 1981 RFC 788
`Simple Mail Transfer Protocol
`
` -------------------------------------------------------------
`
` Example of the SMTP Procedure
`
` This SMTP example shows mail sent by Smith at host Alpha, to
` Jones, Green, and Brown at host Beta. Here we assume that host
` Alpha contacts host Beta directly.
`
` S: MAIL FROM:<Smith@Alpha>
` R: 250 OK
`
` S: RCPT TO:<Jones@Beta>
` R: 250 OK
`
` S: RCPT TO:<Green@Beta>
` R: 550 No such user here
`
` S: RCPT TO:<Brown@Beta>
` R: 250 OK
`
` S: DATA
` R: 354 Start mail input; end with <CRLF>.<CRLF>
` S: Blah blah blah...
` S: ...etc. etc. etc.
` S: <CRLF>.<CRLF>
` R: 250 OK
`
` The mail has now been accepted for Jones and Brown. Green did
` not have a mailbox at host Beta.
`
` Example 1
`
` -------------------------------------------------------------
`
`[Page 6] Postel
`
`RFC 788 November 1981
` Simple Mail Transfer Protocol
`
`Juniper Ex. 1056-p. 8
`Juniper v Implicit
`
`

`

` 3.2. FORWARDING
`
` There are some cases where the destination information in the
` <forward-path> is incorrect, but the receiver-SMTP knows the
` correct destination. In such cases, one the following replies
` should be used to allow the sender to contact the correct
` destination.
`
` 251 User not local; will forward to <forward-path>
`
` This reply indicates that the receiver-SMTP knows the user’s
` mailbox is on another host and indicates the correct
` forward-path to use in the future. Note that either the
` host or user or both may be different. The receiver takes
` responsibility for delivering the message.
`
` 551 User not local; please try <forward-path>
`
` This reply indicates that the receiver-SMTP knows the user’s
` mailbox is on another host and indicates the correct
` forward-path to use. Note that either the host or user or
` both may be different. The receiver refuses to accept mail
` for this user, and the sender must either redirect the mail
` according to the information provided or return an error
` response to the originating user.
`
` Example 2 illustrates the use of these responses.
`
` -------------------------------------------------------------
`
` Example of Forwarding
`
` Either
`
` S: RCPT TO:<Postel@ISI>
` R: 251 User not local; will forward to <Postel@ISIF>
`
` Or
`
` S: RCPT TO:<Paul@ISIB>
` R: 551 User not local; please try <Mockapetris@ISIF>
`
` Example 2
`
` -------------------------------------------------------------
`
`Postel [Page 7]
`
`Juniper Ex. 1056-p. 9
`Juniper v Implicit
`
`

`

`
`November 1981 RFC 788
`Simple Mail Transfer Protocol
`
` 3.3. VERIFYING AND EXPANDING
`
` SMTP provides as additional features, commands to verify a user
` name or expand a mailing list. This is done with the VRFY and
` EXPN commands, which have a character string arguments. For the
` VRFY command, the string is a user name, and the the response may
` include the full name of the user and must include the mailbox of
` 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.
`
` The case of verifying a user name is straightforward as shown in
` example 3.
`
` -------------------------------------------------------------
`
` Example of Verifying a User Name
`
` Either
`
` S: VRFY Postel
` R: 250 Jon Postel <Postel@ISIF>
`
` Or
`
` S: VRFY Jones
` R: 550 String does not match anything.
`
` Example 3
`
` -------------------------------------------------------------
`
`[Page 8] Postel
`
`RFC 788 November 1981
` Simple Mail Transfer Protocol
`
`Juniper Ex. 1056-p. 10
`Juniper v Implicit
`
`

`

` The case of expanding a mailbox list requires a multiline reply as
` shown in example 4.
`
` -------------------------------------------------------------
`
` Example of Expanding a Mailing List
`
` Either
`
` S: EXPN Example-People
` R: 250-Jon Postel <Postel@ISIF>
` R: 250-Fred Fonebone <Fonebone@ISIQ>
` R: 250-Sam Q. Smith <SQSmith@ISIQ>
` R: 250-Quincy Smith <@ISIF,Q-Smith@ISI-VAXA>
` R: 250-<joe@foo-unix>
` R: 250 <xyz@bar-unix>
`
` Or
`
` S: EXPN Executive-Washroom-List
` R: 550 Access Denied to You.
`
` Example 4
`
` -------------------------------------------------------------
`
` 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 is
` a variety of file naming conventions in the internet.
`
` The VRFY and EXPN commands are not included in the minimum
` implementation (Section 4.5.1), and are not required to work
` across relays when they are implemented.
`
`Postel [Page 9]
`
`Juniper Ex. 1056-p. 11
`Juniper v Implicit
`
`

`

`
`November 1981 RFC 788
`Simple Mail Transfer Protocol
`
` 3.4. SENDING AND MAILING
`
` The main purpose of SMTP is to deliver messages to user’s
` mailboxes. A very similar service provided by some hosts is to
` deliver messages to user’s terminals (provided the user is active
` on the host). The delivery to the user’s mailbox is called
` "mailing", the delivery to the user’s terminal is called
` "sending". Because in many hosts the implementation of sending is
` nearly identical to the implementation of mailing these two
` functions are combined in SMTP. However the sending commands are
` not included in the required minimum implementation
` (Section 4.5.1). User’s should have the ability to control the
` writing of messages on their terminals. Most hosts permit the
` user’s to accept or refuse such messages.
`
` The following three command are defined to support the sending
` options, these are used in the mail transaction instead of the
` MAIL command and inform the receiver-SMTP of the special semantics
` of this transaction:
`
` SEND <SP> FROM:<reverse-path> <CRLF>
`
` The SEND command requires that the mail data be delivered to
` the user’s terminal. If the user is not active (or not
` accepting terminal messages) on the host a 450 reply may
` returned to a RCPT command. The mail transaction is
` successful if the message is delivered the terminal.
`
` SOML <SP> FROM:<reverse-path> <CRLF>
`
` The Send Or MaiL command requires that the mail data be
` delivered to the user’s terminal if the user is active (and
` accepting terminal messages) on the host. If the user is
` not active (or not accepting terminal messages) then the
` mail data is entered into the user’s mailbox. The mail
` transaction is successful if the message is delivered either
` to the terminal or the mailbox.
`
` SAML <SP> FROM:<reverse-path> <CRLF>
`
` The Send And MaiL command requires that the mail data be
` delivered to the user’s terminal if the user is active (and
` accepting terminal messages) on the host. In any case the
` mail data is entered into the user’s mailbox. The mail
` transaction is successful if the message is delivered the
` mailbox.
`
`[Page 10] Postel
`
`RFC 788 November 1981
` Simple Mail Transfer Protocol
`
`Juniper Ex. 1056-p. 12
`Juniper v Implicit
`
`

`

` The same reply codes that are used for the MAIL commands are used
` for these commands.
`
`Postel [Page 11]
`
`Juniper Ex. 1056-p. 13
`Juniper v Implicit
`
`

`

`
`November 1981 RFC 788
`Simple Mail Transfer Protocol
`
` 3.5. OPENING AND CLOSING
`
` At the time the transmission channel is opened there is an
` exchange to ensure that the hosts are communicating with the hosts
` they think they are.
`
` The following two commands are used in transmission channel
` opening and closing:
`
` HELO <SP> <host> <CRLF>
`
` QUIT <CRLF>
`
` In the HELO command the host sending the command identifies
` itself; the command may be interpreted as saying "Hello, i am
` <host>".
`
` -------------------------------------------------------------
`
` Example of Connection Opening
`
` R: 220 BBN-UNIX Simple Mail Transfer Service Ready
` S: HELO USC-ISIF
` R: 250 BBN-UNIX
`
` Example 5
`
` -------------------------------------------------------------
`
` -------------------------------------------------------------
`
` Example of Connection Closing
`
` S: QUIT
` R: 221 BBN-UNIX Service closing transmission channel
`
` Example 6
`
` -------------------------------------------------------------
`
`[Page 12] Postel
`
`RFC 788 November 1981
` Simple Mail Transfer Protocol
`
`Juniper Ex. 1056-p. 14
`Juniper v Implicit
`
`

`

` 3.6. RELAYING
`
` The forward-path may be a source route of the form
` "@ONE,@TWO,JOE@THREE", where ONE, TWO, and THREE are hosts. 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.
`
` The elements of the forward-path are moved to the reverse-path as
` the message is relayed from one server-SMTP to another. The
` reverse-path is a reverse source route, (i.e., a source route from
` the current location of the message to the originator of the
` message). When a server-SMTP deletes its identifier from the
` forward-path and inserts it into the reverse-path, it must use the
` name it is known by in the environment it is sending into, not the
` environment the mail came from, in case the server-SMTP is known
` by different names in different environments.
`
` Using source routing the receiver-SMTP receives mail to be relayed
` to another server-SMTP The receiver-SMTP may accept or reject the
` task of relaying the mail in the same way it accepts or rejects
` mail for a local user. The receiver-SMTP transforms the command
` arguments by moving its own identifier from the forward-path to
` the beginning of the reverse-path. The receiver-SMTP then becomes
` a sender-SMTP, establishes a transmission channel to the next SMTP
` in the forward-path, and sends it the mail.
`
` The first host in the reverse-path should be the host sending the
` SMTP commands, and the first host in the forward-path should be
` the host receiving the SMTP commands.
`
` 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.
`
` If a server-SMTP has accepted the task of relaying the mail and
` later finds that the forward-path is incorrect or that the mail
` cannot be delivered for whatever 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).
`
`Postel [Page 13]
`
`Juniper Ex. 1056-p. 15
`Juniper v Implicit
`
`

`

`
`November 1981 RFC 788
`Simple Mail Transfer Protocol
`
` This notification message must be from the server-SMTP at this
` host. Of course, server-SMTPs should not send notification
` messages about problems with 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 relayed it is permissible to leave the reverse-path
` null. A MAIL command with a null reverse-path appears as follows:
`
` MAIL FROM:<>
`
` An undeliverable mail notification message is shown in example 7.
` This notification is in response to a message originated by JOE at
` HOSTW and sent via HOSTX to HOSTY with instructions to relay it on
` to HOSTZ. What we see in the example is the transaction between
` HOSTY and HOSTX, which is the first step in the return of the
` notification message.
`
` -------------------------------------------------------------
`
` Example Undeliverable Mail Notification Message
`
` S: MAIL FROM:<>
` R: 250 ok
` S: RCPT TO:<@HOSTX,JOE@HOSTW>
` R: 250 ok
` S: DATA
` R: 354 send the mail data, end with .
` S: Date: 23 Oct 81
` S: Sender: SMTP@HOSTY
` S: Subject: Mail System Problem
` S:
` S: Sorry JOE, your message to SAM@HOSTZ lost.
` S: HOSTZ said this:
` S: "550 No Such User"
` S: .
` R: 250 ok
`
` Example 7
`
` -------------------------------------------------------------
`
`[Page 14] Postel
`
`RFC 788 November 1981
` Simple Mail Transfer Protocol
`
`Juniper Ex. 1056-p. 16
`Juniper v Implicit
`
`

`

` 3.7. DOMAINS
`
` At some not too distant future time it might be necessary to
` expand the mailbox format to include a region or name domain
` identifier. There is quite a bit of discussion on this at
` present, and is likely that SMTP will be revised in the future to
` take into account naming domains.
`
` The examples in this document do not show mail domains.
`
`Postel [Page 15]
`
`Juniper Ex. 1056-p. 17
`Juniper v Implicit
`
`

`

`
`November 1981 RFC 788
`Simple Mail Transfer Protocol
`
`4. THE SMTP SPECIFICATIONS
`
` 4.1. SMTP COMMANDS
`
` 4.1.1. COMMAND SEMANTICS
`
` 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 mailboxes must conform to
` receiver site conventions. The SMTP commands are discussed
` below. The SMTP replies are discussed in the 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.
`
` HELLO (HELO)
`
` This command is used to identify the sender-SMTP to the
` receiver-SMTP. The argument field contains the host name of
` the sender-SMTP.
`
` The receiver-SMTP identifies itself to the sender-SMTP in
` the connection greeting reply, and in the response to this
` command.
`
` 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 an optional list of hosts and
` the sender mailbox. When the list of hosts is present, it
`
`[Page 16] Postel
`
`RFC 788 November 1981
` Simple Mail Transfer Protocol
`
`Juniper Ex. 1056-p. 18
`Juniper v Implicit
`
`

`

` 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 IPCE to which it is
` relaying the mail rather than the IPCE from which the mail
` came (if they are different). In some types of error
` reporting messages (for example, undeliverable mail
` notifications) the reverse-path may be null (see Example 7).
`
` This command clears the reverse-path buffer, the
` forward-path buffer, and the mail data buffer; and inserts
`