rfc2049.txt

用C#开发实现SMTP相关技术,能接收到带附件的邮件服务功能.

   MIME is a result of the work of the Internet Engineering Task Force
   Working Group on RFC 822 Extensions.  The chairman of that group,
   Greg Vaudreuil, may be reached at:

   Gregory M. Vaudreuil
   Octel Network Services
   17080 Dallas Parkway
   Dallas, TX 75248-1905
   USA

   EMail: [e-mail]

8.  Acknowledgements

   This document is the result of the collective effort of a large
   number of people, at several IETF meetings, on the IETF-SMTP and
   IETF-822 mailing lists, and elsewhere.  Although any enumeration
   seems doomed to suffer from egregious omissions, the following are
   among the many contributors to this effort:

     Harald Tveit Alvestrand       Marc Andreessen
     Randall Atkinson              Bob Braden
     Philippe Brandon              Brian Capouch
     Kevin Carosso                 Uhhyung Choi
     Peter Clitherow               Dave Collier-Brown
     Cristian Constantinof         John Coonrod
     Mark Crispin                  Dave Crocker
     Stephen Crocker               Terry Crowley
     Walt Daniels                  Jim Davis
     Frank Dawson                  Axel Deininger
     Hitoshi Doi                   Kevin Donnelly
     Steve Dorner                  Keith Edwards
     Chris Eich                    Dana S. Emery
     Johnny Eriksson               Craig Everhart
     Patrik Faltstrom              Erik E. Fair
     Roger Fajman                  Alain Fontaine
     Martin Forssen                James M. Galvin
     Stephen Gildea                Philip Gladstone
     Thomas Gordon                 Keld Simonsen
     Terry Gray                    Phill Gross
     James Hamilton                David Herron
     Mark Horton                   Bruce Howard
     Bill Janssen                  Olle Jarnefors
     Risto Kankkunen               Phil Karn
     Alan Katz                     Tim Kehres
     Neil Katin                    Steve Kille
     Kyuho Kim                     Anders Klemets
     John Klensin                  Valdis Kletniek
     Jim Knowles                   Stev Knowles
     Bob Kummerfeld                Pekka Kytolaakso
     Stellan Lagerstrom            Vincent Lau
     Timo Lehtinen                 Donald Lindsay
     Warner Losh                   Carlyn Lowery
     Laurence Lundblade            Charles Lynn
     John R. MacMillan             Larry Masinter
     Rick McGowan                  Michael J. McInerny
     Leo Mclaughlin                Goli Montaser-Kohsari
     Tom Moore                     John Gardiner Myers
     Erik Naggum                   Mark Needleman
     Chris Newman                  John Noerenberg

     Mats Ohrman                   Julian Onions
     Michael Patton                David J. Pepper
     Erik van der Poel             Blake C. Ramsdell
     Christer Romson               Luc Rooijakkers
     Marshall T. Rose              Jonathan Rosenberg
     Guido van Rossum              Jan Rynning
     Harri Salminen                Michael Sanderson
     Yutaka Sato                   Markku Savela
     Richard Alan Schafer          Masahiro Sekiguchi
     Mark Sherman                  Bob Smart
     Peter Speck                   Henry Spencer
     Einar Stefferud               Michael Stein
     Klaus Steinberger             Peter Svanberg
     James Thompson                Steve Uhler
     Stuart Vance                  Peter Vanderbilt
     Greg Vaudreuil                Ed Vielmetti
     Larry W. Virden               Ryan Waldron
     Rhys Weatherly                Jay Weber
     Dave Wecker                   Wally Wedel
     Sven-Ove Westberg             Brian Wideen
     John Wobus                    Glenn Wright
     Rayan Zachariassen            David Zimmerman

   The authors apologize for any omissions from this list, which are
   certainly unintentional.

