Network Working Group J. Klensin, Editor
`Request for Comments: 2821 AT&T Laboratories
`Obsoletes: 821, 974, 1869 April 2001
`Updates: 1123
`Category: Standards Track
`
` Simple Mail Transfer Protocol
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2001). All Rights Reserved.
`
`Abstract
`
` This document is a self-contained specification of the basic protocol
` for the Internet electronic mail transport. It consolidates, updates
` and clarifies, but doesn’t add new or change existing functionality
` of the following:
`
` - the original SMTP (Simple Mail Transfer Protocol) specification of
`RFC 821 [30],
`
` - domain name system requirements and implications for mail
` transport from RFC 1035 [22] and RFC 974 [27],
`
` - the clarifications and applicability statements in RFC 1123 [2],
` and
`
` - material drawn from the SMTP Extension mechanisms [19].
`
` It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces 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.
`
`Klensin Standards Track [Page 1]
`
`Microsoft Ex. 1020, p. 1
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`RFC 2821 Simple Mail Transfer Protocol April 2001
`
` 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 appeared 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 [3, 26]
` and IMAP [6]. Additional submission issues are discussed in RFC 2476
` [15].
`
`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 [32] discusses message headers, message bodies
` and formats and structures for them, and their relationship.
`
`Table of Contents
`
`1. Introduction .................................................. 4
`2. The SMTP Model ................................................ 5
`2.1 Basic Structure .............................................. 5
`2.2 The Extension Model .......................................... 7
`2.2.1 Background ................................................. 7
`2.2.2 Definition and Registration of Extensions .................. 8
`2.3 Terminology .................................................. 9
`2.3.1 Mail Objects ............................................... 10
`2.3.2 Senders and Receivers ...................................... 10
`2.3.3 Mail Agents and Message Stores ............................. 10
`2.3.4 Host ....................................................... 11
`2.3.5 Domain ..................................................... 11
`2.3.6 Buffer and State Table ..................................... 11
`2.3.7 Lines ...................................................... 12
`2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12
`2.3.9 Message Content and Mail Data .............................. 13
`2.3.10 Mailbox and Address ....................................... 13
`2.3.11 Reply ..................................................... 13
`2.4 General Syntax Principles and Transaction Model .............. 13
`3. The SMTP Procedures: An Overview .............................. 15
`3.1 Session Initiation ........................................... 15
`3.2 Client Initiation ............................................ 16
`3.3 Mail Transactions ............................................ 16
`3.4 Forwarding for Address Correction or Updating ................ 19
`
`Klensin Standards Track [Page 2]
`
`Microsoft Ex. 1020, p. 2
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`RFC 2821 Simple Mail Transfer Protocol April 2001
`
`3.5 Commands for Debugging Addresses ............................. 20
`3.5.1 Overview ................................................... 20
`3.5.2 VRFY Normal Response ....................................... 22
`3.5.3 Meaning of VRFY or EXPN Success Response ................... 22
`3.5.4 Semantics and Applications of EXPN ......................... 23
`3.6 Domains ...................................................... 23
`3.7 Relaying ..................................................... 24
`3.8 Mail Gatewaying .............................................. 25
`3.8.1 Header Fields in Gatewaying ................................ 26
`3.8.2 Received Lines in Gatewaying ............................... 26
`3.8.3 Addresses in Gatewaying .................................... 26
`3.8.4 Other Header Fields in Gatewaying .......................... 27
`3.8.5 Envelopes in Gatewaying .................................... 27
`3.9 Terminating Sessions and Connections ......................... 27
`3.10 Mailing Lists and Aliases ................................... 28
`3.10.1 Alias ..................................................... 28
`3.10.2 List ...................................................... 28
`4. The SMTP Specifications ....................................... 29
`4.1 SMTP Commands ................................................ 29
`4.1.1 Command Semantics and Syntax ............................... 29
`4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) ................... 29
`4.1.1.2 MAIL (MAIL) .............................................. 31
`4.1.1.3 RECIPIENT (RCPT) ......................................... 31
`4.1.1.4 DATA (DATA) .............................................. 33
`4.1.1.5 RESET (RSET) ............................................. 34
`4.1.1.6 VERIFY (VRFY) ............................................ 35
`4.1.1.7 EXPAND (EXPN) ............................................ 35
`4.1.1.8 HELP (HELP) .............................................. 35
`4.1.1.9 NOOP (NOOP) .............................................. 35
`4.1.1.10 QUIT (QUIT) ............................................. 36
`4.1.2 Command Argument Syntax .................................... 36
`4.1.3 Address Literals ........................................... 38
`4.1.4 Order of Commands .......................................... 39
`4.1.5 Private-use Commands ....................................... 40
`4.2 SMTP Replies ................................................ 40
`4.2.1 Reply Code Severities and Theory ........................... 42
`4.2.2 Reply Codes by Function Groups ............................. 44
`4.2.3 Reply Codes in Numeric Order .............................. 45
`4.2.4 Reply Code 502 ............................................. 46
`4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46
`4.3 Sequencing of Commands and Replies ........................... 47
`4.3.1 Sequencing Overview ........................................ 47
`4.3.2 Command-Reply Sequences .................................... 48
`4.4 Trace Information ............................................ 49
`4.5 Additional Implementation Issues ............................. 53
`4.5.1 Minimum Implementation ..................................... 53
`4.5.2 Transparency ............................................... 53
`4.5.3 Sizes and Timeouts ......................................... 54
`
`Klensin Standards Track [Page 3]
`
`Microsoft Ex. 1020, p. 3
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`RFC 2821 Simple Mail Transfer Protocol April 2001
`
`4.5.3.1 Size limits and minimums ................................. 54
`4.5.3.2 Timeouts ................................................. 56
`4.5.4 Retry Strategies ........................................... 57
`4.5.4.1 Sending Strategy ......................................... 58
`4.5.4.2 Receiving Strategy ....................................... 59
`4.5.5 Messages with a null reverse-path .......................... 59
`5. Address Resolution and Mail Handling .......................... 60
`6. Problem Detection and Handling ................................ 62
`6.1 Reliable Delivery and Replies by Email ....................... 62
`6.2 Loop Detection ............................................... 63
`6.3 Compensating for Irregularities .............................. 63
`7. Security Considerations ....................................... 64
`7.1 Mail Security and Spoofing ................................... 64
`7.2 "Blind" Copies ............................................... 65
`7.3 VRFY, EXPN, and Security ..................................... 65
`7.4 Information Disclosure in Announcements ...................... 66
`7.5 Information Disclosure in Trace Fields ....................... 66
`7.6 Information Disclosure in Message Forwarding ................. 67
`7.7 Scope of Operation of SMTP Servers ........................... 67
`8. IANA Considerations ........................................... 67
`9. References .................................................... 68
`10. Editor’s Address ............................................. 70
`11. Acknowledgments .............................................. 70
` Appendices ....................................................... 71
`A. TCP Transport Service ......................................... 71
`B. Generating SMTP Commands from RFC 822 Headers ................. 71
`C. Source Routes ................................................. 72
`D. Scenarios ..................................................... 73
`E. Other Gateway Issues .......................................... 76
`F. Deprecated Features of RFC 821 ................................ 76
` Full Copyright Statement ......................................... 79
`
`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
`
`Klensin Standards Track [Page 4]
`
`Microsoft Ex. 1020, p. 4
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`RFC 2821 Simple Mail Transfer Protocol April 2001
`
` 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 [22, 27] (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 [3, 26] or IMAP [6]
` 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
`
`Klensin Standards Track [Page 5]
`
`Microsoft Ex. 1020, p. 5
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`RFC 2821 Simple Mail Transfer Protocol April 2001
`
` 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 command
` pipelining [13].
`
`Klensin Standards Track [Page 6]
`
`Microsoft Ex. 1020, p. 6
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`RFC 2821 Simple Mail Transfer Protocol April 2001
`
` 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:
`
`Klensin Standards Track [Page 7]
`
`Microsoft Ex. 1020, p. 7
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`RFC 2821 Simple Mail Transfer Protocol April 2001
`
` - 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 in non-ASCII transmissions [33].
`
` 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.
`
`Klensin Standards Track [Page 8]
`
`Microsoft Ex. 1020, p. 8
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`RFC 2821 Simple Mail Transfer Protocol April 2001
`
` 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
`
` 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 below.
`
` 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that
` the definition is an absolute requirement of the specification.
`
` 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
` definition is an absolute prohibition of the specification.
`
` 3. SHOULD This word, or the adjective "RECOMMENDED", mean that
` there may exist valid reasons in particular circumstances to
` ignore a particular item, but the full implications must be
` understood and carefully weighed before choosing a different
` course.
`
` 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean
` that there may exist valid reasons in particular circumstances
` when the particular behavior is acceptable or even useful, but the
` full implications should be understood and the case carefully
` weighed before implementing any behavior described with this
` label.
`
` 5. MAY This word, or the adjective "OPTIONAL", mean that an item is
` truly optional. One vendor may choose to include the item because
` a particular marketplace requires it or because the vendor feels
` that it enhances the product while another vendor may omit the
` same item. An implementation which does not include a particular
` option MUST be prepared to interoperate with another
` implementation which does include the option, though perhaps with
` reduced functionality. In the same vein an implementation which
`
`Klensin Standards Track [Page 9]
`
`Microsoft Ex. 1020, p. 9
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`RFC 2821 Simple Mail Transfer Protocol April 2001
`
` does include a particular option MUST be prepared to interoperate
` with another implementation which does not include the option
` (except, of course, for the feature the option provides.)
`
`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 in the message format specification [32]; the
` body, if structured, is defined according to MIME [12]. The content
` is textual in nature, expressed using the US-ASCII repertoire [1].
` Although SMTP extensions (such as "8BITMIME" [20]) may relax this
` restriction for the content body, the content headers are always
` encoded using the US-ASCII repertoire. A MIME extension [23] defines
` an algorithm for representing 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
`
`Klensin Standards Track [Page 10]
`
`Microsoft Ex. 1020, p. 10
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`RFC 2821 Simple Mail Transfer Protocol April 2001
`
` 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 [22]) are
` restricted for SMTP purposes to consist of a sequence of letters,
` digits, and hyphens drawn from the ASCII character set [1]. 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 [22] and
`section 5 of this specification.
`
` The domain name, as described in this document and in [22], 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.
`
`Klensin Standards Track [Page 11]
`
`Microsoft Ex. 1020, p. 11
`Microsoft v. Daedalus Blue
`IPR2021-00831
`
`

`

`RFC 2821 Simple Mail Transfer Protocol April 2001
`
`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 req