RFC 821
`
`SIMPLE MAIL TRANSFER PROTOCOL
`
`Jonathan B. Postel
`
`August 1982
`
`Information Sciences Institute
`University of Southern California
`4676 Admiralty Way
`Marina del Rey, California 90291
`
`(213) 822-1511
`
`RFC 821
`
`August 1982
`Simple Mail Transfer Protocol
`
`TABLE OF CONTENTS
`
`CODE200 ET AL. EXHIBIT 1025
`Page 1 of 70
`
`

`

` 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 ..................................... 11
` 3.5. Opening and Closing ..................................... 13
` 3.6. Relaying ................................................ 14
` 3.7. Domains ................................................. 17
` 3.8. Changing Roles .......................................... 18
`
` 4. THE SMTP SPECIFICATIONS ...................................... 19
`
` 4.1. SMTP Commands ........................................... 19
` 4.1.1. Command Semantics ..................................... 19
` 4.1.2. Command Syntax ........................................ 27
` 4.2. SMTP Replies ............................................ 34
` 4.2.1. Reply Codes by Function Group ......................... 35
` 4.2.2. Reply Codes in Numeric Order .......................... 36
` 4.3. Sequencing of Commands and Replies ...................... 37
` 4.4. State Diagrams .......................................... 39
` 4.5. Details ................................................. 41
` 4.5.1. Minimum Implementation ................................ 41
` 4.5.2. Transparency .......................................... 41
` 4.5.3. Sizes ................................................. 42
`
` APPENDIX A: TCP ................................................. 44
` APPENDIX B: NCP ................................................. 45
` APPENDIX C: NITS ................................................ 46
` APPENDIX D: X.25 ................................................ 47
` APPENDIX E: Theory of Reply Codes ............................... 48
` APPENDIX F: Scenarios ........................................... 51
`
` GLOSSARY ......................................................... 64
`
` REFERENCES ....................................................... 67
`
`Network Working Group J. Postel
`Request for Comments: DRAFT ISI
`Replaces: RFC 788, 780, 772 August 1982
`
` 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.
`
`CODE200 ET AL. EXHIBIT 1025
`Page 2 of 70
`
`

`

` An important feature of SMTP is its capability to relay mail across
` 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]
`
`CODE200 ET AL. EXHIBIT 1025
`Page 3 of 70
`
`

`

`
`August 1982 RFC 821
`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
` two-way 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 821 August 1982
` Simple Mail Transfer Protocol
`
`CODE200 ET AL. EXHIBIT 1025
`Page 4 of 70
`
`

`

` 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]. 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.
`
` 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 meta-linguistic variables.
` However, some arguments use the angle brackets literally. For
` example, an actual reverse-path is enclosed in angle brackets, i.e.,
` "<John.Smith@USC-ISI.ARPA>" is an instance of <reverse-path> (the
` angle brackets are actually transmitted in the command or reply).
`
`Postel [Page 3]
`
`CODE200 ET AL. EXHIBIT 1025
`Page 5 of 70
`
`

`

`
`August 1982 RFC 821
`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, a note on mail
` domains, and a discussion of changing roles. 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 SMTP mail transactions. The transaction
` is started 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 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 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 821 August 1982
` Simple Mail Transfer Protocol
`
`CODE200 ET AL. EXHIBIT 1025
`Page 6 of 70
`
`

`

` The <forward-path> can contain more than just a mailbox. The
` <forward-path> is a source routing list of hosts and the
` 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 from 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 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]
`
`CODE200 ET AL. EXHIBIT 1025
`Page 7 of 70
`
`

`

`
`August 1982 RFC 821
`Simple Mail Transfer Protocol
`
` -------------------------------------------------------------
`
` Example of the SMTP Procedure
`
` This SMTP example shows mail sent by Smith at host Alpha.ARPA,
` to Jones, Green, and Brown at host Beta.ARPA. Here we assume
` that host Alpha contacts host Beta directly.
`
` S: MAIL FROM:<Smith@Alpha.ARPA>
` R: 250 OK
`
` S: RCPT TO:<Jones@Beta.ARPA>
` R: 250 OK
`
` S: RCPT TO:<Green@Beta.ARPA>
` R: 550 No such user here
`
` S: RCPT TO:<Brown@Beta.ARPA>
` 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 821 August 1982
` Simple Mail Transfer Protocol
`
`CODE200 ET AL. EXHIBIT 1025
`Page 8 of 70
`
`

`

` 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 of 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@USC-ISI.ARPA>
` R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>
`
` Or
`
` S: RCPT TO:<Paul@USC-ISIB.ARPA>
` R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA>
`
` Example 2
`
` -------------------------------------------------------------
`
`Postel [Page 7]
`
`CODE200 ET AL. EXHIBIT 1025
`Page 9 of 70
`
`

`

`
`August 1982 RFC 821
`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 character string arguments. For the
` VRFY command, the string is a user name, and 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.
`
` "User name" is a fuzzy term and used purposely. If a host
` implements the VRFY or EXPN commands then at least local mailboxes
` must be recognized as "user names". If a host chooses to
` recognize other strings as "user names" that is allowed.
`
` 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 on receipt of a message
` so addressed it will 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 a positive response can be formed by returning a list
` containing one name, or an error can 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. In the case
` of an ambiguous request, for example, "VRFY Smith", where there
` are two Smith’s the response must be "553 User ambiguous".
`
` The case of verifying a user name is straightforward as shown in
` example 3.
`
`[Page 8] Postel
`
`RFC 821 August 1982
` Simple Mail Transfer Protocol
`
`CODE200 ET AL. EXHIBIT 1025
`Page 10 of 70
`
`

`

