I got so many good coments on my "Implications of MIME for MTAs"
document that I've produced another version. Again, this is intended to
be published simply as an informational RFC, but I'm very interested in
making it as good as possible. Please send any comments on the new
version directly to me. Thanks. -- Nathaniel
----------------------------------------------------------------
Network Working Group
Internet Draft
Nathaniel S. Borenstein
Bellcore
April, 1992
Implications of MIME for Message Transport
Abstract
The recent development of MIME (Multipurpose Internet Mail Extensions)
offers a wide range of new opportunities for electronic mail system
software. Most of these opportunites are relevant only to user agents,
the programs that interact with human users when tthey send and receive
mail. However, some opportunities are also opened up for mail transport
software. While MIME was carefully designed so that it does not require
any changes to message transport facilities, there are several ways in
which message transport software may want to take advantage of MIME.
These opportunities are the subject of this memo.
Status of This Memo
This is an informational memo for the Internet community, and requests
discussion and suggestions for improvements. This memo does not specify
an Internet standard. Distribution of this memo is unlimited.
Background -- The MIME Format
Recently, a new standardized format has been defined for enhanced
electronic mail messages on the Internet. This format, known as MIME,
permits messages to include, in a standardized manner, non-ASCII text,
images, audio, and a variety of other kinds of interesting data.
The MIME effort was explicitly focused on requiring absolutely no
changes at the message transport level. Because of this fact,
MIME-format mail runs transparently on all known Internet or
Internet-style mail systems. This means that those concerned solely
with the maintenance and development of message transport software can
safely ignore MIME completely, if they so choose.
However, the fact that MIME can be ignored, for the purpose of message
transport, does not necessarily mean that it should be ignored. In
particular, MIME offers several features that should be of interest to
those responsible for message transport software. By exploiting these
features, transport software can provide certain kinds of service that
are currently unavailable, and can alleviate a few existing problems.
The remainder of this document is an attempt to briefly point out and
summarize some important ways in which MIME may be of use for message
transport software. This document makes no attempt to present a
complete technical description of MIME, however. For that, the reader
is refered to the MIME document itself [MIME].
Rejected Messages
An unfortunately frequent duty of message transport software is the
rejection of mail to the sender. This may happen because the mail was
undeliverable, or because it did not conform to the requirements of a
gateway (e.g. it was too large).
There has never been a standard format for rejected messages in the
past. This has been an annoyance, but not a major problem for text
messages. For non-text messages, however, the lack of a standard
rejection format is more crucial, because rejected messages typically
appear to be text, and the user who is forced to view images or audio as
text is rarely happy with the result.
MIME makes it very easy to encapsulate messages in such a way that their
semantics are completely preserved. The simplest way to do this is to
make each rejection notice a MIME "multipart/mixed" message. That
multipart message would contain two parts, a text part explaining the
reason for the rejection, and an encapsulated message part that
contained the rejected message itself.
It should be stressed that the transport software does not need to
understand the structure of the rejected message at all. It merely
needs to encapsulate it properly. The following, for example, shows how
any MIME message may be encapsulated in a rejection message in such a
way that all information will be immediately visible in the correct form
if the recipient reads it with a MIME-conformant mail reader:
From: Mailer-Daemon <daemon(_at_)somewhere(_dot_)com>
Subject: Rejected Message
Content-type: multipart/mixed; boundary=unique-boundary
--unique-boundary
Content-type: text/plain; charset=us-ascii
A mail message you sent was rejected. The details of the rejected
message are as follows:
From: Nathainel Borenstein <nsb(_at_)bellcore(_dot_)com>
Message-ID: <12345(_at_)bellcore(_dot_)com>
To: bush(_at_)whitehouse(_dot_)gov
Subject: I know my rights!
Rejection-reason: No mail from libertarians is accepted.
The original message follows below.
--unique-boundary
Content-type: message/rfc822
The ENTIRE REJECTED MESSAGE, starting with the headers, goes here.
--unique-boundary--
In the above example, the ONLY thing that is not 'boilerplate" is the
choice of boundary string. The phrase "unique-boundary" should be
replaced by a string that does not appear (prefixed by two hyphens) in
any of the body parts.
Encapsulating a message in this manner is very easily done, and will
constitute a significant service that message transport software can
perform for MIME users.
IMPORTANT NOTE: The format given above is simply one of many possible
ways to format a rejection message using MIME. Independent IETF efforts
are underway that are aimed at standardizing the format of rejections
and acknowledgements. When those efforts come to fruition, they will
provide a more definitive specification of how rejection messages should
be formatted than is given here.
Fragmenting and Reassembling Large Messages
One problem that occurs with increasing frequency in Internet mail is
the rejection of messages because of size limitations. This problem can
be expected to grow substantially more severe with the acceptance of
MIME, as MIME invites the use of very large objects such as images and
audio clips. Fortunately, MIME also provides mechanisms that can help
alleviate the problem.
One particularly relevant MIME type is "message/partial", which can be
used for the automatic fragmentation and reassembly of large mail
messages. The message/partial type can be handled entirely at the user
agent level, but message transport software can also make use of this
type to provide more intelligent behavior at gateways.
In particular, when gatewaying mail to or from a system or network known
to enforce size limitations that are more or less stringent than are
enforced locally, message transport software might choose either to
break a large message into fragments, or (perhaps less likely) to
reassemble fragments into a larger message. The combination of these
two behaviors can make the overall Internet mail environment appear more
complete and seamless than it actually is.
Details on the message/partial format may be found in the MIME document.
What follows is an example of how a simple short message might be
broken into two message/partial messages. In practice, of course, the
message/partial facility would only be likely to be used for much longer
messages.
The following initial message:
From: Nathaniel Borenstein <nsb(_at_)bellcore(_dot_)com>
To: Ned Free: <ned(_at_)innosoft(_dot_)com>
Subject: a test message
Content-type: image/gif
Content-Transfer-Encoding: base64
R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV
uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90l
XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8vXWfU
qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5W
fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6M
can be transformed, invertibly, into the following two message/partial
messages:
From: Nathaniel Borenstein <nsb(_at_)bellcore(_dot_)com>
To: Ned Freed <ned(_at_)innosoft(_dot_)com>
Subject: a test message
Content-type: message/partial; id="xyx(_at_)host(_dot_)com";
number=1; total=2
Content-type: image/gif
Content-Transfer-Encoding: base64
R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV
and
From: Nathaniel Borenstein <nsb(_at_)bellcore(_dot_)com>
To: Ned Freed <ned(_at_)innosoft(_dot_)com>
Subject: a test message
Content-type: message/partial; id="xyx(_at_)host(_dot_)com";
number=2; total=2
uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90l
XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8vXWfU
qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5W
fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6M
Fragmenting such messages rather than rejecting them might be a
reasonable option for some gateway software, at least for a certain size
range of messages. Of course, it is often difficult for a gateway to
know what size limitations will be encountered "downstream", but
intelligent guesses are often possible. Moreover, an IETF working group
on SMTP extensions has proposed augmenting SMTP with a "SIZE" verb that
would facilitate this process.
Note also that fragmentation or reassembly might reasonably be
performed, in differing circumstances, by either the sending or
receiving MTA software.
Using or Removing External-Body Pointers
Another MIME type oriented to extremely large messages is the
"message/external-body" type. In this type of message, the body data is
not included in the actual message itself. Instead, the Content-Type
header field includes information that tells how the body data can be
retrieved -- either via a file system, via anonymous ftp, or via other
mechanisms.
The message/external-body type provides a new option for mail transport
software that wishes to optimize the way bandwidth resources are used in
a given environment. For example, the basic use of
message/external-body is to reduce bandwidth in email traffic. However,
when email crosses a slow and expensive boundary -- e.g. a satellite
link across the Pacific -- it might make sense to retreive the data
itself and transform the external-body reference into the actual data.
Alternately, it might make sense to copy the data itself to a new
location, closer to the message recipients, and change the location
pointed to in the message. Because the external-body specification can
include an expiration date, message transport software can trade off
storage and bandwidth capabilities to try to optimize the overall use of
resources for very large messages.
For example, the following message includes PostScript data by external
reference:
From: Nathaniel Borenstein <nsb(_at_)bellcore(_dot_)com>
To: Ned Freed <ned(_at_)innosoft(_dot_)com>
Subject: The latest MIME draft
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
A gateway to Australia might choose to copy the file to an Australian
FTP archive, changing the relevant parameters on the Content-type header
field. Alternately, it might choose simply to transform the message
into one in which all the data were included:
From: Nathaniel Borenstein <nsb(_at_)bellcore(_dot_)com>
To: Ned Freed <ned(_at_)innosoft(_dot_)com>
Subject: The latest MIME draft
Content-type: application/postscript
%!PS-Adobe-1.0
%%Creator: greenbush:nsb (Nathaniel Borenstein,MRE
2A-274,4270,9938586,21462)
etc...
Alternatively, instead of replacing an external-body message with its
real contents, it might make sense to transform it into a
"multipart/alternative" message containing both the external body
reference and the expanded version. This means that only the external
body part can be forwarded if desired, and the recipient doesn't lose
the information as to where the data was fetched from, if they want to
fetch an up-to-date version in the future. Such information could be
represented, in MIME, in the following form:
From: Nathaniel Borenstein <nsb(_at_)bellcore(_dot_)com>
To: Ned Freed <ned(_at_)innosoft(_dot_)com>
Subject: The latest MIME draft
Content-type: multipart/alternative; boundary=foo
--foo
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
--foo
Content-type: application/postscript
%!PS-Adobe-1.0
%%Creator: greenbush:nsb (Nathaniel Borenstein,MRE
2A-274,4270,9938586,21462)
etc...
--foo--
Similarly for the case where a message is copied to a local FTP site,
one could offer two external body parts as the alternatives, allowing
the user agent to choose which FTP site is preferred.
Image and other Format Conversions
MIME currently defines two image formats, image/gif and image/jpeg. The
former is much more convenient for many users, and can be displayed more
quickly on many systems. The latter is a much more compact
representation, and therfore places less stress on mail transport
facilities.
Message transport software can optimize both transport bandwidth and
user convenience by intelligent translation between these formats (and
other formats that might be added later). When a message of type
image/gif is submitted for long-haul delivery, it might reasonably be
translated to image/jpeg. Conversely, when image/jpeg data is received
for final delivery on a system with adequate storage resources, it might
be translated to image/gif for the convenience of the recipient.
Software to perform these translations is widely available.
Although MIME currently only defines one audio format, more are likely
to be defined and registered with IANA in the future. In that case,
similar format conversion facilities might be appropriate for audio.
If format conversion is done, it is STRONGLY RECOMMENDED that some kind
of trace information (probably in the form of a Received header field)
should be added to a message to document the conversion that has been
performed.
Some people have expressed concerns, or even the opinion that
conversions should never be done. To accomodate the desires of those
who dislike the idea of automatic format conversion. For this reason,
it is suggested that MTA's which do perform such conversions should be
sensitive to a header field that indicates that the sender does not wish
to have any such conversions performed. A suggested value for this
header field is:
Content-Conversion: prohibited
User agents that wish to explicitly indicate a willingness for such
conversions to be performed may use:
Content-Conversion: permitted
However, this will be the default assumption of many MTA's, so this
header field is not strictly necessary.
Robust Encoding of Data
In addition to all the reasons given above for possible MTA
transformation of body data, it will sometimes be the case that an MTA
can tell that the body data, as given, will not robustly survive the
next step of transport. For example, mail crossing an ASCII-to-EBCDIC
gateway will lose information if certain characters are used. In such
cases, an MTA can make the data more robust simply by applying one of
the MIME Content-Transfer-Encoding algorithms (base64 or
quoted-printable) to the body or body part. This will generally be a
loss-less transformation, but care must be taken to ensure that the
resulting message is MIME-conformant if the inital message was not.
(For example, a MIME-Version header field may need to be added.)
User-oriented concerns
If an MTA is going to perform major transformations on a mail message,
such as translating image formats or mapping between included data and
external-reference data, it seems inevitable that there will be
situations in which users will object to these transformations. This
is, in large part, an implementation issue, but it seems advisable,
wherever possible, to provide a mechanism whereby users can specify, to
their MTA software, whether or not they want such services performed
automatically on their behalf. The use of the "Content-Conversion"
header field, as mentioned above, is suggested for this purpose.
Some have expressed the opinion that format transformations should NEVER
be performed by an MTA. Obviously this is controversial. Certainly, at
a minimum, MTA implementors should consider carefully the needs and
desires of their user community before implementing such a facility.
References
[MIME] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet
Mail Extensions): Mechanisms for Specifying and Describing the Format
of Internet Message Bodies", Internet Draft
draft-ietf822-bodyformats-05", March, 1992.