[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New SMTP 8BITMIME service extension Internet Draft
The following Internet Draft is an updated version of RFC1426. Only minor
editorial changes and clarifications have been made in this new version.
Ned
Network Working Group John Klensin, WG Chair
Internet Draft Ned Freed, Editor
<draft-ietf-smtpex-8bitmime-00.txt> Marshall Rose
Einar Stefferud
David Crocker
SMTP Service Extension
for 8bit-MIMEtransport
March 26, 1994
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 draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not
appropriate to use Internet-Drafts as reference material or to
cite them other than as a "working draft" or "work in
progress".
To learn the current status of any Internet-Draft, please
check the 1id-abstracts.txt listing contained in the
Internet-Drafts Shadow Directories on ds.internic.net,
nic.nordu.net, ftp.isi.edu, or munnari.oz.au.
This draft is intended to supercede RFC 1426.
1. Abstract
This memo defines an extension to the SMTP service whereby an
SMTP content body containing octets outside of the US ASCII
octet range (hex 00-7F) may be relayed using SMTP.
Internet Draft SMTP 8bit-MIMEtransport March 1994
2. Introduction
Although SMTP is widely and robustly deployed, various
extensions have been requested by parts of the Internet
community. In particular, a significant portion of the
Internet community wishes to exchange messages in which the
content body consists of a MIME message [3] containing
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. Note that this
extension does NOT eliminate the possibility of an SMTP server
limiting line length; servers are free to implement this
extension but nevertheless set a line length limit no lower
than 1000 octets.
3. Framework for the 8bit MIME Transport Extension
The 8bit MIME transport extension is laid out as follows:
(1) the name of the SMTP service extension defined here is
8bit-MIMEtransport;
(2) the EHLO keyword value associated with the extension is
8BITMIME;
(3) no parameter is used with the 8BITMIME EHLO keyword;
(4) one optional parameter using the keyword BODY is added to
the MAIL FROM command. The value associated with this
parameter is a keyword indicating whether a 7bit message
(in strict compliance with [1]) or a MIME message (in
strict compliance with [3]) with arbitrary octet content
is being sent. The syntax of the value is as follows,
using the ABNF notation of [2]:
body-value ::= "7BIT" / "8BITMIME"
(5) no additional SMTP verbs are defined by this extension;
and,
(6) the next section specifies how support for the extension
affects the behavior of a server and client SMTP.
Expires September 1994 [Page 2]
Internet Draft SMTP 8bit-MIMEtransport March 1994
4. The 8bit-MIMEtransport service extension
When a client SMTP wishes to submit (using the MAIL command) a
content body consisting of a MIME message containing 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 8BITMIME, then the server SMTP is indicating that it
supports the extended MAIL command and will accept MIME
messages containing arbitrary octet-aligned material.
The extended MAIL command is issued by a client SMTP when it
wishes to transmit a content body consisting of a MIME message
containing arbitrary octet-aligned material. The syntax for
this command is identical to the MAIL command in [1], except
that a BODY parameter must appear after the address.
The complete syntax of this extended command is defined in
[5]. The esmtp-keyword is BODY and the syntax for esmtp-value
is given by the syntax for body-value shown above.
The value associated with the BODY parameter indicates whether
the content body which will be passed using the DATA command
consists of a MIME message containing some arbitrary octet-
aligned material ("8BITMIME") or is encoded entirely in
accordance with [1] ("7BIT").
A server which supports the 8-bit MIME transport 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
Expires September 1994 [Page 3]
Internet Draft SMTP 8bit-MIMEtransport March 1994
between two CR-LF pairs), is still subject to SMTP server line
length restrictions (which may allow as few as 1000 octets on
a single line).
Once a server SMTP supporting the 8bit-MIMEtransport 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 a server SMTP does not support the 8-bit MIME transport
extension (either by not responding with code 250 to the EHLO
command, or by not including the EHLO keyword value 8BITMIME
in its response), then the client SMTP must not, under any
circumstances, attempt to transfer a content which contains
characters outside the US ASCII octet range (hex 00-7F).
A client SMTP has two options in this case: first, it may
implement a gateway transformation to convert the message into
valid 7bit MIME, or second, or may treat this as a permanent
error and handle it in the usual manner for delivery failures.
The specifics of the transformation from 8bit MIME to 7bit
MIME are not described by this RFC; the conversion is
nevertheless constrained in the following ways:
(1) it must cause no loss of information; MIME transport
encodings must be employed as needed to insure this is
the case, and
(2) the resulting message must be valid 7bit MIME.
5. Usage Example
The following dialogue illustrates the use of the 8bit-
MIMEtransport service extension:
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 dbc.mtview.ca.us SMTP service ready
C: EHLO ymir.claremont.edu
S: 250-dbc.mtview.ca.us says hello
S: 250 8BITMIME
C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME
S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok
Expires September 1994 [Page 4]
Internet Draft SMTP 8bit-MIMEtransport March 1994
C: RCPT TO:<mrose@dbc.mtview.ca.us>
S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok
C: DATA
S: 354 Send 8BITMIME message, ending in CRLF.CRLF.
...
C: .
S: 250 OK
C: QUIT
S: 250 Goodbye
6. Security Considerations
This RFC does not discuss security issues and is not believed
to raise any security issues not already endemic in electronic
mail and present in fully conforming implementations of [1].
7. Acknowledgements
This document represents a synthesis of the ideas of many
people and reactions to the ideas and proposals of others.
Randall Atkinson, Craig Everhart, Risto Kankkunen, and Greg
Vaudreuil contributed ideas and text sufficient to be
considered co-authors. Other important suggestions, text, or
encouragement came from Harald Alvestrand, Jim Conklin, Mark
Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per Hedeland,
Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller,
Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John
Wagner, Rayan Zachariassen, and the contributions of the
entire IETF SMTP Working Group. Of course, none of the
individuals are necessarily responsible for the combination of
ideas represented here. Indeed, in some cases, the response to
a particular criticism was to accept the problem
identification but to include an entirely different solution
from the one originally proposed.
Expires September 1994 [Page 5]
Internet Draft SMTP 8bit-MIMEtransport March 1994
8. 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 1521, (September,
1993).
[4] K. Moore. Representation of Non-ASCII Text in Internet
Message Headers. Request for Comments 1522, (September,
1993).
[5] M.T. Rose, E.A. Stefferud, D.H. Crocker, J.C. Klensin,
N. Freed. SMTP Service Extensions. Internet-Draft,
(March, 1994).
[6] C. Partridge. Mail Routing and the Domain System.
Request for Comments 974, (January, 1986).
Expires September 1994 [Page 6]
Internet Draft SMTP 8bit-MIMEtransport March 1994
9. Chair, Editor, and Author Addresses
John Klensin, WG Chair
United Nations University
P.O. Box 500, Charles Street Station
Boston, MA 02114-0500
USA
tel: +1 617 227 8747 fax: +1 617 491 6266
email: klensin@infoods.unu.edu
Ned Freed, Editor
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA
tel: +1 818 919 3600 fax: +1 818 919 3614
email: ned@innosoft.com
Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Moutain View, CA 94043-2186
USA
tel: +1 415 968 1052 fax: +1 415 968 2510
email: mrose@dbc.mtview.ca.us
Einar A. Stefferud
Network Management Associates, Inc.
17301 Drey Lane
Huntington Beach, CA, 92647-5615
USA
tel: +1 714 842 3711 fax: +1 714 848 2091
email: stef@nma.com
Dave Crocker
Silicon Graphics, Inc.
2011 N. Shoreline Blvd.
P.O. Box 7311
Mountain View, CA 94039
USA
tel: +1 415 390 1804 fax: +1 415 962 8404
email: dcrocker@sgi.com
Expires September 1994 [Page 7]