Network Working Group               N. Borenstein, Bellcore
            Request for Comments: 1344                        June 1992

Implications of MIME for Internet Mail Gateways

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.


The recent development of MIME (Multipurpose Internet Mail Extensions) offers a wide range of new opportunities for electronic mail system systems. Most of these opportunites are relevant only to user agents, the programs that interact with human users when they send and receive mail. However, some opportunities are also opened up for mail transport systems. While MIME was carefully designed so that it does not require any changes to Internet electronic message transport facilities, there are several ways in which message transport systems may want to take advantage of MIME. These opportunities are the subject of this memo.

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 services 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 services. By exploiting these features, transport systems can provide certain additional 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

            Borenstein                                          [Page 1]

may be of use for message transport systems. 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 [RFC-1341].

Mail Transport and Gateway Services: A Key Distinction

Before implementing any of the mechanisms discussed in this memo, one should be familiar with the distinction between mail transport service and mail gateway service. Basically, mail transport software is responsible for moving a message within a homogeneous electronic mail service network. Mail gateways, on the other hand, exchange mail between two significantly different mail environments, including via non-electronic services, such as postal mail.

In general, it is widely considered unacceptable for mail transport services to alter the contents of messages. In the case of mail gateways, however, such alteration is often inevitable. Thus, strictly speaking, many of the mechanisms described here apply only to gateways, and should not be used in simple mail transport systems. However, it is possible that some very special situations -- e.g., an SMTP

            relay   that  transports  mail  across  extremely  expensive
            intercontinental network  links  --  might  need  to  modify
            messages,  in order to provide appropriate service for those
            situations, and hence must redefine its role to be that of a

In this memo, it is assumed that transformations which alter a message's contents will be performed only by gateways, but it is recognized that some existing mail transport agents may choose to reclassify themselves as gateways in order to perform the functions described here.

Rejected Messages

An unfortunately frequent duty of message transport services 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 finds himself viewing images or audio as if they were 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

            Borenstein                                          [Page 2]

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 <>
Subject: Rejected Message
Content-type: multipart/mixed; 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 <> Message-ID: <>
Subject: I know my rights!
Rejection-reason: No mail from libertarians is accepted.

The original message follows below.

                 Content-type: message/rfc822

The ENTIRE REJECTED MESSAGE, starting with the headers, goes here.

            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

Encapsulating a message in this manner is very easily done, and will constitute a significant service that message transport services 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 needed in order to standardize the format of rejections and acknowledgements.

            Borenstein                                          [Page 3]

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 services 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 services 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 <> To: Ned Freed: <>
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 <>

            Borenstein                                          [Page 4]

To: Ned Freed <>
Subject: a test message
Content-type: message/partial; id=""; number=1; total=2

Content-type: image/gif
Content-Transfer-Encoding: base64



From: Nathaniel Borenstein <> To: Ned Freed <>
Subject: a test message
Content-type: message/partial; id=""; 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 services, at least for a certain range of message sizes. 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,  thereby  possibly
            requiring  fragmentation   on   the   fly   during   message

Note also that fragmentation or reassembly might reasonably be performed, in differing circumstances, by either the sending or receiving gateway systems, depending on which system knew more about the capabilities of the other.

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, all or part of 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 services 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

            Borenstein                                          [Page 5]

slow and expensive boundary -- e.g., a satellite link across the Pacific -- it might make sense to retrieve 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  services  can
            trade  off  storage  and  bandwidth  capabilities  to try to
            optimize  the  overall  use  of  resources  for  very  large

Such behaviors by a gateway require careful analysis of

            cost/benefit   tradeoffs  and  would be a dramatic departure
            from  typical  mail  transport   services.    However,   the
            potential  benefits  are quite significant, so that such the
            appropriate use of these service options should be explored.

For example, the following message includes PostScript data by external reference:

From: Nathaniel Borenstein <> To: Ned Freed <>
Subject: The latest MIME draft
Content-Type: message/external-body;
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 <> To: Ned Freed <>
Subject: The latest MIME draft
Content-type: application/postscript

%%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A- 274,4270,9938586,21462)

This is an example which suggests both the benefits and the dangers. There is considerable benefit to having a copy of

            the data immediately  available,   but  there  also  may  be
            considerable  expense involved in transporting it to all  of

            Borenstein                                          [Page 6]

a the members of a list, if only a few will use the data anytime soon.

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 <> To: Ned Freed <>
Subject: The latest MIME draft
Content-type: multipart/alternative; boundary=foo

                 Content-Type: message/external-body;
                      expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript

                 Content-type: application/postscript

%%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A- 274,4270,9938586,21462)


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 services 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

            Borenstein                                          [Page 7]

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. It should be noted, however, that performance of such conversions presumes support for the new format by the recipient.

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 such transformations be generally restricted to gateways rather than general message transport services, and that services which 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 gateways, so this header field is not strictly necessary. It also should be noted that such control of conversion would only be available to the sender, rather than to any of the recipients.

            Borenstein                                          [Page 8]

Robust Encoding of Data

In addition to all the reasons given above for possible transformation of body data, it will sometimes be the case that a gateway 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, a gateway 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 a gateway 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 the transport system, 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, since it it least provides some control by the sender, if not the recipient.


            [RFC-1341]    Borenstein,   N.,   and   N.   Freed,    "MIME
            (Multipurpose  Internet  Mail  Extensions):  Mechanisms  for
            Specifying and Describing the  Format  of  Internet  Message
            Bodies", RFC 1341, Bellcore, June, 1992.

Security Considerations

Security issues are not discussed in this memo.

Author's Address

Nathaniel S. Borenstein
MRE 2D-296, Bellcore
445 South St.
Morristown, NJ 07962-1910

Phone: +1 201 829 4270
Fax: +1 201 829 7019

            Borenstein                                          [Page 9]