Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 6477 Isode Ltd
Category: Informational G. Lunt
ISSN: 2070-1721 SMHS Ltd
January 2012
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 6477 Isode Ltd
Category: Informational G. Lunt
ISSN: 2070-1721 SMHS Ltd
January 2012
Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail
用于Internet邮件的军事邮件处理系统（MMHS）头字段的注册
Abstract
摘要
A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2 and ACP 123. This document specifies message header fields and associated processing for RFC 5322 (Internet Message Format) to provide a comparable messaging service. In addition, this document provides for a STANAG 4406 / Internet Email Gateway that supports message conversion.
军事信息处理系统（MMHS）处理正式信息，确保在国家和国际战略和战术网络中发布、分发、安全和及时交付。MMHS服务要素定义为ITU-T X.400（1992）国际标准的一组扩展，并在STANAG 4406第2版和ACP 123中规定。本文档指定RFC 5322（互联网消息格式）的消息头字段和相关处理，以提供类似的消息传递服务。此外，本文档还提供了支持消息转换的STANAG 4406/Internet电子邮件网关。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第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/rfc6477.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6477.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Registration Templates ..........................................3
3.1. Header Field: MMHS-Exempted-Address ........................5
3.2. Header Field: MMHS-Extended-Authorisation-Info .............5
3.3. Header Field: MMHS-Subject-Indicator-Codes .................6
3.4. Header Field: MMHS-Handling-Instructions ...................6
3.5. Header Field: MMHS-Message-Instructions ....................7
3.6. Header Field: MMHS-Codress-Message-Indicator ...............8
3.7. Header Field: MMHS-Originator-Reference ....................8
3.8. Header Field: MMHS-Primary-Precedence ......................9
3.9. Header Field: MMHS-Copy-Precedence ........................10
3.10. Header Field: MMHS-Message-Type ..........................10
3.11. Header Field: MMHS-Other-Recipients-Indicator-To .........11
3.12. Header Field: MMHS-Other-Recipients-Indicator-CC .........12
3.13. Header Field: MMHS-Acp127-Message-Identifier .............13
3.14. Header Field: MMHS-Originator-PLAD .......................13
4. Formal Syntax ..................................................14
5. Service in Comparison to ACP 123 / STANAG 4406 .................16
6. Gatewaying with ACP 123 / STANAG 4406 ..........................16
7. Gatewaying with ACP 127 ........................................18
8. IANA Considerations ............................................18
9. Security Considerations ........................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. Acknowledgements ......................................21
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Registration Templates ..........................................3
3.1. Header Field: MMHS-Exempted-Address ........................5
3.2. Header Field: MMHS-Extended-Authorisation-Info .............5
3.3. Header Field: MMHS-Subject-Indicator-Codes .................6
3.4. Header Field: MMHS-Handling-Instructions ...................6
3.5. Header Field: MMHS-Message-Instructions ....................7
3.6. Header Field: MMHS-Codress-Message-Indicator ...............8
3.7. Header Field: MMHS-Originator-Reference ....................8
3.8. Header Field: MMHS-Primary-Precedence ......................9
3.9. Header Field: MMHS-Copy-Precedence ........................10
3.10. Header Field: MMHS-Message-Type ..........................10
3.11. Header Field: MMHS-Other-Recipients-Indicator-To .........11
3.12. Header Field: MMHS-Other-Recipients-Indicator-CC .........12
3.13. Header Field: MMHS-Acp127-Message-Identifier .............13
3.14. Header Field: MMHS-Originator-PLAD .......................13
4. Formal Syntax ..................................................14
5. Service in Comparison to ACP 123 / STANAG 4406 .................16
6. Gatewaying with ACP 123 / STANAG 4406 ..........................16
7. Gatewaying with ACP 127 ........................................18
8. IANA Considerations ............................................18
9. Security Considerations ........................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. Acknowledgements ......................................21
[RFC5322] defines a protocol for the format of electronic messages exchanged on the Internet. MMHS is a military specification defined in ACP 123 [ACP123] (also specified in STANAG 4406 [STANAG-4406]), which defines a number of extensions to the basic X.400 (1992) protocol for the services required by military messaging.
[RFC5322]定义了互联网上电子信息交换格式的协议。MMHS是ACP 123[ACP123]中定义的军用规范（也在STANAG 4406[STANAG-4406]中指定），它定义了基本X.400（1992）协议的许多扩展，用于军用消息传递所需的服务。
This document supports translating most of the Elements of Service defined in ACP 123 [ACP123] to Internet message header fields (see Section 5 for more details). This specification is written to extend the Mime Internet X.400 Enhanced Relay (MIXER) specification
本文档支持将ACP 123[ACP123]中定义的大部分服务元素转换为Internet消息头字段（有关更多详细信息，请参阅第5节）。本规范旨在扩展Mime Internet X.400增强型中继（混音器）规范
[RFC2156] to enable inter-conversion in a MIXER gateway with the X.400 Interpersonal Messaging System (IPMS) heading extensions defined in ACP 123 / STANAG 4406, Annex A.
[RFC2156]使用ACP 123/STANAG 4406附件a中定义的X.400人际消息传递系统（IPMS）标题扩展，在混音器网关中启用相互转换。
The document is aimed at the ability to represent MMHS messages as RFC 5322 messages. All RFC 5322 header fields defined in this document are prefixed with the string "MMHS-" to distinguish them from any other header fields.
本文档旨在将MMHS消息表示为RFC 5322消息。本文档中定义的所有RFC 5322标题字段都以字符串“MMHS-”作为前缀，以区别于任何其他标题字段。
Unless stated otherwise, all header fields described in this document are OPTIONAL in an Internet Message.
除非另有说明，否则本文档中描述的所有标题字段在Internet消息中都是可选的。
This document is structured as follows: Section 3 and its subsections formally define new Internet header fields and show some examples. Section 4 provides Augmented Backus-Naur Form (ABNF) syntax for them. Section 5 provides some background information about which features of ACP 123 / STANAG 4406 were not implemented in this specification. Subsequent sections talk about additional requirements for gatewaying to/from ACP 123 / STANAG 4406 and ACP 127 [ACP127] environments, respectively.
本文档的结构如下：第3节及其各小节正式定义了新的Internet头字段，并给出了一些示例。第4节为它们提供了扩展的Backus-Naur-Form（ABNF）语法。第5节提供了一些背景信息，说明本规范中未实现ACP 123/STANAG 4406的哪些功能。后续章节将分别讨论与ACP 123/STANAG 4406和ACP 127[ACP127]环境之间的网关连接的附加要求。
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 ABNF [RFC5234] notation including the core rules defined in Appendix B of RFC 5234 [RFC5234].
形式语法使用ABNF[RFC5234]符号，包括RFC 5234[RFC5234]附录B中定义的核心规则。
Header field entries are summarized below in tabular form for convenience of reference and presented in full in the following subsections.
标题字段条目以表格形式总结如下，以便于参考，并在以下小节中完整呈现。
Any header field specified in this document MUST NOT appear more than once in message headers.
此文档中指定的任何标题字段在邮件标题中不得出现多次。
+------------------------------------+----------+-------------------+
| Header name | Protocol | Reference |
+------------------------------------+----------+-------------------+
| MMHS-Exempted-Address | mail | [ACP123], |
| | | Appendices A1.1 |
| | | and B.105 |
| MMHS-Extended-Authorisation-Info | mail | [ACP123], |
| | | Appendices A1.2 |
| | | and B.106 |
| MMHS-Subject-Indicator-Codes | mail | [ACP123], |
| | | Appendices A1.3 |
| | | and B.107 |
| MMHS-Handling-Instructions | mail | [ACP123][ACP123], |
| | | Appendices A1.4 |
| | | and B.108 |
| MMHS-Message-Instructions | mail | [ACP123], |
| | | Appendices A1.5 |
| | | and B.109 |
| MMHS-Codress-Message-Indicator | mail | [ACP123], |
| | | Appendices A1.6 |
| | | and B.110 |
| MMHS-Originator-Reference | mail | [ACP123], |
| | | Appendices A1.7 |
| | | and B.111 |
| MMHS-Primary-Precedence | mail | [ACP123], |
| | | Appendices A1.8 |
| | | and B.101 |
| MMHS-Copy-Precedence | mail | [ACP123], |
| | | Appendices A1.9 |
| | | and B.102 |
| MMHS-Message-Type | mail | [ACP123], |
| | | Appendices A1.10 |
| | | and B.103 |
| MMHS-Other-Recipients-Indicator-To | mail | [ACP123], |
| | | Appendices A1.12 |
| | | and B.113 |
| MMHS-Other-Recipients-Indicator-CC | mail | [ACP123], |
| | | Appendices A1.12 |
| | | and B.113 |
| MMHS-Acp127-Message-Identifier | mail | [ACP123], |
| | | Appendices A1.14 |
| | | and B.116 |
| MMHS-Originator-PLAD | mail | [ACP123], |
| | | Appendices A1.15 |
| | | and B.117 |
+------------------------------------+----------+-------------------+
+------------------------------------+----------+-------------------+
| Header name | Protocol | Reference |
+------------------------------------+----------+-------------------+
| MMHS-Exempted-Address | mail | [ACP123], |
| | | Appendices A1.1 |
| | | and B.105 |
| MMHS-Extended-Authorisation-Info | mail | [ACP123], |
| | | Appendices A1.2 |
| | | and B.106 |
| MMHS-Subject-Indicator-Codes | mail | [ACP123], |
| | | Appendices A1.3 |
| | | and B.107 |
| MMHS-Handling-Instructions | mail | [ACP123][ACP123], |
| | | Appendices A1.4 |
| | | and B.108 |
| MMHS-Message-Instructions | mail | [ACP123], |
| | | Appendices A1.5 |
| | | and B.109 |
| MMHS-Codress-Message-Indicator | mail | [ACP123], |
| | | Appendices A1.6 |
| | | and B.110 |
| MMHS-Originator-Reference | mail | [ACP123], |
| | | Appendices A1.7 |
| | | and B.111 |
| MMHS-Primary-Precedence | mail | [ACP123], |
| | | Appendices A1.8 |
| | | and B.101 |
| MMHS-Copy-Precedence | mail | [ACP123], |
| | | Appendices A1.9 |
| | | and B.102 |
| MMHS-Message-Type | mail | [ACP123], |
| | | Appendices A1.10 |
| | | and B.103 |
| MMHS-Other-Recipients-Indicator-To | mail | [ACP123], |
| | | Appendices A1.12 |
| | | and B.113 |
| MMHS-Other-Recipients-Indicator-CC | mail | [ACP123], |
| | | Appendices A1.12 |
| | | and B.113 |
| MMHS-Acp127-Message-Identifier | mail | [ACP123], |
| | | Appendices A1.14 |
| | | and B.116 |
| MMHS-Originator-PLAD | mail | [ACP123], |
| | | Appendices A1.15 |
| | | and B.117 |
+------------------------------------+----------+-------------------+
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
The MMHS-Exempted-Address header field, by its presence, indicates the addresses of members in an Address List (AL) that should not receive the message. If this header field is absent from the message, all members of an AL will be considered to be valid recipients of the message.
MMHS豁免地址标头字段通过其存在指示地址列表（AL）中不应接收消息的成员的地址。如果邮件中没有此标头字段，则AL的所有成员都将被视为邮件的有效收件人。
Note: there is no guarantee that the exempted addresses will not receive the message as the result of redirection, Distribution List (DL) expansion, etc.
注意：不保证豁免地址不会因为重定向、通讯组列表（DL）扩展等而收到消息。
Example:
MMHS-Exempted-Address:
UK SHL CGT Samuals G <graham.samuals@shl.example.com>,
UK SHL Duty Officer <duty@shl.example.com>
Example:
MMHS-Exempted-Address:
UK SHL CGT Samuals G <graham.samuals@shl.example.com>,
UK SHL Duty Officer <duty@shl.example.com>
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]]
The MMHS-Extended-Authorisation-Info header field, by its presence, indicates either the date and the time when the message was officially released by the releasing officer or the date and time when the message was initially submitted to a communication facility for transmission.
MMHS扩展授权信息标题字段通过其存在，指示发布官员正式发布消息的日期和时间，或消息最初提交给通信设施进行传输的日期和时间。
This header field SHOULD always be present in an email message that complies with this specification.
此标题字段应始终出现在符合此规范的电子邮件中。
Example:
MMHS-Extended-Authorisation-Info:
Mon, 09 Aug 2010 15:27:40 +0100
Example:
MMHS-Extended-Authorisation-Info:
Mon, 09 Aug 2010 15:27:40 +0100
The example above demonstrates use of folding white space (FWS [RFC5322]).
上面的示例演示了折叠空白（FWS[RFC5322]）的使用。
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
A Subject Indicator Code (SIC) is a mechanism for formally identifying the topic of a message. SICs are nested codes that provide information for message distribution after delivery to the recipient organization. SICs are usually three letters or three letters and digits, but may be up to eight characters long. Nations and organizations using SICs usually maintain a central registry.
主题指示符代码（SIC）是一种用于正式标识消息主题的机制。SIC是嵌套的代码，用于在传递到收件人组织后为邮件分发提供信息。SIC通常是三个字母或三个字母和数字，但可能长达八个字符。使用SIC的国家和组织通常都有一个中央注册中心。
When present, an MMHS-Subject-Indicator-Codes header field contains one or more SICs, which indicates distribution information to a recipient or a recipient's User Agent. This information can be used to perform automatic or manual local distribution of a message. If the MMHS-Subject-Indicator-Codes header field is absent, then the local distribution will be in accordance with the message handling policy of the recipient's domain.
当存在时，MMHS主题指示符代码标题字段包含一个或多个SIC，它向收件人或收件人的用户代理指示分发信息。此信息可用于执行消息的自动或手动本地分发。如果MMHS Subject Indicator Codes标头字段不存在，则本地分发将符合收件人域的邮件处理策略。
[ACP123] specifies two optional components of the Distribution Code Element of Service. The MMHS-Subject-Indicator-Codes header field covers only the SIC code component of distribution codes.
[ACP123]指定服务的分发代码元素的两个可选组件。MMHS主题指示符代码标题字段仅涵盖分销代码的SIC代码部分。
Example:
MMHS-Subject-Indicator-Codes: SDM; KKZ ; BRL
Example:
MMHS-Subject-Indicator-Codes: SDM; KKZ ; BRL
The example above includes three SIC codes: "SDM" (GROUND/LAND REQUIREMENTS), "KKZ" (HELICOPTER PUBLICATIONS/MANUALS), and "BRL" (HILEX INCIDENTS).
上述示例包括三个SIC代码：“SDM”（地面/陆地要求）、“KKZ”（直升机出版物/手册）和“BRL”（HILEX事故）。
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
The MMHS-Handling-Instructions header field, by its presence, indicates human-readable local handling instructions that require some manual handling by a traffic operator. If this header field is absent, the message will be considered as not requiring manual handling by a traffic operator.
MMHS Handling Instructions header（MMHS处理指令标题）字段通过其存在表示需要交通运营商进行一些手动处理的人类可读本地处理指令。如果缺少此标题字段，则该消息将被视为不需要交通运营商手动处理。
Handling instructions (also called "transmission instructions") are a part of format line 4 as defined in ACP 127 [ACP127] and concern the sending of the message, e.g., that a particular system shall be used for transfer of the message.
处理指令（也称为“传输指令”）是ACP 127[ACP127]中定义的格式行4的一部分，涉及消息的发送，例如，应使用特定系统传输消息。
This header field is used to support interoperability with ACP 127 systems.
此标题字段用于支持与ACP 127系统的互操作性。
Example: MMHS-Handling-Instructions: RXFPA ZOV MINDEF
示例：MMHS处理说明：RXFPA ZOV MINDEF
The example above includes one ACP 131(F) handling instruction: "RXFPA ZOV MINDEF". The "ZOV MINDEF" indicates that MINDEF rerouted the message for some reason, and the correct routing is via RXFPA.
上述示例包括一条ACP 131（F）处理指令：“RXFPA ZOV MINDEF”。“ZOV MINDEF”表示MINDEF出于某种原因重新路由了消息，正确的路由是通过RXFPA。
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
The MMHS-Message-Instructions header field, by its presence, indicates message instructions (also known as "remarks") accompanying the message (e.g., similar to the operating signals specified in ACP 131 [ACP131]). If this header field is absent, the message will be considered received without message instructions.
MMHS消息指令头字段通过其存在指示伴随消息的消息指令（也称为“备注”）（例如，类似于ACP 131[ACP131]中规定的操作信号）。如果缺少此标头字段，则认为收到的消息没有消息指示。
The difference between handling instructions and message instructions is that the former is only for manual handling by traffic operators, while the latter also contains information of interest to the persons reading the message.
操作说明和信息说明的区别在于，前者仅用于交通运营商的手动操作，而后者还包含阅读信息的人员感兴趣的信息。
Example: MMHS-Message-Instructions: MINIMIZE CONSIDERED; NO DISTRIBUTION
示例：MMHS消息说明：最小化已考虑；无分布
The example above includes two message instructions defined by ACP123(B) [ACP123]: "MINIMIZE CONSIDERED" indicating that the originating user has considered the Minimize status of the recipients and "NO DISTRIBUTION" indicating that the recipients should not distribute the message further without the originating user's approval.
上述示例包括由ACP123（B）[ACP123]定义的两条消息指令：“已考虑最小化”表示发起用户已考虑收件人的最小化状态，“未分发”表示未经发起用户批准，收件人不应进一步分发消息。
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
The MMHS-Codress-Message-Indicator header field, by its presence, indicates that the message is in Codress format. If this header field is absent, the message will be considered received without the Codress format.
MMHS Codress消息指示符标题字段的存在表明消息为Codress格式。如果缺少此标头字段，则认为收到的消息没有Codress格式。
A Codress message is one in which all addresses, i.e., the sender and all recipients, are encrypted within the ACP 127 text (body) [ACP127]. The heading of any Codress message contains only the minimum amount of information that will enable a receiving station to deal properly and expeditiously with the particular transmission. The general rules for the preparation and transmission of Codress messages are given in ACP 121 [ACP121].
Codress消息是所有地址（即发送方和所有接收方）在ACP 127文本（正文）[ACP127]中加密的消息。任何Codress报文的标题仅包含使接收站能够正确、快速地处理特定传输的最小信息量。ACP 121[ACP121]中给出了Codress消息准备和传输的一般规则。
This header field is used only to support interoperability with ACP 127 systems.
此标题字段仅用于支持与ACP 127系统的互操作性。
Example: MMHS-Codress-Message-Indicator: 23
示例：MMHS Codress消息指示器：23
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
The MMHS-Originator-Reference header field, by its presence, indicates a user-defined reference called the "originator's number". If this header field is absent, then the message will be considered received without any user-defined reference.
MMHS发起人参考标题字段通过其存在，表示一个称为“发起人编号”的用户定义参考。如果缺少此标头字段，则消息将被视为在没有任何用户定义引用的情况下收到。
The originator's number is used by the originating organizational unit and is further qualified within national policy.
发起人的编号由发起组织单位使用，并在国家政策中进一步限定。
Note: trailing and leading spaces in an originator reference are not allowed by syntax.
注意：语法不允许原始发件人引用中的尾随空格和前导空格。
Example: MMHS-Originator-Reference: IMSCOM-JIC-612-78
示例：MMHS发起人参考：IMSCOM-JIC-612-78
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
The MMHS-Primary-Precedence header field, by its presence, indicates the precedence level of the primary ("action") recipients. The message originating domain MUST ensure that this header field is always present if the message contains "To:" ("action") addresses.
MMHS主优先级标头字段通过其存在指示主（“操作”）收件人的优先级。如果消息包含“收件人”（“操作”）地址，则消息源域必须确保此标头字段始终存在。
The MMHS Primary Precedence Element of Service indicates the relative order in which Military Messages are to be handled for primary (action) recipients, i.e., a Military Message with a higher MMHS-Primary-Precedence header field value SHOULD be handled before a Military Message with a lower MMHS-Primary-Precedence header field value.
服务的MMHS主优先级元素表示主要（行动）收件人处理军事邮件的相对顺序，即，具有较高MMHS主优先级标头字段值的军事邮件应在具有较低MMHS主优先级标头字段值的军事邮件之前处理。
The header field value is a non-negative integer, or one of the six predefined case-insensitive labels: "deferred" (same as "0"), "routine" (same as "1"), "priority" (same as "2"), "immediate" (same as "3"), "flash" (same as "4"), or "override" (same as "5"), optionally followed by a comment. Note that, according to ACP 123, values in the range from 0 to 15 are reserved for NATO-defined precedence levels, and values in the range from 16 to 31 are reserved for national users.
标题字段值是一个非负整数，或六个预定义的不区分大小写标签之一：“延迟”（与“0”相同）、“例程”（与“1”相同）、“优先级”（与“2”相同）、“立即”（与“3”相同）、“闪存”（与“4”相同）或“覆盖”（与“5”相同），可选地后跟注释。请注意，根据ACP 123，0到15范围内的值保留给北约定义的优先级别，16到31范围内的值保留给国家用户。
Example 1: MMHS-Primary-Precedence: 0 (Deferred)
示例1:MMHS主优先级：0（延迟）
Example 2: MMHS-Primary-Precedence: FLASH
示例2:MMHS主优先级：闪存
Example 3: MMHS-Primary-Precedence: 7
示例3:MMHS主优先级：7
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
The MMHS-Copy-Precedence header field, by its presence, indicates the precedence level of the copy ("information") recipients. The message originating domain MUST ensure that this header field is always present if the message contains "Cc:" or "Bcc:" ("information") addresses.
MMHS复制优先头字段通过其存在指示复制（“信息”）收件人的优先级别。如果消息包含“Cc:”或“Bcc:”（“信息”）地址，则消息源域必须确保此标头字段始终存在。
The MMHS Copy Precedence Element of Service indicates the relative order in which Military Messages are to be handled for copy (information) recipients. i.e. a Military Message with higher MMHS-Copy-Precedence header field value SHOULD be handled before a Military Message with a lower MMHS-Copy-Precedence header field value.
服务的MMHS复制优先级元素表示副本（信息）收件人处理军事邮件的相对顺序。i、 e.具有较高MMHS复制优先头字段值的军事消息应在具有较低MMHS复制优先头字段值的军事消息之前处理。
The header field value is a non-negative integer, or one of the 6 predefined case-insensitive labels: "deferred" (same as "0"), "routine" (same as "1"), "priority" (same as "2"), "immediate" (same as "3"), "flash" (same as "4"), or "override" (same as "5"), optionally followed by a comment. Note that according to ACP 123, values in the range from 0 to 15 are reserved for NATO-defined precedence levels and values in the range from 16 to 31 are reserved for national users.
标题字段值是非负整数，或6个预定义的不区分大小写标签中的一个：“延迟”（与“0”相同）、“例程”（与“1”相同）、“优先级”（与“2”相同）、“立即”（与“3”相同）、“闪存”（与“4”相同）或“覆盖”（与“5”相同），可选地后跟注释。请注意，根据ACP 123，0到15范围内的值保留给北约定义的优先级别，16到31范围内的值保留给国家用户。
Example 1: MMHS-Copy-Precedence: 2 (priority)
示例1:MMHS复制优先级：2（优先级）
Example 2: MMHS-Copy-Precedence: Priority
示例2:MMHS复制优先级：优先级
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
The MMHS-Message-Type heading extension, by its presence, indicates whether the message is to be considered as an exercise, an operation, a project, or a drill. (Note that the list of types is extensible, and other types can be specified using the numeric form, see below).
MMHS消息类型标题扩展名通过其存在指示消息是被视为练习、操作、项目还是演练。（请注意，类型列表是可扩展的，可以使用数字形式指定其他类型，请参见下文）。
It may include an optional parameter specifying the name of the exercise, operation, project, or drill. If this extension is absent, the message will be considered to be of an undefined type.
它可能包括一个可选参数，指定练习、操作、项目或演练的名称。如果缺少此扩展名，则消息将被视为未定义类型。
The header field value is a non-negative integer, or one of the four predefined case-insensitive labels: "exercise" (same as "0"), "operation" (same as "1"), "project" (same as "2"), "drill" (same as "3"). Note that according to ACP 123, values in the range from 0 to 127 are reserved for NATO-defined Message Type identifiers and values in the range from 128 to 255 are not defined by NATO and may be used nationally or bilaterally.
标题字段值为非负整数，或四个预定义的不区分大小写标签之一：“练习”（与“0”相同）、“操作”（与“1”相同）、“项目”（与“2”相同）、“钻取”（与“3”相同）。请注意，根据ACP 123，0到127范围内的值是为北约定义的消息类型标识符保留的，128到255范围内的值不是北约定义的，可以在国家或双边使用。
Example 1:
MMHS-Message-Type: 0(exercise); identifier="CANDLE FISH"
Example 1:
MMHS-Message-Type: 0(exercise); identifier="CANDLE FISH"
Example 2: MMHS-Message-Type: 3
示例2:MMHS消息类型：3
Example 3: MMHS-Message-Type: 2 (projet)
示例3:MMHS消息类型：2（projet）
Example 4: MMHS-Message-Type: project
示例4:MMHS消息类型：项目
Note that some of the examples above demonstrate use of optional comments. See Section 4 for the exact syntax of this header field.
注意，上面的一些示例演示了可选注释的使用。有关此标题字段的确切语法，请参见第4节。
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
The MMHS-Other-Recipients-Indicator-To header field, by its presence, indicates the names of primary ("action") recipients that are intended to receive, or have received, the message via means other than MMHS. Note that the absence of both this header field and the MMHS-Other-Recipients-Indicator-CC header field (see Section 3.12) does not guarantee that all recipients are within the MMHS.
MMHS Other Recipients Indicator To header（MMHS其他收件人指示符至标题）字段通过其存在，指示打算通过MMHS以外的方式接收或已接收邮件的主要（“操作”）收件人的姓名。请注意，缺少此标题字段和MMHS其他收件人指示符CC标题字段（参见第3.12节）并不保证所有收件人都在MMHS内。
This header field enables a recipient to determine all action recipients of a Military Message. This header field is derived from the Other Recipient Indicator Element of Service.
此标头字段使收件人能够确定军事邮件的所有操作收件人。此标头字段派生自服务的其他收件人指示符元素。
There are several reasons as to why a recipient of a Military Message may be identified by this header:
有几个原因可以说明为什么军事邮件的收件人可以通过此标头进行标识：
1. The recipient is not part of the MMHS.
1. 收件人不是MMHS的一部分。
2. The path to the recipient through the MMHS may not be secure; therefore, the originator has used alternative mechanisms to distribute the Military Message.
2. 通过MMHS到收件人的路径可能不安全；因此，发起人使用了其他机制来传播军事信息。
3. The recipient was already in receipt of the Military Message prior to the Military Message being inserted into the MMHS.
3. 在将军事信息插入MMHS之前，收件人已收到该军事信息。
Example: MMHS-Other-Recipients-Indicator-To: UK SHL COS; UK SHL IM
示例：MMHS其他收件人指标至：英国SHL COS；英国SHL IM
The example above includes names of two primary recipients that received the message via means other than MMHS.
上述示例包括通过MMHS以外的方式接收消息的两个主要收件人的姓名。
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
The MMHS-Other-Recipients-Indicator-CC header field, by its presence, indicates the names of copy ("information") recipients that are intended to receive, or have received, the message via means other than MMHS. Note that the absence of both this header field and the MMHS-Other-Recipients-Indicator-To header field (see Section 3.11) does not guarantee that all recipients are within the MMHS.
MMHS其他收件人指示符CC标头字段通过其存在，指示拟通过MMHS以外的方式接收或已接收邮件的副本（“信息”）收件人的名称。请注意，缺少此标题字段和MMHS其他收件人指示符至标题字段（参见第3.11节）并不保证所有收件人都在MMHS内。
This header field enables a recipient to determine all copy recipients of a Military Message. This header field is derived from the Other Recipient Indicator Element of Service.
此标头字段使收件人能够确定军事邮件的所有副本收件人。此标头字段派生自服务的其他收件人指示符元素。
There are several reasons as to why a recipient of a Military Message may be identified by this header:
有几个原因可以说明为什么军事邮件的收件人可以通过此标头进行标识：
1. The recipient is not part of the MMHS.
1. 收件人不是MMHS的一部分。
2. The path to the recipient through the MMHS may not be secure; therefore, the originator has used alternative mechanisms to distribute the Military Message.
2. 通过MMHS到收件人的路径可能不安全；因此，发起人使用了其他机制来传播军事信息。
3. The recipient was already in receipt of the Military Message prior to it being inserted into the MMHS.
3. 在将军事信息插入MMHS之前，收件人已收到该军事信息。
Example: MMHS-Other-Recipients-Indicator-CC: UK SHL LEGAD
示例：MMHS其他收件人指标CC:UK SHL LEGAD
The example above includes 1 copy (information) recipient that received the message via means other than MMHS.
上述示例包括1个通过MMHS以外的方式接收消息的副本（信息）收件人。
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
The MMHS-Acp127-Message-Identifier header field, by its presence, indicates an ACP 127 message identifier [ACP127] for a message that originated from an ACP 127 domain. If this extension is absent, then the message did not encounter an ACP 127 domain.
MMHS-Acp127-Message-Identifier报头字段通过其存在表示源自ACP 127域的消息的ACP 127消息标识符[Acp127]。如果没有此扩展，则消息没有遇到ACP 127域。
The MMHS-Acp127-Message-Identifier contains the contents of ACP 127 format line 3, which consists of three space-separated fields: the Calling Station (DERI), Station Serial Number (SSN), and Filing Time (JFT) [ACP127].
MMHS-Acp127-Message-Identifier包含ACP 127格式第3行的内容，该行由三个空格分隔的字段组成：呼叫站（DERI）、站序列号（SSN）和归档时间（JFT）[Acp127]。
This header field is used only to support interoperability with ACP 127 systems, it should be treated as opaque by a pure MMHS system.
此标题字段仅用于支持与ACP 127系统的互操作性，纯MMHS系统应将其视为不透明。
Example: MMHS-Acp127-Message-Identifier: RPDLE 1234 0341215
示例：MMHS-Acp127-Message-Identifier:RPDLE 1234 0341215
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
Applicable protocol: mail [RFC5322]
Status: informational
Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF
Specification document(s): [RFC6477]
The MMHS-Originator-PLAD (PLAD: Plain Language Address Designator) header field, by its presence, indicates the plain language address associated with an originator for cross-referencing purposes. If this header field is absent, then the message will be considered not to have an originator PLAD cross-reference between the MMHS and ACP 127 domains.
MMHS发起者PLAD（PLAD：普通语言地址指示符）标题字段通过其存在，指示与发起者关联的普通语言地址，以便进行交叉引用。如果缺少此标头字段，则消息将被视为在MMHS和ACP 127域之间没有发起人PLAD交叉引用。
This header field is used only to support interoperability with ACP 127 systems.
此标题字段仅用于支持与ACP 127系统的互操作性。
This header field and the MMHS-Extended-Authorisation-Info header field provide a cross-reference for message identification in both ACP 127 and MMHS domains.
此标头字段和MMHS扩展授权信息标头字段为ACP 127和MMHS域中的消息标识提供了交叉引用。
Example: MMHS-Originator-PLAD: SACLANT
示例：MMHS发起人PLAD:SACLANT
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in [RFC5234]. Terms not defined here are taken from [RFC5322], [RFC5234], and [RFC2156].
以下语法规范使用了[RFC5234]中所述的增广Backus-Naur形式（ABNF）。此处未定义的术语取自[RFC5322]、[RFC5234]和[RFC2156]。
NZ-DIGIT = %x31-39
; "1".."9"
NZ-DIGIT = %x31-39
; "1".."9"
nonneg-integer = "0" / (NZ-DIGIT *DIGIT)
nonneg-integer = "0" / (NZ-DIGIT *DIGIT)
military-string = 1*69( ps-char )
military-string = 1*69( ps-char )
quoted-military-string = DQUOTE military-string DQUOTE
quoted-military-string = DQUOTE military-string DQUOTE
military-string-sequence = military-string *( [FWS] ";" [FWS] military-string )
军用字符串序列=军用字符串*（[FWS]“；”[FWS]军用字符串）
Exempted-Address = "MMHS-Exempted-Address:" [FWS] address-list [FWS] CRLF
豁免地址=“MMHS豁免地址：”[FWS]地址列表[FWS]CRLF
Extended-Authorisation-Info = "MMHS-Extended-Authorisation-Info:" [FWS] date-time CRLF
扩展授权信息=“MMHS扩展授权信息：”[FWS]日期时间CRLF
Subject-Indicator-Codes = "MMHS-Subject-Indicator-Codes:" [FWS] sic-sequence [FWS] CRLF
主题指示器代码=“MMHS主题指示器代码：”[FWS]sic序列[FWS]CRLF
sic-sequence = sic *( [FWS] ";" [FWS] sic )
; ACP 123 specifies that the maximum number of
; SICs is 8. Use of more than 8 SICs is
; permitted, but additional SICs might not
; be transferred to ACP 123 system.
sic-sequence = sic *( [FWS] ";" [FWS] sic )
; ACP 123 specifies that the maximum number of
; SICs is 8. Use of more than 8 SICs is
; permitted, but additional SICs might not
; be transferred to ACP 123 system.
sic = 3*8( ps-char )
sic = 3*8( ps-char )
Handling-Instructions = "MMHS-Handling-Instructions:" [FWS] military-string-sequence [FWS] CRLF
处理说明=“MMHS处理说明：”[FWS]军用字符串序列[FWS]CRLF
Message-Instructions = "MMHS-Message-Instructions:" [FWS] military-string-sequence [FWS] CRLF
Message Instructions=“MMHS Message Instructions:”[FWS]军用字符串序列[FWS]CRLF
Codress-Message-Indicator = "MMHS-Codress-Message-Indicator:" [FWS] nonneg-integer [FWS] CRLF
Codress Message Indicator=“MMHS Codress Message Indicator:[FWS]非负整数[FWS]CRLF
Originator-Reference = "MMHS-Originator-Reference:" [FWS] military-string [FWS] CRLF
发起人参考=“MMHS发起人参考：”[FWS]军事字符串[FWS]CRLF
PrimaryPrecedence = "MMHS-Primary-Precedence:" [FWS] precedence CRLF
PrimaryPreference=“MMHS主优先级：”[FWS]优先级CRLF
CopyPrecedence = "MMHS-Copy-Precedence:" [FWS] precedence CRLF
CopyPreference=“MMHS复制优先级：”[FWS]优先级CRLF
precedence = (nonneg-integer / std-precedence) [CFWS]
precedence = (nonneg-integer / std-precedence) [CFWS]
std-precedence = "deferred" / "routine" / "priority" /
"immediate" / "flash" / "override"
; deferred == 0
; routine == 1
; priority == 2
; immediate == 3
; flash == 4
; override == 5
std-precedence = "deferred" / "routine" / "priority" /
"immediate" / "flash" / "override"
; deferred == 0
; routine == 1
; priority == 2
; immediate == 3
; flash == 4
; override == 5
MessageType = "MMHS-Message-Type:" [FWS] message-type [CFWS] [";" [FWS] MessageTypeParam [FWS] ] CRLF
MessageType=“MMHS消息类型：”[FWS]消息类型[CFWS][”；“[FWS]消息类型参数[FWS]]CRLF
message-type = nonneg-integer / std-message-type
message-type = nonneg-integer / std-message-type
std-message-type = "exercise" / "operation" / "project" / "drill"
; exercise == 0
; operation == 1
; project == 2
; drill == 3
std-message-type = "exercise" / "operation" / "project" / "drill"
; exercise == 0
; operation == 1
; project == 2
; drill == 3
MessageTypeParam = "identifier" [FWS] "=" [FWS] quoted-military-string
MessageTypeParam=“标识符”[FWS]“=”[FWS]带引号的军事字符串
Designator = military-string
Designator = military-string
OtherRecipIndicatorPrimary = "MMHS-Other-Recipients-Indicator-To:" [FWS] Designator *([FWS] ";" [FWS] Designator) [FWS] CRLF
OtherRecipientIndicatorPrimary=“MMHS其他收件人指示符至：“[FWS]指示符*（[FWS]”；“[FWS]指示符”[FWS]CRLF
OtherRecipIndicatorCopy = "MMHS-Other-Recipients-Indicator-CC:" [FWS] Designator *([FWS] ";" [FWS] Designator) [FWS] CRLF
OtherRecipientIndicatorCopy=“MMHS其他收件人指示符抄送：“[FWS]指示符*（[FWS]”；“[FWS]指示符”[FWS]CRLF
Acp127MessageIdentifier = "MMHS-Acp127-Message-Identifier:" [FWS] military-string [FWS] CRLF
Acp127MessageIdentifier=“MMHS-Acp127-Message-Identifier:”[FWS]军事字符串[FWS]CRLF
OriginatorPLAD = "MMHS-Originator-PLAD:" [FWS] military-string [FWS] CRLF
发起人PLAD=“MMHS发起人PLAD:“[FWS]军事字符串[FWS]CRLF”
address-list = <Defined in RFC 5322>
address-list = <Defined in RFC 5322>
The service specified in this document is a subset of the functionality set out in Annex A1 "Military Heading Extensions" of [ACP123]. The majority of this functionality is supported in this document. A few capabilities have been left out, which would have significantly increased the complexity of this specification.
本文件中规定的服务是[ACP123]附录A1“军事标题扩展”中规定的功能的子集。本文档支持此功能的大部分。遗漏了一些功能，这将大大增加本规范的复杂性。
For Distribution Codes (A.1.3) only Subject Indicator Codes are supported and Distribution Extensions are omitted. Authors of this document believe that distribution extensions are not widely used.
对于分发代码（A.1.3），仅支持主题指示符代码，并且省略分发扩展。本文作者认为，分发扩展没有得到广泛应用。
Address List Indication (A.1.11) is not supported. This complex extension is deprecated in [ACP123].
不支持地址列表指示（A.1.11）。[ACP123]中不推荐使用此复杂扩展。
Pilot Forwarding Information (A.1.13) is not supported.
不支持导频转发信息（A.1.13）。
Security Information Labels (A.1.16) is not supported. This extension is deprecated in favor of Annex A of [ACP123], which uses Enhanced Security Services (ESS) Labels [RFC2634] that can be supported in a directly compatible manner in S/MIME [RFC5751].
不支持安全信息标签（A.1.16）。为了支持[ACP123]的附录A，不推荐使用此扩展，因为附录A使用了增强型安全服务（ESS）标签[RFC2634]，该标签可以在S/MIME[RFC5751]中以直接兼容的方式支持。
ACP 127 Notification Requests (see Annex A.2.1 of [ACP123) and Responses (see Annex A.3.1 of [ACP123]) are not supported. These extensions are used to request and return notifications from ACP 127 gateways, and are not relevant to an SMTP gateway.
不支持ACP 127通知请求（见[ACP123]的附录A.2.1）和响应（见[ACP123]的附录A.3.1）。这些扩展用于从ACP 127网关请求和返回通知，与SMTP网关无关。
The header fields defined in this specification are designed to be mapped with ACP 123 Annex A1 heading extensions as part of a MIXER mapping according to [RFC2156]. The syntax of these headings is defined such that mapping is mechanical. OR Names SHOULD be mapped with Internet Email addresses according to [RFC2156].
根据[RFC2156]，本规范中定义的标题字段设计为与ACP 123附录A1标题扩展进行映射，作为混音器映射的一部分。这些标题的语法定义使得映射是机械的。或者名称应根据[RFC2156]与互联网电子邮件地址进行映射。
This section summarizes how a gateway between [ACP123] and [RFC5322] conformant to this specification operates.
本节总结了[ACP123]和[RFC5322]之间符合本规范的网关的运行方式。
If an incoming X.400 message is encoded as P772, [RFC5322] header fields MUST be generated according to this specification for all ACP 123 heading extensions where an equivalent header is defined in this specification. For the three heading extensions where no mapping is defined, the heading extension MAY be discarded or mapped in a
如果传入的X.400消息编码为P772，则必须根据本规范为所有ACP 123标题扩展生成[RFC5322]标题字段，其中本规范中定义了等效标题。对于未定义映射的三个标题扩展，标题扩展可能会被丢弃或映射到
proprietary manner. If a Distribution Extension is encoded, this MAY be discarded or represented as a comment (<CFWS>). The whole message MAY be signed according to [RFC5652]. These rules also apply to heading extensions in forwarded messages. MM-Message MUST be treated as a forwarded message for the purposes of MIXER mapping. If an ACP 127 Notification Request is present, this MAY be discarded or represented as a comment (<CFWS>).
专有方式。如果对分发扩展进行了编码，则可能会将其丢弃或表示为注释（<CFWS>）。可根据[RFC5652]对整个消息进行签名。这些规则也适用于转发消息中的标题扩展名。出于混音器映射的目的，MM消息必须被视为转发消息。如果存在ACP 127通知请求，则可能会丢弃该请求或将其表示为注释（<CFWS>）。
Incoming X.400 notifications are encoded according to [RFC2156]. If an ACP 127 Notification Response is present, this MAY be discarded or mapped in a proprietary manner.
传入的X.400通知根据[RFC2156]进行编码。如果存在ACP 127通知响应，则可以以专有方式丢弃或映射该响应。
If an incoming SMTP message contains any of the header fields defined in this specification, the outgoing X.400 message MUST be encoded as P772. The outgoing message MAY be encoded as P772 for other reasons, for instance, policy or characteristics such as the message containing a military body part. The X.400 message might be signed according to ACP 123 Annex B [ACP123] or STANAG 4406 Annex G [STANAG-4406]. message/rfc822 body parts included in the message SHOULD be mapped to MM-Message and the heading mapping rules applied.
如果传入SMTP邮件包含本规范中定义的任何标头字段，则传出X.400邮件必须编码为P772。出于其他原因，例如，政策或特征，例如包含军事身体部分的消息，传出消息可被编码为P772。X.400报文可根据ACP 123附录B[ACP123]或STANAG 4406附录G[STANAG-4406]进行签名。消息中包含的消息/rfc822正文部分应映射到MM消息，并应用标题映射规则。
Generated P772 messages SHOULD follow the following rules, generating heading extensions if needed.
生成的P772消息应遵循以下规则，必要时生成标题扩展。
a. Extended Authorization is required. If the MMHS-Extended-Authorization-Info header field is absent, then the default value is taken from the Date header field.
a. 需要扩展授权。如果MMHS扩展授权信息标题字段不存在，则默认值取自日期标题字段。
b. Primary Precedence is required if the To header field is present. If the MMHS-Primary-Precedence header field is absent, the message need not be considered a Military Message and can be handled according to a local policy.
b. 如果存在“收件人标头”字段，则需要主优先级。如果MMHS主优先级标头字段不存在，则该消息无需视为军事消息，可以根据本地策略进行处理。
c. Copy Precedence is required if the Cc header field is present and there is an MMHS-Copy-Precedence header field that is different from the MMHS-Primary-Precedence header field.
c. 如果存在Cc标头字段，并且存在与MMHS主优先级标头字段不同的MMHS复制优先级标头字段，则需要复制优先级。
d. For Message-ID fields, ACP 123 applies additional constraints over X.400, leading to the following rules in addition to [RFC2156], which SHOULD be followed by a gateway following this specification.
d. 对于消息ID字段，ACP 123在X.400上应用了额外的约束，除了[RFC2156]之外，还产生了以下规则，这些规则应该由遵循本规范的网关遵循。
1. The local identifier MUST be at least 15 characters long. If the [RFC2156] generated value is shorter than this, then it is padded with spaces to 15 characters. This value will correctly reverse map.
1. 本地标识符的长度必须至少为15个字符。如果生成的[RFC2156]值短于此值，则用空格填充至15个字符。此值将正确反转贴图。
2. The OR Address part is required, and it is not usually generated by an [RFC2156] mapping. It is mandatory in ACP 123. The gateway SHOULD generate an OR Address in a manner that can be reverse mapped. It MAY use the OR Address to encode long message ids that cannot be encoded in the local identifier.
2. OR地址部分是必需的，通常不是由[RFC2156]映射生成的。在ACP123中是强制性的。网关应以可反向映射的方式生成或地址。它可以使用或地址对无法在本地标识符中编码的长消息ID进行编码。
The header fields defined in this specification include fields to carry Elements of Service specific to ACP 127 [ACP127]. This specification does not define a mapping of these header fields to ACP 127. In the absence of this mapping, it is recommended that these headings be mapped to ACP 123 and hence into ACP 127 following the Annex D (Gateway Translation) of [STANAG-4406].
本规范中定义的标题字段包括用于承载特定于ACP 127[ACP127]的服务元素的字段。本规范未定义这些头字段到ACP 127的映射。在没有这种映射的情况下，建议按照[STANAG-4406]的附录D（网关翻译）将这些标题映射到ACP 123，从而映射到ACP 127。
IANA has added the list of header fields specified in subsections of Section 3 to the "Permanent Message Header Field Names" registry defined by "Registration Procedures for Message Header Fields" [RFC3864].
IANA已将第3节小节中规定的标题字段列表添加到“消息标题字段注册程序”[RFC3864]定义的“永久消息标题字段名称”注册表中。
Annex B of [ACP123] describes how MMHS messages can be protected in an X.400 environment. Similar protection can be provided using S/MIME [RFC5751] and/or DKIM [RFC6376]. In particular, DKIM can be used to protect against alteration, deletion, or insertion of header fields specified in this document that can affect disposition and quality of service applied to processing of the protected Internet message by receiving gateways/endpoints that support this specification. (Note that most of the header fields defined in this document might affect processing of the message by the receiving gateway/end system, MMHS-Subject-Indicator-Codes and MMHS-Primary-Precedence/MMHS-Copy-Precedence header fields being the most important examples. For example, alteration of the MMHS-Primary-Precedence header field value might affect processing speed of the message by the recipient Message Transfer Agent (MTA).)
[ACP123]的附录B描述了如何在X.400环境中保护MMHS消息。可以使用S/MIME[RFC5751]和/或DKIM[RFC6376]提供类似的保护。特别是，DKIM可用于防止本文档中指定的头字段的更改、删除或插入，这些头字段可能会通过接收支持本规范的网关/端点而影响应用于受保护Internet消息处理的处置和服务质量。（请注意，本文档中定义的大多数标头字段可能会影响接收网关/终端系统对消息的处理，MMHS主题指示符代码和MMHS主优先级/MMHS副本优先级标头字段是最重要的示例。例如，更改MMHS主优先级标头字段值可能会收件人邮件传输代理（MTA）对邮件的ct处理速度。）
When the original message header fields are digitally signed, the act of gatewaying messages with such header fields to/from an Internet environment from/to an ACP 123 environment breaks digital signatures. The gateway can sign the translated message itself (e.g., with DKIM), but a message recipient would be unable to verify that the message was generated by the original sender.
当对原始消息头字段进行数字签名时，将带有此类头字段的消息从互联网环境从ACP 123环境传送到互联网环境的行为会破坏数字签名。网关可以对翻译后的邮件本身进行签名（例如，使用DKIM），但邮件收件人将无法验证邮件是否由原始发件人生成。
[ACP123] CCEB, "Common Messaging Strategy and Procedures", ACP 123 (B), May 2009, http://jcs.dtic.mil/j6/cceb/acps/acp123/.
[ACP123]CCEB，“通用信息策略和程序”，ACP 123（B），2009年5月，http://jcs.dtic.mil/j6/cceb/acps/acp123/.
[ACP127] CCEB, "Communication Instructions - Tape Relay Procedures", ACP 127 (G), November 1988, http://jcs.dtic.mil/j6/cceb/acps/acp127/.
[ACP127]CCEB，“通信说明-磁带中继程序”，ACP 127（G），1988年11月，http://jcs.dtic.mil/j6/cceb/acps/acp127/.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[RFC2156]Kille，S.，“混音器（Mime互联网X.400增强中继）：X.400和RFC 822/Mime之间的映射”，RFC 2156，1998年1月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，RFC 63762011年9月。
[ACP121] CCEB, "Comms Instructions - General", ACP 121 (I), October 2010, http://jcs.dtic.mil/j6/cceb/acps/acp121/.
[ACP121]CCEB，“通信说明-概述”，ACP 121（I），2010年10月，http://jcs.dtic.mil/j6/cceb/acps/acp121/.
[ACP131] CCEB, "Comms Instructions - Operating Signals", ACP 131 (F), April 2009, http://jcs.dtic.mil/j6/cceb/acps/acp131/.
[ACP131]CCEB，“通信指令-操作信号”，ACP 131（F），2009年4月，http://jcs.dtic.mil/j6/cceb/acps/acp131/.
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[RFC2634]Hoffman，P.，Ed.“S/MIME的增强安全服务”，RFC 2634，1999年6月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[STANAG-4406] NATO, "STANAG 4406 Edition 2: Military Message Handling System", STANAG 4406, March 2005.
[STANAG-4406]北约，“STANAG 4406第2版：军事信息处理系统”，STANAG 4406，2005年3月。
This document copies a lot of text from the "Mapping between X.400 P772 and RFC-822" by Julian Onions and Graeme Lunt and STANAG 4406 (2nd Edition). So the authors of this document would like to acknowledge contributions made by the authors of these documents.
本文件复制了Julian Ononis和Graeme Lunt以及STANAG 4406（第二版）的“X.400 P772和RFC-822之间的映射”中的大量文本。因此，本文件的作者要感谢这些文件的作者所做的贡献。
Many thanks for reviews and text provided by Steve Kille, Alan Ross, David Wilson, James Usmar, Kathy Nuckles, Andy Trayler, Ken Carlberg, Chris Bonatti, Oeyvind Jonsson, Mykyta Yevstifeyev, Sean Turner, Stephen Farrell, Adrian Farrel, and Peter Saint-Andre.
非常感谢Steve Kille、Alan Ross、David Wilson、James Usmar、Kathy Nuckles、Andy Trayler、Ken Carlberg、Chris Bonatti、Oeyvind Jonsson、Mykyta Yevstifeyev、Sean Turner、Stephen Farrell、Adrian Farrel和Peter Saint Andre提供的评论和文本。
Authors' Addresses
作者地址
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex, TW12 2BX UK
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton，Middlesex，TW12 2BX英国
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com
Graeme Lunt SMHS Ltd Bescar Moss Farm Bescar Lane Ormskirk L40 9QN UK
Graeme Lunt SMHS有限公司Bescar Moss Farm Bescar Lane Ormskirk L40 9QN英国
EMail: graeme.lunt@smhs.co.uk
EMail: graeme.lunt@smhs.co.uk