Browse Prior Art Database

SMTP Service Extension for 8bit-MIMEtransport (RFC1652)

IP.com Disclosure Number: IPCOM000002488D
Original Publication Date: 1994-Jul-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 6 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Klensin: AUTHOR [+4]

Related Documents

10.17487/RFC1652: DOI

Abstract

This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US- ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 33% of the total text.

Network Working Group J. Klensin, WG Chair Request for Comments: 1652 MCI Obsoletes: 1426 N. Freed, Editor Category: Standards Track Innosoft M. Rose Dover Beach Consulting, Inc. E. Stefferud Network Management Associates, Inc. D. Crocker Silicon Graphics, Inc. July 1994

SMTP Service Extension for 8bit-MIMEtransport

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Abstract

This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US- ASCII octet range (hex 00-7F) may be relayed using SMTP.

1. 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. Given that this restriction still applies, this extension does NOT 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 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.

3. 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 lines of 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 res...

Processing...
Loading...