Skip to main content

SMTP and MIME Extensions for Content Conversion

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4141.
Authors Dave Crocker , Kiyoshi Toyoda
Last updated 2020-01-21 (Latest revision 2005-01-21)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4141 (Proposed Standard)
Action Holders
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Scott Hollenbeck
Send notices to
Network Working Group                             K. Toyoda / PCC Draft         
                            D. Crocker / Brandenburg
   draft-ietf-fax-esmtp-conneg-13.txt                January 2005 
Expires: <06-05>

                       SMTP and MIME Extensions
                        For Content Conversion
   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.
     Copyright (C) The Internet Society (2003).  All Rights
     A message originator sometimes sends content in a form
     the recipient cannot process or would prefer not to 
     process a form of lower quality than is preferred.  
     Such content needs to be converted to a related form, 
     with the same or constrained information, such as 
     changing from color to black and white.  In a store-
     and-forward environment, it can be convenient to have 
     this conversion performed by an intermediary.  This 
     specification integrates two ESMTP extensions and 
     three MIME content headers, defining a cooperative 
     service that permits authorized, accountable content 
     form conversion by intermediaries.

1.   Introduction
     1.1. Background
     1.2. Overview
     1.3. Notational Conventions
2.   Applicability
3.   Service Specification
     3.1. Sending Permission
     3.2. Returning Capabilities
     3.3. Next-Hop Non-Support of Service
4.   Content Conversion Permission SMTP Extension
     4.1. Content Conversion Permission Service Extension
     4.2. CONPERM Parameter to Mail-From
     4.3. Syntax
5.   Content Negotiation SMTP extension
     5.1. Content Negotiation Service Extension Definition
     5.2. CONNEG parameter to RCPT-TO
     5.3. Syntax
6.   MIME Content-Features Header
7.   MIME Content-Convert Header
8.   MIME Content-Previous Header
9.   Examples
     8.1. CONPERM Negotiation
     8.2. Example CONNEG Negotiation
     8.3. Content-Previous
10.   IANA Considerations
11.  Security Considerations
12.  Acknowledgements
13.  References
14.  Authors' Addresses
15.  Intellectual Property Statement
16.  Full Copyright Statement
Appendix A:   CONNEG with Direct SMTP
Appendix B.   USING Combinations of the Extensions

     Internet specifications typically define common
     capabilities that are supported by all participants
     for a particular service.  This permits sending basic
     data without needing to know the additional
     capabilities supported by individual recipients.
     However, knowing those capabilities permits sending
     additional types of data and data of enhanced richness.
     Otherwise, a message originator is faced with sending
     content in a form the recipient cannot process or with
     sending multiple forms of data.  This specification extends 
     the work of [CONMSG] which permits a recipient to solicit 
     alternative content forms from the originator. The current 
     specification enables MIME content conversion by 
     intermediaries, on behalf of a message originator and a 
     message recipient.

1.1.      Background
     MIME enables distinguishing and labeling different
     types of content. However an email originator cannot know
     whether a recipient is able to support (interpret) any
     particular data type. In order to permit basic use of
     MIME, a minimum set of data types are specified as its
     support base. How is an originator to know whether a
     recipient can support any other types?
     A mechanism for describing MIME types is specified in
     [FEAT]. A mechanism that permits an originator to query
     a recipient about the types it supports, by using email
     messages for the control exchange, is specified in
     [CONMSG]. In particular, this permits a recipient to
     propagate information about its capabilities back to an
     originator. Obviously, using end-to-end email messages
     for the control exchange introduces considerable
     latency and some unreliability.
     An alternative approach is for an originator to use the
     "best" form of data that it can, to include the same types 
     of permitted representation information used in [CONMSG], 
     and hope that the recipient, or an intermediary, can translate 
     this into a form that is supported by a limited recipient. 
     This specification defines such a mechanism. It defines a 
     means of matching message content form to the capabilities of 
     a recipient device or system, by using MIME content descriptors 
     and the optional use of an SMTP-based negotiation mechanism.

