rfc1344.txt

RFC 的详细文档！

            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 <[e-mail]>
                 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 <[e-mail]>
                 Message-ID: <[e-mail]>
                 To: [e-mail]
                 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 <[e-mail]>
                 To: Ned Freed: <[e-mail]>
                 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 <[e-mail]>





            Borenstein                                          [Page 4]




            RFC 1344           MIME and Mail Gateways          June 1992


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

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

                 R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV

            and

                 From:  Nathaniel Borenstein <[e-mail]>
                 To: Ned Freed <[e-mail]>
                 Subject: a test message
                 Content-type: message/partial; id="[e-mail]";
                      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