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 that

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. Commands and Replies

SMTP commands and, unless altered by a service extension, message

data, are transmitted from the sender to the receiver via the

transmission channel in "lines".

An SMTP reply is an acknowledgment (positive or negative) sent in

"lines" 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. RFC 3463[25], specifies further

structuring of the reply strings, including the use of supplemental

and more specific completion codes (see also RFC 5248[26]).

2.3.8. 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).

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.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 the message header section and

the possibly structured message body. The MIME specification (RFC

2045[21]) provides the standard mechanisms for structured message bodies.

2.3.10. 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 that

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 RFC 2979[27]).