1.2.      Overview
     An originator describes desirable content forms, in
     MIME content descriptors.  It further may give
     "permission", to any intermediary or the recipient, to
     convert the content to only one of those forms.
     Separately, an SMTP server may report the target's
     content capabilities back to the SMTP client.  The
     client is then able to convert message content to a
     form that is both supported by the target system and is
     acceptable to the originator.
     A conversion service needs to balance between
     directions provided by the originator, directions
     provided on behalf of the recipient, and capabilities of 
     the intermediary that is performing the conversions.  This
     is made more complex by needing to distinguish between
     such directions being merely advisory, versus having
     them intended as requirements.  Conversions that are
     specified as advisory are performed if possible, but
     they do not alter message delivery.  In contrast,
     conversion specifications that are treated as a
     requirement prohibit delivery if the recipient will be
     unable to process the content.
     These possibilities interact to form different
     processing scenarios, in the event the intermediary
     cannot satisfy the desires of both the originator and
     the recipient:
               Table 1: FAILURE HANDLING
          \  RECEIVER|          |          |
           +-------+ |  Advise  | Require  |
          ORIGINATOR\|          |          |
                     | Deliver  | Deliver  |
          Advise     | original | original |
                     | content  | content  |
                     | Return   | Return   |
          Require    | w/out    | w/out    |
                     | delivery | delivery |
     This table reflects a policy that determines failure
     handling solely based on the direction provided by the
     originator.  Hence, information on behalf of the recipient
     is used to guide the details of conversion, but not to
     decide whether to deliver the message.
     This is intended to continue existing email practice of
     delivering content that a recipient might not be able
     to process.  Clearly the above table could be modified
     to reflect a different policy.  However that would
     limit the backward compatibility experienced by users.
     This specification provides mechanisms to support a
     controlled, transit-time mail content conversion
     service, through a series of mechanisms.  These
     *    an optional ESMTP hop-by-hop service that uses the
          CONPERM SMTP service extensions, issued by the originator,
     *    an optional ESMTP hop-by-hop service that uses the
          CONNEG SMTP service extensions, issued on behalf of the 
          recipient, and
     *    three MIME Content headers (Content-Convert, Content-
          Previous and Content-Features) that specify appropriate
          content headers and record conversions that have been
       +------------+                      +-----------+
       | Originator |                      | Recipient |
       +------------+                      +-----------+
            ||Posting                   Delivering/\
            \/                                    ||
        +--------+    +-----------------+    +--------+
        |  SMTP  |    |    SMTP Relay   |    |  SMTP  |
        | Client |--->| Server | Client |--->| Server |
        +--------+    +--------+--------+    +--------+

