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).
SMTP Terminology
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 F and Appendix 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] and RFC 2231 [24])
define an algorithm for representing header values outside the US-
ASCII repertoire, while still encoding them using the US-ASCII
repertoire.