RFC 1344

Implications of MIME for Internet Mail Gateways 🎀

Okay bestie, so this is RFC 1344 from the Network Working Group 🌸 It was written by N. Borenstein of Bellcore and dated June 1992 📅 It's an Informational doc, not a standard, and the title block doesn't list any RFCs it obsoletes or updates 💅

Status of This Memo 📋

This is an informational memo for the Internet community 🌐 It's basically asking everyone to discuss it and suggest improvements 💬 It does not specify an Internet standard, so no pressure lol 🫶 Distribution of this memo is unlimited 🦋

Abstract 🦋

MIME (Multipurpose Internet Mail Extensions) opened up a whole buffet of new possibilities for email 🍓 Most of them are for user agents, the programs humans actually touch when they send and read mail 💅 But some are for mail transport systems too! MIME was carefully designed so that it does not require any changes to Internet electronic message transport facilities, but there are still several ways transport systems may want to take advantage of it 🧚 This memo is all about those ways ✨

Background -- The MIME Format 🌈

Recently, the Internet got a new standardized format for enhanced email messages, called MIME 💌 It lets messages carry non-ASCII text, images, audio, and a bunch of other fun data in a standard way 🎧

The MIME effort was explicitly focused on requiring absolutely no changes at the message transport level 🙅‍♀️ That means MIME-format mail runs transparently on every known Internet or Internet-style mail system. So folks who only care about keeping transport running can safely ignore MIME totally if they want 😌

But ignoring MIME for transport doesn't necessarily mean it should be ignored 👀 MIME has several features that transport people should be excited about. By exploiting them, transport systems can offer some extra kinds of service that don't exist right now, and fix a few existing problems 🔥

This doc isn't a full technical description of MIME, just a quick tour of the important ways MIME can help message transport. For the full details, check out the MIME document itself [RFC-1341] 📚

Mail Transport and Gateway Services: A Key Distinction 🔑

Before you implement anything from this memo, you need to know the difference between mail transport service and mail gateway service 🧠 Transport software moves a message around inside one homogeneous email network. Gateways are different: they swap mail between two significantly different mail environments, including non-electronic ones like postal mail 📮

It's widely considered unacceptable for transport services to alter message contents 😤 For gateways, though, changing contents is often unavoidable 🤷‍♀️ So strictly speaking, many of the mechanisms here only apply to gateways, and should not be used in simple transport systems. However, some very special situations, like an SMTP relay pushing mail across super expensive intercontinental links, might need to modify messages to give good service there. In that case it has to redefine its role as a gateway 🌍

In this memo, we assume that transformations which alter message contents will only be done by gateways. It's recognized, though, that some existing mail transport agents may choose to reclassify themselves as gateways so they can do the stuff described here 💅

Rejected Messages 🙅‍♀️

Rejecting mail back to the sender is an unfortunately frequent job for message transport services 😩 It can happen because the mail was undeliverable, or because it didn't meet a gateway's requirements (like being too large, for example) 📦

Historically, there has never been a standard format for rejected messages. That's annoying, but not a huge deal for text messages 🙃 For non-text messages it's way more crucial, because rejections usually look like text, and nobody is happy seeing an image or audio file rendered as if it were text 😭

MIME makes it super easy to wrap messages up so their semantics stay totally intact ✨ The simplest approach is making each rejection notice a MIME "multipart/mixed" message. That multipart message has two parts: a text part explaining why it was rejected, and an encapsulated message part containing the rejected message itself 🎁

Key point: transport software doesn't need to understand the structure of the rejected message at all. It just has to encapsulate it properly 🧃 The example below shows how any MIME message can be wrapped in a rejection message, so everything shows up correctly if the recipient reads it with a MIME-conformant mail reader 💖

From: Mailer-Daemon <daemon@somewhere.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@bellcore.com>
Message-ID: <12345@bellcore.com>
To: bush@whitehouse.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--

Honestly, the only non-boilerplate thing in that example is the choice of boundary string 🫶 The phrase "unique-boundary" should be replaced by a string that doesn't show up (prefixed by two hyphens) in any of the body parts 🔐 Wrapping a message like this is really easy, and it's a seriously good service message transport can offer MIME users 👑

IMPORTANT NOTE: That format is just 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 🚨

Fragmenting and Reassembling Large Messages 🧩

Okay so this one happens more and more: messages getting rejected because of size limits 📏 It's only going to get worse with MIME, since MIME invites big stuff like images and audio clips 🎧 The good news is that MIME also has mechanisms to help 💖

One especially relevant MIME type is "message/partial", which handles automatic fragmenting and reassembling of large mail messages 🧩 The message/partial type can be handled entirely at the user agent level, but transport services can use it too, for smarter gateway behavior 🧠

