Implications of MIME for Internet Mail Gateways
RFC 1344

Document Type RFC - Informational (June 1992; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf ps html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1344 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text