` -------------------------------------------------------------
`
` Example of Verifying a User Name
`
` Either
`
` S: VRFY Smith
` R: 250 Fred Smith <Smith@USC-ISIF.ARPA>
`
` Or
`
` S: VRFY Smith
` R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA>
`
` Or
`
` S: VRFY Jones
` R: 550 String does not match anything.
`
` Or
`
` S: VRFY Jones
` R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>
`
` Or
`
` S: VRFY Gourzenkyinplatz
` R: 553 User ambiguous.
`
` Example 3
`
` -------------------------------------------------------------
`
`Postel [Page 9]
`
`CODE200 ET AL. EXHIBIT 1025
`Page 11 of 70
`
`

`

`
`August 1982 RFC 821
`Simple Mail Transfer Protocol
`
` 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@USC-ISIF.ARPA>
` R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
` R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.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>
`
` 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.
`
`[Page 10] Postel
`
`RFC 821 August 1982
` Simple Mail Transfer Protocol
`
`CODE200 ET AL. EXHIBIT 1025
`Page 12 of 70
`
`

`

` 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). Users should have the ability to control the
` writing of messages on their terminals. Most hosts permit the
` users 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.
`
`Postel [Page 11]
`
`CODE200 ET AL. EXHIBIT 1025
`Page 13 of 70
`
`

`

`
`August 1982 RFC 821
`Simple Mail Transfer Protocol
`
` The same reply codes that are used for the MAIL commands are used
` for these commands.
`
`[Page 12] Postel
`
`RFC 821 August 1982
` Simple Mail Transfer Protocol
`
`CODE200 ET AL. EXHIBIT 1025
`Page 14 of 70
`
`

`

` 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> <domain> <CRLF>
`
` QUIT <CRLF>
`
` In the HELO command the host sending the command identifies
` itself; the command may be interpreted as saying "Hello, I am
` <domain>".
`
` -------------------------------------------------------------
`
` Example of Connection Opening
`
` R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
` S: HELO USC-ISIF.ARPA
` R: 250 BBN-UNIX.ARPA
`
` Example 5
`
` -------------------------------------------------------------
`
` -------------------------------------------------------------
`
` Example of Connection Closing
`
` S: QUIT
` R: 221 BBN-UNIX.ARPA Service closing transmission channel
`
` Example 6
`
` -------------------------------------------------------------
`
`Postel [Page 13]
`
`CODE200 ET AL. EXHIBIT 1025
`Page 15 of 70
`
`

`

`
`August 1982 RFC 821
`Simple Mail Transfer Protocol
`
` 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.
`
` Conceptually 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.
`
` If when the message arrives at an SMTP the first element of the
` forward-path is not the identifier of that SMTP the element is not
` deleted from the forward-path and is used to determine the next
` SMTP to send the message to. In any case, the SMTP adds its own
` identifier to the reverse-path.
`
` 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
`
`[Page 14] Postel
`
`RFC 821 August 1982
` Simple Mail Transfer Protocol
`
`CODE200 ET AL. EXHIBIT 1025
`Page 16 of 70
`
`

`

` 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).
`
` 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.
`
`Postel [Page 15]
`
`CODE200 ET AL. EXHIBIT 1025
`Page 17 of 70
`
`

`

`
`August 1982 RFC 821
`Simple Mail Transfer Protocol
`
` -------------------------------------------------------------
`
` Example Undeliverable Mail Notification Message
`
` S: MAIL FROM:<>
` R: 250 ok
` S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA>
` R: 250 ok
` S: DATA
` R: 354 send the mail data, end with .
` S: Date: 23 Oct 81 11:22:33
` S: From: SMTP@HOSTY.ARPA
` S: To: JOE@HOSTW.ARPA
` S: Subject: Mail System Problem
` S:
` S: Sorry JOE, your message to SAM@HOSTZ.ARPA lost.
` S: HOSTZ.ARPA said this:
` S: "550 No Such User"
` S: .
` R: 250 ok
`
` Example 7
`
` -------------------------------------------------------------
`
`[Page 16] Postel
`
`RFC 821 August 1982
` Simple Mail Transfer Protocol
`
`CODE200 ET AL. EXHIBIT 1025
`Page 18 of 70
`
`

`

` 3.7. DOMAINS
`
` Domains are a recently introduced concept in the ARPA Internet
` mail system. The use of domains changes the address space from a
` flat global space of simple character string host names to a
` hierarchically structured rooted tree of global addresses. The
` host name is replaced by a domain and host designator which is a
` sequence of domain element strings separated by periods with the
` understanding that the domain elements are ordered from the most
` specific to the most general.
`
` For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and
` "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.
`
` Whenever domain names are used in SMTP only the official names are
` used, the use of nicknames or aliases is not allowed.
`
`Postel [Page 17]
`
`CODE200 ET AL. EXHIBIT 1025
`Page 19 of 70
`
`

`

`
`August 1982 RFC 821
`Simple Mail Transfer Protocol
`
` 3.8. CHANGING ROLES
`
` The TURN command may be used