1.3.      Notational Conventions
     In examples, "C:" and "S:" indicate lines sent by the
     client and server respectively.
     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD
     NOT" and "MAY" in this document are to be interpreted
     as defined in "Key words for use in RFCs to Indicate
     Requirement Levels" [KEYWORDS].

     This specification defines a cooperative mechanism that
     facilitates early transformation of content. The mechanism
     can be used to save bandwidth and to permit rendering on
     recipient devices that have limited capabilities. In the
     first case, the assumption is that conversion will produce
     smaller content. In the latter case, the assumption is that
     the recipient device can render content in a form that can be
     derived from the original, but that the device cannot render
     the original form.
     The mechanism can impose significant resource requirements on
     an intermediary doing conversions. Further, the intermediary
     accepts responsibility for conversion prior to knowing
     whether it can perform the conversion.  Also note that
     conversion is not possible for content that has been
     digitally signed or encrypted, unless the converting
     intermediary can decode and re-code the content.

     This service integrates two ESMTP extensions and three
     MIME content headers, to permit authorized, accountable
     content form conversion by intermediaries.
     Intermediaries are ESMTP hosts (clients and servers)
     along the transmission path between an originator and a
     An originator specifies preferred content-types through
     the Content-Convert MIME content header. The content
     headers occur in each MIME body-part to which they
     apply.  That is, each MIME body-part contains its own
     record of conversion guidance and history.
     The originator's preferences are raised to the level
     of requirement, through the ESMTP CONPERM service
     extension.  The CONPERM mechanism is only needed when
     an originator requires that conversion limitations be
     enforced by the mail transfer service.  If an acceptable 
     content type cannot be delivered, then no delivery is to 
     take place.
     Target system capabilities are communicated in SMTP
     sessions through the ESMTP CONNEG service extension.
     This information is used to restrict the range of
     conversions that may be performed, but does not affect
     When CONPERM is used, conversions are performed by the 
     first ESMTP host that can obtain both the originator's 
     permission and information about the capabilities that can 
     be supported on behalf of the recipient. If a relay or 
     client is unable to transmit the message to a next-hop 
     that supports CONPERM or to perform appropriate conversion, 
     then it terminates message transmission and returns a [DSN,
     DSNFMT, DSNCOD] to the originator, with status code 5.6.3 
     (Conversion required but not supported).
     When an SMTP relay or server performs content
     conversion, it records which specific conversions are
     made, into Content-Previous and Content-Features MIME
     headers associated with each, converted MIME body-part.
     If a message is protected by strong content authentication or
     privacy techniques, then an intermediary that converts message
     content MUST ensure that the results of its processing are
     similarly protected.  Otherwise it MUST NOT perform conversion.
     Originator Action:
          An originator specifies desired conversion
     results, through the MIME Content-Convert header. If the
     originator includes a Content-Convert header, then they must
     also include a Content-Feature header, to describe the current
     form of the content. Intermediaries MAY interpret the presence of 
     this header as authorization to perform conversions. When 
     Content- Convert headers are the sole means for guiding 
     conversions by intermediaries, then they serve only as 
     advisories.  In particular, failure to satisfy the 
     guidance of these headers does not affect final delivery.
          The originator MAY also specify transit-service
     enforcement of conversion limitations by using the
     ESMTP CONPERM service extension when posting a new
     message.  Conversions MUST be limited to those
     specified in MIME Content-Convert headers, in each of 
     the MIME body-parts for which conversion is authorized.  
     If conversion is needed, but an authorized conversion
     cannot be performed, then the message is returned to
     the originator.  If CONPERM is not used, then failure
     to perform an authorized conversion does not affect
     normal delivery handling.
     Figure 2: CONPERM USAGE
     | Originator |
      SMTP  ||
       or   || CONPERM
     SUBMIT \/
        +--------+            +----------------+
        |  SMTP  |   SMTP     |    SMTP Relay  |
        | Client |----------->| Server |       |
        +--------+  CONPERM   +--------+-------+
     Recipient Action:
          With the ESMTP mail transfer service, capabilities that can 
     be supported on behalf of the recipient SHOULD be communicated to 
     intermediaries by the ESMTP CONNEG service extension.
     Figure 3: CONNEG USAGE
                                           | Recipient |
                  +----------------+         +--------+
                  |   SMTP Relay   |  CONNEG |  SMTP  |
                  |       | Client |<--------| Server |
                  +-------+--------+         +--------+
     Intermediary Actions:
          An intermediary MAY be given CONPERM direction
     when receiving a message, and MAY be given CONNEG
     guidance, before sending the message.  CONPERM and
     CONNEG operate on a per-message basis.  Therefore they
     are issued through the ESMTP MAIL-FROM request.  CONNEG
     response information is provided on a per-recipient
     basis, through the response to ESMTP RCPT-TO.
          Conversion MUST be performed by the first CONPERM intermediary
     that obtains CONNEG capability information. The MIME
     Content-Type MUST conform to the result of the converted content,
     as per [MEDTYP]. When an intermediary obtains different capability
     information for different recipients of the same message, it MAY
     *    Create a single, converted copy of the content that can
          be supported by all of the recipients, or
     *    Create multiple converted copies, matching the
          capabilities of subsets of the recipients.  Each version is
          then sent separately, to an appropriate subset of the
          recipients, using separate, standard SMTP sessions with
          separate, standard RFC2821.Rcpt-To lists of addresses.
          A record of conversions is placed into MIME
     Content-Previous headers.  The current form of the
     content is described in MIME Content-Features headers.
          A special case of differential capabilities occurs
     when an intermediary receives capability information
     about some recipients, but no information about others.
     An example of this scenario can occur when sending a
     message to some recipients within one's own
     organization and other recipients located elsewhere.
     The intermediary might have capability information
     about the local recipients, but will not have any for
     distant recipients.  This is treated as a variation of
     the handling that is required for situations in which 
     the permissible conversions are the null set -- that is, 
     no valid conversions are possible for a recipient.
     Rather than simply failing transmission to the recipients for
     which there is no capability information, the intermediary MAY
     choose to split the list of addressees into subsets of separate, 
     standard RFC2821.Rcpt-To lists and separate, standard SMTP 
     sessions, and then continue the transmission of the original
     content to those recipients, via the continued use of the CONPERM 
     mechanism.  Hence, the handling for such recipients is performed 
     as if no CONNEG transaction took place.
          Once an intermediary has performed conversion, it
     MAY terminate use of CONPERM.  However some relay
     environments, such as those re-directing mail to a new
     target device, will benefit from further conversion.
     Intermediaries MAY continue to use CONPERM or MAY re-
     initiate CONPERM use, when they have knowledge about
     possible variations in target device.
        A new, transformed version of content may have less
        information than the earlier version. Of course, a sequence of
        transformations may lose additional information at each step.
        Perhaps surprisingly, this can result in more loss than might
        otherwise be necessary. For example, transformation x could
        change content form A to content form B, and then
        transformation y change B to C. However it is possible that
        transformation y could have accepted form A directly and
        produced form D which has more of the original information
        than C.
        An originator MAY validate any conversions that are made by
        requesting a positive [DSN].  If the DSN request includes the 
        "RET" parameter, the delivery agent SHOULD return an exact copy 
        of the delivered (converted) message content. This will permit 
        the originator to inspect the results of any conversion(s).

