rack-mail_exception 0.0.1

data/vendor/mail/reference/rfc1049 Content-Type Header Field for Internet Messages.txt

@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                           M. Sirbu
+Request for Comments:  1049                                          CMU
+                                                              March 1988
+
+           A CONTENT-TYPE HEADER FIELD FOR INTERNET MESSAGES
+
+STATUS OF THIS MEMO
+
+   This RFC suggests proposed additions to the Internet Mail Protocol,
+   RFC-822, for the Internet community, and requests discussion and
+   suggestions for improvements.  Distribution of this memo is
+   unlimited.
+
+ABSTRACT
+
+   A standardized Content-type field allows mail reading systems to
+   automatically identify the type of a structured message body and to
+   process it for display accordingly.  The structured message body must
+   still conform to the RFC-822 requirements concerning allowable
+   characters.  A mail reading system need not take any specific action
+   upon receiving a message with a valid Content-Type header field.  The
+   ability to recognize this field and invoke the appropriate display
+   process accordingly will, however, improve the readability of
+   messages, and allow the exchange of messages containing mathematical
+   symbols, or foreign language characters.
+
+                             Table of Contents
+
+   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 1
+   2. Problems with Structured Messages . . . . . . . . . . . . . . . 3
+   3. The Content-type Header Field . . . . . . . . . . . . . . . . . 5
+        3.1. Type Values  . . . . . . . . . . . . . . . . . . . . . . 5
+        3.2. Version Number . . . . . . . . . . . . . . . . . . . . . 6
+        3.3. Resource Reference . . . . . . . . . . . . . . . . . . . 6
+        3.4. Comment. . . . . . . . . . . . . . . . . . . . . . . . . 7
+   4. Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+
+1. Introduction
+
+   As defined in RFC-822, [2], an electronic mail message consists of a
+   number of defined header fields, some containing structured
+   information (e.g., date, addresses), and a message body consisting of
+   an unstructured string of ASCII characters.
+
+   The success of the Internet mail system has led to a desire to use
+   the mail system for sending around information with a greater degree
+   of structure, while remaining within the constraints imposed by the
+   limited character set.  A prime example is the use of mail to send a
+
+
+
+Sirbu                                                           [Page 1]
+
+RFC 1049                   Mail Content Type                  March 1988
+
+
+   document with embedded TROFF formatting commands.  A more
+   sophisticated example would be a message body encoded in a Page
+   Description Language (PDL) such as Postscript.  In both cases, simply
+   mapping the ASCII characters to the screen or printer in the usual
+   fashion will not render the document image intended by the sender; an
+   additional processing step is required to produce an image of the
+   message text on a display device or a piece of paper.
+
+   In both of these examples, the message body contains only the legal
+   character set, but the content has a structure which produces some
+   desirable result after appropriate processing by the recipient.  If a
+   message header field could be used to indicate the structuring
+   technique used in the message body, then a sophisticated mail system
+   could use such a field to automatically invoke the appropriate
+   processing of the message body.  For example, a header field which
+   indicated that the message body was encoded using Postscript could be
+   used to direct a mail system running under Sun Microsystem's NEWS
+   window manager to process the Postscript to produce the appropriate
+   page image on the screen.
+
+   Private header fields (beginning with "X-") are already being used by
+   some systems to affect such a result (e.g., the Andrew Message System
+   developed at Carnegie Mellon University).  However, the widespread
+   use of such techniques will require general agreement on the name and
+   allowed parameter values for a header field to be used for this
+   purpose.
+
+   We propose that a new header field, "Content-type:"  be recognized as
+   the standard field for indicating the structure of the message body.
+   The contents of the "Content-Type:"  field are parameters which
+   specify what type of structure is used in the message body.
+
+   Note that we are not proposing that the message body contain anything
+   other than ASCII characters as specified in RFC-822.  Whatever
+   structuring is contained in the message body must be represented
+   using only the allowed ASCII characters.  Thus, this proposal should
+   have no impact on existing mailers, only on mail reading systems.
+
+   At the same time, this restriction eliminates the use of more general
+   structuring techniques such as Abstract Syntax Notation, (CCITT
+   Recommendation X.409) as used in the X.400 messaging standard, which
+   are octet-oriented.
+
+   This is not the first proposal for structuring message bodies.
+   RFC-767 discusses a proposed technique for structuring multi-media
+   mail messages.  We are also aware that many users already employ mail
+   to send TROFF, SCRIBE, TEX, Postscript or other structured
+   information.  Such postprocessing as is required must be invoked
+
+
+
+Sirbu                                                           [Page 2]
+
+RFC 1049                   Mail Content Type                  March 1988
+
+
+   manually by the message recipient who looks at the message text
+   displayed as conventional ASCII and recognizes that it is structured
+   in some way that requires additional processing to be properly
+   rendered.  Our proposal is designed to facilitate automatic
+   processing of messages by a mail reading system.
+
+2. Problems with Structured Messages
+
+   Once we introduce the notion that a message body might require some
+   processing other than simply painting the characters to the screen we
+   raise a number of fundamental questions.  These generally arise due
+   to the certainty that some receiving systems will have the facilities
+   to process the received message and some will not.  The problem is
+   what to do in the presence of systems with different levels of
+   capability.
+
+   First, we must recognize that the purpose of structured messages is
+   to be able to send types of information, ultimately intended for
+   human consumption, not expressable in plain ASCII.  Thus, there is no
+   way in plain ASCII to send the italics, boldface, or greek characters
+   that can be expressed in Postscript.  If some different processing is
+   necessary to render these glyphs, then that is the minimum price to
+   be paid in order to send them at all.
+
+   Second, by insisting that the message body contain only ASCII, we
+   insure that it will not "break" current mail reading systems which
+   are not equipped to process the structure; the result on the screen
+   may not be readily interpretable by the human reader, however.
+
+   If a message sender knows that the recipient cannot process
+   Postscript, he or she may prefer that the message be revised to
+   eliminate the use of italics and boldface, rather than appear
+   incomprehensible.  If Postscript is being used because the message
+   contains passages in Greek, there may be no suitable ASCII
+   equivalent, however.
+
+   Ideally, the details of structuring the message (or not) to conform
+   to the capabilities of the recipient system could be completely
+   hidden from the message sender.  The distributed Internet mail system
+   would somehow determine the capabilities of the recipient system, and
+   convert the message automatically; or, if there was no way to send
+   Greek text in ASCII, inform the sender that his message could not be
+   transmitted.
+
+
+
+
+
+
+
+
+Sirbu                                                           [Page 3]
+
+RFC 1049                   Mail Content Type                  March 1988
+
+
+   In practice, this is a difficult task.  There are three possible
+   approaches:
+
+      1. Each mail system maintains a database of capabilities of
+         remote systems it knows how to send to.  Such a database
+         would be very difficult to keep up to date.
+
+      2. The mail transport service negotiates with the receiving
+         system as to its capabilities.  If the receiving system
+         cannot support the specified content type, the mail is
+         transformed into conventional ASCII before transmission.
+         This would require changes to all existing SMTP
+         implementations, and could not be implemented in the case
+         where RFC-822 type messages are being forwarded via Bitnet or
+         other networks which do not implement SMTP.
+
+      3. An expanded directory service maintains information on mail
+         processing capabilities of receiving hosts.  This eliminates
+         the need for real-time negotiation with the final
+         destination, but still requires direct interaction with the
+         directory service.  Since directory querying is part of mail
+         sending as opposed to mail composing/reading systems, this
+         requires changes to existing mailers as well as a major
+         change to the domain name directory service.
+
+   We note in passing that the X.400 protocol implements approach number
+   2, and that the Draft Recommendations for X.DS, the Directory
+   Service, would support option 3.
+
+   In the interest of facilitating early usage of structured messages,
+   we choose not to recommend any of the three approaches described
+   above at the present time.  In a forthcoming RFC we will propose a
+   solution based on option 2, requiring modification to mailers to
+   support negotiation over capabilities.  For the present, then, users
+   would be obliged to keep their own private list of capabilities of
+   recipients and to take care that they do not send Postscript, TROFF
+   or other structured messages to recipients who cannot process them.
+   The penalty for failure to do so will be the frustration of the
+   recipient in trying to read a raw Postscript or TROFF file painted on
+   his or her screen.  Some System Administrators may attempt to
+   implement option 1 for the benefit of their users, but this does not
+   impose a requirement for changes on any other mail system.
+
+   We recognize that the long-term solution must require changes to
+   mailers.  However, in order to begin now to standardize the header
+   fields, and to facilitate experimentation, we issue the present RFC.
+
+
+
+
+
+Sirbu                                                           [Page 4]
+
+RFC 1049                   Mail Content Type                  March 1988
+
+
+3. The Content-type Header Field
+
+   Whatever structuring technique is specified by the Content-type
+   field, it must be known precisely to both the sender and the
+   recipient of the message in order for the message to be properly
+   interpreted.  In general, this means that the allowed parameter
+   values for the Content-type:  field must identify a well-defined,
+   standardized, document structuring technique.  We do not preclude,
+   however, the use of a Content-type:  parameter value to specify a
+   private structuring technique known only to the sender and the
+   recipient.
+
+   More precisely, we propose that the Content-type:  header field
+   consist of up to four parameter values.  The first, or type parameter
+   names the structuring technique; the second, optional, parameter is a
+   version number, ver-num, which indicates a particular version or
+   revision of the standardized structuring technique.  The third
+   parameter is a resource reference, resource-ref, which may indicate a
+   standard database of information to be used in interpreting the
+   structured document.  The last parameter is a comment.
+
+   In the Extended Backus Naur Form of RFC-822, we have:
+
+   Content-Type:= type [";" ver-num [";" 1#resource-ref]] [comment]
+
+3.1. Type Values
+
+   Initially, the type parameter would be limited to the following set
+   of values:
+
+   type:=           "POSTSCRIPT"/"SCRIBE"/"SGML"/"TEX"/"TROFF"/
+                    "DVI"/"X-"atom
+
+   These values are not case sensitive.  POSTSCRIPT, Postscript, and
+   POStscriPT are all equivalent.
+
+   POSTSCRIPT      Indicates the enclosed document consists of
+                   information encoded using the Postscript Page
+                   Definition Language developed by Adobe Systems,
+                   Inc. [1]
+
+   SCRIBE          Indicates the document contains embedded formatting
+                   information according to the syntax used by the
+                   Scribe document formatting language distributed by
+                   the Unilogic Corporation. [6]
+
+   SGML            Indicates the document contains structuring
+                   information to according the rules specified for
+
+
+
+Sirbu                                                           [Page 5]
+
+RFC 1049                   Mail Content Type                  March 1988
+
+
+                   the Standard Generalized Markup Language, IS 8879,
+                   as published by the International Organization for
+                   Standardization. [3] Documents structured according
+                   to the ISO DIS 8613--Office Docment Architecture and
+                   Interchange Format--may also be encoded using SGML
+                   syntax.
+
+   TEX             Indicates the document contains embedded formatting
+                   information according to the syntax of the TEX
+                   document production language. [4]
+
+   TROFF           Indicates the document contains embedded formatting
+                   information according to the syntax specified for the
+                   TROFF formatting package developed by AT&T Bell
+                   Laboratories. [5]
+
+   DVI             Indicates the document contains information according
+                   to the device independent file format produced by
+                   TROFF or TEX.
+
+   "X-"atom        Any type value beginning with the characters "X-" is
+                   a private value.
+
+3.2. Version Number
+
+   Since standard structuring techniques in fact evolve over time, we
+   leave room for specifying a version number for the content type.
+   Valid values will depend upon the type parameter.
+
+   ver-num:=      local-part
+
+     In particular, we have the following valid values:
+
+     For type=POSTSCRIPT
+
+   ver-num:= "1.0"/"2.0"/"null"
+
+     For type=SCRIBE
+
+   ver-num:= "3"/"4"/"5"/"null"
+
+     For type=SGML
+
+   ver-num:="IS.8879.1986"/"null"
+
+3.3. Resource Reference
+
+   resource-ref:=  local-part
+
+
+
+Sirbu                                                           [Page 6]
+
+RFC 1049                   Mail Content Type                  March 1988
+
+
+   As Apple has demonstrated with their implementation of the
+   Laserwriter, a very general document structuring technique can be
+   made more efficient by defining a set of macros or other similar
+   resources to be used in interpreting any transmitted stream.  The
+   Macintosh transmits a LaserPrep file to the Laserwriter containing
+   font and macro definitions which can be called upon by subsequent
+   documents.  The result is that documents as sent to the Laserwriter
+   are considerably more compact than if they had to include the
+   LaserPrep file each time.  The Resource Reference parameter allows
+   specification of a well known resource, such as a LaserPrep file,
+   which should be used by the receiving system when processing the
+   message.
+
+   Resource references could also include macro packages for use with
+   TEX or references to preprocessors such as eqn and tbl for use with
+   troff.  Allowed values will vary according to the type parameter.
+
+     In particular, we propose the following values:
+
+     For type = POSTSCRIPT
+
+   resource-ref:=  "laserprep2.9"/"laserprep3.0"/"laserprep3.1"/
+                   "laserprep4.0"/local-part
+
+     For type = TROFF
+
+   resource-ref:=  "eqn"/"tbl"/"me"/local-part
+
+3.4. Comment
+
+   The comment field can be any additional comment text the user
+   desires.  Comments are enclosed in parentheses as specified in
+   RFC-822.
+
+4. Conclusion
+
+   A standardized Content-type field allows mail reading systems to
+   automatically identify the type of a structured message body and to
+   process it for display accordingly.  The strcutured message body must
+   still conform to the RFC-822 requirements concerning allowable
+   characters.  A mail reading system need not take any specific action
+   upon receiving a message with valid Content-Type header field.  The
+   ability to recognize this field and invoke the appropriate display
+   process accordingly will, however, improve the readability of
+   messages, and allow the exchange of messages containing mathematical
+   symbols, or foreign language characters.
+
+
+
+
+
+Sirbu                                                           [Page 7]
+
+RFC 1049                   Mail Content Type                  March 1988
+
+
+   In the near term, the major use of a Content-Type:  header field is
+   likely to be for designating the message body as containing a Page
+   Definition Language representation such as Postscript.
+
+   Additional type values shall be registered with Internet Assigned
+   Numbers Coordinator at USC-ISI.  Please contact:
+
+                   Joyce K. Reynolds
+                   USC Information Sciences Institute
+                   4676 Admiralty Way
+                   Marina del Rey, CA  90292-6695
+
+                   213-822-1511    JKReynolds@ISI.EDU
+
+                                REFERENCES
+
+   1.  Adobe Systems, Inc.  Postscript Language Reference Manual.
+       Addison-Wesley, Reading, Mass., 1985.
+
+   2.  Crocker, David H.  RFC-822:  Standard for the Format of ARPA
+       Internet Text Messages.  Network Information Center,
+       August 13, 1982.
+
+   3.  ISO TC97/SC18.  Standard Generalized Markup Language.
+       Tech. Rept. DIS 8879, ISO, 1986.
+
+   4.  Knuth, Donald E.  The TEXbook.  Addison-Wesley, Reading, Mass.,
+       1984.
+
+   5.  Ossanna, Joseph F. NROFF/TROFF User's Manual.  Bell
+       Laboratories, Murray Hill, New Jersey, 1976.  Computing Science
+       Technical Report No.54.
+
+   6.  Unilogic.  SCRIBE Document Production Software.  Unilogic, 1985.
+       Fourth Edition.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sirbu                                                           [Page 8]
+

data/vendor/mail/reference/rfc1344 Implications of MIME for Internet Mail Gateways.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]
+
+