Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1

          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.
          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
          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
          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
               From: Mailer-Daemon <>
               Subject: Rejected Message
               Content-type: multipart/mixed; boundary=unique-boundary
  1. -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 <>
               Message-ID: <>
               Subject: I know my rights!
               Rejection-reason:  No mail from libertarians is
               The original message follows below.
               Content-type: message/rfc822
               The ENTIRE REJECTED MESSAGE, starting with the headers,
               goes here.
  1. -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
          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
          The following initial message:
               From:  Nathaniel Borenstein <>
               To: Ned Freed: <>
               Subject: a test message
               Content-type: image/gif
               Content-Transfer-Encoding: base64
          can  be  transformed,  invertibly,  into  the  following two
          message/partial messages:
               From:  Nathaniel Borenstein <>
          Borenstein                                          [Page 4]
          RFC 1344           MIME and Mail Gateways          June 1992
               To: Ned Freed <>
               Subject: a test message
               Content-type: message/partial; id="";
                    number=1; total=2
               Content-type: image/gif
               Content-Transfer-Encoding: base64
               From:  Nathaniel Borenstein <>
               To: Ned Freed <>
               Subject: a test message
               Content-type: message/partial; id="";
                    number=2; total=2
          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
          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
          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 <>
               To: Ned Freed <>
               Subject: The latest MIME draft
               Content-Type: message/external-body;
                    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 <>
               To: Ned Freed <>
               Subject: The latest MIME draft
               Content-type: application/postscript
               %%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A-
          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 <>
               To: Ned Freed <>
               Subject: The latest MIME draft
               Content-type: multipart/alternative; boundary=foo
  1. -foo

Content-Type: message/external-body;

                    expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
               Content-type: application/postscript
               Content-type: application/postscript
               %%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A-
          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.
          [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
          Phone: +1 201 829 4270
          Fax:  +1 201 829 7019
          Borenstein                                          [Page 9]
/data/webs/external/dokuwiki/data/pages/rfc/rfc1344.txt · Last modified: 1992/06/10 20:38 (external edit)