3.1.      Sending Permission
     A message originator that permits content conversion by
     intermediaries MAY use the CONPERM ESMTP service
     extension and Content-Convert MIME headers to indicate
     what conversions are permitted by intermediaries.
     Other mechanisms by which a message originator
     communicates this permission to the SMTP message
     transfer service are outside the scope of this
          This option requires that a server make an open-ended 
          commitment to ensure that acceptable conversions are 
          performed. In particular, it is possible that an 
          intermediary be required to perform conversion but be 
          unable to do so. This will result intermediary will be 
          required to perform conversion but will be in undelivered 
     When an ESMTP client is authorized to participate in
     the CONPERM service it MUST interact with the next SMTP
     hop server, about:
     *    The server's ability to enforce authorized conversions,
          through ESMTP CONPERM
     *    The capabilities supported for the target device or
          system, through ESMTP CONNEG
     Successful use of CONPERM does not require that
     conversion take place along the message transfer path.
     Rather, it requires that conversion take place whenever
     a next-hop server reports capabilities that can be supported on 
     behalf of the recipient, through CONNEG, and those capabilities do 
     not include support for the current representation of the content.
          It is acceptable to have every SMTP server -- including
          the last-hop server -- support CONPERM, with none
          offering CONNEG.  In this case, the message is
          delivered to the recipient in its original form.  Any
          possible conversions to be performed are left to the
          recipient.  Hence the recipient is given the original
          form of the content, along with an explicit list of
          conversions that the originator deems acceptable.
     An SMTP server MAY offer ESMTP CONPERM, without being
     able to perform conversions, if it knows that
     conversions can be performed along the remainder of the 
     transfer path, or by the target device or system.

3.2.      Returning Capabilities
     A target recipient device or system arranges announcement of its
     content form capabilities to the SMTP service through a
     means outside the scope of this specification.  Note that 
     enabling a server to issue CONNEG information on behalf 
     of the recipient may require substantial mechanism between the 
     recipeint and the server. When an ESMTP server knows a target's 
     capabilities, it MAY offer the CONNEG ESMTP service extension.
          One aspect of that mechanism, between the recipient and an 
          ESMTP server offering the CONNEG ESMTP service extension, 
          could include offering capabilities that are beyond those 
          directly supported by the recipient. In particular, the 
          server -- or other intermediaries between the server and the 
          recipient -- could support capabilities that they can convert 
          to a recipient's capability. As long as the result is 
          acceptable to the set specified in the relevant Content-
          Convert headers of the message being converted, the details 
          of these conversions are part of the recipient/server 
          mechanism that is outside  the scope of the current 
     When a message is being processed according to the
     CONPERM mechanism, if a next-hop ESMTP server responds
     that it supports CONNEG, then the SMTP client:
     (1)  MUST request CONNEG information
     (2)  MUST perform the requisite conversions, if possible,
          before sending the message to the next-hop SMTP server
     (3)  MUST fail message processing, if any conversion for the
          message fails and MUST return a failure DSN to the
          originator, with status code 5.6.5  (Conversion failed).
     When performing conversions, as specified in Content-
     Convert MIME headers, the Client MUST:
     (1)  Add a Content-Previous header and a Content-Features
          header to each MIME body-part that has been converted.
          removing any existing Content-Features header.
     (2)  Either:
          *    Send a single copy to the next-hop SMTP server, using a
               best capabilities that are supported to all recipients 
               along that path, or
          *    Separate the transfers into multiple, standard 
               RFC2821.Rcpt-To and ESMTP sessions, in order to provide 
               the best conversions possible for subsets of the 
     If the transfers are to be separated, then the current
     session MUST be terminated, and new sessions conducted
     for each subset.
     The conversions that are performed are determined by
     the intersection of three lists:
     *    Conversions permitted by the originator
     *    Content capabilities of the target
     *    Conversions that can be performed by the SMTP client
     Failed Conversion
     If the result of this intersection is the null set of
     representations, for an addressee, then delivery to
     that addressee MUST be handled as a conversion failure.
     If handling is subject to the CONPERM mechanism and:
     *    the next-hop SMTP host does not indicate that it can
          represent the target's capabilities through CONNEG, but
     *    does respond that it can support CONPERM,
     then the client SMTP MUST send the existing content,
     if all other SMTP transmission requirements are
     If handling is not subject to the CONPERM mechanism,
     then conversion failures do not affect message

3.3.      Next-Hop Non-Support of Service
     If a Client is participating in the CONPERM mechanism,
     but the next-hop SMTP server does not support CONPERM
     and does not support CONNEG, then the SMTP client
     (1)  MUST terminate the session to the next-hop SMTP server,
          without sending the message
     (2)  MUST return a DSN notification to the originator, with status
          code 5.6.3 (Conversion required but not supported). [DSN,
          DSNFMT, SYSCOD]
     If a Client is participating in the CONPERM mechanism
     and the next-hop SMTP server supports CONNEG but
     provides no capabilities for an individual RCPT-TO
     addressee, then the SMTP client's processing for that
     recipient MUST be either to:
     (1)  Treat the addressee as a conversion failure, or
     (2)  Separate the addressee from the address list that is
          processed according to CONNEG, and continue to process the
          addressee according to CONPERM.


