As per Relevance of the word containing, we have this rfc below:
Network Working Group J. Klensin, WG
Request for Comments: 1652
Obsoletes: 1426 N. Freed,
Category: Standards Track
M.
Dover Beach Consulting, Inc
E.
Network Management Associates, Inc
D.
Silicon Graphics, Inc
July 1994
SMTP Service Extension for 8bit-
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This memo defines an extension to the SMTP service whereby an
content body consisting of text containing octets outside of the US
ASCII octet range (hex 00-7F) may be relayed using SMTP
1.
Although SMTP is widely and robustly deployed, various
have been requested by parts of the Internet community.
particular, a significant portion of the Internet community wishes
exchange messages in which the content body consists of a
message [3] containing arbitrary octet-aligned material. This
uses the mechanism described in [5] to define an extension to
SMTP service whereby such contents may be exchanged. Note that
extension does NOT eliminate the possibility of an SMTP
limiting line length; servers are free to implement this
but nevertheless set a line length limit no lower than 1000 octets
Given that this restriction still applies, this extension does
provide a means for transferring unencoded binary via SMTP
Klensin, Freed, Rose, Stefferud & Crocker [Page 1]
RFC 1652 SMTP 8bit-MIMEtransport July 1994
2. Framework for the 8bit MIME Transport
The 8bit MIME transport extension is laid out as follows
(1) the name of the SMTP service extension defined here
8bit-MIMEtransport
(2) the EHLO keyword value associated with the extension
8BITMIME
(3) no parameter is used with the 8BITMIME EHLO keyword
(4) one optional parameter using the keyword BODY is added
the MAIL FROM command. The value associated with
parameter is a keyword indicating whether a 7bit
(in strict compliance with [1]) or a MIME message (
strict compliance with [3]) with arbitrary octet
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
affects the behavior of a server and client SMTP
3. The 8bit-MIMEtransport service
When a client SMTP wishes to submit (using the MAIL command)
content body consisting of a MIME message containing arbitrary
of octet-aligned material, it first issues the EHLO command to
server SMTP. If the server SMTP responds with code 250 to the
command, and the response includes the EHLO keyword value 8BITMIME
then the server SMTP is indicating that it supports the extended
command and will accept MIME messages containing arbitrary octet
aligned material
The extended MAIL command is issued by a client SMTP when it
to transmit a content body consisting of a MIME message
arbitrary lines of octet-aligned material. The syntax for
command is identical to the MAIL command in [1], except that a
parameter must appear after the address. Only one BODY parameter
be used in a single MAIL command
Klensin, Freed, Rose, Stefferud & Crocker [Page 2]
RFC 1652 SMTP 8bit-MIMEtransport July 1994
The complete syntax of this extended command is defined in [5].
esmtp-keyword is BODY and the syntax for esmtp-value is given by
syntax for body-value shown above
The value associated with the BODY parameter indicates whether
content body which will be passed using the DATA command consists
a MIME message containing some arbitrary octet-aligned
("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT").
A server which supports the 8-bit MIME transport service
shall preserve all bits in each octet passed using the DATA command
Naturally, the usual SMTP data-stuffing algorithm applies so that
content which contains the five-character sequence
or a content that begins with the three-character sequence
does not prematurely terminate the transfer of the content. Further
it should be noted that the CR-LF pair immediately preceeding
final dot is considered part of the content. Finally, although
content body contains arbitrary lines of octet-aligned material,
length of each line (number of octets between two CR-LF pairs),
still subject to SMTP server line length restrictions (which
allow as few as 1000 octets on a single line). This restriction
that this extension MAY provide the necessary facilities
transferring a MIME object with the 8BIT content-transfer-encoding
it DOES NOT provide a means of transferring an object with the
content-transfer-encoding
Once a server SMTP supporting the 8bit-MIMEtransport
extension accepts a content body containing octets with the high
order (8th) bit set, the server SMTP must deliver or relay
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
(either by not responding with code 250 to the EHLO command, or
not including the EHLO keyword value 8BITMIME in its response),
the client SMTP must not, under any circumstances, attempt
transfer a content which contains characters outside the US-
octet range (hex 00-7F).
A client SMTP has two options in this case: first, it may implement
gateway transformation to convert the message into valid 7bit MIME
or second, or may treat this as a permanent error and handle it
Klensin, Freed, Rose, Stefferud & Crocker [Page 3]
RFC 1652 SMTP 8bit-MIMEtransport July 1994
the usual manner for delivery failures. The specifics of
transformation from 8bit MIME to 7bit MIME are not described by
RFC; the conversion is nevertheless constrained in the
ways
(1) it must cause no loss of information; MIME
encodings must be employed as needed to insure this
the case,
(2) the resulting message must be valid 7bit MIME
4. Usage
The following dialogue illustrates the use of the 8bit-
service extension
S: connection on TCP port 25>
C: connection to server
S: 220 dbc.mtview.ca.us SMTP service
C: EHLO ymir.claremont.
S: 250-dbc.mtview.ca.us says
S: 250 8
C: MAIL FROM: BODY=8
S: 250 ... Sender and 8BITMIME
C: RCPT TO:
S: 250 ... Recipient
C:
S: 354 Send 8BITMIME message, ending in CRLF.CRLF
...
C: .
S: 250
C:
S: 250
5. Security
This RFC does not discuss security issues and is not believed
raise any security issues not already endemic in electronic mail
present in fully conforming implementations of [1].
6.
This document represents a synthesis of the ideas of many people
reactions to the ideas and proposals of others. Randall Atkinson
Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed
and text sufficient to be considered co-authors. Other
suggestions, text, or encouragement came from Harald Alvestrand,
Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson,
Klensin, Freed, Rose, Stefferud & Crocker [Page 4]
RFC 1652 SMTP 8bit-MIMEtransport July 1994
Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A
Miller, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert,
Wagner, Rayan Zachariassen, and the contributions of the entire
SMTP Working Group. Of course, none of the individuals
necessarily responsible for the combination of ideas
here. Indeed, in some cases, the response to a particular
was to accept the problem identification but to include an
different solution from the one originally proposed
7.
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet
Messages", STD 11, RFC 822, UDEL, August 1982.
[3] Borenstein, N., and N. Freed, "Multipurpose Internet
Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
[4] Moore, K., "Representation of Non-ASCII Text in Internet
Headers", RFC 1522, University of Tennessee, September 1993.
[5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker
"SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover
Consulting, Inc., Network Management Associates, Inc.,
Graphics, Inc., July 1994.
[6] Partridge, C., "Mail Routing and the Domain System", STD 14,
974, BBN, January 1986.
8. Chair, Editor, and Authors'
John Klensin, WG
MCI Data Services
2100 Reston Parkway, 6th
Reston, VA 22091
Phone:: 1 703 715 7361
Fax: +1 703 715 7435
EMail: klensin@mci.
Klensin, Freed, Rose, Stefferud & Crocker [Page 5]
RFC 1652 SMTP 8bit-MIMEtransport July 1994
Ned Freed,
Innosoft International, Inc
1050 East Garvey Avenue
West Covina, CA 91790
Phone:: +1 818 919 3600
Fax: +1 818 919 3614
EMail: ned@innosoft.
Marshall T.
Dover Beach Consulting, Inc
420 Whisman
Moutain View, CA 94043-2186
Phone: +1 415 968 1052
Fax: +1 415 968 2510
EMail: mrose@dbc.mtview.ca.
Einar A.
Network Management Associates, Inc
17301 Drey
Huntington Beach, CA, 92647-5615
Phone: +1 714 842 3711
Fax: +1 714 848 2091
EMail: stef@nma.
Dave
Silicon Graphics, Inc
2011 N. Shoreline Blvd
P.O. Box 7311
Mountain View, CA 94039
Phone: +1 415 390 1804
Fax: +1 415 962 8404
EMail: dcrocker@sgi.
Klensin, Freed, Rose, Stefferud & Crocker [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