Specifically: when gatewaying mail to or from a system or network that enforces size limits that are more or less strict than the local ones, transport services might break a large message into fragments, or (perhaps less likely) reassemble fragments into a larger message 📦 Do both and the overall Internet mail environment looks way more complete and seamless than it actually is 🌈

Details on the message/partial format are in the MIME document. Here's an example of a simple short message being split into two message/partial messages. In practice, message/partial would only really be used for much longer messages 💅

The following initial message:

From:  Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed: <ned@innosoft.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@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: a test message
Content-type: message/partial; id="xyx@host.com";
     number=1; total=2

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

R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV

and 👀 (the second partial is coming up next, bestie 🫶)

Okay so, fragmenting these chonky messages instead of just rejecting them? Honestly a reasonable move 🎀 for some gateway services, at least when the message sizes fall inside a certain range. The tricky part is that it's often hard for a gateway to know what size limits are waiting "downstream" 🙈, but smart guesses are usually possible ✨. Also, an IETF working group on SMTP extensions has proposed adding a "SIZE" verb to SMTP 📬. That would make the whole thing way easier, and it could mean fragmenting on the fly while the message is actually being sent 🔥.

Note also that fragmentation or reassembly can happen on either the sending or the receiving gateway system, depending on the situation 🦋. Whichever one knows more about the other's capabilities is the one with the inside scoop 💅.

Using or Removing External-Body Pointers 🌸

Another MIME type that's all about super huge messages is "message/external-body" 💜. In this type, all or part of the body data is not actually inside the message. Instead, the Content-Type header field tells you how to go get the body data, whether that's from a file system, via anonymous ftp, or through other mechanisms 📂.

This type gives mail transport services a new way to optimize bandwidth 🧚 in a given environment. The basic use of message/external-body is to cut down on bandwidth in email traffic, but when email crosses a slow and expensive boundary (think a satellite link across the Pacific 🛰️), it might make sense to go fetch the actual data and swap the external-body reference for the real thing 😭. Or, alternatively, you could copy the data to a new spot closer to the recipients and change the location the message points to 🗺️. The external-body spec can include an expiration date, so transport services can trade off storage and bandwidth to try to optimize resources for very large messages 💅.

Such gateway behaviors need careful cost/benefit analysis, and they'd be a dramatic departure from typical mail transport services 💀. But the potential benefits are quite significant, so the appropriate use of these service options should be explored 🔥.

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

From:  Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.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 is included:

From:  Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.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...

This is an example that shows both the benefits and the dangers 🙃. There is considerable benefit to having a copy of the data immediately available, but there may also be considerable expense in transporting it to all of 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 track of where the data was fetched from, in case they want an up-to-date version in the future. In MIME, that information could be represented in the following form:

From:  Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.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, if a message is copied to a local FTP site, one could offer two external body parts as the alternatives, letting the user agent 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, so it places less stress on mail transport facilities 🪶.

Message transport services can optimize both transport bandwidth and user convenience through 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 recipient's convenience 💖. Software to perform these translations is widely available. It should be noted, however, that performance of such conversions presumes the recipient supports the new format 🤔.

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 too 🎧.

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 was performed 📝. No skipping this one, bestie 🚨.

Some people have concerns, or even think conversions should never be done at all 😤. To respect those who dislike the idea of automatic format conversion, it is suggested that such transformations be generally restricted to gateways rather than general message transport services. It's also suggested that services which perform such conversions should be sensitive to a header field indicating 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 say they're fine with such conversions being 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 this control over conversion would only be available to the sender, not to any of the recipients 🫠.

Robust Encoding of Data 🧸

Beyond all the reasons given above for possibly transforming body data, sometimes a gateway can tell that the body data, as given, won't 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 cases like this, a gateway can make the data more robust 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 lossless transformation, but care must be taken to ensure that the resulting message is MIME-conformant if the initial message was not. (For example, a MIME-Version header field may need to be added.) 💅

User-oriented concerns 👑

okay so this is where it gets spicy 🌶️ if a gateway is about to do major transformations on a mail message, like translating image formats or mapping between included data and external-reference data, it seems inevitable that some users are gonna object 🙅‍♀️ this is mostly an implementation issue, but it's advisable, wherever possible, to give users a way to tell the transport system whether they want those services done automatically on their behalf 💅 the Content-Conversion header field we talked about above is suggested for this purpose, since it at least gives the sender some control, even if the recipient doesn't get any 🫶

References 📚

[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. 💀 bestie, don't go assuming it's covered somewhere else.

Author's Address ✍️

the legend who wrote this one is Nathaniel S. Borenstein 👑

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

Email: nsb@bellcore.com
Phone: +1 201 829 4270
Fax:  +1 201 829 7019