4.1.      Content Conversion Permission Service Extension
     (1)  The name of the SMTP service extension is
     (2)  The EHLO keyword value associated with this extension
     (3)  A parameter using the keyword "CONPERM" is added to the
          MAIL-FROM command.
     (4)  The server responds with acceptance or rejection of
          support for CONPERM, for this message.

4.2.      CONPERM Parameter to Mail-From
          There are no arguments.  Specification of
     permitted conversions is located in a Content-Convert
     header for each MIME body-part for which conversion is
     Client Action:
          If the server issued a 250-CONPERM, as part of its
     EHLO response for the current session and the client is
     participating in the CONPERM service for this message -
     - such as by having received the message with a CONPERM
     requirement -- then the client MUST issue the CONPERM
     parameter in the MAIL-FROM.  If the server does not
     issue 250-CONPERM, and the client is participating in
     the CONPERM service for this message, then the client
     MUST treat the transmission as permanently rejected.
     Server Action:
          If the client specifies CONPERM in the MAIL-FROM,
     but the server does not support the CONPERM parameter,
     the server MUST reject the MAIL-FROM command with a 504-
     CONPERM reply.
          If the client issues the CONPERM parameter in the
     MAIL-FROM, then the server MUST conform to this
     specification.  Either it MUST relay the message
     according to CONPERM, or it MUST convert the message
     according to CONNEG information.

4.3.      Syntax
     Content_Conversion_Permission =    "CONPERM"

5.1.      Content Negotiation Service Extension Definition
     (1)  The name of the SMTP service extension is:
     (2)  The EHLO keyword value associated with this extension
     (3)  A parameter using the keyword "CONNEG" is added to the
          RCPT-TO command
     (4)  The server responds with a report indicating the content
          capabilities that can be received on behalf of the recipient 
          device or system, associated with the target RCPT-TO address 

5.2.      CONNEG parameter to RCPT-TO
          There are no arguments.
     Client Action:
          If a message is subject to CONPERM requirements and
     the server issues a 250-CONNEG, as part of its EHLO
     response for the current session, the client MUST issue
     the CONNEG parameter in the RCPT-TO request.  If the
     message is not subject to CONPERM requirements and the
     server issues a 250-CONNEG, the client MAY issue the
     CONNEG parameter with RCPT-TO.
          If the client issues the CONNEG parameter with
     RCPT-TO, then it MUST honor the capabilities returned
     in the CONNEG RCPT-TO replies for that message, and it
     MUST convert the message content, if the current form
     of the content is not included in the capabilities listed, 
     on behalf of the recipient.
          The conversions that are performed are determined
     by the intersection of the:
          *    Conversions permitted by the originator
          *    Content capabilities of the target
          *    Conversions that can be performed by the SMTP client
     If the result of this intersection is the null set
     of representations, then the Client processing depends
     upon whether the next-hop server has offered CONPERM, as well as
          (1)  If the message will be subject to CONPERM at the next
               hop, the Client MAY to transmit the original content
               to the next hop, continuing CONPERM requirements.
          (2)  Otherwise, the Client MUST treat the conversion as
          If the result of the intersection is not null, the
     client SHOULD convert the data to the "highest" level
     of capability of the server.  Determination of the
     level that is highest is left to the discretion of the
     host performing the conversion.
          Each converted MIME body-part, MUST have a Content-
     Previous header that indicates the previous body-part
     form and a Content-Features header, indicating the new
     body-part form.
     Server Action:
          If the client specifies CONNEG in the RCPT-TO, but
     the server does not support the CONNEG parameter, the
     server MUST reject the RCPT-TO addressees with 504
          If the server does support the CONNEG parameter
     and it knows the capabilities of the target device or
     system, then it MUST provide that information through
     CONNEG. The server MAY provide a broader list than is 
     simply supported by the recipient, if the server can 
     ensure that the form of content finally delivered can 
     be processed by the recipient, while still satisfying 
     the constraints of the author's Content-Convert 
          The response to a CONNEG RCPT-TO request will be
     multi-line RCPT-TO replies.  For successful (250)
     responses, at least the first line of the response is
     for RCPT-TO information other than CONNEG.  Additional
     response lines are for CONNEG.  In order to avoid
     problems due to variations in line buffer sizes, the
     total parametric listing must be provided as a series
     of lines, each beginning with "250-CONNEG" except for
     the last line, which is "250 CONNEG".
          The contents of the capability listing MUST
     conform to the specifications in [SYN] and covers the 
     same range of specifications permitted in [CONMSG].

