diff options
Diffstat (limited to 'doc/rfc/rfc1344.txt')
| -rw-r--r-- | doc/rfc/rfc1344.txt | 586 |
1 files changed, 586 insertions, 0 deletions
diff --git a/doc/rfc/rfc1344.txt b/doc/rfc/rfc1344.txt new file mode 100644 index 0000000..fc59dfa --- /dev/null +++ b/doc/rfc/rfc1344.txt @@ -0,0 +1,586 @@ + + + + + + + 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. + + Abstract + + 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] + + + + + RFC 1344 MIME and Mail Gateways June 1992 + + + 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 + gateway. + + 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] + + + + + RFC 1344 MIME and Mail Gateways June 1992 + + + 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@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-- + 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 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] + + + + + RFC 1344 MIME and Mail Gateways June 1992 + + + 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 <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> + + + + + + Borenstein [Page 4] + + + + + RFC 1344 MIME and Mail Gateways June 1992 + + + 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 + + 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=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 + transmission. + + 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] + + + + + RFC 1344 MIME and Mail Gateways June 1992 + + + 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 + messages. + + 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 <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 were 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 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] + + + + + RFC 1344 MIME and Mail Gateways June 1992 + + + 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 <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 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] + + + + + RFC 1344 MIME and Mail Gateways June 1992 + + + 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] + + + + + RFC 1344 MIME and Mail Gateways June 1992 + + + 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. + + 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. + + Author's Address + + 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 + + + + + + Borenstein [Page 9] + +
\ No newline at end of file |