rfc2046.txt

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

   A media type of "image" indicates that the body contains an image.
   The subtype names the specific image format.  These names are not
   case sensitive. An initial subtype is "jpeg" for the JPEG format
   using JFIF encoding [JPEG].

   The list of "image" subtypes given here is neither exclusive nor
   exhaustive, and is expected to grow as more types are registered with
   IANA, as described in RFC 2048.

   Unrecognized subtypes of "image" should at a miniumum be treated as
   "application/octet-stream".  Implementations may optionally elect to
   pass subtypes of "image" that they do not specifically recognize to a
   secure and robust general-purpose image viewing application, if such
   an application is available.

   NOTE: Using of a generic-purpose image viewing application this way
   inherits the security problems of the most dangerous type supported
   by the application.

4.3.  Audio Media Type

   A media type of "audio" indicates that the body contains audio data.
   Although there is not yet a consensus on an "ideal" audio format for
   use with computers, there is a pressing need for a format capable of
   providing interoperable behavior.

   The initial subtype of "basic" is specified to meet this requirement
   by providing an absolutely minimal lowest common denominator audio
   format.  It is expected that richer formats for higher quality and/or
   lower bandwidth audio will be defined by a later document.

   The content of the "audio/basic" subtype is single channel audio
   encoded using 8bit ISDN mu-law [PCM] at a sample rate of 8000 Hz.

   Unrecognized subtypes of "audio" should at a miniumum be treated as
   "application/octet-stream".  Implementations may optionally elect to
   pass subtypes of "audio" that they do not specifically recognize to a
   robust general-purpose audio playing application, if such an
   application is available.

4.4.  Video Media Type

   A media type of "video" indicates that the body contains a time-
   varying-picture image, possibly with color and coordinated sound.
   The term 'video' is used in its most generic sense, rather than with
   reference to any particular technology or format, and is not meant to
   preclude subtypes such as animated drawings encoded compactly.  The
   subtype "mpeg" refers to video coded according to the MPEG standard
   [MPEG].

   Note that although in general this document strongly discourages the
   mixing of multiple media in a single body, it is recognized that many
   so-called video formats include a representation for synchronized
   audio, and this is explicitly permitted for subtypes of "video".

   Unrecognized subtypes of "video" should at a minumum be treated as
   "application/octet-stream".  Implementations may optionally elect to
   pass subtypes of "video" that they do not specifically recognize to a
   robust general-purpose video display application, if such an
   application is available.

4.5.  Application Media Type

   The "application" media type is to be used for discrete data which do
   not fit in any of the other categories, and particularly for data to
   be processed by some type of application program.  This is
   information which must be processed by an application before it is
   viewable or usable by a user.  Expected uses for the "application"
   media type include file transfer, spreadsheets, data for mail-based
   scheduling systems, and languages for "active" (computational)
   material.  (The latter, in particular, can pose security problems
   which must be understood by implementors, and are considered in
   detail in the discussion of the "application/PostScript" media type.)

   For example, a meeting scheduler might define a standard
   representation for information about proposed meeting dates.  An
   intelligent user agent would use this information to conduct a dialog
   with the user, and might then send additional material based on that
   dialog.  More generally, there have been several "active" messaging
   languages developed in which programs in a suitably specialized
   language are transported to a remote location and automatically run
   in the recipient's environment.

   Such applications may be defined as subtypes of the "application"
   media type. This document defines two subtypes:

   octet-stream, and PostScript.

   The subtype of "application" will often be either the name or include
   part of the name of the application for which the data are intended.
   This does not mean, however, that any application program name may be
   used freely as a subtype of "application".

4.5.1.  Octet-Stream Subtype

   The "octet-stream" subtype is used to indicate that a body contains
   arbitrary binary data.  The set of currently defined parameters is:

    (1)   TYPE -- the general type or category of binary data.
          This is intended as information for the human recipient
          rather than for any automatic processing.

    (2)   PADDING -- the number of bits of padding that were
          appended to the bit-stream comprising the actual
          contents to produce the enclosed 8bit byte-oriented
          data.  This is useful for enclosing a bit-stream in a
          body when the total number of bits is not a multiple of
          8.

   Both of these parameters are optional.

   An additional parameter, "CONVERSIONS", was defined in RFC 1341 but
   has since been removed.  RFC 1341 also defined the use of a "NAME"
   parameter which gave a suggested file name to be used if the data
   were to be written to a file.  This has been deprecated in
   anticipation of a separate Content-Disposition header field, to be
   defined in a subsequent RFC.

   The recommended action for an implementation that receives an
   "application/octet-stream" entity is to simply offer to put the data
   in a file, with any Content-Transfer-Encoding undone, or perhaps to
   use it as input to a user-specified process.

   To reduce the danger of transmitting rogue programs, it is strongly
   recommended that implementations NOT implement a path-search
   mechanism whereby an arbitrary program named in the Content-Type
   parameter (e.g., an "interpreter=" parameter) is found and executed
   using the message body as input.