5.3.      Syntax
     Content_Negotiation =    "CONNEG"
     Capability =             <<as per [SYN]>>

     The Content-Features header describes the characteristics 
     of the current version of the content for the MIME 
     body-part in which the header occurs.  There is a separate 
     Content-Features header for each MIME body-part.  
     The specification for this header is contained in

     Content-Convert is a header field that specifies preferred 
     conversions for the associated content.  It MAY be used 
     without the other mechanisms defined in this document.  
     If present, this header MUST be carried unmodified and 
     delivered to the recipient. In its absence the content 
     originator has provided no guidance about content conversions, 
     and intermediaries SHOULD NOT perform content conversion.
     In the extended ABNF notation, the Content-Convert
     header field is defined as follows:
     Convert =                "Content-convert" ":"
     Permitted =              "ANY" / "NONE" /
                              <<permitted conversions, per
                              [SYN] RFC2533.Filter syntax>>
     If the permitted conversions are specified as "ANY"
     then the intermediary may perform any conversions it
     deems appropriate.
     If the permitted conversions are specified as "NONE"
     then the intermediary SHOULD NOT perform any
     conversions to this MIME body-part, even when the
     target device or system does not support the original
     form of the content.
     If a Content-Convert header is present, then a Content-
     Features header MUST also be present, to describe the 
     current form of the Content.

     When an intermediary has performed conversion of the
     associated content, the intermediary MUST record
     details of the previous representation, from which the
     conversion was performed.  This information is placed
     in a Content-Previous header that is part of the
     MIME body-part with the converted content.  There is
     a separate header for each, converted MIME body-part.
     When an intermediary has performed conversion, the
     intermediary MUST record details of the result of the
     conversion that was performed, by creating or revising 
     the Content-Features header for the MIME body-part that 
     was converted.
     In the extended [ABNF] notation, the Content-Previous
     header field is defined as follows:
     previous =          "Content-Previous" [CFWS] ":"
                         date by type
     date =              "Date " [CFWS] date-time [CFWS]";"
     by =                "By " [CFWS] domain [CFWS]";"
     type =              <<content characteristics, per
                         [SYN], without alternatives>>
     The Date field specifies the date and time at which the
     indicated representation was converted into a newer
     The By field specifies the domain name of the
     intermediary that performed the conversion.
     An intermediary MAY choose to derive the Content-
     Previous header, for a body-part, from an already-
     existing Content-Features header in that body-part,
     before that header is replaced with the description of
     the current representation.


9.1.      CONPERM Negotiation
     S: 220 IFAX
     C: EHLO
     S: 250-
     S: 250-DSN
     S: 250 CONPERM
     S: 250 <> originator ok
     C: RCPT TO:<>
     S: 250-<> recipient ok
     C: DATA
     S: 354 okay, send data
     C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
        (  image-file-structure=TIFF-minimal
        with MIME body-parts including:
                 (dpi-xyratio=[204/98,204/196]) )
                 (dpi-xyratio=[200/100,1]) )
                 (dpi-xyratio=1) ) )
                 (JBIG-stripe-size=128) ) )
             (ua-media=stationery) )
     S: 250 message accepted
     C: QUIT
     S: 221 goodbye

