RFC 1344 (rfc1344) - Page 2 of 9
Implications of MIME for Internet Mail Gateways
Alternative Format: Original Text Document
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