Independent Submission A. Melnikov
Request for Comments: 7912 Isode Ltd
Category: Informational June 2016
ISSN: 2070-1721
Independent Submission A. Melnikov
Request for Comments: 7912 Isode Ltd
Category: Informational June 2016
ISSN: 2070-1721
Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure
邮件授权电子邮件标题字段及其在草稿和发布过程中的使用
Abstract
摘要
This document describes a procedure for when a Military Message Handling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more Authorizing Users authorize release of the message by adding the MMHS-Authorizing-Users header field. The resulting message can be optionally signed by the sender and/or reviewer, allowing recipients to verify both the original signature (if any) and the review signatures.
本文档描述了当军事消息处理系统（MMHS）消息由一个用户组成，并且仅当一个或多个授权用户通过添加MMHS授权用户标题字段授权消息发布时，才将其发布到邮件传输系统的过程。生成的邮件可以由发件人和/或审阅者选择性地签名，从而允许收件人验证原始签名（如果有）和审阅签名。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7912.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7912.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Draft and Release Procedure . . . . . . . . . . . . . . . . . 3
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Handling of Initial Message Submission by the MSA . . . . 3
3.3. Review by Authorizing User(s) . . . . . . . . . . . . . . 4
3.3.1. Processing of Encrypted Messages . . . . . . . . . . 5
3.3.2. Authorizing S/MIME Signatures . . . . . . . . . . . . 5
3.4. Role of Other Messaging Agents at the Sender's Domain . . 6
3.4.1. MDA at the Sender's Domain . . . . . . . . . . . . . 6
3.4.2. Border MTA at the Sender's Domain . . . . . . . . . . 6
4. MMHS-Authorizing-Users Header Field . . . . . . . . . . . . . 6
5. Updated MIXER Mapping . . . . . . . . . . . . . . . . . . . . 7
5.1. Mapping from RFC 5322/MIME to X.400 . . . . . . . . . . . 7
5.2. Mapping from X.400 to RFC 5322/MIME . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 9
7.2. Intentionally Malformed Header Fields . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Draft and Release Procedure . . . . . . . . . . . . . . . . . 3
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Handling of Initial Message Submission by the MSA . . . . 3
3.3. Review by Authorizing User(s) . . . . . . . . . . . . . . 4
3.3.1. Processing of Encrypted Messages . . . . . . . . . . 5
3.3.2. Authorizing S/MIME Signatures . . . . . . . . . . . . 5
3.4. Role of Other Messaging Agents at the Sender's Domain . . 6
3.4.1. MDA at the Sender's Domain . . . . . . . . . . . . . 6
3.4.2. Border MTA at the Sender's Domain . . . . . . . . . . 6
4. MMHS-Authorizing-Users Header Field . . . . . . . . . . . . . 6
5. Updated MIXER Mapping . . . . . . . . . . . . . . . . . . . . 7
5.1. Mapping from RFC 5322/MIME to X.400 . . . . . . . . . . . 7
5.2. Mapping from X.400 to RFC 5322/MIME . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 9
7.2. Intentionally Malformed Header Fields . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
In some secure environments, email messages can't be released to the Message Transfer System (MTS); thus, they can't be delivered to recipients unless they are authorized by one or more Authorizing Users (e.g., Releasing Officers or Release Authorities). This document describes how this mechanism can be realized by an additional Internet Email [RFC5322] header field and optionally protected using S/MIME [RFC5750] [RFC5751] or DomainKeys Identified Mail (DKIM) [RFC6376].
在某些安全环境中，电子邮件无法发布到消息传输系统（MTS）；因此，除非获得一个或多个授权用户（例如，发布官员或发布机构）的授权，否则无法将其交付给收件人。本文档描述了如何通过附加的Internet电子邮件[RFC5322]头字段实现此机制，并可选择使用S/MIME[RFC5750][RFC5751]或域密钥标识邮件（DKIM）[RFC6376]进行保护。
This document describes a procedure for how an email message composed by one user can be released to the MTS when one or more Authorizing Users authorize and optionally countersign the message. The MMHS-Authorizing-Users header field (see Section 4) communicates which user(s) authorized the message. If S/MIME signed, the resulting message allows recipients to verify both the original (if any) and counter signatures. The original S/MIME signature generated by the sender (if any) is unaffected by additional S/MIME review signatures.
本文档描述了当一个或多个授权用户授权并可选地会签邮件时，如何将由一个用户编写的电子邮件发布到MTS的过程。MMHS授权用户标题字段（见第4节）传达授权消息的用户。如果S/MIME签名，则生成的消息允许收件人验证原始签名（如果有）和反签名。发件人生成的原始S/MIME签名（如果有）不受其他S/MIME审阅签名的影响。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation, including the core rules defined in Appendix B of RFC 5234 [RFC5234]. Terms not defined in this document are taken from [RFC5322].
形式语法使用增广的巴科斯诺尔形式（ABNF）[RFC5234]表示法，包括RFC 5234[RFC5234]附录B中定义的核心规则。本文件中未定义的术语取自[RFC5322]。
Drafter: Any email user that composes a message (Draft Message) needing authorization before it is released to its intended recipients.
起草人：在将邮件（草稿邮件）发布给预期收件人之前，需要授权才能撰写邮件（草稿邮件）的任何电子邮件用户。
Authorizing User (also Releaser or Authorizer): The mailbox of a user or a group of users that must inspect and authorize the release of a Draft Message before it can be sent. An organization may require more than one Authorizing User to authorize the release of a Draft Message.
授权用户（也称为发布者或授权者）：在发送草稿邮件之前，必须检查并授权发布草稿邮件的用户或用户组的邮箱。组织可能需要多个授权用户来授权发布草稿邮件。
The original email message to be sent doesn't include the MMHS-Authorizing-Users header field. It may or may not include the sender's S/MIME signature.
要发送的原始电子邮件不包括MMHS授权用户标题字段。它可能包括也可能不包括发件人的/MIME签名。
The message to be sent is first submitted over SMTP [RFC6409]. The specific mechanism for how it arrives to the Authorizing User(s) is not specified in this document. One possibility is for the Message Submission Agent (MSA) to redirect all email messages not addressed to Authorizing Users and not submitted by Authorizing Users to a preconfigured mailbox(es) that can be accessed by Authorizing User(s). Another possibility is for the MSA to redirect all email messages without the MMHS-Authorizing-Users header field and/or corresponding S/MIME review signatures to a preconfigured mailbox(es) that can be accessed by Authorizing User(s).
要发送的邮件首先通过SMTP[RFC6409]提交。本文档中未指定如何将其送达授权用户的具体机制。一种可能性是，邮件提交代理（MSA）将所有未发送给授权用户且未通过授权用户提交的电子邮件重定向到授权用户可以访问的预配置邮箱。另一种可能性是MSA将所有不带MMHS Authorization Users标头字段和/或相应S/MIME review签名的电子邮件重定向到授权用户可以访问的预配置邮箱。
In order to prevent a malicious sender from bypassing or altering the Draft and Release procedure, the MSA MUST check that the MMHS-Authorizing-Users header field (if present) is syntactically valid, contains the email addresses of entities authorized to act as Authorizing Users, and, when review signatures are used, that every
为了防止恶意发件人绕过或更改草稿和发布程序，MSA必须检查MMHS授权用户标题字段（如果存在）是否在语法上有效，是否包含被授权作为授权用户的实体的电子邮件地址，以及在使用审阅签名时是否
entity listed has one or more matching review signature (or signature) that is valid.
列出的实体具有一个或多个有效的匹配审阅签名（或签名）。
Each user agent (UA) that is used by an authorized user MUST perform the following steps (if there are multiple Authorizing Users, the whole sequence of steps below is repeated for each Authorizing User):
授权用户使用的每个用户代理（UA）必须执行以下步骤（如果有多个授权用户，则对每个授权用户重复以下整个步骤顺序）：
1. Verify the origination of the message (From/Sender header fields). The exact mechanism to do that is out of scope for this document, but one example is by verifying the S/MIME signature, making sure that the signature protects all header fields (i.e., wrapped by message/rfc822, as described in Section 3.1 of [RFC5751]) and that it matches the sender of the message, as described in [RFC5750]. Another example is by verifying a DKIM signature [RFC6376] (added by the Drafter's Mail User Agent (MUA) or MSA) that covers the From/Sender header fields.
1. 验证邮件的来源（发件人/发件人标头字段）。这样做的确切机制不在本文档的范围内，但一个示例是通过验证S/MIME签名，确保签名保护所有标题字段（即，如[RFC5751]第3.1节所述，由message/rfc822包装），并与[RFC5750]中所述的消息发送方匹配。另一个示例是验证DKIM签名[RFC6376]（由起草人的邮件用户代理（MUA）或MSA添加），该签名覆盖发件人/发件人标头字段。
2. Check if the message already contains the MMHS-Authorizing-Users header field with the email address of the Authorizing User. (This can happen, for example, if the email system is misconfigured and thus contains a loop, or if a malicious sender or attacker is trying to affect the authorization procedure.) If the message doesn't contain the email address of the Authorizing User in the MMHS-Authorizing-Users header field, then go to the next step. If the MMHS-Authorizing-Users header field contains the email address of the Authorizing User, verify the validity of the header field (for example, by checking for the S/MIME signature/review signature or for the DKIM signature) and also verify that the email address associated with the signature matches the email address of the Authorizing User. If the validity of the MMHS-Authorizing-Users header field can be verified, go to step 5 below. Otherwise, return the message to the sender (bounce) or redirect the message to a designated abuse mailbox.
2. 检查邮件是否已包含MMHS Authorization Users标头字段以及授权用户的电子邮件地址。（例如，如果电子邮件系统配置错误，因此包含循环，或者恶意发件人或攻击者试图影响授权过程，则可能会发生这种情况。）如果消息在MMHS authorization Users标头字段中不包含授权用户的电子邮件地址，则转至下一步。如果MMHS授权用户标题字段包含授权用户的电子邮件地址，请验证标题字段的有效性（例如，通过检查S/MIME签名/审阅签名或DKIM签名）并且还验证与签名关联的电子邮件地址与授权用户的电子邮件地址匹配。如果可以验证MMHS授权用户标题字段的有效性，请转至下面的步骤5。否则，请将邮件返回给发件人（退回）或将邮件重定向到指定的邮箱。
3. Allow the Authorizing User to review the content of the message. Some of the checks can be automated (for example, search for keywords). (See Section 3.3.1 for additional considerations.) If, based on the check, the Authorizing User is happy to release the message to the MTS (or to the next Authorizing User, if multiple authorizations are required), the UA SHOULD enable the Authorizing User to protect additions to the MMHS-Authorizing-Users header field, for example, by allowing the addition of the S/MIME review signature (if S/MIME is used for protecting the MMHS-Authorizing-Users header field. See Section 3.3.2 for more details). If the Authorizing User wants to reject the message,
3. 允许授权用户查看消息的内容。一些检查可以自动化（例如，搜索关键字）。（更多注意事项请参见第3.3.1节。）如果根据检查，授权用户愿意将消息发布给MTS（或下一个授权用户，如果需要多个授权），UA应允许授权用户保护MMHS授权用户标题字段的添加内容，例如，通过允许添加S/MIME审查签名（如果S/MIME用于保护MMHS授权用户标题字段。有关更多详细信息，请参阅第3.3.2节）。如果授权用户想要拒绝该消息，
it SHOULD be returned to the Drafter with an explanatory note or it MAY be discarded. The Authorizing User can also choose to forward the message to another Authorizing User for additional approval or become a new Drafter of the message. If the Authorizing User becomes the new Drafter, its UA MUST strip any existing email addresses from the MMHS-Authorizing-Users header field.
应将其返回给起草人，并附上解释性说明，否则可能会被丢弃。授权用户还可以选择将消息转发给另一个授权用户以获得额外批准，或成为消息的新起草人。如果授权用户成为新的起草人，其UA必须从MMHS授权用户标题字段中删除任何现有电子邮件地址。
4. If there is an existing MMHS-Authorizing-Users header field containing the email address of the Authorizing User, skip this step. Otherwise, insert a new MMHS-Authorizing-Users header field (if absent) containing the email address of the Authorizing User or append the email address of the Authorizing User to the end of the existing MMHS-Authorizing-Users header field.
4. 如果存在包含授权用户电子邮件地址的现有MMHS授权用户标题字段，请跳过此步骤。否则，插入包含授权用户电子邮件地址的新MMHS授权用户标题字段（如果不存在），或将授权用户的电子邮件地址附加到现有MMHS授权用户标题字段的末尾。
5. The (possibly) updated email message is either released to the MTS or to the next Authorizing User, as per email system configuration. Note that if the Authorizing User updates the message in a manner that invalidates existing S/MIME or DKIM signature(s), the Authorizing User becomes the Drafter and needs to reapply any protections.
5. 根据电子邮件系统配置，将（可能）更新的电子邮件消息发布给MTS或下一个授权用户。请注意，如果授权用户以使现有S/MIME或DKIM签名无效的方式更新消息，则授权用户将成为起草人，需要重新应用任何保护。
Any encrypted message sent in an environment where the Draft and Release procedure is in force also needs to be encrypted to all Authorizing Users, so that they can perform review of the message. If a User Agent used by an Authorizing User can't decrypt the message, it SHOULD notify the sender (which can be the Drafter or a previous Authorizing User) about the problem using a non-delivery Delivery Status Notification (DSN) or through some other means. The ciphertext that cannot be decrypted by the Authorizing User MAY be included in the notification to aid debugging. A possible reason not to notify the sender is to avoid Denial-of-Service attacks, for example, if an attacker discovers a way to inject fake messages with encryption that doesn't validate in order to overflow the sender's INBOX.
在草稿和发布过程生效的环境中发送的任何加密消息也需要对所有授权用户进行加密，以便他们能够对消息进行审查。如果授权用户使用的用户代理无法解密邮件，则应使用未送达状态通知（DSN）或通过其他方式将问题通知发件人（可以是起草人或以前的授权用户）。授权用户无法解密的密文可以包含在通知中，以帮助调试。不通知发件人的一个可能原因是为了避免拒绝服务攻击，例如，如果攻击者发现一种方法，使用未验证的加密注入假消息，从而使发件人的收件箱溢出。
If S/MIME were not used, the Authorizing User can become the original signer of the message.
如果未使用S/MIME，授权用户可以成为消息的原始签名者。
If a message is signed with multiple signatures (for example, using different cryptographic algorithms, as described in [RFC5752]), all of the signatures that can be verified by an Authorizing User SHOULD be signed with a review signature (authorizing signatures). A recipient of the message can consider any chain of review signatures
如果使用多个签名对消息进行签名（例如，使用不同的加密算法，如[RFC5752]中所述），则授权用户可以验证的所有签名都应使用审查签名（授权签名）进行签名。消息的接收者可以考虑任何评审签名链。
that matches MMHS-Authorizing-Users header field values as valid, only if all signatures in the chain are verified. All of the signatures that cannot be verified MUST be stripped by the Authorizing User Agent.
仅当验证链中的所有签名时，才将MMHS授权用户标题字段值匹配为有效。授权用户代理必须删除所有无法验证的签名。
When triple wrapping [RFC2634] is used, authorizing signatures are applied to the outer level, so that it can be verified by Message Transfer Agents (MTAs) without the need to decrypt content.
当使用三重包装[RFC2634]时，授权签名将应用于外部级别，这样就可以由消息传输代理（MTA）进行验证，而无需解密内容。
If a message being sent is to be delivered within the sender's domain, Message Delivery Agents (MDAs) are responsible for ensuring that the message was properly authorized by Authorizing User(s), as determined by the sender's domain email system configuration. They verify the presence and validity of the MMHS-Authorizing-Users header field in the message, as well as the validity of associated signatures on the message.
如果要在发件人的域内传递正在发送的邮件，则邮件传递代理（MDA）负责确保该邮件已由授权用户正确授权，这由发件人的域电子邮件系统配置决定。它们验证消息中MMHS Authorization Users标头字段的存在和有效性，以及消息上相关签名的有效性。
Note that the above requirements don't apply to direct delivery to any user designated as an Authorizing User.
请注意，上述要求不适用于直接交付给指定为授权用户的任何用户。
The sender's domain border MTAs are responsible for ensuring that all messages that leave the sender's domain were properly authorized by the Authorizing User(s), as determined by the sender's domain email system configuration. They verify the presence and validity of the MMHS-Authorizing-Users header field in outgoing messages, as well as the validity of associated signatures on the message.
发件人的域边界MTA负责确保所有离开发件人域的邮件都由授权用户正确授权，这由发件人的域电子邮件系统配置决定。它们验证传出消息中MMHS Authorization Users标头字段的存在和有效性，以及消息上相关签名的有效性。
The MMHS-Authorizing-Users header field specifies the list of Authorizing Users (or entities(*)) that countersigned this email message (for example, using S/MIME) before it was authorized for release to the MTS. Each user/entity is described by the email address.
MMHS Authorizing Users标头字段指定在授权将此电子邮件发布到MTS之前对其进行会签（例如，使用S/MIME）的授权用户（或实体（*）列表。每个用户/实体由电子邮件地址描述。
(*) Note that in some environments, identities of Authorizing Users are required to be hidden from recipients of email messages; so, upon receipt, MMHS-Authorizing-Users might contain an email address associated with a group of possible users. Such email addresses need to have signatures that don't disclose group membership.
（*）请注意，在某些环境中，授权用户的身份需要对电子邮件收件人隐藏；因此，收到后，授权用户的MMHS可能会包含一个与一组可能的用户关联的电子邮件地址。这样的电子邮件地址需要有不透露集团成员身份的签名。
The MMHS-Authorizing-Users header field specified in this document MUST NOT appear more than once in message headers. An email message that contains multiple MMHS-Authorizing-Users is malformed. An agent processing such a malformed message SHOULD either return it to the sender (if possible) or fix the message so that it contains only one copy of the header field.
此文档中指定的MMHS Authorization Users标头字段在邮件标头中不得出现多次。包含多个MMH授权用户的电子邮件格式不正确。处理此类格式错误的邮件的代理应将其返回给发件人（如果可能），或修复邮件，使其仅包含一个标头字段副本。
MMHS-Authorizing-Users = "MMHS-Authorizing-Users:" mailbox-list CRLF
MMHS Authorizing Users=“MMHS Authorizing Users:”邮箱列表CRLF
mailbox-list = <Defined in RFC 5322>
mailbox-list = <Defined in RFC 5322>
This section provides an updated version of the MIXER mapping specified in [RFC2156] for MMHS applications.
本节提供[RFC2156]中针对MMHS应用指定的混频器映射的更新版本。
In the absence of the MMHS-Authorizing-Users header field, the From and Sender header fields are mapped to their X.400 equivalents as specified in [RFC2156].
如果没有MMHS Authorization Users标头字段，则发件人和发件人标头字段将映射到[RFC2156]中指定的X.400等效项。
If the MMHS-Authorizing-Users header field is present:
如果存在MMHS授权用户标题字段：
1. If the Sender header field is present, it is mapped to IPMS.Heading.originator; otherwise, the first From header field address is mapped to IPMS.Heading.originator.
1. 如果存在发件人标头字段，则将其映射到IPMS.Heading.originator；否则，第一个From标头字段地址将映射到IPMS.Heading.originator。
2. Map the From header field address(es) and the MMHS-Authorizing-Users header field address(es) to IPMS.Heading.authorizing-users, skipping the first From header field address if it was mapped to IPMS.Heading.originator.
2. 将发件人标头字段地址和MMHS授权用户标头字段地址映射到IPMS.Heading.Authorizing-Users，如果第一个发件人标头字段地址映射到IPMS.Heading.originator，则跳过该地址。
Mapping from X.400 to the Internet is controlled by whether or not a particular message is considered a military message. A message is considered a military message (as defined by ACP 123 [ACP123] and also specified in STANAG 4406 [STANAG-4406]) if there are any MMHS heading extensions present. Alternatively, this MAY be done by configuration (i.e., all messages can be considered military messages).
从X.400到Internet的映射由是否将特定消息视为军事消息来控制。如果存在任何MMHS标题扩展，则消息被视为军事消息（如ACP 123[ACP123]所定义，也在STANAG 4406[STANAG-4406]中规定）。或者，这可以通过配置完成（即，所有消息都可以被视为军事消息）。
For non-military messages, mapping from X.400 as specified in [RFC2156] is used.
对于非军事消息，使用[RFC2156]中规定的X.400映射。
For military messages, the following mapping is used:
对于军事信息，使用以下映射：
1. IPMS.Heading.originator is mapped to the From header field.
1. IPMS.Heading.originator映射到From标头字段。
2. The IPMS.Heading.authorizing-users is mapped to the MMHS-Authorizing-Users header field.
2. IPMS.Heading.authorizing-users映射到MMHS authorizing-users标头字段。
IANA has added the MMHS-Authorizing-Users header field specified in Section 4 to the "Provisional Message Header Field Names" registry, defined by "Registration Procedures for Message Header Fields" [RFC3864]. The registration template is as follows:
IANA已将第4节中指定的MMHS授权用户标题字段添加到“临时消息标题字段名称”注册表中，该注册表由“消息标题字段注册程序”[RFC3864]定义。注册模板如下：
Header field name: MMHS-Authorizing-Users
标题字段名称：MMHS授权用户
Applicable protocol: mail ([RFC5322])
适用协议：邮件（[RFC5322]）
Status: provisional
现状：临时
Author/Change controller: Alexey Melnikov <alexey.melnikov@isode.com>
Author/Change controller: Alexey Melnikov <alexey.melnikov@isode.com>
Specification document(s): RFC 7912
规范文件：RFC 7912
Related information:
有关资料：
In some military environments, the identities of Authorizing Users are required to be hidden from recipients of email messages. This can be accomplished by using a group address for the MMHS-Authorizing-Users. In this way, the recipient will know that it was released by an Authorizing User in that group, but the recipient will not know which one of them took the action.
在某些军事环境中，授权用户的身份需要对电子邮件收件人隐藏。这可以通过使用MMHS授权用户的组地址来实现。通过这种方式，接收者将知道它是由该组中的授权用户发布的，但接收者将不知道他们中的哪一个采取了该操作。
For those organizations that do not wish to disclose the Authorizing Users' group membership, care must also be taken to ensure that the information included in the certificate used for signing email messages does not disclose individuals in the group.
对于那些不希望披露授权用户集团成员身份的组织，还必须注意确保用于签署电子邮件的证书中包含的信息不会披露集团中的个人。
Further security considerations are described in subsections of this section.
本节各小节介绍了进一步的安全注意事项。
A malicious sender may add/change an MMHS-Authorizing-Users header field to bypass or alter the message authorization procedure invoked for messages with no MMHS-Authorizing-Users header field. For this reason, it is important for agents and clients that rely on the validity of the MMHS-Authorizing-Users header field to also verify the review signature (or a similar protection mechanism) that confirms that a particular person or entity authorized release of a message.
恶意发件人可能会添加/更改MMHS authorization Users标头字段，以绕过或更改为没有MMHS authorization Users标头字段的邮件调用的邮件授权过程。因此，依赖MMHS Authorization Users标头字段有效性的代理和客户端还必须验证确认特定个人或实体授权发布消息的审查签名（或类似保护机制）。
It is possible for an attacker to add an MMHS-Authorizing-Users header field that is extraordinarily large or otherwise malformed in an attempt to discover or exploit weaknesses in the header field parsing code. Implementations MUST thoroughly verify all such header fields received from MTAs and be robust against intentionally as well as unintentionally malformed header fields.
攻击者可能会添加一个非常大或格式错误的MMHS Authorization Users标头字段，试图发现或利用标头字段解析代码中的弱点。实现必须彻底验证从MTA接收到的所有此类头字段，并对有意或无意格式错误的头字段具有鲁棒性。
[ACP123] CCEB, "Common Messaging strategy and procedures", ACP 123 (B), May 2009.
[ACP123]CCEB，“通用信息策略和程序”，ACP 123（B），2009年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, DOI 10.17487/RFC2156, January 1998, <http://www.rfc-editor.org/info/rfc2156>.
[RFC2156]Kille，S.，“混音器（Mime互联网X.400增强中继）：X.400和RFC 822/Mime之间的映射”，RFC 2156，DOI 10.17487/RFC2156，1998年1月<http://www.rfc-editor.org/info/rfc2156>.
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, DOI 10.17487/RFC2634, June 1999, <http://www.rfc-editor.org/info/rfc2634>.
[RFC2634]Hoffman，P.，Ed.“S/MIME的增强安全服务”，RFC 2634，DOI 10.17487/RFC2634，1999年6月<http://www.rfc-editor.org/info/rfc2634>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<http://www.rfc-editor.org/info/rfc5322>.
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, <http://www.rfc-editor.org/info/rfc5750>.
[RFC5750]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2证书处理”，RFC 5750，DOI 10.17487/RFC5750，2010年1月<http://www.rfc-editor.org/info/rfc5750>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，DOI 10.17487/RFC5751，2010年1月<http://www.rfc-editor.org/info/rfc5751>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <http://www.rfc-editor.org/info/rfc6376>.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 6376，DOI 10.17487/RFC6376，2011年9月<http://www.rfc-editor.org/info/rfc6376>.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <http://www.rfc-editor.org/info/rfc6409>.
[RFC6409]Gellens，R.和J.Klensin，“邮件的邮件提交”，STD 72，RFC 6409，DOI 10.17487/RFC6409，2011年11月<http://www.rfc-editor.org/info/rfc6409>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，DOI 10.17487/RFC3864，2004年9月<http://www.rfc-editor.org/info/rfc3864>.
[RFC5752] Turner, S. and J. Schaad, "Multiple Signatures in Cryptographic Message Syntax (CMS)", RFC 5752, DOI 10.17487/RFC5752, January 2010, <http://www.rfc-editor.org/info/rfc5752>.
[RFC5752]Turner，S.和J.Schaad，“加密消息语法（CMS）中的多重签名”，RFC 5752，DOI 10.17487/RFC5752，2010年1月<http://www.rfc-editor.org/info/rfc5752>.
[STANAG-4406] NATO, "STANAG 4406 Edition 2: Military Message Handling System", STANAG 4406 Ed. 2, March 2005.
[STANAG-4406]北约，“STANAG 4406第2版：军事信息处理系统”，STANAG 4406第2版，2005年3月。
Acknowledgements
致谢
Many thanks for reviews and text provided by Steve Kille, Jim Schaad, Russ Housley, David Wilson, Chris Bonatti, and Sean Turner.
非常感谢Steve Kille、Jim Schaad、Russ Housley、David Wilson、Chris Bonatti和Sean Turner提供的评论和文本。
Some text in this document was copied from RFC 7001.
本文档中的某些文本是从RFC 7001复制的。
Author's Address
作者地址
Alexey Melnikov Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom
Alexey Melnikov Isode Ltd 14 Castle Mews Hampton，英国米德尔塞克斯TW12 2NP
Email: Alexey.Melnikov@isode.com
Email: Alexey.Melnikov@isode.com