9.2.      Example CONNEG Negotiation
     S: 220 IFAX
     C: EHLO
     S: 250-
     S: 250-DSN
     S: 250 CONNEG
     C: MAIL FROM:<>
     S: 250 <> originator ok
     S: 250-<> recipient ok
     S: 250-CONNEG (&(image-file-structure=TIFF-minimal)
     S: 250-CONNEG   (MRC-mode=0)
     S: 250-CONNEG   (color=Binary)
     S: 250-CONNEG   (|(&(dpi=204)
     S: 250-CONNEG       (dpi-xyratio=[204/98,204/196]) )
     S: 250-CONNEG     (&(dpi=200)
     S: 250-CONNEG       (dpi-xyratio=[200/100,1]) ) )
     S: 250-CONNEG   (image-coding=[MH,MR,MMR])
     S: 250-CONNEG   (size-x<=2150/254)
     S: 250-CONNEG   (paper-size=[letter,A4])
     S: 250 CONNEG   (ua-media=stationery) )
     C: DATA
     S: 354 okay, send data
     C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
          (  image-file-structure=TIFF-minimal
     S: 250 message accepted
     C: QUIT
     S: 221 goodbye

9.3.      Content-Previous
        Date  Tue, 1 Jul 2001 10:52:37 +0200;
            (dpi-xyratio=1) )
            (JBIG-stripe-size=128) )
          (ua-media=stationery) )

     There are no IANA considerations regarding this document.

     This service calls for disclosure of capabilities, on
     behalf of recipients.  Mechanisms for determining the
     requestor's and the respondent's authenticated identity
     are outside the scope of this specification.  It is
     intended that these mechanisms permit disclosure of
     information that can safely be public; hence there is
     no inherent need for security measures.
     Information that should receive restricted distribution
     is still able to be disclosed.  It is, therefore, the
     responsibility of the disclosing ESMTP server or
     disclosing ESMTP client to determine whether additional
     security measures should be applied to the use of this
     ESMTP option.
     Use of the ESMTP CONNEG option permits content transformation
     by an intermediary, along the mail transfer path.  When
     the contents are encrypted, the intermediary cannot perform
     the conversion, since it is not expected to have access to the
     relevant secret keying material.  When the contents are signed,
     but not encrypted, conversion will invalidate the signature.
     This specification provides for potentially unbounded computation
     by intermediary MTAs, depending upon the nature and amount 
     of conversion required.  Further, this computation burden might 
     provide an opportunity for denial-of-service attacks, given that 
     Internet mail typically permits intermediaries to receive messages 
     from all Internet sources.
     This specification provides for content conversion by 
     unspecified intermediaries. Use of this mechanism 
     carries significant risk. Although intermediaries 
     always have the ability to perform damaging 
     transformations, use of this specification could result 
     in more exploration of that potential and, therefore, 
     more misbehavior. Use of intermediaries is discussed 
     in [RFC3238].
     Conperm/Conneg provide a cooperative mechanism, rather than
     enabling intermediary actions that have not previously been
     possible. Intermediaries already can and do make conversions
     on their own initiative. Hence the mechanism introduces
     essentially no security concerns, other than divulging
     recipient preferences.

     Graham Klyne and Eric Burger provided extensive,
     diligent reviews and suggestions. Keith Moore, Giat
     Hana and Joel Halpern provided feedback that resulted 
     in improving the specification's integration into 
     established email practice.

