2.2.3. Special Issues with Extensions

Extensions that change fairly basic properties of SMTP operation are

permitted. The text in other sections of this document must be

understood in that context. In particular, extensions can change the

minimum limits specified in Section 4.5.3, can change the ASCII

character set requirement as mentioned above, or can introduce some

optional modes of message handling.

In particular, if an extension implies that the delivery path

normally supports special features of that extension, and an

intermediate SMTP system finds a next hop that does not support the

required extension, it MAY choose, based on the specific extension

and circumstances, to requeue the message and try later and/or try an

alternate MX host. If this strategy is employed, the timeout to fall

back to an unextended format (if one is available) SHOULD be less

than the normal timeout for bouncing as undeliverable (e.g., if

normal timeout is three days, the requeue timeout before attempting

to transmit the mail without the extension might be one day).

2.3. Smtp Terminology

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 reverse-path (originator) address specification

command (MAIL) could be used to specify alternate delivery modes,

such as immediate display; those variations have now been deprecated

(see Appendix FandAppendix F.6).

The SMTP content is sent in the SMTP DATA protocol unit and has two

parts: the header section and the body. If the content conforms to

other contemporary standards, the header section consists of a

collection of header fields, each consisting of a header name, a

colon, and data, structured as in the message format specification

(RFC 5322[4]); the body, if structured, is defined according to MIME

(RFC 2045[21]). The content is textual in nature, expressed using

the US-ASCII repertoire [6]. Although SMTP extensions (such as

"8BITMIME", RFC 1652[22]) may relax this restriction for the content

body, the content header fields are always encoded using the US-ASCII

repertoire. Two MIME extensions (RFC 2047[23] andRFC 2231[24])

define 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.