(2) Only those header fields in the enclosed message which start
with "Content-" and "Message-ID", "Encrypted", and "MIME-Version"
must be appended, in order, to the header fields of the new
message. Any header fields in the enclosed message which do not
start with "Content-" (except for "Message-ID", "Encrypted", and
"MIME-Version") will be ignored.
(3) All of the header fields from the second and any subsequent
messages will be ignored.
For example, if an audio message is broken into two parts, the first
part might look something like this:
X-Weird-Header-1: Foo
From: Bill@host.com
To: joe@otherhost.com
Subject: Audio mail
Message-ID: <id1@host.com>
MIME-Version: 1.0
Content-type: message/partial;
id="ABC@host.com";
number=1; total=2
X-Weird-Header-1: Bar
X-Weird-Header-2: Hello
Message-ID: <anotherid@foo.com>
MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64
... first half of encoded audio data goes here...
and the second half might look something like this:
From: Bill@host.com
To: joe@otherhost.com
Subject: Audio mail
MIME-Version: 1.0
Message-ID: <id2@host.com>
Content-type: message/partial;
id="ABC@host.com"; number=2; total=2
... second half of encoded audio data goes here...
Then, when the fragmented message is reassembled, the resulting
message to be displayed to the user should look something like this:
X-Weird-Header-1: Foo
From: Bill@host.com
To: joe@otherhost.com
Subject: Audio mail
Message-ID: <anotherid@foo.com>
MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64
... first half of encoded audio data goes here...
... second half of encoded audio data goes here...
Note on encoding of MIME entities encapsulated inside message/partial
entities: Because data of type "message" may never be encoded in
base64 or quoted-printable, a problem might arise if message/partial
entities are constructed in an environment that supports binary or
8-bit transport. The problem is that the binary data would be split
into multiple message/partial objects, each of them requiring binary
transport. If such objects were encountered at a gateway into a 7-
bit transport environment, there would be no way to properly encode
them for the 7-bit world, aside from waiting for all of the parts,
reassembling the message, and then encoding the reassembled data in
base64 or quoted-printable. Since it is possible that different
parts might go through different gateways, even this is not an
acceptable solution. For this reason, it is specified that MIME
entities of type message/partial must always have a content-
transfer-encoding of 7-bit (the default). In particular, even in
environments that support binary or 8-bit transport, the use of a
content-transfer-encoding of "8bit" or "binary" is explicitly
prohibited for entities of type message/partial.
It should be noted that, because some message transfer agents may
choose to automatically fragment large messages, and because such
agents may use different fragmentation thresholds, it is possible
that the pieces of a partial message, upon reassembly, may prove
themselves to comprise a partial message. This is explicitly
permitted.
It should also be noted that the inclusion of a "References" field in
the headers of the second and subsequent pieces of a fragmented
message that references the Message-Id on the previous piece may be
of benefit to mail readers that understand and track references.
However, the generation of such "References" fields is entirely
optional.
Finally, it should be noted that the "Encrypted" header field has
been made obsolete by Privacy Enhanced Messaging (PEM), but the rules
above are believed to describe the correct way to treat it if it is
encountered in the context of conversion to and from message/partial
fragments.
7.3.3. The Message/External-Body subtype
The external-body subtype indicates that the actual body data are not
included, but merely referenced. In this case, the parameters
describe a mechanism for accessing the external data.
When an entity is of type "message/external-body", it consists of a
header, two consecutive CRLFs, and the message header for the
encapsulated message. If another pair of consecutive CRLFs appears,
this of course ends the message header for the encapsulated message.
However, since the encapsulated message's body is itself external, it
does NOT appear in the area that follows. For example, consider the
following message:
Content-type: message/external-body; access-
type=local-file;
name="/u/nsb/Me.gif"
Content-type: image/gif
Content-ID: <id42@guppylake.bellcore.com>
Content-Transfer-Encoding: binary
THIS IS NOT REALLY THE BODY!
The area at the end, which might be called the "phantom body", is
ignored for most external-body messages. However, it may be used to
contain auxiliary information for some such messages, as indeed it is
when the access-type is "mail-server". Of the access-types defined
by this document, the phantom body is used only when the access-type
is "mail-server". In all other cases, the phantom body is ignored.
The only always-mandatory parameter for message/external-body is
"access-type"; all of the other parameters may be mandatory or
optional depending on the value of access-type.
ACCESS-TYPE -- A case-insensitive word, indicating the supported
access mechanism by which the file or data may be obtained.
Values include, but are not limited to, "FTP", "ANON-FTP", "TFTP",
"AFS", "LOCAL-FILE", and "MAIL-SERVER". Future values, except for
experimental values beginning with "X-" must be registered with
IANA, as described in Appendix E .
In addition, the following three parameters are optional for ALL
access-types:
EXPIRATION -- The date (in the RFC822 "date-time" syntax, as
extended by RFC1123 to permit 4 digits in the year field) after
which the existence of the external data is not guaranteed.
SIZE -- The size (in octets) of the data. The intent of this
parameter is to help the recipient decide whether or not to expend
the necessary resources to retrieve the external data. Note that
this describes the size of the data in its canonical form, that
is, before any Content- Transfer-Encoding has been applied or
after the data have been decoded.
PERMISSION -- A case-insensitive field that indicates whether or
not it is expected that clients might also attempt to overwrite
the data. By default, or if permission is "read", the assumption
is that they are not, and that if the data is retrieved once, it
is never needed again. If PERMISSION is "read-write", this
assumption is invalid, and any local copy must be considered no
more than a cache. "Read" and "Read-write" are the only defined
values of permission.
The precise semantics of the access-types defined here are described
in the sections that follow.
The encapsulated headers in ALL message/external-body entities MUST
include a Content-ID header field to give a unique identifier by
which to reference the data. This identifier may be used for
cacheing mechanisms, and for recognizing the receipt of the data when
the access-type is "mail-server".
Note that, as specified here, the tokens that describe external-body
data, such as file names and mail server commands, are required to be
in the US-ASCII character set. If this proves problematic in
practice, a new mechanism may be required as a future extension to
MIME, either as newly defined access-types for message/external-body
or by some other mechanism.
As with message/partial, it is specified that MIME entities of type
message/external-body must always have a content-transfer-encoding of
7-bit (the default). In particular, even in environments that
support binary or 8-bit transport, the use of a content-transfer-
encoding of "8bit" or "binary" is explicitly prohibited for entities
of type message/external-body.
7.3.3.1. The "ftp" and "tftp" access-types
An access-type of FTP or TFTP indicates that the message body is
accessible as a file using the FTP [RFC-959] or TFTP [RFC-783]
protocols, respectively. For these access-types, the following
additional parameters are mandatory:
NAME -- The name of the file that contains the actual body data.
SITE -- A machine from which the file may be obtained, using the
given protocol. This must be a fully qualified domain name, not a
nickname.
Before any data are retrieved, using FTP, the user will generally
need to be asked to provide a login id and a password for the machine
named by the site parameter. For security reasons, such an id and
password are not specified as content-type parameters, but must be
obtained from the user.
In addition, the following parameters are optional:
DIRECTORY -- A directory from which the data named by NAME should
be retrieved.
MODE -- A case-insensitive string indicating the mode to be used
when retrieving the information. The legal values for access-type
"TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the
TFTP protocol [RFC-783]. The legal values for access-type "FTP"
are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a
decimal integer, typically 8. These correspond to the
representation types "A" "E" "I" and "L n" as specified by the FTP
protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid
values for MODE, but that "OCTET" or "IMAGE" or "LOCAL8" should be
used instead. IF MODE is not specified, the default value is
"NETASCII" for TFTP and "ASCII" otherwise.
7.3.3.2. The "anon-ftp" access-type
The "anon-ftp" access-type is identical to the "ftp" access type,
except that the user need not be asked to provide a name and password
for the specified site. Instead, the ftp protocol will be used with
login "anonymous" and a password that corresponds to the user's email
address.
7.3.3.3. The "local-file" and "afs" access-types
An access-type of "local-file" indicates that the actual body is
accessible as a file on the local machine. An access-type of "afs"
indicates that the file is accessible via the global AFS file system.
In both cases, only a single parameter is required:
NAME -- The name of the file that contains the actual body data.
The following optional parameter may be used to describe the locality
of reference for the data, that is, the site or sites at which the
file is expected to be visible:
SITE -- A domain specifier for a machine or set of machines that
are known to have access to the data file. Asterisks may be used
for wildcard matching to a part of a domain name, such as
"*.bellcore.com", to indicate a set of machines on which the data
should be directly visible, while a single asterisk may be used to
indicate a file that is expected to be universally available,
e.g., via a global file system.
7.3.3.4. The "mail-server" access-type
The "mail-server" access-type indicates that the actual body is
available from a mail server. The mandatory parameter for this
access-type is:
SERVER -- The email address of the mail server from which the
actual body data can be obtained.
Because mail servers accept a variety of syntaxes, some of which is
multiline, the full command to be sent to a mail server is not
included as a parameter on the content-type line. Instead, it is
provided as the "phantom body" when the content-type is
message/external-body and the access- type is mail-server.
An optional parameter for this access-type is:
SUBJECT -- The subject that is to be used in the mail that is sent
to obtain the data. Note that keying mail servers on Subject lines
is NOT recommended, but such mail servers are known to exist.
Note that MIME does not define a mail server syntax. Rather, it
allows the inclusion of arbitrary mail server commands in the phantom
body. Implementations must include the phantom body in the body of
the message it sends to the mail server address to retrieve the
relevant data.
It is worth noting that, unlike other access-types, mail-server
access is asynchronous and will happen at an unpredictable time in
the future. For this reason, it is important that there be a
mechanism by which the returned data can be matched up with the
original message/external-body entity. MIME mailservers must use the
same Content-ID field on the returned message that was used in the
original message/external-body entity, to facilitate such matching.
7.3.3.5. Examples and Further Explanations
With the emerging possibility of very wide-area file systems, it
becomes very hard to know in advance the set of machines where a file
will and will not be accessible directly from the file system.
Therefore it may make sense to provide both a file name, to be tried
directly, and the name of one or more sites from which the file is
known to be accessible. An implementation can try to retrieve remote
files using FTP or any other protocol, using anonymous file retrieval
or prompting the user for the necessary name and password. If an
external body is accessible via multiple mechanisms, the sender may
include multiple parts of type message/external-body within an entity
of type multipart/alternative.
However, the external-body mechanism is not intended to be limited to
file retrieval, as shown by the mail-server access-type. Beyond
this, one can imagine, for example, using a video server for external
references to video clips.
If an entity is of type "message/external-body", then the body of the
entity will contain the header fields of the encapsulated message.
The body itself is to be found in the external location. This means
that if the body of the "message/external-body" message contains two
consecutive CRLFs, everything after those pairs is NOT part of the
message itself. For most message/external-body messages, this
trailing area must simply be ignored. However, it is a convenient
place for additional data that cannot be included in the content-type
header field. In particular, if the "access-type" value is "mail-
server", then the trailing area must contain commands to be sent to
the mail server at the address given by the value of the SERVER
parameter.
The embedded message header fields which appear in the body of the
message/external-body data must be used to declare the Content-type
of the external body if it is anything other than plain ASCII text,
since the external body does not have a header section to declare its
type. Similarly, any Content-transfer-encoding other than "7bit"
must also be declared here. Thus a complete message/external-body
message, referring to a document in PostScript format, might look
like this:
From: Whomever
To: Someone
Subject: whatever
MIME-Version: 1.0
Message-ID: <id1@host.com>
Content-Type: multipart/alternative; boundary=42
Content-ID: <id001@guppylake.bellcore.com>
--42
Content-Type: message/external-body;
name="BodyFormats.ps";
site="thumper.bellcore.com";
access-type=ANON-FTP;
directory="pub";
mode="image";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
Content-ID: <id42@guppylake.bellcore.com>
--42
Content-Type: message/external-body;
name="/u/nsb/writing/rfcs/RFC-MIME.ps";
site="thumper.bellcore.com";
access-type=AFS
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
Content-ID: <id42@guppylake.bellcore.com>
--42
Content-Type: message/external-body;
access-type=mail-server
server="listserv@bogus.bitnet";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
Content-ID: <id42@guppylake.bellcore.com>
get RFC-MIME.DOC
--42--
Note that in the above examples, the default Content-transfer-
encoding of "7bit" is assumed for the external postscript data.
Like the message/partial type, the message/external-body type is
intended to be transparent, that is, to convey the data type in the
external body rather than to convey a message with a body of that
type. Thus the headers on the outer and inner parts must be merged
using the same rules as for message/partial. In particular, this
means that the Content-type header is overridden, but the From and
Subject headers are preserved.
Note that since the external bodies are not transported as mail, they
need not conform to the 7-bit and line length requirements, but might
in fact be binary files. Thus a Content-Transfer-Encoding is not
generally necessary, though it is permitted.
Note that the body of a message of type "message/external-body" is
governed by the basic syntax for an RFC822 message. In particular,
anything before the first consecutive pair of CRLFs is header
information, while anything after it is body information, which is
ignored for most access-types.
The formal grammar for content-type header fields for data of type
message is given by:
message-type := "message" "/" message-subtype
message-subtype := "rfc822"
/ "partial" 2#3partial-param
/ "external-body" 1*external-param
/ extension-token
partial-param := (";" "id" "=" value)
/ (";" "number" "=" 1*DIGIT)
/ (";" "total" "=" 1*DIGIT)
; id & number required; total required for last part
external-param := (";" "access-type" "=" atype)
/ (";" "expiration" "=" date-time)
; Note that date-time is quoted
/ (";" "size" "=" 1*DIGIT)
/ (";" "permission" "=" ("read" / "read-write"))
; Permission is case-insensitive
/ (";" "name" "=" value)
/ (";" "site" "=" value)
/ (";" "dir" "=" value)
/ (";" "mode" "=" value)
/ (";" "server" "=" value)
/ (";" "subject" "=" value)
; access-type required;others required based on access-type
atype := "ftp" / "anon-ftp" / "tftp" / "local-file"
/ "afs" / "mail-server" / extension-token
; Case-insensitive
7.4. The Application Content-Type
The "application" Content-Type is to be used for data which do not
fit in any of the other categories, and particularly for data to be
processed by mail-based uses of application programs. This is
information which must be processed by an application before it is
viewable or usable to a user. Expected uses for Content-Type
application include mail-based file transfer, spreadsheets, data for
mail-based scheduling systems, and languages for "active"
(computational) email. (The latter, in particular, can pose security
problems which must be understood by implementors, and are considered
in detail in the discussion of the application/PostScript content-
type.)
For example, a meeting scheduler might define a standard
representation for information about proposed meeting dates. An
intelligent user agent would use this information to conduct a dialog
with the user, and might then send further mail based on that dialog.
More generally, there have been several "active" messaging languages
developed in which programs in a suitably specialized language are
sent through the mail and automatically run in the recipient's
environment.
Such applications may be defined as subtypes of the "application"
Content-Type. This document defines two subtypes: octet-stream, and
PostScript.
In general, the subtype of application will often be the name of the
application for which the data are intended. This does not mean,
however, that any application program name may be used freely as a
subtype of application. Such usages (other than subtypes beginning
with "x-") must be registered with IANA, as described in Appendix E.
7.4.1. The Application/Octet-Stream (primary) subtype
The primary subtype of application, "octet-stream", may be used to
indicate that a body contains binary data. The set of possible
parameters includes, but is not limited to:
TYPE -- the general type or category of binary data. This is
intended as information for the human recipient rather than for
any automatic processing.
PADDING -- the number of bits of padding that were appended to the
bit-stream comprising the actual contents to produce the enclosed
byte-oriented data. This is useful for enclosing a bit-stream in
a body when the total number of bits is not a multiple of the byte
size.
An additional parameter, "conversions", was defined in [RFC-1341] but
has been removed.
RFC1341 also defined the use of a "NAME" parameter which gave a
suggested file name to be used if the data were to be written to a
file. This has been deprecated in anticipation of a separate
Content-Disposition header field, to be defined in a subsequent RFC.
The recommended action for an implementation that receives
application/octet-stream mail is to simply offer to put the data in a
file, with any Content-Transfer-Encoding undone, or perhaps to use it
as input to a user-specified process.
To reduce the danger of transmitting rogue programs through the mail,
it is strongly recommended that implementations NOT implement a
path-search mechanism whereby an arbitrary program named in the
Content-Type parameter (e.g., an "interpreter=" parameter) is found
and executed using the mail body as input.
7.4.2. The Application/PostScript subtype
A Content-Type of "application/postscript" indicates a PostScript
program. Currently two variants of the PostScript language are
allowed; the original level 1 variant is described in [POSTSCRIPT]
and the more recent level 2 variant is described in [POSTSCRIPT2].
PostScript is a registered trademark of Adobe Systems, Inc. Use of
the MIME content-type "application/postscript" implies recognition of
that trademark and all the rights it entails.
The PostScript language definition provides facilities for internal
labeling of the specific language features a given program uses. This
labeling, called the PostScript document structuring conventions, is
very general and provides substantially more information than just
the language level.
The use of document structuring conventions, while not required, is
strongly recommended as an aid to interoperability. Documents which
lack proper structuring conventions cannot be tested to see whether
or not they will work in a given environment. As such, some systems
may assume the worst and refuse to process unstructured documents.
The execution of general-purpose PostScript interpreters entails
serious security risks, and implementors are discouraged from simply
sending PostScript email bodies to "off-the-shelf" interpreters.
While it is usually safe to send PostScript to a printer, where the
potential for harm is greatly constrained, implementors should
consider all of the following before they add interactive display of
PostScript bodies to their mail readers.
The remainder of this section outlines some, though probably not all,
of the possible problems with sending PostScript through the mail.
Dangerous operations in the PostScript language include, but may not
be limited to, the PostScript operators deletefile, renamefile,
filenameforall, and file. File is only dangerous when applied to
something other than standard input or output. Implementations may
also define additional nonstandard file operators; these may also
pose a threat to security. Filenameforall, the wildcard file search
operator, may appear at first glance to be harmless. Note, however,
that this operator has the potential to reveal information about what
files the recipient has access to, and this information may itself be
sensitive. Message senders should avoid the use of potentially
dangerous file operators, since these operators are quite likely to
be unavailable in secure PostScript implementations. Message-
receiving and -displaying software should either completely disable
all potentially dangerous file operators or take special care not to
delegate any special authority to their operation. These operators
should be viewed as being done by an outside agency when interpreting
PostScript documents. Such disabling and/or checking should be done
completely outside of the reach of the PostScript language itself;
care should be taken to insure that no method exists for re-enabling
full-function versions of these operators.
The PostScript language provides facilities for exiting the normal
interpreter, or server, loop. Changes made in this "outer"
environment are customarily retained across documents, and may in
some cases be retained semipermanently in nonvolatile memory. The
operators associated with exiting the interpreter loop have the
potential to interfere with subsequent document processing. As such,
their unrestrained use constitutes a threat of service denial.
PostScript operators that exit the interpreter loop include, but may
not be limited to, the exitserver and startjob operators. Message-
sending software should not generate PostScript that depends on
exiting the interpreter loop to operate. The ability to exit will
probably be unavailable in secure PostScript implementations.
Message-receiving and -displaying software should, if possible,
disable the ability to make retained changes to the PostScript
environment, and eliminate the startjob and exitserver commands. If
these commands cannot be eliminated, the password associated with
them should at least be set to a hard-to-guess value.
PostScript provides operators for setting system-wide and device-
specific parameters. These parameter settings may be retained across
jobs and may potentially pose a threat to the correct operation of
the interpreter. The PostScript operators that set system and device
parameters include, but may not be limited to, the setsystemparams
and setdevparams operators. Message-sending software should not
generate PostScript that depends on the setting of system or device
parameters to operate correctly. The ability to set these parameters
will probably be unavailable in secure PostScript implementations.
Message-receiving and -displaying software should, if possible,
disable the ability to change system and device parameters. If these
operators cannot be disabled, the password associated with them
should at least be set to a hard-to-guess value.
Some PostScript implementations provide nonstandard facilities for
the direct loading and execution of machine code. Such facilities
are quite obviously open to substantial abuse. Message-sending
software should not make use of such features. Besides being totally
hardware- specific, they are also likely to be unavailable in secure
implementations of PostScript. Message-receiving and -displaying
software should not allow such operators to be used if they exist.
PostScript is an extensible language, and many, if not most,
implementations of it provide a number of their own extensions. This
document does not deal with such extensions explicitly since they
constitute an unknown factor. Message-sending software should not
make use of nonstandard extensions; they are likely to be missing
from some implementations. Message-receiving and -displaying software
should make sure that any nonstandard PostScript operators are secure
and don't present any kind of threat.
It is possible to write PostScript that consumes huge amounts of
various system resources. It is also possible to write PostScript
programs that loop infinitely. Both types of programs have the
potential to cause damage if sent to unsuspecting recipients.
Message-sending software should avoid the construction and
dissemination of such programs, which is antisocial. Message-
receiving and -displaying software should provide appropriate
mechanisms to abort processing of a document after a reasonable
amount of time has elapsed. In addition, PostScript interpreters
should be limited to the consumption of only a reasonable amount of
any given system resource.
Finally, bugs may exist in some PostScript interpreters which could
possibly be exploited to gain unauthorized access to a recipient's
system. Apart from noting this possibility, there is no specific
action to take to prevent this, apart from the timely correction of
such bugs if any are found.
7.4.3. Other Application subtypes
It is expected that many other subtypes of application will be
defined in the future. MIME implementations must generally treat any
unrecognized subtypes as being equivalent to application/octet-
stream.
The formal grammar for content-type header fields for application
data is given by:
application-type := "application" "/" application-subtype
application-subtype := ("octet-stream" *stream-param)
/ "postscript" / extension-token
stream-param := (";" "type" "=" value)
/ (";" "padding" "=" padding)
padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"
7.5. The Image Content-Type
A Content-Type of "image" indicates that the body contains an image.
The subtype names the specific image format. These names are case
insensitive. Two initial subtypes are "jpeg" for the JPEG format,
JFIF encoding, and "gif" for GIF format [GIF].
The list of image subtypes given here is neither exclusive nor
exhaustive, and is expected to grow as more types are registered with
IANA, as described in Appendix E.
The formal grammar for the content-type header field for data of type
image is given by:
image-type := "image" "/" ("gif" / "jpeg" / extension-token)
7.6. The Audio Content-Type
A Content-Type of "audio" indicates that the body contains audio
data. Although there is not yet a consensus on an "ideal" audio
format for use with computers, there is a pressing need for a format
capable of providing interoperable behavior.
The initial subtype of "basic" is specified to meet this requirement
by providing an absolutely minimal lowest common denominator audio
format. It is expected that richer formats for higher quality and/or
lower bandwidth audio will be defined by a later document.
The content of the "audio/basic" subtype is audio encoded using 8-bit
ISDN mu-law [PCM]. When this subtype is present, a sample rate of
8000 Hz and a single channel is assumed.
The formal grammar for the content-type header field for data of type
audio is given by:
audio-type := "audio" "/" ("basic" / extension-token)
7.7. The Video Content-Type
A Content-Type of "video" indicates that the body contains a time-
varying-picture image, possibly with color and coordinated sound.
The term "video" is used extremely generically, rather than with
reference to any particular technology or format, and is not meant to
preclude subtypes such as animated drawings encoded compactly. The
subtype "mpeg" refers to video coded according to the MPEG standard
[MPEG].
Note that although in general this document strongly discourages the
mixing of multiple media in a single body, it is recognized that many
so-called "video" formats include a representation for synchronized
audio, and this is explicitly permitted for subtypes of "video".
The formal grammar for the content-type header field for data of type
video is given by:
video-type := "video" "/" ("mpeg" / extension-token)
7.8. Experimental Content-Type Values
A Content-Type value beginning with the characters "X-" is a private
value, to be used by consenting mail systems by mutual agreement.
Any format without a rigorous and public definition must be named
with an "X-" prefix, and publicly specified values shall never begin
with "X-". (Older versions of the widely-used Andrew system use the
"X-BE2" name, so new systems should probably choose a different
name.)
In general, the use of "X-" top-level types is strongly discouraged.
Implementors should invent subtypes of the existing types whenever
possible. The invention of new types is intended to be restricted
primarily to the development of new media types for email, such as
digital odors or holography, and not for new data formats in general.
In many cases, a subtype of application will be more appropriate than
a new top-level type.
8. Summary
Using the MIME-Version, Content-Type, and Content-Transfer-Encoding
header fields, it is possible to include, in a standardized way,
arbitrary types of data objects with RFC822 conformant mail
messages. No restrictions imposed by either RFC821 or RFC822 are
violated, and care has been taken to avoid problems caused by
additional restrictions imposed by the characteristics of some
Internet mail transport mechanisms (see Appendix B). The "multipart"
and "message" Content-Types allow mixing and hierarchical structuring
of objects of different types in a single message. Further Content-
Types provide a standardized mechanism for tagging messages or body
parts as audio, image, or several other kinds of data. A
distinguished parameter syntax allows further specification of data
format details, particularly the specification of alternate character
sets. Additional optional header fields provide mechanisms for
certain extensions deemed desirable by many implementors. Finally, a
number of useful Content-Types are defined for general use by
consenting user agents, notably message/partial, and
message/external-body.
9. Security Considerations
Security issues are discussed in Section 7.4.2 and in Appendix F.
Implementors should pay special attention to the security
implications of any mail content-types that can cause the remote
execution of any actions in the recipient's environment. In such
cases, the discussion of the application/postscript content-type in
Section 7.4.2 may serve as a model for considering other content-
types with remote execution capabilities.
10. Authors' Addresses
For more information, the authors of this document may be contacted
via Internet mail:
Nathaniel S. Borenstein
MRE 2D-296, Bellcore
445 South St.
Morristown, NJ 07962-1910
Phone: +1 201 829 4270
Fax: +1 201 829 7019
Email: nsb@bellcore.com
Ned Freed
Innosoft International, Inc.
250 West First Street
Suite 240
Claremont, CA 91711
Phone: +1 909 624 7907
Fax: +1 909 621 5319
Email: ned@innosoft.com
MIME is a result of the work of the Internet Engineering Task Force
Working Group on Email Extensions. The chairman of that group, Greg
Vaudreuil, may be reached at:
Gregory M. Vaudreuil
Tigon Corporation
17060 Dallas Parkway
Dallas Texas, 75248
Phone: +1 214-733-2722
EMail: gvaudre@cnri.reston.va.us
11. Acknowledgements
This document is the result of the collective effort of a large
number of people, at several IETF meetings, on the IETF-SMTP and
IETF-822 mailing lists, and elsewhere. Although any enumeration
seems doomed to suffer from egregious omissions, the following are
among the many contributors to this effort:
Harald Tveit Alvestrand Timo Lehtinen
Randall Atkinson John R. MacMillan
Philippe Brandon Rick McGowan
Kevin Carosso Leo Mclaughlin
Uhhyung Choi Goli Montaser-Kohsari
Cristian Constantinof Keith Moore
Mark Crispin Tom Moore
Dave Crocker Erik Naggum
Terry Crowley Mark Needleman
Walt Daniels John Noerenberg
Frank Dawson Mats Ohrman
Hitoshi Doi Julian Onions
Kevin Donnelly Michael Patton
Keith Edwards David J. Pepper
Chris Eich Blake C. Ramsdell
Johnny Eriksson Luc Rooijakkers
Craig Everhart Marshall T. Rose
Patrik Faeltstroem Jonathan Rosenberg
Erik E. Fair Jan Rynning
Roger Fajman Harri Salminen
Alain Fontaine Michael Sanderson
James M. Galvin Masahiro Sekiguchi
Philip Gladstone Mark Sherman
Thomas Gordon Keld Simonsen
Phill Gross Bob Smart
James Hamilton Peter Speck
Steve Hardcastle-Kille Henry Spencer
David Herron Einar Stefferud
Bruce Howard Michael Stein
Bill Janssen Klaus Steinberger
Olle Jaernefors Peter Svanberg
Risto Kankkunen James Thompson
Phil Karn Steve Uhler
Alan Katz Stuart Vance
Tim Kehres Erik van der Poel
Neil Katin Guido van Rossum
Kyuho Kim Peter Vanderbilt
Anders Klemets Greg Vaudreuil
John Klensin Ed Vielmetti
Valdis Kletniek Ryan Waldron
Jim Knowles Wally Wedel
Stev Knowles Sven-Ove Westberg
Bob Kummerfeld Brian Wideen
Pekka Kytolaakso John Wobus
Stellan Lagerstrom Glenn Wright
Vincent Lau Rayan Zachariassen
Donald Lindsay David Zimmerman
Marc Andreessen Bob Braden
Brian Capouch Peter Clitherow
Dave Collier-Brown John Coonrod
Stephen Crocker Jim Davis
Axel Deininger Dana S Emery
Martin Forssen Stephen Gildea
Terry Gray Mark Horton
Warner Losh Carlyn Lowery
Laurence Lundblade Charles Lynn
Larry Masinter Michael J. McInerny
Jon Postel Christer Romson
Yutaka Sato Markku Savela
Richard Alan Schafer Larry W. Virden
Rhys Weatherly Jay Weber
Dave Wecker
The authors apologize for any omissions from this list, which are
certainly unintentional.
Appendix A -- Minimal MIME-Conformance
The mechanisms described in this document are open-ended. It is
definitely not expected that all implementations will support all of
the Content-Types described, nor that they will all share the same
extensions. In order to promote interoperability, however, it is
useful to define the concept of "MIME-conformance" to define a
certain level of implementation that allows the useful interworking
of messages with content that differs from US ASCII text. In this
section, we specify the requirements for such conformance.
A mail user agent that is MIME-conformant MUST:
1. Always generate a "MIME-Version: 1.0" header field.
2. Recognize the Content-Transfer-Encoding header field, and
decode all received data encoded with either the quoted-printable
or base64 implementations. Encode any data sent that is not in
seven-bit mail-ready representation using one of these
transformations and include the appropriate Content-Transfer-
Encoding header field, unless the underlying transport mechanism
supports non-seven-bit data, as SMTP does not.
3. Recognize and interpret the Content-Type header field, and
avoid showing users raw data with a Content-Type field other than
text. Be able to send at least text/plain messages, with the
character set specified as a parameter if it is not US-ASCII.
4. Explicitly handle the following Content-Type values, to at
least the following extents:
Text:
-- Recognize and display "text" mail
with the character set "US-ASCII."
-- Recognize other character sets at
least to the extent of being able
to inform the user about what
character set the message uses.
-- Recognize the "ISO-8859-*" character
sets to the extent of being able to
display those characters that are
common to ISO-8859-* and US-ASCII,
namely all characters represented
by octet values 0-127.
-- For unrecognized subtypes, show or
offer to show the user the "raw"
version of the data after
conversion of the content from
canonical form to local form.
Message:
-- Recognize and display at least the
primary (822) encapsulation.
Multipart:
-- Recognize the primary (mixed)
subtype. Display all relevant
information on the message level
and the body part header level and
then display or offer to display
each of the body parts individually.
-- Recognize the "alternative" subtype,
and avoid showing the user
redundant parts of
multipart/alternative mail.
-- Treat any unrecognized subtypes as if
they were "mixed".
Application:
-- Offer the ability to remove either of
the two types of Content-Transfer-
Encoding defined in this document
and put the resulting information
in a user file.
5. Upon encountering any unrecognized Content- Type, an
implementation must treat it as if it had a Content-Type of
"application/octet-stream" with no parameter sub-arguments. How
such data are handled is up to an implementation, but likely
options for handling such unrecognized data include offering the
user to write it into a file (decoded from its mail transport
format) or offering the user to name a program to which the
decoded data should be passed as input. Unrecognized predefined
types, which in a MIME-conformant mailer might still include
audio, image, or video, should also be treated in this way.
A user agent that meets the above conditions is said to be MIME-
conformant. The meaning of this phrase is that it is assumed to be
"safe" to send virtually any kind of properly-marked data to users of
such mail systems, because such systems will at least be able to
treat the data as undifferentiated binary, and will not simply splash
it onto the screen of unsuspecting users. There is another sense in
which it is always "safe" to send data in a format that is MIME-
conformant, which is that such data will not break or be broken by
any known systems that are conformant with RFC821 and RFC822. User
agents that are MIME-conformant have the additional guarantee that
the user will not be shown data that were never intended to be viewed
as text.
Appendix B -- General Guidelines For Sending Email Data
Internet email is not a perfect, homogeneous system. Mail may become
corrupted at several stages in its travel to a final destination.
Specifically, email sent throughout the Internet may travel across
many networking technologies. Many networking and mail technologies
do not support the full functionality possible in the SMTP transport
environment. Mail traversing these systems is likely to be modified
in such a way that it can be transported.
There exist many widely-deployed non-conformant MTAs in the Internet.
These MTAs, speaking the SMTP protocol, alter messages on the fly to
take advantage of the internal data structure of the hosts they are
implemented on, or are just plain broken.
The following guidelines may be useful to anyone devising a data
format (Content-Type) that will survive the widest range of
networking technologies and known broken MTAs unscathed. Note that
anything encoded in the base64 encoding will satisfy these rules, but
that some well-known mechanisms, notably the UNIX uuencode facility,
will not. Note also that anything encoded in the Quoted-Printable
encoding will survive most gateways intact, but possibly not some
gateways to systems that use the EBCDIC character set.
(1) Under some circumstances the encoding used for data may change
as part of normal gateway or user agent operation. In particular,
conversion from base64 to quoted-printable and vice versa may be
necessary. This may result in the confusion of CRLF sequences with
line breaks in text bodies. As such, the persistence of CRLF as
something other than a line break must not be relied on.
(2) Many systems may elect to represent and store text data using
local newline conventions. Local newline conventions may not match
the RFC822 CRLF convention -- systems are known that use plain CR,
plain LF, CRLF, or counted records. The result is that isolated
CR and LF characters are not well tolerated in general; they may
be lost or converted to delimiters on some systems, and hence must
not be relied on.
(3) TAB (HT) characters may be misinterpreted or may be
automatically converted to variable numbers of spaces. This is
unavoidable in some environments, notably those not based on the
ASCII character set. Such conversion is STRONGLY DISCOURAGED, but
it may occur, and mail formats must not rely on the persistence of
TAB (HT) characters.
(4) Lines longer than 76 characters may be wrapped or truncated in
some environments. Line wrapping and line truncation are STRONGLY
DISCOURAGED, but unavoidable in some cases. Applications which
require long lines must somehow differentiate between soft and
hard line breaks. (A simple way to do this is to use the quoted-
printable encoding.)
(5) Trailing "white space" characters (SPACE, TAB (HT)) on a line
may be discarded by some transport agents, while other transport
agents may pad lines with these characters so that all lines in a
mail file are of equal length. The persistence of trailing white
space, therefore, must not be relied on.
(6) Many mail domains use variations on the ASCII character set,
or use character sets such as EBCDIC which contain most but not
all of the US-ASCII characters. The correct translation of
characters not in the "invariant" set cannot be depended on across
character converting gateways. For example, this situation is a
problem when sending uuencoded information across BITNET, an
EBCDIC system. Similar problems can occur without crossing a
gateway, since many Internet hosts use character sets other than
ASCII internally. The definition of Printable Strings in X.400
adds further restrictions in certain special cases. In
particular, the only characters that are known to be consistent
across all gateways are the 73 characters that correspond to the
upper and lower case letters A-Z and a-z, the 10 digits 0-9, and
the following eleven special characters:
"'" (ASCII code 39)
"(" (ASCII code 40)
")" (ASCII code 41)
"+" (ASCII code 43)
"," (ASCII code 44)
"-" (ASCII code 45)
"." (ASCII code 46)
"/" (ASCII code 47)
":" (ASCII code 58)
"=" (ASCII code 61)
"?" (ASCII code 63)
A maximally portable mail representation, such as the base64
encoding, will confine itself to relatively short lines of text in
which the only meaningful characters are taken from this set of 73
characters.
(7) Some mail transport agents will corrupt data that includes
certain literal strings. In particular, a period (".") alone on a
line is known to be corrupted by some (incorrect) SMTP
implementations, and a line that starts with the five characters
"From " (the fifth character is a SPACE) are commonly corrupted as
well. A careful composition agent can prevent these corruptions