13.       REFERENCES
     [ABNF]         Crocker, D., Overell, P., "Augmented BNF for Syntax 
                    Specifications: ABNF",  RFC 2234, November 1997.
     [KEYWORDS]     Bradner, S., "Key words for use in RFCs to 
                    Indicate Requirement Levels", RFC2119, March 1997
     [CONMSG]       Klyne, G., Iwazaki, R., Crocker. D., ,
                    "Content Negotiation for Messaging
                    Services based on Email", RFC 3297, July
     [DISP]         Masinter, L., Holtman, K., Mutz, A. and
                    D. Wing, "Media Features for Display,
                    Print, and Fax", RFC 2534, March 1999.
     [DSN]          Moore, K. "Simple Mail Transfer Protocol (SMTP) 
                    Service Extension for Delivery Status 
                    Notifications (DSNs)", RFC 3461, January 2003
     [DSNFMT]       K. Moore and G. Vaudreuil, "An Extensible Message
                    Format for Delivery Status Notifications", 
                    RFC 3464, January 2003.
     [DSNSMTP]      Moore, K. "Simple Mail Transfer Protocol (SMTP) 
                    Service Extension for Delivery Status Notifications
                    (DSNs)",RFC 3461, January 2003
     [SYSCOD]       Vaudreuil, G., "Enhanced Mail System Status 
                    Codes", RFC3463, January 2003.
     [ESMTP1]       Klensin, J., Freed, N., Rose, M.,
                    Stefferud, E. and D. Crocker, "SMTP
                    Service Extensions", RFC 1869, November
     [ESMTP2]       Klensin, J., "Simple Mail Transfer
                    Protocol", RFC 2821, April 2001.
     [FEAT]         Klyne, G., "Indicating Media Features
                    for MIME Content", RFC 2912, September
     [IMF]          Resnick, P., "Internet Message Format",
                    RFC 2822, April 2001
     [SYSCOD]       Vaudreuil, G., "Enhanced Mail System Status Codes", 
                    RFC 3463, January 2003.
     [TAG]          Holtman, K., Mutz, A. and T. Hardie,
                    "Media Feature Tag Registration
                    Procedure", RFC 2506, March 1999.
     [SYN]          Klyne, G. "A Syntax for Describing Media
                    Feature Sets", RFC 2533, March 1999
     [MEDTYP]        IANA, "MIME Media Types", 

     [RFC3238]      Floyd, S., Daigle, L., "IAB Architectural 
                    and Policy Considerations for Open Pluggable 
                    Edge Services", RFC 3238, January 2002

     Kiyoshi Toyoda
     Panasonic Communications Co., Ltd.
     4-1-62 Minoshima Hakata-ku, Fukuoka 812-8531 Japan
     Dave Crocker
     Brandenburg InternetWorking
     675 Spruce Drive
     Sunnyvale, CA  94086  USA
     Tel: +1.408.246.8253

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.
   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive

   Copyright (C) The Internet Society (year). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.
   This document and the information contained herein are provided on an

     This Appendix is descriptive.  It only provides 
     discussion of usage issues permitted or required by 
     the normative text
     In some configurations it is possible to have direct
     email-based interactions -- where the originator's
     system conducts a direct, interactive TCP connection
     with the recipient's system.  This configuration
     permits a use of the content form negotiation service
     that conforms to the specification here, but permits
     some simplifications.  This single SMTP session does
     not have the complexity of multiple, relaying sessions
     and therefore does not have the requirement for
     propagating permissions to intermediaries.
     The Originator's system provides user-level functions
     for the originator, and it contains the SMTP Client for
     sending messages. Hence, the formal step of email
     "posting" is a process that is internal or virtual,
     within the Originating system.  The recipient's service
     contains the user-level functions for the recipient,
     and it contains the SMTP server, for receiving
     messages. Hence the formal steps of email "delivering"
     and "receipt" are internal or virtual, within the
     Receiving system.
     Figure 4: DIRECT CONNEG
      Originating system          Receiving system
     +------------------+       +------------------+
     |  +------------+  |       |   +-----------+  |
     |  | Originator |  |       |   | Recipient |  |
     |  +------------+  |       |   +-----------+  |
     |       ||Posting  |       |      /\Receiving |
     |       \/         |       |      ||          |
     |   +---------+    |       |    +--------+    |
     |   |  SMTP   |<---|-------|----|  SMTP  |    |
     |   | Client  |----|-------|--->| Server |    |
     |   +---------+    |       |    +--------+    |
     +------------------+       +------------------+
     In this case CONPERM is not needed, because the SMTP
     Client is part of the originating system.  Therefore it
     already has the necessary permission.  Similarly, the
     SMTP server will be certain to know the recipient's
     capabilities, because the server is part of the
     receiving system.
     Therefore, Direct Mode email transmission can achieve
     content capability and form matching by having:
     *    Originating systems that conform to this specification
          and a communication process between originator and recipient
          that is the same as would take place between a last-hop SMTP
          Relay and the Delivering SMTP server it connects to.
     *    That is, the Client and Server MUST employ CONNEG and
          the Client MUST perform any requisite conversions.

     This specification defines a number of mechanisms.  It is not 
     required that they all be used together.  For example, the 
     difference between listing preferred conversions, versus 
     specifying enforced limitations to conversions, is discussed in
     the Introduction. This Appendix further describes some scenarios 
     which might call for using fewer than the complete set that is
     defined in this specification. It also summarizes the conditions 
     which mandate that an intermediary perform conversion.
     This Appendix is descriptive.  It only provides discussion of 
     usage issues permitted or required by the normative text
     The available mechanisms are:
     1.   CONPERM Parameter to Mail-From
     2.   CONNEG parameter to RCPT-TO
     3.   MIME Content-Convert Header
     4.   MIME Content-Previous Header
     5.   MIME Content-Features Header
B.1  Specifying Suggested Conversion Constraints
     Use of the MIME Content-Convert header specifies the originator's 
     preferences, should conversion be performed.  This does not impose
     any requirements on the conversion, but instead is merely advisory.

B.2  Specifying Required Conversion Constraints
     When the MIME Content-Convert specification is coupled with the 
     ESMTP CONPERM option, then the originator's specification of
     preferred conversions rises to the level of requirement. No other
     conversions are permitted, except those specified in the Content-
     Convert header.  
     Note that the presence of both these mechanisms does not require
     that conversions be performed.  Rather, it constrains conversions,
     should they occur.  
B.3  Accepting All Forms of Content
     Although it is unlikely that any device is always able to process 
     every type of existing content, some devices can be upgraded 
     easily, such as by adding plug-in.  Hence such a device 
     effectively is able to process all content.  
     For such devices, it is better to refrain from issuing a CONNEG 
     assertion.  Instead, the CONPERM request should be propagated all 
     the way to the target device.
B.4  When Conversion is Required
     A node is required to perform conversion when:
          1. At least one MIME Content-Covert header is present in 
             the message, 
          2. ESMTP CONPERM is in force at the node processing the 
          3. ESMTP CONNEG is also in force at the same node, 
          4. The current content form is not cited in the CONNEG 
          5. At least one content form is present both in the 
             Content-Convert list and the CONNEG list, and
          6. The intermediary is able to convert from the current 
             form to one of the forms listed in both Content-Convert 
             and Conneg.