This is a purely informative rendering of an RFC that includes verified errata. This rendering may not be used as a reference.
The following 'Verified' errata have been incorporated in this document:EID 805,EID 4762
Network Working Group K. ToyodaRequest for Comments: 4141 PCCCategory: Standards Track D. Crocker Brandenburg November 2005 SMTP and MIME Extensions for Content ConversionStatus 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.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. . . . . . . . . . . . 241. 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.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. 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. 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. 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. 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 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 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 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 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 * 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 Extension4.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.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 Extension5.1. Content Negotiation Service Extension Definition 1) The name of the SMTP service extension is: "Content-Negotiation" 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: 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] }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 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. Examples9.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
EID 4762 (Verified) is as follows:Section: 9.1Original Text:S: 250-<June@some.example.com> recipient okCorrected Text:S: 250 <June@some.example.com> recipient ok
Notes: The example in section 9.1 incorrectly lists a hyphen between the status code (250) and message text (<June...) as if there would be more data coming from the server regarding the "RCPT TO:<June..." command but there is not.
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 goodbye9.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) 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 goodbye9.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. 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. References12.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. [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.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: * 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 FieldB.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.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 RegistrationsC.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. 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.netFull 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.
EID 805 (Verified) is as follows:Section: 99Original Text:(1)In Section 1.2, the last paragraph at the bottom of page 4 says: * 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.It should say: * 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.(2)In Section 3, the fourth paragraph on page 6 says: 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).It should say: 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 Delivery Status Notification (DSN) [DSNSMTP, DSNFMT, SYSCOD] to the originator, with status code 5.6.3 (Conversion required but not supported).Rationale: Probably, that triple of RFCs should not be sent :-)The proposed text change conforms to the current authoring styleguides for I-Ds / RFCs, spelling out the abbreviation 'MDN' at itsfirst occurrance in the text.(3)Similarly, the final NOTE in Section 3, on page 9, says: NOTE: An originator MAY validate any conversions that are made by requesting a positive [DSNSMTP]. ...where it should better say: NOTE: An originator MAY validate any conversions that are made| by requesting a positive DSN [DSNSMTP]. ...(4)The second item of the first enumerated list in Section 3.3,on page 12, contains a (visually hidden) word replication.The text says: 2) MUST return a DSN notification to the originator, with status code 5.6.3 (Conversion required but not supported). [DSNSMTP, DSNFMT, SYSCOD]It should say:| 2) MUST return a DSN to the originator, with status code 5.6.3 (Conversion required but not supported). [DSNSMTP, DSNFMT, SYSCOD]Rationale: The trailing "N" of "DSN" already stands for "notification".(5)To make the spelling of [E]SMTP keywords and verbs consistent withinthe text, the headline of Section 4.2 (on page 13), 4.2. CONPERM Parameter to Mail-Fromshould better use uppercaes spelling as well, to read: 4.2. CONPERM Parameter to MAIL-FROM(6)The ABNF given in Section 7, on page 16, and Section 8, on page 17,does not fully conform to the contemporary (RFC 2822) style.The ABNF in Section 7 omits the explicit specification of whitespace usage that presumably has been intended.The ABNF in Section 8 inserts a paramount of CFWS.NOTE:- RFC 2822 has deprecated the use of white space between header field names and the subsequent ":" and, as far as I can see, comments have not been allowed at such places by RFC 822, and aren't by the "obsolete syntax" in RFC 2822.- RFC 2822 has carefully made [C]FWS an intrinsic part of many low-level syntactic constructs to improve readability of the high-level ABNF productions. Thus, CFWS should not be inserted again where it is (logically) already present.Furthermore, the spelling of ABNF production names should beself-consistent within a certain field. RFC 2822 makes use oflowercase production (rule) names for teh syntactic descriptionof the Internet Message Format; therefore it seems preferrableto follow this style when defining IMF extensions.In the light of these explanations (and detailed inspection ofRFC 2822), the ABNF productions in Section 7 : Convert = "Content-convert" ":" permitted Permitted = "ANY" / "NONE" / permitted-listshould perhaps be re-written as : convert = "Content-convert:" [CFWS] permitted permitted = "ANY" / "NONE" / permitted-listand the ABNF productions in Section 8 : previous = "Content-Previous" [CFWS] ":" [CFWS] date by type date = "Date " [CFWS] date-time [CFWS] ";" [CFWS] by = "By " [CFWS] domain [CFWS] ";" [CFWS]should perhaps be re-written as : previous = "Content-Previous:" date by type date = "Date " [CFWS] date-time ";" [CFWS] by = "By " domain ";" [CFWS]or even (disallowing comments after "Date " - like RFC 2822 does): previous = "Content-Previous:" date by type date = "Date " date-time ";" [CFWS] by = "By " domain ";" [CFWS](7)The examples in Section 9 contain improperly truncated referencesto MIME Content-Types.The following line that appears - in Section 9.1 in the 3rd text line on page 18,and - in Section 9.2 in the 10th text line : C: <<RFC 2822 message with MIME Content-Type:TIFF-FXshould, in both cases, read: C: <<RFC 2822 message with MIME Content-Type: image/TIFF-FX(8)In Appendix C, the headline: Appendix C. MIME Content-Type Registrationsshould say: Appendix C. MIME Header Field Registrations(9)Perhaps, in Appendix C, the IANA should have been directed toadd to the MIME Header Registration for "Content-Features:"an additional reference to RFC 4141.E.g., add on page 25, before the "Authors' Addresses": C.3. Content-Features This memo substantially amends the specification of the MIME Header Field "Content-Features:" registered by [[FEAT]. The IANA should include into the 'Specification document(s)' clause of that registration a pointer to RFC 4141.Corrected Text:[see above]
Notes: From Dave Crocker:
I congratulate you on such an excellent job of proof-reading. I certainly do recommend that you post your note on the errata page.
All of your points are worth considering. Some entail simple errors and some entail matters of taste.
I believe that the errors you cite do not change the substance of the specification, although the question of white space syntax could formally involve a meaningful technical error. (Normally it would be clear that it is significant; given the history of RFC733/RFC722/RFC2822 and the slow adoption of 2822, I'm not too worried that the error in our document will hurt real-world interoperability.