NOTE: The CRLF preceding the boundary delimiter line is conceptually
attached to the boundary so that it is possible to have a part that
does not end with a CRLF (line break). Body parts that must be
considered to end with line breaks, therefore, must have two CRLFs
preceding the boundary delimiter line, the first of which is part of
the preceding body part, and the second of which is part of the
encapsulation boundary.
Boundary delimiters must not appear within the encapsulated material,
and must be no longer than 70 characters, not counting the two
leading hyphens.
The boundary delimiter line following the last body part is a
distinguished delimiter that indicates that no further body parts
will follow. Such a delimiter line is identical to the previous
delimiter lines, with the addition of two more hyphens after the
boundary parameter value.
--gc0pJq0M:08jU534c0p--
NOTE TO IMPLEMENTORS: Boundary string comparisons must compare the
boundary value with the beginning of each candidate line. An exact
match of the entire candidate line is not required; it is sufficient
that the boundary appear in its entirety following the CRLF.
There appears to be room for additional information prior to the
first boundary delimiter line and following the final boundary
delimiter line. These areas should generally be left blank, and
implementations must ignore anything that appears before the first
boundary delimiter line or after the last one.
NOTE: These "preamble" and "epilogue" areas are generally not used
because of the lack of proper typing of these parts and the lack of
clear semantics for handling these areas at gateways, particularly
X.400 gateways. However, rather than leaving the preamble area
blank, many MIME implementations have found this to be a convenient
place to insert an explanatory note for recipients who read the
message with pre-MIME software, since such notes will be ignored by
MIME-compliant software.
NOTE: Because boundary delimiters must not appear in the body parts
being encapsulated, a user agent must exercise care to choose a
unique boundary parameter value. The boundary parameter value in the
example above could have been the result of an algorithm designed to
produce boundary delimiters with a very low probability of already
existing in the data to be encapsulated without having to prescan the
data. Alternate algorithms might result in more "readable" boundary
delimiters for a recipient with an old user agent, but would require
more attention to the possibility that the boundary delimiter might
appear at the beginning of some line in the encapsulated part. The
simplest boundary delimiter line possible is something like "---",
with a closing boundary delimiter line of "-----".
As a very simple example, the following multipart message has two
parts, both of them plain text, one of them explicitly typed and one
of them implicitly typed:
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary"
This is the preamble. It is to be ignored, though it
is a handy place for composition agents to include an
explanatory note to non-MIME conformant readers.
--simple boundary
This is implicitly typed plain US-ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii
This is explicitly typed plain US-ASCII text.
It DOES end with a linebreak.
--simple boundary--
This is the epilogue. It is also to be ignored.
The use of a media type of "multipart" in a body part within another
"multipart" entity is explicitly allowed. In such cases, for obvious
reasons, care must be taken to ensure that each nested "multipart"
entity uses a different boundary delimiter. See RFC2049 for an
example of nested "multipart" entities.
The use of the "multipart" media type with only a single body part
may be useful in certain contexts, and is explicitly permitted.
NOTE: Experience has shown that a "multipart" media type with a
single body part is useful for sending non-text media types. It has
the advantage of providing the preamble as a place to include
decoding instructions. In addition, a number of SMTP gateways move
or remove the MIME headers, and a clever MIME decoder can take a good
guess at multipart boundaries even in the absence of the Content-Type
header and thereby successfully decode the message.
The only mandatory global parameter for the "multipart" media type is
the boundary parameter, which consists of 1 to 70 characters from a
set of characters known to be very robust through mail gateways, and
NOT ending with white space. (If a boundary delimiter line appears to
end with white space, the white space must be presumed to have been
added by a gateway, and must be deleted.) It is formally specified
by the following BNF:
boundary := 0*69<bchars> bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
"+" / "_" / "," / "-" / "." /
"/" / ":" / "=" / "?"
Overall, the body of a "multipart" entity may be specified as
follows:
dash-boundary := "--" boundary
; boundary taken from the value of
; boundary parameter of the
; Content-Type field.
multipart-body := [preamble CRLF]
dash-boundary transport-padding CRLF
body-part *encapsulation
close-delimiter transport-padding
[CRLF epilogue]
transport-padding := *LWSP-char
; Composers MUST NOT generate
; non-zero length transport
; padding, but receivers MUST
; be able to handle padding
; added by message transports.
encapsulation := delimiter transport-padding
CRLF body-part
delimiter := CRLF dash-boundary
close-delimiter := delimiter "--"
preamble := discard-text
epilogue := discard-text
discard-text := *(*text CRLF) *text
; May be ignored or discarded.
body-part := MIME-part-headers [CRLF *OCTET]
; Lines in a body-part must not start
; with the specified dash-boundary and
; the delimiter must not appear anywhere
; in the body part. Note that the
; semantics of a body-part differ from
; the semantics of a message, as
; described in the text.
OCTET := <any 0-255 octet value>
IMPORTANT: The free insertion of linear-white-space and RFC822
comments between the elements shown in this BNF is NOT allowed since
this BNF does not specify a structured header field.
NOTE: In certain transport enclaves, RFC822 restrictions such as
the one that limits bodies to printable US-ASCII characters may not
be in force. (That is, the transport domains may exist that resemble
standard Internet mail transport as specified in RFC821 and assumed
by RFC822, but without certain restrictions.) The relaxation of
these restrictions should be construed as locally extending the
definition of bodies, for example to include octets outside of the
US-ASCII range, as long as these extensions are supported by the
transport and adequately documented in the Content- Transfer-Encoding
header field. However, in no event are headers (either message
headers or body part headers) allowed to contain anything other than
US-ASCII characters.
NOTE: Conspicuously missing from the "multipart" type is a notion of
structured, related body parts. It is recommended that those wishing
to provide more structured or integrated multipart messaging
facilities should define subtypes of multipart that are syntactically
identical but define relationships between the various parts. For
example, subtypes of multipart could be defined that include a
distinguished part which in turn is used to specify the relationships
between the other parts, probably referring to them by their
Content-ID field. Old implementations will not recognize the new
subtype if this approach is used, but will treat it as
multipart/mixed and will thus be able to show the user the parts that
are recognized.
5.1.2. Handling Nested Messages and Multiparts
The "message/rfc822" subtype defined in a subsequent section of this
document has no terminating condition other than running out of data.
Similarly, an improperly truncated "multipart" entity may not have
any terminating boundary marker, and can turn up operationally due to
mail system malfunctions.
It is essential that such entities be handled correctly when they are
themselves imbedded inside of another "multipart" structure. MIME
implementations are therefore required to recognize outer level
boundary markers at ANY level of inner nesting. It is not sufficient
to only check for the next expected marker or other terminating
condition.
5.1.3. Mixed Subtype
The "mixed" subtype of "multipart" is intended for use when the body
parts are independent and need to be bundled in a particular order.
Any "multipart" subtypes that an implementation does not recognize
must be treated as being of subtype "mixed".
5.1.4. Alternative Subtype
The "multipart/alternative" type is syntactically identical to
"multipart/mixed", but the semantics are different. In particular,
each of the body parts is an "alternative" version of the same
information.
Systems should recognize that the content of the various parts are
interchangeable. Systems should choose the "best" type based on the
local environment and references, in some cases even through user
interaction. As with "multipart/mixed", the order of body parts is
significant. In this case, the alternatives appear in an order of
increasing faithfulness to the original content. In general, the
best choice is the LAST part of a type supported by the recipient
system's local environment.
"Multipart/alternative" may be used, for example, to send a message
in a fancy text format in such a way that it can easily be displayed
anywhere:
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
... plain text version of message goes here ...
--boundary42
Content-Type: text/enriched
... RFC1896 text/enriched version of same message
goes here ...
--boundary42
Content-Type: application/x-whatever
... fanciest version of same message goes here ...
--boundary42--
In this example, users whose mail systems understood the
"application/x-whatever" format would see only the fancy version,
while other users would see only the enriched or plain text version,
depending on the capabilities of their system.
In general, user agents that compose "multipart/alternative" entities
must place the body parts in increasing order of preference, that is,
with the preferred format last. For fancy text, the sending user
agent should put the plainest format first and the richest format
last. Receiving user agents should pick and display the last format
they are capable of displaying. In the case where one of the
alternatives is itself of type "multipart" and contains unrecognized
sub-parts, the user agent may choose either to show that alternative,
an earlier alternative, or both.
NOTE: From an implementor's perspective, it might seem more sensible
to reverse this ordering, and have the plainest alternative last.
However, placing the plainest alternative first is the friendliest
possible option when "multipart/alternative" entities are viewed
using a non-MIME-conformant viewer. While this approach does impose
some burden on conformant MIME viewers, interoperability with older
mail readers was deemed to be more important in this case.
It may be the case that some user agents, if they can recognize more
than one of the formats, will prefer to offer the user the choice of
which format to view. This makes sense, for example, if a message
includes both a nicely- formatted image version and an easily-edited
text version. What is most critical, however, is that the user not
automatically be shown multiple versions of the same data. Either
the user should be shown the last recognized version or should be
given the choice.
THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each part of a
"multipart/alternative" entity represents the same data, but the
mappings between the two are not necessarily without information
loss. For example, information is lost when translating ODA to
PostScript or plain text. It is recommended that each part should
have a different Content-ID value in the case where the information
content of the two parts is not identical. And when the information
content is identical -- for example, where several parts of type
"message/external-body" specify alternate ways to access the
identical data -- the same Content-ID field value should be used, to
optimize any caching mechanisms that might be present on the
recipient's end. However, the Content-ID values used by the parts
should NOT be the same Content-ID value that describes the
"multipart/alternative" as a whole, if there is any such Content-ID
field. That is, one Content-ID value will refer to the
"multipart/alternative" entity, while one or more other Content-ID
values will refer to the parts inside it.
5.1.5. Digest Subtype
This document defines a "digest" subtype of the "multipart" Content-
Type. This type is syntactically identical to "multipart/mixed", but
the semantics are different. In particular, in a digest, the default
Content-Type value for a body part is changed from "text/plain" to
"message/rfc822". This is done to allow a more readable digest
format that is largely compatible (except for the quoting convention)
with RFC934.
Note: Though it is possible to specify a Content-Type value for a
body part in a digest which is other than "message/rfc822", such as a
"text/plain" part containing a description of the material in the
digest, actually doing so is undesireble. The "multipart/digest"
Content-Type is intended to be used to send collections of messages.
If a "text/plain" part is needed, it should be included as a seperate
part of a "multipart/mixed" message.
A digest in this format might, then, look something like this:
From: Moderator-Address
To: Recipient-List
Date: Mon, 22 Mar 1994 13:34:51 +0000
Subject: Internet Digest, volume 42
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="---- main boundary ----"
------ main boundary ----
...Introductory text or table of contents...
------ main boundary ----
Content-Type: multipart/digest;
boundary="---- next message ----"
------ next message ----
From: someone-else
Date: Fri, 26 Mar 1993 11:13:32 +0200
Subject: my opinion
...body goes here ...
------ next message ----
From: someone-else-again
Date: Fri, 26 Mar 1993 10:07:13 -0500
Subject: my different opinion
... another body goes here ...
------ next message ------
------ main boundary ------
5.1.6. Parallel Subtype
This document defines a "parallel" subtype of the "multipart"
Content-Type. This type is syntactically identical to
"multipart/mixed", but the semantics are different. In particular,
in a parallel entity, the order of body parts is not significant.
A common presentation of this type is to display all of the parts
simultaneously on hardware and software that are capable of doing so.
However, composing agents should be aware that many mail readers will
lack this capability and will show the parts serially in any event.
5.1.7. Other Multipart Subtypes
Other "multipart" subtypes are expected in the future. MIME
implementations must in general treat unrecognized subtypes of
"multipart" as being equivalent to "multipart/mixed".
5.2. Message Media Type
It is frequently desirable, in sending mail, to encapsulate another
mail message. A special media type, "message", is defined to
facilitate this. In particular, the "rfc822" subtype of "message" is
used to encapsulate RFC822 messages.
NOTE: It has been suggested that subtypes of "message" might be
defined for forwarded or rejected messages. However, forwarded and
rejected messages can be handled as multipart messages in which the
first part contains any control or descriptive information, and a
second part, of type "message/rfc822", is the forwarded or rejected
message. Composing rejection and forwarding messages in this manner
will preserve the type information on the original message and allow
it to be correctly presented to the recipient, and hence is strongly
encouraged.
Subtypes of "message" often impose restrictions on what encodings are
allowed. These restrictions are described in conjunction with each
specific subtype.
Mail gateways, relays, and other mail handling agents are commonly
known to alter the top-level header of an RFC822 message. In
particular, they frequently add, remove, or reorder header fields.
These operations are explicitly forbidden for the encapsulated
headers embedded in the bodies of messages of type "message."
5.2.1. RFC822 Subtype
A media type of "message/rfc822" indicates that the body contains an
encapsulated message, with the syntax of an RFC822 message.
However, unlike top-level RFC822 messages, the restriction that each
"message/rfc822" body must include a "From", "Date", and at least one
destination header is removed and replaced with the requirement that
at least one of "From", "Subject", or "Date" must be present.
It should be noted that, despite the use of the numbers "822", a
"message/rfc822" entity isn't restricted to material in strict
conformance to RFC822, nor are the semantics of "message/rfc822"
objects restricted to the semantics defined in RFC822. More
specifically, a "message/rfc822" message could well be a News article
or a MIME message.
No encoding other than "7bit", "8bit", or "binary" is permitted for
the body of a "message/rfc822" entity. The message header fields are
always US-ASCII in any case, and data within the body can still be
encoded, in which case the Content-Transfer-Encoding header field in
the encapsulated message will reflect this. Non-US-ASCII text in the
headers of an encapsulated message can be specified using the
mechanisms described in RFC2047.
5.2.2. Partial Subtype
The "partial" subtype is defined to allow large entities to be
delivered as several separate pieces of mail and automatically
reassembled by a receiving user agent. (The concept is similar to IP
fragmentation and reassembly in the basic Internet Protocols.) This
mechanism can be used when intermediate transport agents limit the
size of individual messages that can be sent. The media type
"message/partial" thus indicates that the body contains a fragment of
a larger entity.
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 8bit
transport. The problem is that the binary data would be split into
multiple "message/partial" messages, each of them requiring binary
transport. If such messages were encountered at a gateway into a
7bit transport environment, there would be no way to properly encode
them for the 7bit world, aside from waiting for all of the fragments,
reassembling the inner message, and then encoding the reassembled
data in base64 or quoted-printable. Since it is possible that
different fragments might go through different gateways, even this is
not an acceptable solution. For this reason, it is specified that
entities of type "message/partial" must always have a content-
transfer-encoding of 7bit (the default). In particular, even in
environments that support binary or 8bit transport, the use of a
content- transfer-encoding of "8bit" or "binary" is explicitly
prohibited for MIME entities of type "message/partial". This in turn
implies that the inner message must not use "8bit" or "binary"
encoding.
Because some message transfer agents may choose to automatically
fragment large messages, and because such agents may use very
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.
Three parameters must be specified in the Content-Type field of type
"message/partial": The first, "id", is a unique identifier, as close
to a world-unique identifier as possible, to be used to match the
fragments together. (In general, the identifier is essentially a
message-id; if placed in double quotes, it can be ANY message-id, in
accordance with the BNF for "parameter" given in RFC2045.) The
second, "number", an integer, is the fragment number, which indicates
where this fragment fits into the sequence of fragments. The third,
"total", another integer, is the total number of fragments. This
third subfield is required on the final fragment, and is optional
(though encouraged) on the earlier fragments. Note also that these
parameters may be given in any order.
Thus, the second piece of a 3-piece message may have either of the
following header fields:
Content-Type: Message/Partial; number=2; total=3;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
Content-Type: Message/Partial;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
number=2
But the third piece MUST specify the total number of fragments:
Content-Type: Message/Partial; number=3; total=3;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
Note that fragment numbering begins with 1, not 0.
When the fragments of an entity broken up in this manner are put
together, the result is always a complete MIME entity, which may have
its own Content-Type header field, and thus may contain any other
data type.
5.2.2.1. Message Fragmentation and Reassembly
The semantics of a reassembled partial message must be those of the
"inner" message, rather than of a message containing the inner
message. This makes it possible, for example, to send a large audio
message as several partial messages, and still have it appear to the
recipient as a simple audio message rather than as an encapsulated
message containing an audio message. That is, the encapsulation of
the message is considered to be "transparent".
When generating and reassembling the pieces of a "message/partial"
message, the headers of the encapsulated message must be merged with
the headers of the enclosing entities. In this process the following
rules must be observed:
(1) Fragmentation agents must split messages at line
boundaries only. This restriction is imposed because
splits at points other than the ends of lines in turn
depends on message transports being able to preserve
the semantics of messages that don't end with a CRLF
sequence. Many transports are incapable of preserving
such semantics.
(2) All of the header fields from the initial enclosing
message, except those that start with "Content-" and
the specific header fields "Subject", "Message-ID",
"Encrypted", and "MIME-Version", must be copied, in
order, to the new message.
(3) The header fields in the enclosed message which start
with "Content-", plus the "Subject", "Message-ID",
"Encrypted", and "MIME-Version" fields, 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 the
"Subject", "Message-ID", "Encrypted", and "MIME-
Version" fields) will be ignored and dropped.
(4) All of the header fields from the second and any
subsequent enclosing messages are discarded by the
reassembly process.
5.2.2.2. Fragmentation and Reassembly Example
If an audio message is broken into two pieces, the first piece might
look something like this:
X-Weird-Header-1: Foo
From: Bill@host.com
To: joe@otherhost.com
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 1 of 2)
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>
Subject: Audio mail
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
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 2 of 2)
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
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
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 ...
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) [RFC-1421,
RFC-1422, RFC-1423, RFC-1424], but the rules above are nevertheless
believed to describe the correct way to treat it if it is encountered
in the context of conversion to and from "message/partial" fragments.
5.2.3. 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 a MIME 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.jpeg"
Content-type: image/jpeg
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". The only access-type defined
in this document that uses the phantom body is "mail-server", but
other access-types may be defined in the future in other
specifications that use this area.
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 caching
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", MIME entities of type "message/external-
body" MUST have a content-transfer-encoding of 7bit (the default).
In particular, even in environments that support binary or 8bit
transport, the use of a content- transfer-encoding of "8bit" or
"binary" is explicitly prohibited for entities of type
"message/external-body".
5.2.3.1. General External-Body Parameters
The parameters that may be used with any "message/external- body"
are:
(1) ACCESS-TYPE -- A word indicating the supported access
mechanism by which the file or data may be obtained.
This word is not case sensitive. Values include, but
are not limited to, "FTP", "ANON-FTP", "TFTP", "LOCAL-
FILE", and "MAIL-SERVER". Future values, except for
experimental values beginning with "X-", must be
registered with IANA, as described in RFC2048.
This parameter is unconditionally mandatory and MUST be
present on EVERY "message/external-body".
(2) 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. This parameter may be
used with ANY access-type and is ALWAYS optional.
(3) 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. This parameter
may be used with ANY access-type and is ALWAYS
optional.
(4) 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. This
parameter may be used with ANY access-type and is
ALWAYS optional.
The precise semantics of the access-types defined here are described
in the sections that follow.
5.2.3.2. 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:
(1) NAME -- The name of the file that contains the actual
body data.
(2) 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.
(3) 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:
(1) DIRECTORY -- A directory from which the data named by
NAME should be retrieved.
(2) MODE -- A case-insensitive string indicating the mode
to be used when retrieving the information. The valid
values for access-type "TFTP" are "NETASCII", "OCTET",
and "MAIL", as specified by the TFTP protocol [RFC-
783]. The valid 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 and 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.
5.2.3.3. 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 mail
address.
5.2.3.4. The 'local-file' Access-Type
An access-type of "local-file" indicates that the actual body is
accessible as a file on the local machine. Two additional parameters
are defined for this access type:
(1) NAME -- The name of the file that contains the actual
body data. This parameter is mandatory for the
"local-file" access-type.
(2) SITE -- A domain specifier for a machine or set of
machines that are known to have access to the data
file. This optional parameter is 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.
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.
5.2.3.5. The 'mail-server' Access-Type
The "mail-server" access-type indicates that the actual body is
available from a mail server. Two additional parameters are defined
for this access-type:
(1) SERVER -- The addr-spec of the mail server from which
the actual body data can be obtained. This parameter
is mandatory for the "mail-server" access-type.
(2) 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. This is an optional
parameter.
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 in the content-type header field. Instead,
it is provided as the "phantom body" when the media type is
"message/external-body" and the access-type is mail-server.
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.
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 mail servers must use the same Content-ID field on the returned
message that was used in the original "message/external-body"
entities, to facilitate such matching.
5.2.3.6. External-Body Security Issues
"Message/external-body" entities give rise to two important security
issues:
(1) Accessing data via a "message/external-body" reference
effectively results in the message recipient performing
an operation that was specified by the message
originator. It is therefore possible for the message
originator to trick a recipient into doing something
they would not have done otherwise. For example, an
originator could specify a action that attempts
retrieval of material that the recipient is not
authorized to obtain, causing the recipient to
unwittingly violate some security policy. For this
reason, user agents capable of resolving external
references must always take steps to describe the
action they are to take to the recipient and ask for
explicit permisssion prior to performing it.
The 'mail-server' access-type is particularly
vulnerable, in that it causes the recipient to send a
new message whose contents are specified by the
original message's originator. Given the potential for
abuse, any such request messages that are constructed
should contain a clear indication that they were
generated automatically (e.g. in a Comments: header
field) in an attempt to resolve a MIME
"message/external-body" reference.
(2) MIME will sometimes be used in environments that
provide some guarantee of message integrity and
authenticity. If present, such guarantees may apply
only to the actual direct content of messages -- they
may or may not apply to data accessed through MIME's
"message/external-body" mechanism. In particular, it
may be possible to subvert certain access mechanisms
even when the messaging system itself is secure.
It should be noted that this problem exists either with
or without the availabilty of MIME mechanisms. A
casual reference to an FTP site containing a document
in the text of a secure message brings up similar
issues -- the only difference is that MIME provides for
automatic retrieval of such material, and users may
place unwarranted trust is such automatic retrieval
mechanisms.
5.2.3.7. Examples and Further Explanations
When the external-body mechanism is used in conjunction with the
"multipart/alternative" media type it extends the functionality of
"multipart/alternative" to include the case where the same entity is
provided in the same format but via different accces mechanisms.
When this is done the originator of the message must order the parts
first in terms of preferred formats and then by preferred access
mechanisms. The recipient's viewer should then evaluate the list
both in terms of format and access mechanisms.
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 entities of type "message/external-body" within the
body parts of an enclosing "multipart/alternative" entity.
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.
The embedded message header fields which appear in the body of the
"message/external-body" data must be used to declare the media type
of the external body if it is anything other than plain US-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 an object in PostScript
format, might look like this:
From: Whomever
To: Someone
Date: Whenever
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"; mode="image";
access-type=ANON-FTP; directory="pub";
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=local-file;
name="/u/nsb/writing/rfcs/RFC-MIME.ps";
site="thumper.bellcore.com";
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" media
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 and Subject fields are overridden,
but the From field is preserved.
Note that since the external bodies are not transported along with
the external body reference, they need not conform to transport
limitations that apply to the reference itself. In particular,
Internet mail transports may impose 7bit and line length limits, but
these do not automatically apply to binary external body references.
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.
5.2.4. Other Message Subtypes
MIME implementations must in general treat unrecognized subtypes of
"message" as being equivalent to "application/octet-stream".
Future subtypes of "message" intended for use with email should be
restricted to "7bit" encoding. A type other than "message" should be
used if restriction to "7bit" is not possible.
6. Experimental Media Type Values
A media type value beginning with the characters "X-" is a private
value, to be used by consenting 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. In many cases, a subtype of "application" will be more
appropriate than a new top-level type.
7. Summary
The five discrete media types provide provide a standardized
mechanism for tagging entities as "audio", "image", or several other
kinds of data. The composite "multipart" and "message" media types
allow mixing and hierarchical structuring of entities of different
types in a single message. 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 media
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 the context of the
"application/postscript" type, the "message/external-body" type, and
in RFC2048. Implementors should pay special attention to the
security implications of any media types that can cause the remote
execution of any actions in the recipient's environment. In such
cases, the discussion of the "application/postscript" type may serve
as a model for considering other media types with remote execution
capabilities.
9. Authors' Addresses
For more information, the authors of this document are best contacted
via Internet mail:
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA
Phone: +1 818 919 3600
Fax: +1 818 919 3614
EMail: ned@innosoft.com
Nathaniel S. Borenstein
First Virtual Holdings
25 Washington Avenue
Morristown, NJ 07960
USA
Phone: +1 201 540 8967
Fax: +1 201 993 3032
EMail: nsb@nsb.fv.com
MIME is a result of the work of the Internet Engineering Task Force
Working Group on