draft SMTP 8bit-cleanliness Oct 92
SMTP Service Extension
for 8bit-cleanliness
Fri Oct 16 23:17:52 1992
Einar A. Stefferud
Network Management Associates, Inc.
stef@nma.com
David H. Crocker
The Branch Office
dcrocker@mordor.stanford.edu
Marshall T. Rose
Dover Beach Consulting, Inc.
mrose@dbc.mtview.ca.us
1. Status of this Memo
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at any
time. (The file 1id-abstracts.txt on nic.ddn.mil describes
the current status of each Internet Draft.) It is not
appropriate to use Internet Drafts as reference material or to
cite them other than as a "work in progress".
2. Abstract
This memo defines an extension to the SMTP service whereby an
SMTP content body containing octets outside of the US ASCII
repertoire may be relayed using SMTP.
Expires April 16, 1993 [Page 1]
draft SMTP 8bit-cleanliness Oct 92
3. Introduction
The Simple Mail Transfer Protocol (SMTP) [1] has provided a
stable, effective basis for the relay function of message
transfer agents. Although a decade old, SMTP has proven
remarkably resilient.
4. Framework for SMTP Extensions
For the purpose of service extensions to the SMTP, SMTP relays
a mail object containing an envelope and a content.
(1) The SMTP envelope is straight-forward, and is sent as a
series of SMTP protocol units: it consists of an
originator address (to which error reports should be
directed); a delivery mode (e.g., deliver to recipient
mailboxes); and, one or more recipient addresses.
(2) The SMTP content is sent in the SMTP DATA protocol unit
and has two parts: the headers and the body. The headers
form a collection of field/value pairs structured
according to RFC 822 [2], whilst the body, if structured,
is defined according to MIME [3]. The content is textual
in nature, expressed using the US ASCII repertoire (ISO
registered character set number 6). Although extensions
(such as MIME) may relax this restriction for the content
body, the content headers are always encoded using the US
ASCII repertoire. The algorithm defined in [4] is used
to represent header values outside the US ASCII
repertoire, whilst still encoding them using the US ASCII
repertoire.
Although SMTP is widely and robustly deployed, some parts of
the Internet community might wish to extend the SMTP service.
In particular, a significant portion of the Internet community
wishes to exchange messages in which the content body contains
arbitrary octet-aligned material. This memo uses the
mechanism described in [5] to define an extension to the SMTP
service whereby such contents may be exchanged:
(1) the name of the SMTP service extension is 8bit-
cleanliness;
Expires April 16, 1993 [Page 2]
draft SMTP 8bit-cleanliness Oct 92
(2) the EHLO keyword value associated with the extension is
8BIT;
(3) the syntax of the parameter (using the ABNF notation of
[2]) associated with this EHLO keyword value is:
8bit-param ::= "CONVERT" / "NOCONVERT" / "MIME"
(4) the next section specifies how support for the extension
affects the behavior of a server and client SMTP.
5. The 8bit-cleanliness service extension
When a client SMTP wishes to relay (using the MAIL command) a
content body which contains arbitrary octet-aligned material,
it first issues the EHLO command to the server SMTP. If the
server SMTP responds with code 250 to the EHLO command, and
the response includes the EHLO keyword value 8BIT, then the
server SMTP is indicating that it supports the extended MAIL
command and will accept some types of octet-aligned material.
If the parameter associated with the EHLO keyword value 8BIT
is "MIME", then the client SMTP may transmit a content body
containing octet-aligned material only if it is structured
according to the rules given in [3] (i.e., any body part
containing arbitrary octet-aligned material is tagged with a
Content-Transfer-Encoding header field).
Otherwise, if the parameter associated with the EHLO keyword
value 8BIT is "CONVERT" or "NOCONVERT", then the client SMTP
is permitted to transmit a content body containing arbitrary
octet-aligned material to the server SMTP.
The extended MAIL command is issued by a client SMTP when it
wishes to transmit a content body containing arbitrary octet-
aligned material. The syntax for this command is identical to
the MAIL command in [1], except that a BODY parameter may
appear after the address. The syntax of the extended MAIL
command (using the ABNF notation of [2]) is:
email-cmd ::= "MAIL FROM:<" reverse-path ">" body-param
body-param ::= SPACE "BODY=" ( "USASCII" / "OCTET" )
Expires April 16, 1993 [Page 3]
draft SMTP 8bit-cleanliness Oct 92
The value associated with the BODY parameter indicates whether
the content body which will be passed using the DATA command
contains some arbitrary octet-aligned material ("OCTET") or is
encoded entirely in US ASCII ("ASCII").
A server which supports the 8-bit cleanliness service
extension shall preserve all bits in each octet passed using
the DATA command.
Naturally, the usual SMTP data-stuffing algorithm applies so
that a content which contains the five-character sequence of
<CR> <LF> <DOT> <CR> <LF>
or a content that begins with the three-character sequence of
<DOT> <CR> <LF>
does not prematurely terminate the transfer of the content.
Further, it should be noted that the CR-LF pair immediately
preceeding the final dot is considered part of the content.
Finally, although the content body contains arbitrary octet-
aligned material, the length of each line (number of octets
between two CR-LF pairs), must not exceed 1000 characters, as
specified in [1].
Once a server SMTP supporting the 8bit-cleanliness service
extension accepts a content body containing octets with the
high-order 8th bit set, the server SMTP must deliver or relay
the content in such a way as to preserve all bits in each
octet.
If the path to the next hop (or a recipient's user agent) is
not known to preserve all bits in each octet, then the
behavior of the server SMTP depends on the parameter
associated with the EHLO keyword value 8BIT.
If the parameter had the value "CONVERT" or "MIME", then the
server SMTP must transform the content body (as described in
Section 5.1).
Otherwise, if the parameter had the value "NOCONVERT", then
this is treated as a permanent error, and is handled in the
usual manner for delivery failures for that server SMTP.
Expires April 16, 1993 [Page 4]
draft SMTP 8bit-cleanliness Oct 92
If a server SMTP does not support the 8-bit cleanliness
extension (either by not responding with code 250 to the EHLO
command, or by not including the EHLO keyword value 8BIT in
its response), then the client SMTP must not, under any
circumstances, attempt to transfer a content which contains
characters outside the US ASCII repertoire.
A client SMTP has two options in this case: first, it may seek
another server SMTP to act as a mail relay for the current
recipients (according to the rules of [6]), and which supports
the 8-bit cleanliness extension (this might result in the
message being re-queued by the client SMTP); or, it may
implement the gateway transformations described in Section
5.1. If neither option is available, then this is treated as
a permanent error, and is handled in the usual manner for
delivery failures for that server SMTP.
5.1. Client SMTP performing gateway transformations
If the client SMTP chooses to operate as a mail domain
gateway, then it first examines the content headers looking
for two header fields: MIME-Version and Content-Type. If both
are present, and if the content-type associated with the
latter is either Multipart or Message, then the client SMTP
recursively examines, and if necessary, transforms, the
transfer encodings of the body parts contained therein. For
example, if only one part of a multipart content-type is
encoded using characters outside of the US ASCII repertoire,
then only that part is transformed.
Otherwise, if the content-type is neither Multipart nor
Message (or lacks the MIME-Version and/or Content-Type
fields), then the client SMTP applies either the quoted-
printable or base64 transfer-encoding to the content body.
(The choice of transfer-encoding is at the discretion of the
client SMTP.) The Content-Transfer-Encoding field in the
content headers is changed to reflect the transfer-encoding in
use, as specified in [3]. (If this field is not present, then
it is added.) If a MIME-Version field is not present, then it
is added, i.e.,
MIME-Version: 1.0
If a Content-Type field is not present, then it, along with a
Content-Description field, shall be added, specifically: i.e.,
Expires April 16, 1993 [Page 5]
draft SMTP 8bit-cleanliness Oct 92
Content-Type: application/octet-stream
Content-Description: untagged data converted to MIME
After transforming the content body, the client SMTP
determines if any textual components of the content headers
contain characters outside of the US ASCII repertoire. If so,
these are transformed using the rules defined in [4].
However, since no information is available as to the
repertoire in use, the charset value of "unknown" is used.
For each word encoded, the choice of applying either the "Q"
or "B" transfer-encoding lies with the client SMTP.
Finally, the client SMTP adds trace information to the content
headers. This takes the form of a single Received: field
placed above any other such fields in the content headers.
This new field should indicate the nature of the
transformation which was applied, using a "with" phrase, with
a value of "binary-to-base64" or "binary-to-quoted", e.g.,
Received: from baiji.dbc.mtview.ca.us by dbc.mtview.ca.us
with binary-to-base64
; Tue, 01 Sep 1992 01:18:00 -0700
6. Acknowledgements
The authors acknowledge the comments of Harald T. Alvestrand,
Ned Freed, John C. Kleinsen, Keith Moore, Neil W. Rickert,
and, John Wagner.
7. References
[1] J.B. Postel. Simple Mail Transfer Protocol. Request for
Comments 821, (August, 1982).
[2] D.H. Crocker. Standard for the Format of ARPA Internet
Text Messages. Request for Comments 822, (August, 1982).
[3] N.S. Borenstein, N. Freed. Multipurpose Internet Mail
Extensions. Request for Comments 1341, (June, 1992).
Expires April 16, 1993 [Page 6]
draft SMTP 8bit-cleanliness Oct 92
[4] K. Moore. Representation of Non-ASCII Text in Internet
Message Headers. Request for Comments 1342, (June,
1992).
[5] M.T. Rose, E.A. Stefferud, D.H. Crocker. SMTP Service
Extensions. Internet-Draft, (September, 1992).
[6] C. Partridge. Mail Routing and the Domain System.
Request for Comments 974, (January, 1986).
Expires April 16, 1993 [Page 7]