Appendix A -- A Complex Multipart Example

   What follows is the outline of a complex multipart message.  This
   message contains five parts that are to be displayed serially:  two
   introductory plain text objects, an embedded multipart message, a
   text/enriched object, and a closing encapsulated text message in a
   non-ASCII character set.  The embedded multipart message itself
   contains two objects to be displayed in parallel, a picture and an
   audio fragment.

     MIME-Version: 1.0
     From: Nathaniel Borenstein <[e-mail]>
     To: Ned Freed <[e-mail]>
     Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
     Subject: A multipart example
     Content-Type: multipart/mixed;
                   boundary=unique-boundary-1

     This is the preamble area of a multipart message.
     Mail readers that understand multipart format
     should ignore this preamble.

     If you are reading this text, you might want to
     consider changing to a mail reader that understands
     how to properly display multipart messages.

     --unique-boundary-1

       ... Some text appears here ...

     [Note that the blank between the boundary and the start
      of the text in this part means no header fields were
      given and this is text in the US-ASCII character set.
      It could have been done with explicit typing as in the
      next part.]

     --unique-boundary-1
     Content-type: text/plain; charset=US-ASCII

     This could have been part of the previous part, but
     illustrates explicit versus implicit typing of body
     parts.

     --unique-boundary-1
     Content-Type: multipart/parallel; boundary=unique-boundary-2

     --unique-boundary-2
     Content-Type: audio/basic

     Content-Transfer-Encoding: base64

       ... base64-encoded 8000 Hz single-channel
           mu-law-format audio data goes here ...

     --unique-boundary-2
     Content-Type: image/jpeg
     Content-Transfer-Encoding: base64

       ... base64-encoded image data goes here ...

     --unique-boundary-2--

     --unique-boundary-1
     Content-type: text/enriched

     This is <bold><italic>enriched.</italic></bold>
     <smaller>as defined in RFC 1896</smaller>

     Isn't it
     <bigger><bigger>cool?</bigger></bigger>

     --unique-boundary-1
     Content-Type: message/rfc822

     From: (mailbox in US-ASCII)
     To: (address in US-ASCII)
     Subject: (subject in US-ASCII)
     Content-Type: Text/plain; charset=ISO-8859-1
     Content-Transfer-Encoding: Quoted-printable

       ... Additional text in ISO-8859-1 goes here ...

     --unique-boundary-1--

Appendix B -- Changes from RFC 1521, 1522, and 1590

   These documents are a revision of RFC 1521, 1522, and 1590.  For the
   convenience of those familiar with the earlier documents, the changes
   from those documents are summarized in this appendix.  For further
   history, note that Appendix H in RFC 1521 specified how that document
   differed from its predecessor, RFC 1341.

    (1)   This document has been completely reformatted and split
          into multiple documents.  This was done to improve the
          quality of the plain text version of this document,
          which is required to be the reference copy.

    (2)   BNF describing the overall structure of MIME object
          headers has been added. This is a documentation change
          only -- the underlying syntax has not changed in any
          way.

    (3)   The specific BNF for the seven media types in MIME has
          been removed.  This BNF was incorrect, incomplete, amd
          inconsistent with the type-indendependent BNF.  And
          since the type-independent BNF already fully specifies
          the syntax of the various MIME headers, the type-
          specific BNF was, in the final analysis, completely
          unnecessary and caused more problems than it solved.

    (4)   The more specific "US-ASCII" character set name has
          replaced the use of the informal term ASCII in many
          parts of these documents.

    (5)   The informal concept of a primary subtype has been
          removed.

    (6)   The term "object" was being used inconsistently.  The
          definition of this term has been clarified, along with
          the related terms "body", "body part", and "entity",
          and usage has been corrected where appropriate.

    (7)   The BNF for the multipart media type has been
          rearranged to make it clear that the CRLF preceeding
          the boundary marker is actually part of the marker
          itself rather than the preceeding body part.

    (8)   The prose and BNF describing the multipart media type
          have been changed to make it clear that the body parts
          within a multipart object MUST NOT contain any lines
          beginning with the boundary parameter string.

    (9)   In the rules on reassembling "message/partial" MIME
          entities, "Subject" is added to the list of headers to
          take from the inner message, and the example is
          modified to clarify this point.

    (10)  "Message/partial" fragmenters are restricted to
          splitting MIME objects only at line boundaries.

    (11)  In the discussion of the application/postscript type,
          an additional paragraph has been added warning about
          possible interoperability problems caused by embedding
          of binary data inside a PostScript MIME entity.

    (12)  Added a clarifying note to the basic syntax rules for
          the Content-Type header field to make it clear that the
          following two forms:

            Content-type: text/plain; charset=us-ascii (comment)

            Content-type: text/plain; charset="us-ascii"

          are completely equivalent.

    (13)  The following sentence has been removed from the
          discussion of the MIME-Version header: "However,
          conformant software is encouraged to check the version
          number and at least warn the user if an unrecognized
          MIME-version is encountered."

    (14)  A typo was fixed that said "application/external-body"
          instead of "message/external-body".

    (15)  The definition of a character set has been reorganized
          to make the requirements clearer.

    (16)  The definition of the "image/gif" media type has been
          moved to a separate document. This change was made
          because of potential conflicts with IETF rules
          governing the standardization of patented technology.

    (17)  The definitions of "7bit" and "8bit" have been
          tightened so that use of bare CR, LF can only be used
          as end-of-line sequences.  The document also no longer
          requires that NUL characters be preserved, which brings
          MIME into alignment with real-world implementations.

    (18)  The definition of canonical text in MIME has been
          tightened so that line breaks must be represented by a
          CRLF sequence.  CR and LF characters are not allowed
          outside of this usage.  The definition of quoted-
          printable encoding has been altered accordingly.

    (19)  The definition of the quoted-printable encoding now
          includes a number of suggestions for how quoted-
          printable encoders might best handle improperly encoded
          material.

    (20)  Prose was added to clarify the use of the "7bit",