4.5.2.  PostScript Subtype

   A media type of "application/postscript" indicates a PostScript
   program.  Currently two variants of the PostScript language are
   allowed; the original level 1 variant is described in [POSTSCRIPT]
   and the more recent level 2 variant is described in [POSTSCRIPT2].

   PostScript is a registered trademark of Adobe Systems, Inc.  Use of
   the MIME media type "application/postscript" implies recognition of
   that trademark and all the rights it entails.

   The PostScript language definition provides facilities for internal
   labelling of the specific language features a given program uses.
   This labelling, called the PostScript document structuring
   conventions, or DSC, is very general and provides substantially more
   information than just the language level.  The use of document
   structuring conventions, while not required, is strongly recommended
   as an aid to interoperability.  Documents which lack proper
   structuring conventions cannot be tested to see whether or not they
   will work in a given environment.  As such, some systems may assume
   the worst and refuse to process unstructured documents.

   The execution of general-purpose PostScript interpreters entails
   serious security risks, and implementors are discouraged from simply
   sending PostScript bodies to "off- the-shelf" interpreters.  While it
   is usually safe to send PostScript to a printer, where the potential
   for harm is greatly constrained by typical printer environments,
   implementors should consider all of the following before they add
   interactive display of PostScript bodies to their MIME readers.

   The remainder of this section outlines some, though probably not all,
   of the possible problems with the transport of PostScript entities.

    (1)   Dangerous operations in the PostScript language
          include, but may not be limited to, the PostScript
          operators "deletefile", "renamefile", "filenameforall",
          and "file".  "File" is only dangerous when applied to
          something other than standard input or output.
          Implementations may also define additional nonstandard
          file operators; these may also pose a threat to
          security. "Filenameforall", the wildcard file search
          operator, may appear at first glance to be harmless.

          Note, however, that this operator has the potential to
          reveal information about what files the recipient has
          access to, and this information may itself be
          sensitive.  Message senders should avoid the use of
          potentially dangerous file operators, since these
          operators are quite likely to be unavailable in secure
          PostScript implementations.  Message receiving and
          displaying software should either completely disable
          all potentially dangerous file operators or take
          special care not to delegate any special authority to
          their operation.  These operators should be viewed as
          being done by an outside agency when interpreting
          PostScript documents.  Such disabling and/or checking
          should be done completely outside of the reach of the
          PostScript language itself; care should be taken to
          insure that no method exists for re-enabling full-
          function versions of these operators.

    (2)   The PostScript language provides facilities for exiting
          the normal interpreter, or server, loop.  Changes made
          in this "outer" environment are customarily retained
          across documents, and may in some cases be retained
          semipermanently in nonvolatile memory.  The operators
          associated with exiting the interpreter loop have the
          potential to interfere with subsequent document
          processing.  As such, their unrestrained use
          constitutes a threat of service denial.  PostScript
          operators that exit the interpreter loop include, but
          may not be limited to, the exitserver and startjob
          operators.  Message sending software should not
          generate PostScript that depends on exiting the
          interpreter loop to operate, since the ability to exit
          will probably be unavailable in secure PostScript
          implementations.  Message receiving and displaying
          software should completely disable the ability to make
          retained changes to the PostScript environment by
          eliminating or disabling the "startjob" and
          "exitserver" operations.  If these operations cannot be
          eliminated or completely disabled the password
          associated with them should at least be set to a hard-
          to-guess value.

    (3)   PostScript provides operators for setting system-wide
          and device-specific parameters.  These parameter
          settings may be retained across jobs and may
          potentially pose a threat to the correct operation of
          the interpreter.  The PostScript operators that set
          system and device parameters include, but may not be

          limited to, the "setsystemparams" and "setdevparams"
          operators.  Message sending software should not
          generate PostScript that depends on the setting of
          system or device parameters to operate correctly.  The
          ability to set these parameters will probably be
          unavailable in secure PostScript implementations.
          Message receiving and displaying software should
          disable the ability to change system and device
          parameters.  If these operators cannot be completely
          disabled the password associated with them should at
          least be set to a hard-to-guess value.

    (4)   Some PostScript implementations provide nonstandard
          facilities for the direct loading and execution of
          machine code.  Such facilities are quite obviously open
          to substantial abuse.  Message sending software should
          not make use of such features.  Besides being totally
          hardware-specific, they are also likely to be
          unavailable in secure implementations of PostScript.
          Message receiving and displaying software should not
          allow such operators to be used if they exist.

    (5)   PostScript is an extensible language, and many, if not
          most, implementations of it provide a number of their
          own extensions.  This document does not deal with such
          extensions explicitly since they constitute an unknown
          factor.  Message sending software should not make use
          of nonstandard extensions; they are likely to be
          missing from some implementations.  Message receiving
          and displaying software should make sure that any
          nonstandard PostScript operators are secure and don't
          present any kind of threat.