diff options
Diffstat (limited to 'doc/rfc/rfc4141.txt')
| -rw-r--r-- | doc/rfc/rfc4141.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc4141.txt b/doc/rfc/rfc4141.txt new file mode 100644 index 0000000..5ab6f4e --- /dev/null +++ b/doc/rfc/rfc4141.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group K. Toyoda +Request for Comments: 4141 PCC +Category: Standards Track D. Crocker + Brandenburg + November 2005 + + + SMTP and MIME Extensions for Content Conversion + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + 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 an + acceptable form, with the same information or constrained information + (e.g., changing from color to black and white). In a store-and- + forward environment, it may be convenient to have this conversion + performed by an intermediary. This specification integrates two + ESMTP extensions and three MIME content header fields, which defines + a cooperative service that permits authorized, accountable content + form conversion by intermediaries. + + + + + + + + + + + + + + + + + + +Toyoda & Crocker Standards Track [Page 1] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Background. . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.3. Notational Conventions. . . . . . . . . . . . . . . . . . 5 + 2. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Service Specification. . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Sending Permission. . . . . . . . . . . . . . . . . . . . 9 + 3.2. Returning Capabilities. . . . . . . . . . . . . . . . . . 10 + 3.3. Next-Hop Non-Support of Service . . . . . . . . . . . . . 12 + 4. Content Conversion Permission SMTP Extension . . . . . . . . . 12 + 4.1. Content Conversion Permission Service Extension + Definition. . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.2. CONPERM Parameter to Mail-From. . . . . . . . . . . . . . 13 + 4.3. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 5. Content Negotiation SMTP Extension . . . . . . . . . . . . . . 13 + 5.1. Content Negotiation Service Extension Definition. . . . . 13 + 5.2. CONNEG Parameter to RCPT-TO . . . . . . . . . . . . . . . 14 + 5.3. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 6. MIME Content-Features Header Field . . . . . . . . . . . . . . 16 + 7. MIME Content-Convert Header Field. . . . . . . . . . . . . . . 16 + 8. MIME Content-Previous Header Field . . . . . . . . . . . . . . 16 + 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 9.1. CONPERM Negotiation . . . . . . . . . . . . . . . . . . . 17 + 9.2. Example CONNEG Negotiation. . . . . . . . . . . . . . . . 18 + 9.3. Content-Previous. . . . . . . . . . . . . . . . . . . . . 19 + 10. Security Considerations. . . . . . . . . . . . . . . . . . . . 19 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + Appendix A. CONNEG with Direct SMTP. . . . . . . . . . . . . . . . 22 + Appendix B. USING Combinations of the Extensions . . . . . . . . . 23 + Appendix C. MIME Content-Type Registrations. . . . . . . . . . . . 24 + +1. Introduction + + Internet specifications typically define common capabilities for a + particular service that are supported by all participants. This + permits the sending of basic data without knowing which additional + capabilities individual recipients support. However, knowing those + capabilities permits the sending of additional types of data and data + of enhanced richness. Otherwise, a message originator will send + content in a form the recipient cannot process or will send 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. + + + +Toyoda & Crocker Standards Track [Page 2] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + +1.1. Background + + MIME enables the distinguishing and labeling of different types of + content [IMF, MEDTYP]. However, an email originator cannot know + whether a recipient is able to support (interpret) a particular data + type. To permit the basic use of MIME, a minimum set of data types + is specified as its support base. How will an originator know + whether a recipient can support any other data types? + + A mechanism for describing MIME types is specified in [FEAT]. + [CONMSG] specifies a mechanism that permits an originator to query a + recipient about the types it supports using email messages for the + control exchange. This permits a recipient to propagate information + about its capabilities back to an originator. For the control + exchange, using end-to-end email messages introduces considerable + latency and some unreliability. + + An alternative approach is for an originator to use the "best" form + of data that it can, and to include the same types of permitted + representation information used in [CONMSG]. Hopefully, the + recipient, or an intermediary, can translate this into a form + 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 [ESMTP1, ESMTP2]. + +1.2. Overview + + An originator describes desirable content forms in MIME content + descriptors. It may give "permission", to any intermediary or the + recipient, to convert the content to 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 the message + content into a form that is both supported by the target system and + 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 performs the conversions. This + is complicated by the need to determine whether the directions are + advisory or whether they are intended to be requirements. + Conversions specified as advisory are performed if possible, but they + do not alter message delivery. In contrast, conversion + specifications that are treated as a requirement will prohibit + delivery if the recipient will not be able to process the content. + + + + + +Toyoda & Crocker Standards Track [Page 3] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + These possibilities interact to form different processing scenarios, + in the event that 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. Thus, information + on behalf of the recipient is used to guide the details of + conversion, but not delivery of the message. + + This is intended to continue the 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 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 include: + + * 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 header fields (Content-Convert, Content- + Previous and * Content-Features) that specify appropriate + content header fields and record conversions that have been + performed. + + + + + + + +Toyoda & Crocker Standards Track [Page 4] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + Figure 1: EXAMPLE RELAY ENVIRONMENT + + +------------+ +-----------+ + | 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]. + +2. Applicability + + 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 + derived from the original, but cannot render the original form. + + The mechanism can impose significant resource requirements on + intermediaries performing 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. + +3. Service Specification + + This service integrates two ESMTP extensions and three MIME content + header fields, in order 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 recipient. + + + + + + +Toyoda & Crocker Standards Track [Page 5] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + An originator specifies preferred content-types through the Content- + Convert MIME content header field. The content header fields 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 delivery. + + 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 supported by 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 [DSNSMTP, DSNFMT, SYSCOD] 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 header fields 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 field. If the originator includes + a Content-Convert header field, then it must also include a + Content-Feature header field, to indicate the current form of the + content. Intermediaries MAY interpret the presence of this header + field as authorization to perform conversions. When Content- + Convert header fields are the sole means for guiding conversions + by intermediaries, then they serve only as advisories. Failure to + satisfy the guidance of these header fields does not affect final + delivery. + + + +Toyoda & Crocker Standards Track [Page 6] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + When posting a new message, the originator MAY specify + transit-service enforcement of conversion limitations by using the + ESMTP CONPERM service extension. In each of the MIME body-parts + for which conversion is authorized, conversions MUST be limited to + those specified in MIME Content-Convert header fields. If + conversion is needed, but an authorized conversion cannot be + performed, then the message will be returned to the originator. + If CONPERM is not used, then failure to perform an authorized + conversion will 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 | + +-----------+ + Capabilities|| + \/ + +----------------+ +--------+ + | 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 and + are issued through the ESMTP MAIL-FROM request. CONNEG response + + + +Toyoda & Crocker Standards Track [Page 7] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + 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 the 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 either: + + * 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 + header fields. The current form of the content is described in + MIME Content-Features header fields. + + 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, along with 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 + + + +Toyoda & Crocker Standards Track [Page 8] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + CONPERM or MAY re-initiate CONPERM use when they have knowledge of + possible variations in a target device. + + NOTE: 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 + be necessary. For example, transformation x could change + content form A to content form B; then transformation y changes + B to C. However, it is possible that transformation y might + have accepted form A directly and produced form D, which has + more of the original information than C. + + NOTE: An originator MAY validate any conversions that are made + by requesting a positive [DSNSMTP]. 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 header fields 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 specification. + + NOTE: 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 will be + required to perform conversion, but be unable to do so. The + result will be that the intermediary will be required to + perform conversion, but it will be performed in undelivered + mail. + + 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 + + + + + + +Toyoda & Crocker Standards Track [Page 9] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + Successful use of CONPERM does not require that conversion take place + along the message transfer path. Rather, it requires that conversion + take place when a next-hop server reports capabilities that can be + supported on behalf of the recipient (through CONNEG) and that those + capabilities do not include support for the current representation of + the content. + + NOTE: 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. + Thus, the recipient is given the original form of the + content, along with an explicit list of conversions deemed + acceptable by the originator. + + An SMTP server MAY offer ESMTP CONPERM, without being able to perform + conversions, if it knows 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 announcements 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 a + substantial mechanism between the recipient and server. When an + ESMTP server knows a target's capabilities, it MAY offer the CONNEG + ESMTP service extension. + + NOTE: One aspect of that mechanism, between the recipient + and an ESMTP server offering the CONNEG ESMTP service + extension could include offering capabilities 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 header fields of the message being converted, the + details of these conversions are part of the + recipient/server mechanism, and fall outside the scope of + the current specification. + + If a next-hop ESMTP server responds that it supports CONNEG when a + message is being processed according to the CONPERM mechanism, then + the SMTP client: + + 1) MUST request CONNEG information + + + +Toyoda & Crocker Standards Track [Page 10] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + 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 + header fields, the Client MUST: + + 1) Add a Content-Previous header field and a Content-Features + header field to each MIME body-part that has been converted, + removing any existing Content-Features header fields. + + 2) Either: + + * Send a single copy to the next-hop SMTP server, using the + best capabilities supported by 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 + recipients. + + If the transfers are to be separated, then the current session MUST + be terminated, and new sessions conducted for each subset. + + The conversions to be 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 host + + 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 + + + + +Toyoda & Crocker Standards Track [Page 11] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + * does respond that it can support CONPERM, then the client + SMTP MUST send the existing content, if all other SMTP + transmission requirements are satisfied. + + If handling is not subject to the CONPERM mechanism, then + conversion failures do not affect message delivery. + +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 or 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). [DSNSMTP, + 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. Content Conversion Permission SMTP Extension + +4.1. Content Conversion Permission Service Extension Definition + + 1) The name of the SMTP service extension is + + "Content-Conversion-Permission" + + 2) The EHLO keyword value associated with this extension is + + "CONPERM" + + 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. + + + +Toyoda & Crocker Standards Track [Page 12] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + +4.2. CONPERM Parameter to Mail-From + + Parameter: + + CONPERM + + Arguments: + + There are no arguments. Specification of permitted + conversions is located in a Content-Convert header field for each + MIME body-part in which conversion is permitted. + + 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. Content Negotiation SMTP Extension + +5.1. Content Negotiation Service Extension Definition + + 1) The name of the SMTP service extension is: + + "Content-Negotiation" + + + + + + +Toyoda & Crocker Standards Track [Page 13] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + 2) The EHLO keyword value associated with this extension is: + + "CONNEG" + + 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 + + Parameter: + + CONNEG + + Arguments: + + 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. In addition, 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 host + + 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 CONNEG: + + + +Toyoda & Crocker Standards Track [Page 14] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + 1) If the message will be subject to CONPERM at the next hop, + the Client MAY transmit the original content to the next hop + and continue CONPERM requirements. + + 2) Otherwise, the Client MUST treat the conversion as failed. + + 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 field that indicates the previous body-part form and a + Content-Features header field, 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 replies. + + 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 supported by the recipient if the server can + ensure that the form of content delivered can be processed by the + recipient, while still satisfying the constraints of the author's + Content-Convert specification(s). + + 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 must contain RCPT-TO information other + than CONNEG. Additional response lines are for CONNEG. 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 cover the same range of specifications + permitted in [CONMSG]. + +5.3. Syntax + + Content-Negotiation = "CONNEG" + Capability = { <filter> specification, + as per [SYN] } + + + + +Toyoda & Crocker Standards Track [Page 15] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + +6. MIME Content-Features Header Field + + The Content-Features header field describes the characteristics of + the current version of the content for the MIME body-part in which + the header field occurs. There is a separate Content-Features header + field for each MIME body-part. The specification for this header + field is contained in [FEAT]. + +7. MIME Content-Convert Header Field + + 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 + field MUST be carried unmodified and delivered to the recipient. In + its absence, the content originator provides 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 + + Permitted = "ANY" / "NONE" / permitted-list + + permitted-list = { explicit list of permitted + final forms, using <filter> + syntax in [SYN] } + + 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 field is present, then a Content-Features + header field MUST also be present to describe the current form of the + Content. + +8. MIME Content-Previous Header Field + + 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 field that is part + + + +Toyoda & Crocker Standards Track [Page 16] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + of the MIME body-part with the converted content. There is a + separate header field for each converted MIME body-part. + + When an intermediary has performed conversion, the intermediary MUST + record details of the result of the conversion by creating or + revising the Content-Features header field for the converted MIME + body-part. + + In the extended [ABNF] notation, the Content-Previous header field is + defined as follows: + + previous = "Content-Previous" [CFWS] ":" + [CFWS] + date by type + + date = "Date " [CFWS] date-time [CFWS] ";" + [CFWS] + + by = "By " [CFWS] domain [CFWS] ";" + [CFWS] + + type = { content characteristics, using + <filter> syntax in [SYN] } + + The Date field specifies the date and time at which the indicated + representation was converted into a newer representation. + + The By field specifies the domain name of the intermediary that + performed the conversion. + + An intermediary MAY choose to derive the Content-Previous header + field, for a body-part, from an already-existing Content-Features + header field in that body-part, before that header field is replaced + with the description of the current representation. + +9. Examples + +9.1. CONPERM Negotiation + + S: 220 example.com IFAX + C: EHLO example.com + S: 250- example.com + S: 250-DSN + S: 250 CONPERM + C: MAIL FROM:May@some.example.com CONPERM + S: 250 <May@some.example.com> originator ok + C: RCPT TO:<June@some.example.com> + S: 250-<June@some.example.com> recipient ok + + + +Toyoda & Crocker Standards Track [Page 17] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + C: DATA + S: 354 okay, send data + C: <<RFC 2822 message with MIME Content-Type:TIFF-FX + Per: + ( image-file-structure=TIFF-minimal + dpi=400 + image-coding=JBIG + size-x=2150/254 + paper-size=letter + ) + with MIME body-parts including: + Content-Convert: + (&(image-file-structure=TIFF-minimal) + (MRC-mode=0) + (color=Binary) + (|(&(dpi=204) + (dpi-xyratio=[204/98,204/196]) ) + (&(dpi=200) + (dpi-xyratio=[200/100,1]) ) + (&(dpi=400) + (dpi-xyratio=1) ) ) + (|(image-coding=[MH,MR,MMR]) + (&(image-coding=JBIG) + (image-coding-constraint=JBIG-T85) + (JBIG-stripe-size=128) ) ) + (size-x<=2150/254) + (paper-size=[letter,A4]) + (ua-media=stationery) ) + >> + S: 250 message accepted + C: QUIT + S: 221 goodbye + +9.2. Example CONNEG Negotiation + + S: 220 example.com IFAX + C: EHLO example.com + S: 250- example.com + S: 250-DSN + S: 250 CONNEG + C: MAIL FROM:<May@some.example.com> + S: 250 <May@some.example.com> originator ok + C: RCPT TO:<June@ifax1.jp> CONNEG + S: 250-<June@some.example.com> 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) + + + +Toyoda & Crocker Standards Track [Page 18] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + 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 + Per: + ( image-file-structure=TIFF-minimal + dpi=400 + image-coding=JBIG + size-x=2150/254 + paper-size=letter + ) + >> + S: 250 message accepted + C: QUIT + S: 221 goodbye + +9.3. Content-Previous + + Content-Previous: + Date Tue, 1 Jul 2001 10:52:37 +0200; + By relay.example.com; + (&(image-file-structure=TIFF-minimal) + (MRC-mode=0) + (color=Binary) + (&(dpi=400) + (dpi-xyratio=1) ) + (&(image-coding=JBIG) + (image-coding-constraint=JBIG-T85) + (JBIG-stripe-size=128) ) + (size-x=2150/254) + (paper-size=A4) + (ua-media=stationery) ) + +10. Security Considerations + + 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. These mechanisms are intended to permit disclosure of + information that is safe for public distribution; hence, there is no + inherent need for security measures. + + + + +Toyoda & Crocker Standards Track [Page 19] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + Information that should have restricted distribution is still able to + be disclosed. Therefore, it is 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, because 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 on 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 were not previously possible. + Intermediaries already make conversions on their own initiative. + Hence, the mechanism introduces essentially no security concerns, + other than divulging recipient preferences. + +11. Acknowledgements + + 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. + +12. References + +12.1. Normative References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + +Toyoda & Crocker Standards Track [Page 20] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + [CONMSG] Klyne, G., Iwazaki, R., and D. Crocker, "Content + Negotiation for Messaging Services based on Email", RFC + 3297, July 2002. + + [DSNSMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service + Extension for Delivery Status Notifications (DSNs)", RFC + 3461, January 2003. + + [DSNFMT] Moore, K. and G. Vaudreuil, "An Extensible Message Format + for Delivery Status Notifications", RFC 3464, January + 2003. + + [SYSCOD] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC + 3463, January 2003. + + [ESMTP1] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. + Crocker, "SMTP Service Extensions", STD 10, RFC 1869, + November 1995. + + [ESMTP2] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [FEAT] Klyne, G., "Indicating Media Features for MIME Content", + RFC 2912, September 2000. + + [IMF] Resnick, P., "Internet Message Format", RFC 2822, April + 2001. + + [SYN] Klyne, G., "A Syntax for Describing Media Feature Sets", + RFC 2533, March 1999. + + [MEDTYP] IANA, "MIME Media Types", + <http://www.iana.org/assignments/media-types> + + [CFWS] Alvestrand, H., "Content Language Headers", RFC 3282, May + 2002. + +12.2. Informative References + + [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy + Considerations for Open Pluggable Edge Services", RFC + 3238, January 2002. + + + + + + + + + +Toyoda & Crocker Standards Track [Page 21] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + +Appendix A. CONNEG with Direct SMTP + + 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 + 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 and 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: + + + + + + +Toyoda & Crocker Standards Track [Page 22] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + * 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 to which it is connected. + + * That is, the Client and Server MUST employ CONNEG and the + Client MUST perform any requisite conversions. + +Appendix B. Using Combinations of the Extensions + + 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 scenarios that might call for using fewer + than the complete set 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 Field + 4. MIME Content-Previous Header Field + 5. MIME Content-Features Header Field + +B.1. Specifying Suggested Conversion Constraints + + Use of the MIME Content-Convert header field specifies the + originator's preferences, should conversion be performed. This does + not impose any requirements on the conversion; it 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 + field. + + Note that the presence of both mechanisms does not require that + conversions be performed. Rather, it constrains conversions, + should they occur. + + + + +Toyoda & Crocker Standards Track [Page 23] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + +B.3. Accepting All Forms of Content + + Although it is unlikely that any device will always able to process + every type of existing content, some devices can be upgraded easily + (e.g., adding plug-in). Hence, such a device is able to process all + content effectively. + + For such devices, it is better to refrain from issuing a CONNEG + assertion. Instead, the CONPERM request should be propagated 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 field is present in the + message, + + 2. ESMTP CONPERM is in force at the node processing the message, + + 3. ESMTP CONNEG is also in force at the same node, + + 4. The current content form is not cited in the CONNEG list, + + 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. + +Appendix C. MIME Content-Type Registrations + +C.1. Content-Convert + + Header field name: + Content-Convert + + Applicable protocol: + Mail (RFC 2822) + + Status: + Proposed Standard + + Author/Change controller: + IETF + + Specification document(s): + RFC 4141. + + + +Toyoda & Crocker Standards Track [Page 24] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + + Related information: + None. + +C.2. Content-Previous + + Header field name: + Content-Previous + + Applicable protocol: + Mail (RFC 2822) + + Status: + Proposed Standard + + Author/Change controller: + IETF + + Specification document(s): + RFC 4141, Section 8 + + Related information: + None. + +Authors' Addresses + + Kiyoshi Toyoda + Panasonic Communications Co., Ltd. + 4-1-62 Minoshima Hakata-ku, Fukuoka 812-8531 Japan + + EMail: toyoda.kiyoshi@jp.panasonic.com + + + Dave Crocker + Brandenburg InternetWorking + 675 Spruce Drive + Sunnyvale, CA 94086 USA + + Phone: +1.408.246.8253 + EMail: dcrocker@bbiw.net + + + + + + + + + + + + +Toyoda & Crocker Standards Track [Page 25] + +RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + 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 + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Toyoda & Crocker Standards Track [Page 26] + |