Network Working Group K. Toyoda
Request for Comments: 4141 PCC
Category: Standards Track D. Crocker
Brandenburg
November 2005
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
用于内容转换的SMTP和MIME扩展
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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.
消息发起人有时以收件人无法处理或不希望处理质量低于首选格式的格式发送内容。此类内容需要转换为可接受的形式，具有相同的信息或受约束的信息（例如，从颜色更改为黑白）。在存储转发环境中，由中介执行此转换可能很方便。该规范集成了两个ESMTP扩展和三个MIME内容头字段，它们定义了一个协作服务，该服务允许中介机构进行授权的、负责的内容形式转换。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
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.
Internet规范通常定义由所有参与者支持的特定服务的通用功能。这允许发送基本数据，而不知道单个收件人支持哪些附加功能。但是，了解这些功能可以发送其他类型的数据和更丰富的数据。否则，邮件发起者将以收件人无法处理的形式发送内容，或发送多种形式的数据。本规范扩展了[CONMSG]的工作，它允许接收者向发起者索取替代内容表单。当前规范允许中间人代表消息发起人和消息接收方进行MIME内容转换。
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?
MIME支持区分和标记不同类型的内容[IMF、MEDTYP]。但是，电子邮件发起者无法知道收件人是否能够支持（解释）特定的数据类型。为了允许MIME的基本使用，指定了一组最小的数据类型作为其支持基础。发起人如何知道收件人是否可以支持任何其他数据类型？
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.
[FEAT]中指定了描述MIME类型的机制。[CONMSG]指定一种机制，允许发端人使用控制交换的电子邮件向收件人查询其支持的类型。这允许接收者将有关其能力的信息传播回发起人。对于控制交换，使用端到端电子邮件消息会带来相当大的延迟和一些不可靠性。
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].
另一种方法是，发起者尽可能使用“最佳”数据形式，并包括[CONMSG]中使用的相同类型的许可表示信息。希望接收者或中间人能够将其转换为有限接收者支持的形式。本规范定义了这种机制。它通过使用MIME内容描述符和可选的基于SMTP的协商机制[ESMTP1，ESMTP2]，定义了一种将邮件内容形式与收件人设备或系统的功能相匹配的方法。
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.
发起者在MIME内容描述符中描述所需的内容形式。它可以“允许”任何中间人或接收人将内容转换为其中一种形式。另外，SMTP服务器可以向SMTP客户端报告目标的内容功能。然后，客户机能够将消息内容转换为目标系统支持且发端人可接受的形式。
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
表1：故障处理
\ RECEIVER| | |
+-------+ | Advise | Require |
ORIGINATOR\| | |
-----------+----------+----------+
| Deliver | Deliver |
Advise | original | original |
| content | content |
-----------+----------+----------+
| Return | Return |
Require | w/out | w/out |
| delivery | delivery |
-----------+----------+----------+
\ 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,
* 一个可选的ESMTP逐跳服务，使用由发起者发布的CONPERM SMTP服务扩展，
* an optional ESMTP hop-by-hop service that uses the CONNEG SMTP service extensions, issued on behalf of the recipient, and
* 可选的ESMTP逐跳服务，使用代表收件人发出的CONNEG SMTP服务扩展，以及
* 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.
* 三个MIME内容头字段（Content Convert、Content Previous和*Content Features），用于指定适当的内容头字段和已执行的记录转换。
Figure 1: EXAMPLE RELAY ENVIRONMENT
图1：示例中继环境
+------------+ +-----------+
| Originator | | Recipient |
+------------+ +-----------+
||Posting Delivering/\
\/ ||
+--------+ +-----------------+ +--------+
| SMTP | | SMTP Relay | | SMTP |
| Client |--->| Server | Client |--->| Server |
+--------+ +--------+--------+ +--------+
+------------+ +-----------+
| Originator | | Recipient |
+------------+ +-----------+
||Posting Delivering/\
\/ ||
+--------+ +-----------------+ +--------+
| SMTP | | SMTP Relay | | SMTP |
| Client |--->| Server | Client |--->| Server |
+--------+ +--------+--------+ +--------+
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
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].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照“RFC中用于指示需求水平的关键词”中的定义进行解释[关键词]。
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.
该机制可以对执行转换的中介机构施加大量的资源需求。此外，中介机构在知道其是否能够执行转换之前接受转换责任。还请注意，对于已经数字签名或加密的内容，转换是不可能的，除非转换中介可以对内容进行解码和重新编码。
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.
该服务集成了两个ESMTP扩展和三个MIME内容头字段，以便允许中介机构进行授权的、可问责的内容形式转换。中介是发起者和接收者之间传输路径上的ESMTP主机（客户端和服务器）。
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.
发起人通过content Convert MIME content header字段指定首选内容类型。内容头字段出现在应用它们的每个MIME主体部分中。也就是说，每个MIME主体部分都包含自己的转换指南和历史记录。
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.
发起人的偏好通过ESMTP CONPERM服务扩展提升到需求级别。只有当发起人要求邮件传输服务强制执行转换限制时，才需要CONPERM机制。如果无法交付可接受的内容类型，则不进行交付。
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.
目标系统功能通过ESMTP CONNEG服务扩展在SMTP会话中进行通信。此信息用于限制可能执行的转换范围，但不影响交付。
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).
使用CONPERM时，转换由第一台ESMTP主机执行，该主机可以获得发端人的许可和接收方支持的功能信息。如果中继或客户端无法将消息传输到支持CONPERM的下一个跃点或执行适当的转换，则它将终止消息传输并将状态代码为5.6.3（需要转换但不支持）的[DSNSMTP、DSNFMT、SYSCOD]返回给发起人。
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.
当SMTP中继或服务器执行内容转换时，它会记录将哪些特定转换为与每个转换的MIME正文部分关联的content Previous和content Features MIME头字段。
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.
发起人通过MIME内容转换头字段指定所需的转换结果。如果发起人包括内容转换标题字段，则还必须包括内容功能标题字段，以指示内容的当前形式。中介机构可以将此标头字段的存在解释为执行转换的授权。当Content Convert标头字段是中介机构指导转换的唯一方法时，它们仅用作建议。未能满足这些标题字段的指导并不影响最终交付。
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.
发布新邮件时，发端人可通过使用ESMTP CONPERM服务扩展指定转换限制的传输服务实施。在授权转换的每个MIME主体部分中，转换必须限制为MIME内容转换头字段中指定的转换。如果需要转换，但无法执行授权转换，则消息将返回给发起人。如果未使用CONPERM，则未执行授权转换不会影响正常交付处理。
Figure 2: CONPERM USAGE
图2:CONPERM的使用
+------------+
| Originator |
+------------+
SMTP ||
or || CONPERM
SUBMIT \/
+--------+ +----------------+
| SMTP | SMTP | SMTP Relay |
| Client |----------->| Server | |
+--------+ CONPERM +--------+-------+
+------------+
| 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.
通过ESMTP邮件传输服务，可以代表收件人支持的功能应通过ESMTP CONNEG服务扩展传达给中介机构。
Figure 3: CONNEG USAGE
图3：连接使用
+-----------+
| Recipient |
+-----------+
Capabilities||
\/
+----------------+ +--------+
| SMTP Relay | CONNEG | SMTP |
| | Client |<--------| Server |
+-------+--------+ +--------+
+-----------+
| 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
在接收消息时，可以向中间层提供CONPERM指示，并且在发送消息之前可以向中间层提供CONNEG指导。CONPERM和CONNEG以每封邮件为基础，通过ESMTP邮件发送请求发出。康涅格反应
information is provided on a per-recipient basis, through the response to ESMTP RCPT-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:
转换必须由获得CONNEG能力信息的第一个CONPERM中介执行。MIME内容类型必须符合[MEDTYP]中转换内容的结果。当中介为同一消息的不同收件人获取不同的功能信息时，它可以：
* 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.
* 创建多个转换副本，与收件人子集的功能相匹配。然后，使用单独的标准SMTP会话和单独的标准RFC2821.Rcpt-to地址列表，将每个版本分别发送给相应的收件人子集。
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.
转换记录放在MIME内容前面的标题字段中。内容的当前形式在MIME内容功能标题字段中描述。
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.
中介机构可以选择将收件人列表拆分为单独的标准RFC2821.Rcpt-to列表和单独的标准SMTP会话的子集，而不是简单地无法传输到没有能力信息的收件人，然后通过继续使用CONPERM机制继续将原始内容传输给这些接收者。因此，对此类收件人的处理就像没有发生CONNEG事务一样执行。
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的使用。但是，某些中继环境（例如将邮件重新定向到新的目标设备的中继环境）将受益于进一步的转换。中介机构可继续使用
CONPERM or MAY re-initiate CONPERM use when they have knowledge of possible variations in a target device.
当他们知道目标设备中的可能变化时，CONPERM或可能重新启动CONPERM使用。
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.
注意：内容的新转换版本可能比早期版本包含更少的信息。当然，一系列转换可能会在每一步丢失额外的信息。也许令人惊讶的是，这可能导致比必要的更多的损失。例如，转换x可以将内容形式A更改为内容形式B；然后转换y将B更改为C。然而，转换y可能直接接受了形式A并生成了形式D，它比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).
注：发起人可通过请求正[DSNSMTP]来验证任何转换。如果DSN请求包含“RET”参数，则传递代理应返回已传递（转换）邮件内容的准确副本。这将允许发起人检查任何转换的结果。
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.
允许中间人进行内容转换的消息发起人可以使用CONPERM ESMTP服务扩展和content Convert MIME头字段来指示中间人允许的转换。邮件发起人将此权限传递给SMTP邮件传输服务的其他机制不在本规范的范围内。
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:
当ESMTP客户端被授权参与CONPERM服务时，它必须与下一个SMTP跃点服务器进行以下交互：
* The server's ability to enforce authorized conversions, through ESMTP CONPERM
* 服务器通过ESMTP CONPERM强制执行授权转换的能力
* The capabilities supported for the target device or system, through ESMTP CONNEG
* 通过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.
成功使用CONPERM不需要沿消息传输路径进行转换。相反，它要求在下一跳服务器报告可以代表收件人（通过CONNEG）支持的功能时进行转换，并且这些功能不包括对内容当前表示的支持。
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.
注意：允许每个SMTP服务器（包括最后一跳服务器）都支持CONPERM，但不提供CONNEG。在这种情况下，消息将以其原始形式传递给收件人。任何可能要执行的转换都留给收件人。因此，收件人将获得内容的原始形式，以及发起者认为可接受的转换的明确列表。
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.
如果SMTP服务器知道可以沿传输路径的其余部分或由目标设备或系统执行转换，则可能会提供ESMTP CONPERM，而无法执行转换。
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.
目标收件人设备或系统通过本规范范围之外的方式向SMTP服务安排其内容表单功能的公告。请注意，使服务器能够代表接收者发布CONNEG信息可能需要接收者和服务器之间的实质性机制。当ESMTP服务器知道目标的功能时，它可以提供CONNEG ESMTP服务扩展。
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.
注意：在接收方和提供CONNEG ESMTP服务扩展的ESMTP服务器之间，该机制的一个方面可能包括提供接收方直接支持的功能以外的功能。特别是，服务器（或服务器与收件人之间的其他中介机构）可以支持它们可以转换为收件人功能的功能。只要结果为正在转换的邮件的相关Content Convert标头字段中指定的集合所接受，这些转换的详细信息就是收件人/服务器机制的一部分，不属于当前规范的范围。
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:
如果下一跳ESMTP服务器在根据CONPERM机制处理邮件时响应它支持CONNEG，则SMTP客户端：
1) MUST request CONNEG information
1) 必须请求CONNEG信息
2) MUST perform the requisite conversions, if possible, before sending the message to the next-hop SMTP server
2) 在将邮件发送到下一跳SMTP服务器之前，必须执行必要的转换（如果可能）
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).
3) 如果消息的任何转换失败，则必须使消息处理失败，并且必须将失败DSN返回给发端人，状态代码为5.6.5（转换失败）。
When performing conversions, as specified in Content-Convert MIME header fields, the Client MUST:
执行转换时，如Content Convert MIME标头字段中所指定，客户端必须：
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.
1) 向已转换的每个MIME正文部分添加“Content Previous”标题字段和“Content Features”标题字段，删除任何现有的“Content Features”标题字段。
2) Either:
2) 要么：
* Send a single copy to the next-hop SMTP server, using the best capabilities supported by all recipients along that path, or
* 使用该路径上所有收件人支持的最佳功能，将单个副本发送到下一跳SMTP服务器，或
* 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.
* 将传输分离为多个标准RFC2821.Rcpt-To和ESMTP会话，以便为收件人子集提供最佳转换。
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
* 可由SMTP客户端主机执行的转换
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:
如果按照CONPERM机制进行处理，并且：
* the next-hop SMTP host does not indicate that it can represent the target's capabilities through CONNEG, but
* 下一跳SMTP主机并不表示它可以通过CONNEG表示目标的功能，但是
* does respond that it can support CONPERM, then the client SMTP MUST send the existing content, if all other SMTP transmission requirements are satisfied.
* 没有响应它可以支持CONPERM，那么客户端SMTP必须发送现有内容，如果满足所有其他SMTP传输要求。
If handling is not subject to the CONPERM mechanism, then conversion failures do not affect message delivery.
如果处理不受CONPERM机制的约束，则转换失败不会影响消息传递。
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
如果客户端正在参与CONPERM机制，但下一跳SMTP服务器不支持CONPERM或CONNEG，则SMTP客户端
1) MUST terminate the session to the next-hop SMTP server, without sending the message
1) 必须在不发送邮件的情况下终止与下一跳SMTP服务器的会话
2) MUST return a DSN notification to the originator, with status code 5.6.3 (Conversion required but not supported). [DSNSMTP, DSNFMT, SYSCOD]
2) 必须向发起人返回DSN通知，状态代码为5.6.3（需要转换，但不受支持）。[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:
如果客户端正在参与CONPERM机制，并且下一跳SMTP服务器支持CONNEG，但不为单个RCPT-TO收件人提供任何功能，则SMTP客户端对该收件人的处理必须是：
1) Treat the addressee as a conversion failure, or
1) 将收件人视为转换失败，或
2) Separate the addressee from the address list that is processed according to CONNEG, and continue to process the addressee according to CONPERM.
2) 将收件人从根据CONNEG处理的地址列表中分离出来，并根据CONPERM继续处理收件人。
1) The name of the SMTP service extension is
1) SMTP服务扩展名为
"Content-Conversion-Permission"
“内容转换权限”
2) The EHLO keyword value associated with this extension is
2) 与此扩展关联的EHLO关键字值为
"CONPERM"
“CONPERM”
3) A parameter using the keyword "CONPERM" is added to the MAIL-FROM command.
3) 将使用关键字“CONPERM”的参数添加到MAIL-FROM命令中。
4) The server responds with acceptance or rejection of support for CONPERM, for this message.
4) 服务器对此消息的响应是接受或拒绝对CONPERM的支持。
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.
没有争论。允许转换的规范位于允许转换的每个MIME主体部分的Content Convert标头字段中。
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.
如果服务器发出250-CONPERM作为当前会话的EHLO响应的一部分，并且客户端正在参与此消息的CONPERM服务（例如通过接收具有CONPERM要求的消息），则客户端必须在MAIL-FROM中发出CONPERM参数。如果服务器未发出250-CONPERM，并且客户端正在为此消息参与CONPERM服务，则客户端必须将传输视为永久拒绝。
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.
如果客户端在MAIL-FROM中指定了CONPERM，但服务器不支持CONPERM参数，则服务器必须使用504-CONPERM回复拒绝MAIL-FROM命令。
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.
如果客户机在邮件发件人中发出CONPERM参数，则服务器必须符合此规范。它必须根据CONPERM中继消息，或者必须根据CONNEG信息转换消息。
Content-Conversion-Permission = "CONPERM"
Content-Conversion-Permission = "CONPERM"
1) The name of the SMTP service extension is:
1) SMTP服务扩展名为：
"Content-Negotiation"
“内容协商”
2) The EHLO keyword value associated with this extension is:
2) 与此扩展关联的EHLO关键字值为：
"CONNEG"
“康涅格”
3) A parameter, using the keyword "CONNEG", is added to the RCPT-TO command.
3) 将使用关键字“CONNEG”的参数添加到RCPT-to命令中。
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.
4) 服务器响应一个报告，指示可以代表接收方设备或系统接收的与目标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.
如果消息符合CONPERM要求，并且服务器发出250-CONNEG，作为当前会话的EHLO响应的一部分，客户端必须在RCPT-to请求中发出CONNEG参数。如果消息不受CONPERM要求的约束，并且服务器发出250-CONNEG，则客户端可能会发出CONNEG参数和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.
如果客户机向CONNEG参数发出RCPT-TO，那么它必须遵守CONNEG RCPT-TO回复中针对该消息返回的功能。此外，如果内容的当前形式未包含在列出的功能中，则它必须代表收件人转换消息内容。
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
* 可由SMTP客户端主机执行的转换
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:
如果此交集的结果为空表示集，则客户端处理取决于下一跳服务器是否提供了CONPERM以及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.
1) 如果消息将在下一跳进行CONPERM，则客户端可以将原始内容传输到下一跳并继续CONPERM要求。
2) Otherwise, the Client MUST treat the conversion as failed.
2) 否则，客户端必须将转换视为失败。
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.
每个转换的MIME正文部分必须有一个Content Previous标头字段，该字段指示先前的正文部分表单，以及一个Content Features标头字段，该字段指示新的正文部分表单。
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.
如果客户端在RCPT-TO中指定了CONNEG，但服务器不支持CONNEG参数，则服务器必须以504个回复拒绝RCPT-TO收件人。
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).
如果服务器确实支持CONNEG参数，并且它知道目标设备或系统的功能，那么它必须通过CONNEG提供该信息。如果服务器能够确保收件人能够处理交付的内容的形式，同时仍然满足作者的内容转换规范的约束，则服务器可以提供比收件人支持的范围更广的列表。
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".
对CONNEG RCPT-to请求的响应将是多行RCPT-to回复。对于成功的（250）响应，至少响应的第一行必须包含RCPT-TO信息，而不是CONNEG。额外的响应线用于CONNEG。为了避免由于行缓冲区大小的变化而产生的问题，必须将总参数列表作为一系列行提供，每个行以“250-CONNEG”开头，最后一行除外，即“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].
能力清单的内容必须符合[SYN]中的规范，并涵盖[CONMSG]中允许的相同规范范围。
Content-Negotiation = "CONNEG"
Capability = { <filter> specification,
as per [SYN] }
Content-Negotiation = "CONNEG"
Capability = { <filter> specification,
as per [SYN] }
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].
Content Features标头字段描述出现标头字段的MIME正文部分内容的当前版本的特征。每个MIME主体部分都有一个单独的Content Features头字段。此标题字段的规范包含在[FEAT]中。
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.
Content Convert是一个标头字段，用于指定关联内容的首选转换。它可以在没有本文件中定义的其他机制的情况下使用。如果存在，则此标题字段必须未经修改而携带并交付给收件人。如果没有，内容发起人不提供有关内容转换的指导，中介机构不应执行内容转换。
In the extended ABNF notation, the Content-Convert header field is defined as follows:
在扩展ABNF表示法中，Content Convert标头字段定义如下：
Convert = "Content-convert" ":" permitted
Convert=“Content Convert”“：”允许
Permitted = "ANY" / "NONE" / permitted-list
Permitted = "ANY" / "NONE" / permitted-list
permitted-list = { explicit list of permitted
final forms, using <filter>
syntax in [SYN] }
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.
如果允许的转换被指定为“无”，则中介不应执行对此MIME主体部分的任何转换，即使目标设备或系统不支持内容的原始形式。
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.
如果存在Content Convert标头字段，则还必须存在Content Features标头字段来描述内容的当前形式。
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.
已转换内容的MIME正文部分的。每个转换的MIME正文部分都有一个单独的标题字段。
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.
中介体执行转换后，中介体必须通过为转换后的MIME正文部分创建或修改Content Features标头字段来记录转换结果的详细信息。
In the extended [ABNF] notation, the Content-Previous header field is defined as follows:
在扩展[ABNF]表示法中，Content Previous header字段定义如下：
previous = "Content-Previous" [CFWS] ":" [CFWS] date by type
previous=“Content previous”[CFWS]：“[CFWS]日期（按类型）
date = "Date " [CFWS] date-time [CFWS] ";" [CFWS]
date=“date”[CFWS]日期时间[CFWS]；“[CFWS]
by = "By " [CFWS] domain [CFWS] ";" [CFWS]
by=“by”[CFWS]域[CFWS]；“[CFWS]
type = { content characteristics, using
<filter> syntax in [SYN] }
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.
By字段指定执行转换的中介的域名。
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.
在标题字段替换为当前表示的描述之前，中介可以选择从该主体部分中已存在的内容特征标题字段派生主体部分的内容前一标题字段。
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
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
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
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
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: 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 goodbye
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
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) )
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) )
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.
本应限制分发的信息仍然可以披露。因此，披露ESMTP服务器或披露ESMTP客户端有责任确定是否应在使用该ESMTP选项时采取额外的安全措施。
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.
使用ESMTP CONNEG选项可以通过中介沿邮件传输路径进行内容转换。当内容被加密时，中介无法执行转换，因为它不能访问相关的密钥材料。当内容已签名但未加密时，转换将使签名无效。本规范规定了中间MTA可能进行的无限制计算，具体取决于所需转换的性质和数量。此外，考虑到Internet邮件通常允许中介接收来自所有Internet来源的消息，这种计算负担可能会为拒绝服务攻击提供机会。
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].
本规范规定由未指定的中介进行内容转换。使用这一机制会带来重大风险。尽管中介体总是能够执行破坏性的转换，但使用该规范可能会导致对该潜力的更多探索，从而导致更多的不当行为。[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.
CONPERM/CONNEG提供了一种协作机制，而不是支持以前不可能的中介操作。中介机构已经主动进行了转换。因此，该机制基本上不涉及安全问题，只涉及泄露接收者偏好。
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.
格雷厄姆·克莱恩（Graham Klyne）和埃里克·伯格（Eric Burger）提供了广泛、认真的评论和建议。Keith Moore、Giat Hana和Joel Halpern提供了反馈，从而改进了规范与既定电子邮件实践的集成。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[CONMSG] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, July 2002.
[CONMSG]Klyne，G.，Iwazaki，R.，和D.Crocker，“基于电子邮件的消息传递服务的内容协商”，RFC 3297，2002年7月。
[DSNSMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSNSMTP]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[DSNFMT] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSNFMT]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[SYSCOD] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[SYSCOD]Vaudreuil，G.“增强邮件系统状态代码”，RFC 3463，2003年1月。
[ESMTP1] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[ESMTP1]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.，和D.Crocker，“SMTP服务扩展”，STD 10，RFC 18691995年11月。
[ESMTP2] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[ESMTP2]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[FEAT] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
[FEAT]Klyne，G.“为MIME内容指示媒体功能”，RFC 2912，2000年9月。
[IMF] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[IMF]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[SYN] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[SYN]Klyne，G.“描述媒体功能集的语法”，RFC2531999年3月。
[MEDTYP] IANA, "MIME Media Types",
<http://www.iana.org/assignments/media-types>
[MEDTYP] IANA, "MIME Media Types",
<http://www.iana.org/assignments/media-types>
[CFWS] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[CFWS]Alvestrand，H.，“内容语言标题”，RFC 3282，2002年5月。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[RFC3238]Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB体系结构和政策考虑”，RFC 3238，2002年1月。
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.
在某些配置中，可以进行直接的、基于电子邮件的交互，其中发端人的系统与收件人的系统进行直接的、交互的TCP连接。此配置允许使用符合此处规范的内容表单协商服务，但允许进行一些简化。此单个SMTP会话不具有多个中继会话的复杂性，因此不需要向中介传播权限。
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.
发端人的系统为发端人提供用户级功能，并包含用于发送邮件的SMTP客户端。因此，电子邮件“发布”的正式步骤是发起系统内部或虚拟的过程。收件人的服务包含收件人的用户级功能，并包含用于接收邮件的SMTP服务器。因此，电子邮件“发送”和“接收”的正式步骤在接收系统中是内部的或虚拟的。
Figure 4: DIRECT CONNEG
图4：直接连接
Originating system Receiving system
+------------------+ +------------------+
| +------------+ | | +-----------+ |
| | Originator | | | | Recipient | |
| +------------+ | | +-----------+ |
| ||Posting | | /\Receiving |
| \/ | | || |
| +---------+ | | +--------+ |
| | SMTP |<---|-------|----| SMTP | |
| | Client |----|-------|--->| Server | |
| +---------+ | | +--------+ |
+------------------+ +------------------+
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.
在这种情况下，不需要CONPERM，因为SMTP客户端是原始系统的一部分，并且已经具有必要的权限。类似地，SMTP服务器肯定知道收件人的功能，因为服务器是接收系统的一部分。
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.
* 符合本规范的发起系统，以及发起人和收件人之间的通信过程，与最后一跳SMTP中继及其所连接的传送SMTP服务器之间的通信过程相同。
* That is, the Client and Server MUST employ CONNEG and the Client MUST perform any requisite conversions.
* 也就是说，客户机和服务器必须使用CONNEG，客户机必须执行任何必要的转换。
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
1. 从2发送邮件的CONPERM参数。将参数连接至RCPT-3。MIME内容转换头字段4。MIME内容上一个标题字段5。MIME内容特征头字段
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.
使用MIME Content Convert标头字段指定应执行转换的原始发件人的首选项。这对转换没有任何要求；这仅仅是建议。
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.
当MIME内容转换规范与ESMTP CONPERM选项结合使用时，发起者的首选转换规范将上升到需求级别。除了在Content Convert标头字段中指定的转换之外，不允许进行其他转换。
Note that the presence of both mechanisms does not require that conversions be performed. Rather, it constrains conversions, should they occur.
请注意，这两种机制的存在并不要求执行转换。相反，如果发生转换，它会限制转换。
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.
对于这样的设备，最好不要发出CONNEG断言。相反，CONPERM请求应该传播到目标设备。
A node is required to perform conversion when:
在以下情况下，需要节点执行转换：
1. At least one MIME Content-Covert header field is present in the message,
1. 消息中至少存在一个MIME内容转换头字段，
2. ESMTP CONPERM is in force at the node processing the message,
2. ESMTP CONPERM在处理消息的节点生效，
3. ESMTP CONNEG is also in force at the same node,
3. ESMTP CONNEG也在同一节点生效，
4. The current content form is not cited in the CONNEG list,
4. CONNEG列表中未引用当前内容表，
5. At least one content form is present, both in the Content-Convert list and the CONNEG list, and
5. 内容转换列表和CONNEG列表中至少存在一个内容表单，并且
6. The intermediary is able to convert from the current form to one of the forms listed in both Content-Convert and CONNEG.
6. 中介可以从当前表单转换为Content convert和CONNEG中列出的表单之一。
Header field name: Content-Convert
标题字段名称：内容转换
Applicable protocol: Mail (RFC 2822)
适用协议：邮件（RFC 2822）
Status: Proposed Standard
现状：拟议标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document(s): RFC 4141.
规范文件：RFC 4141。
Related information: None.
相关信息：无。
Header field name: Content-Previous
标题字段名称：上一个内容
Applicable protocol: Mail (RFC 2822)
适用协议：邮件（RFC 2822）
Status: Proposed Standard
现状：拟议标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document(s): RFC 4141, Section 8
规范文件：RFC 4141，第8节
Related information: None.
相关信息：无。
Authors' Addresses
作者地址
Kiyoshi Toyoda Panasonic Communications Co., Ltd. 4-1-62 Minoshima Hakata-ku, Fukuoka 812-8531 Japan
日本福冈市博田町4-1-62 Minoshima Hakata ku丰田清通信有限公司812-8531
EMail: toyoda.kiyoshi@jp.panasonic.com
EMail: toyoda.kiyoshi@jp.panasonic.com
Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA
戴夫·克罗克·勃兰登堡互联网络美国加利福尼亚州桑尼维尔市云杉大道675号，邮编94086
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。