Network Working Group R. Gellens
Request for Comments: 4356 Qualcomm
Category: Standards Track January 2006
Network Working Group R. Gellens
Request for Comments: 4356 Qualcomm
Category: Standards Track January 2006
Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail
彩信服务（MMS）与Internet邮件之间的映射
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols that are similar to, but differ in key ways from, those used in Internet mail.
蜂窝电话行业定义了一种称为彩信服务（MMS）的服务。此服务使用的格式和协议与Internet邮件中使用的格式和协议相似，但在关键方面有所不同。
One important difference between MMS and Internet Mail is that MMS uses headers that start with "X-Mms-" to carry a variety of user agent- and server-related information elements.
MMS和Internet Mail之间的一个重要区别是，MMS使用以“X-MMS-”开头的标题来携带各种与用户代理和服务器相关的信息元素。
This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in SMTP and Internet message headers.
本文档指定了如何在这两个服务之间交换邮件，包括将MMS X-MMS-*邮件头中使用的信息元素以及传递和处置报告映射到SMTP和Internet邮件头中使用的信息元素。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Scope ......................................................2
1.2. Conventions Used in This Document ..........................3
1.3. Definitions ................................................3
1.4. Abbreviations ..............................................4
1.5. Assumptions ................................................4
2. Mapping Between MMS and Internet Mail ...........................4
2.1. Mapping Specification ......................................5
2.1.1. MMS to Internet Mail ................................5
2.1.2. Internet Mail to MMS ................................5
2.1.3. MMS Information Element Mappings ....................6
2.1.4. Report Generation and Conversion ...................20
2.1.5. Message Delivery ...................................27
3. Security Considerations ........................................27
4. IANA Considerations ............................................27
5. Acknowledgements ...............................................27
6. Normative References ...........................................27
7. Informative References .........................................29
1. Introduction ....................................................2
1.1. Scope ......................................................2
1.2. Conventions Used in This Document ..........................3
1.3. Definitions ................................................3
1.4. Abbreviations ..............................................4
1.5. Assumptions ................................................4
2. Mapping Between MMS and Internet Mail ...........................4
2.1. Mapping Specification ......................................5
2.1.1. MMS to Internet Mail ................................5
2.1.2. Internet Mail to MMS ................................5
2.1.3. MMS Information Element Mappings ....................6
2.1.4. Report Generation and Conversion ...................20
2.1.5. Message Delivery ...................................27
3. Security Considerations ........................................27
4. IANA Considerations ............................................27
5. Acknowledgements ...............................................27
6. Normative References ...........................................27
7. Informative References .........................................29
This document describes how to exchange messages between Multimedia Messaging Service (MMS) systems (as defined by [3GPP][3GPP2][OMA]) and Internet mail systems (that is, [SMTP] and [Msg-Fmt]). This includes the translation of message formats, message header elements, message delivery reports [DSN-Msg], and message disposition reports [MDN].
本文档描述了如何在彩信服务（MMS）系统（由[3GPP][3GPP2][OMA]定义）和Internet邮件系统（即[SMTP]和[Msg Fmt]）之间交换消息。这包括消息格式、消息头元素、消息传递报告[DSN Msg]和消息处置报告[MDN]的翻译。
The MMS architecture [Stage_2] and specifications [Stage_3] refer to interfaces as reference points named MMx. For example, MM1 is the client-server interface, MM4 is the server-server interface, and MM3 is an interface to "external" or non-MMS systems. The specification in this document can be used for message exchange between any system that uses Internet message formats and protocols and an MMS system; from the perspective of the MMS system, reference point MM3 is used.
MMS体系结构[Stage_2]和规范[Stage_3]将接口称为名为MMx的参考点。例如，MM1是客户端-服务器接口，MM4是服务器-服务器接口，MM3是“外部”或非MMS系统的接口。本文件中的规范可用于使用互联网消息格式和协议的任何系统与MMS系统之间的消息交换；从MMS系统的角度来看，使用参考点MM3。
This document includes support for voice messages specified by the Voice Profile for Internet Mail [VPIM]. The VPIM specification allows voice messages to be exchanged between voice mail systems using the Internet mail format [Msg-Fmt] and transported via [SMTP]. Thus, the MMS MM3 interface supports the ability to exchange voice messages between an MMS system and a voice mail system. Note that such use is distinct from voice media being part of a user-composed multimedia message.
本文档包括对Internet邮件语音配置文件[VPIM]指定的语音消息的支持。VPIM规范允许使用互联网邮件格式[Msg Fmt]在语音邮件系统之间交换语音消息，并通过[SMTP]传输。因此，MMS MM3接口支持在MMS系统和语音邮件系统之间交换语音消息。请注意，这种使用不同于作为用户编写的彩信的一部分的语音媒体。
Note that MM3 can also be used for interworking with "external" (non-MMS) systems other than Internet mail, such as Short Messaging Service (SMS) and access to external mail stores (such as a voice mail system). This specification does not address these other uses or sub-interfaces of MM3; it is only concerned with Internet mail interworking and specifically exchange of messages.
请注意，MM3还可用于与Internet邮件以外的“外部”（非MMS）系统（如短消息服务（SMS））互通，以及访问外部邮件存储（如语音邮件系统）。本规范不涉及MM3的其他用途或子接口；它只涉及互联网邮件互通，特别是信息交换。
All MM3 Stage 2 [Stage_2] functions are supported except for reply charging and sender address hiding.
除回复计费和发送方地址隐藏外，支持所有MM3第2阶段[Stage_2]功能。
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key Words for Use in RFCs to Indicate Requirement Levels" [KEYWORDS].
本文件中的关键词“必需”、“必须”、“不得”、“应该”、“不应该”和“可能”应按照“RFC中用于指示需求水平的关键词”[关键词]中的描述进行解释。
--------------------|----------------------------------------------
Body |The portion of an [SMTP] message's Content
|following the Header (that is, following the
|first blank line). The Body may contain
|structured parts and sub-parts, each of which
|may have its own Header and Body. The Body
|contains information intended for the message
|recipient (human or software).
--------------------|----------------------------------------------
Content |The portion of an SMTP message that is
|delivered. The Content consists of a Header
|and a Body.
--------------------|----------------------------------------------
Disposition Report |Feedback information to an originator User
|Agent by a recipient User Agent about
Message Disposition |handling of an original message. This may
Notification |include notification that the message was or
|was not read, was deleted unread, etc.
--------------------|----------------------------------------------
Envelope |The portion of an SMTP message not included in
|the Content, that is, not in the Header or in
|the Body. While some of it may be copied into
|the Content on delivery, envelope information
|exists only while the message is in transit,
|and contains information used by SMTP agents
|(Mail Transfer Agents (MTAs)).
--------------------|----------------------------------------------
Gateway |See [SMTP], Section 2.3.8.
--------------------|----------------------------------------------
--------------------|----------------------------------------------
Body |The portion of an [SMTP] message's Content
|following the Header (that is, following the
|first blank line). The Body may contain
|structured parts and sub-parts, each of which
|may have its own Header and Body. The Body
|contains information intended for the message
|recipient (human or software).
--------------------|----------------------------------------------
Content |The portion of an SMTP message that is
|delivered. The Content consists of a Header
|and a Body.
--------------------|----------------------------------------------
Disposition Report |Feedback information to an originator User
|Agent by a recipient User Agent about
Message Disposition |handling of an original message. This may
Notification |include notification that the message was or
|was not read, was deleted unread, etc.
--------------------|----------------------------------------------
Envelope |The portion of an SMTP message not included in
|the Content, that is, not in the Header or in
|the Body. While some of it may be copied into
|the Content on delivery, envelope information
|exists only while the message is in transit,
|and contains information used by SMTP agents
|(Mail Transfer Agents (MTAs)).
--------------------|----------------------------------------------
Gateway |See [SMTP], Section 2.3.8.
--------------------|----------------------------------------------
--------------------|----------------------------------------------
Header |The first part of an SMTP message's Content.
|The Header is separated from the Body by a
|blank line. The Header consists of Fields
|(such as "To:"), also known as Header Fields
|or Headers. The message Header contains
|information used by User Agents.
--------------------|----------------------------------------------
Relay/Server |An MMS server. See [Stage_2]. For purposes
|of this document, an MMS Relay/Server acts as
|a gateway when it receives or sends messages
|via Internet mail.
--------------------|----------------------------------------------
User Agent |An MMS or email user agent.
--------------------|----------------------------------------------
--------------------|----------------------------------------------
Header |The first part of an SMTP message's Content.
|The Header is separated from the Body by a
|blank line. The Header consists of Fields
|(such as "To:"), also known as Header Fields
|or Headers. The message Header contains
|information used by User Agents.
--------------------|----------------------------------------------
Relay/Server |An MMS server. See [Stage_2]. For purposes
|of this document, an MMS Relay/Server acts as
|a gateway when it receives or sends messages
|via Internet mail.
--------------------|----------------------------------------------
User Agent |An MMS or email user agent.
--------------------|----------------------------------------------
--------|----------------------------------------------------------
MSA |Message Submission Agent. A server that accepts messages
|from User Agents and processes them, either delivering
|them locally or relaying to an MTA. See [Submission].
--------|----------------------------------------------------------
MTA |Mail Transfer Agent. A server that implements [SMTP].
--------|----------------------------------------------------------
--------|----------------------------------------------------------
MSA |Message Submission Agent. A server that accepts messages
|from User Agents and processes them, either delivering
|them locally or relaying to an MTA. See [Submission].
--------|----------------------------------------------------------
MTA |Mail Transfer Agent. A server that implements [SMTP].
--------|----------------------------------------------------------
It is assumed that the reader is already familiar with the contents of the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1 (requirements) [Stage_1] and Stage 2 (architecture and abstract messages) [Stage_2], and 3GPP/3GPP2 Stage 3 (protocols) [Stage_3] documents. It is also assumed that the reader is familiar with Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt].
假设读者已经熟悉3GPP2 MMS规范概述[概述]、MMS阶段1（需求）[阶段1]和阶段2（架构和抽象消息）[阶段2]以及3GPP/3GPP2阶段3（协议）[阶段3]文档的内容。还假设读者熟悉互联网邮件，尤其是RFC 2821[SMTP]和RFC 2822[Msg Fmt]。
This section defines the interworking between MMS Relay/Servers and External Servers using native [SMTP]. That is, information elements are exchanged using standard Internet message [Msg-Fmt] header fields, such as those in [Hdrs], and standard [SMTP] elements.
本节定义了MMS中继/服务器与使用本机[SMTP]的外部服务器之间的互通。也就是说，使用标准Internet消息[Msg Fmt]头字段（如[Hdrs]中的头字段）和标准[SMTP]元素交换信息元素。
SMTP and Internet mail extensions are used for features such as delivery reports, message expiration, and discovery of server support for optional features.
SMTP和Internet邮件扩展用于传递报告、邮件过期和发现可选功能的服务器支持等功能。
When sending a message to an Internet mail system, the MMS Relay/Server MUST convert the MM if required, and MUST comply with the requirements of [SMTP].
向Internet邮件系统发送邮件时，MMS中继/服务器必须在需要时转换MM，并且必须符合[SMTP]的要求。
The MMS Relay/Server SHOULD use the information elements associated with the MM to define the control information (Internet message header fields and SMTP envelope values) needed for the transfer protocol.
MMS中继/服务器应使用与MM相关的信息元素来定义传输协议所需的控制信息（Internet邮件头字段和SMTP信封值）。
Section 2.1.3 lists the mappings between X-Mms-* headers and Internet message header fields and SMTP values.
第2.1.3节列出了X-Mms-*标头与Internet邮件标头字段和SMTP值之间的映射。
Delivery and read report MMs SHOULD be converted to standard Internet message report format (multipart/report). In addition to converting Internet Message reports, the MMS Relay/Server MUST generate delivery and read report MMs for received messages as appropriate. See Section 2.1.4 for more information.
传递和阅读报告彩信应转换为标准互联网消息报告格式（多部分/报告）。除了转换Internet消息报告外，彩信中继/服务器还必须根据需要为接收到的消息生成传递和读取报告彩信。详见第2.1.4节。
When receiving a message from an Internet mail system, the MMS Relay/Server converts incoming messages to the MM format used within the receiving system.
从Internet邮件系统接收消息时，MMS中继/服务器将传入消息转换为接收系统中使用的MM格式。
The MMS Relay/Server converts control information received from the Internet mail server into appropriate information elements of an MM.
MMS中继/服务器将从Internet邮件服务器接收的控制信息转换为MM的适当信息元素。
Section 2.1.3 lists the mappings between X-Mms-* headers and Internet message header fields and SMTP values.
第2.1.3节列出了X-Mms-*标头与Internet邮件标头字段和SMTP值之间的映射。
Standard Internet message report format (multipart/report) messages MAY be converted to delivery or read report MMs, as appropriate. In addition to converting report MMs, implementations conforming to this document MUST generate standard Internet message delivery and disposition reports for received Internet messages as appropriate. See Section 2.1.4 for more information.
标准Internet消息报告格式（多部分/报告）消息可酌情转换为传送或读取报告彩信。除转换报告MMs外，符合本文件要求的实施方案还必须酌情为收到的互联网消息生成标准互联网消息交付和处置报告。详见第2.1.4节。
The mappings between MMS elements and SMTP/Internet message elements ([SMTP] parameters, [Msg-Fmt] headers, and [DSN-Msg] fields) are summarized in table 1 below, and detailed in subsequent sections. The "MMS Headers" are from [OMA-MMS]. Note that only information elements that need to be mapped are listed. [Msg-Fmt] headers not listed here SHOULD be passed unaltered.
MMS元素和SMTP/Internet消息元素之间的映射（[SMTP]参数、[Msg Fmt]头和[DSN Msg]字段）在下表1中进行了总结，并在后续章节中进行了详细说明。“彩信头”来自[OMA-MMS]。请注意，只列出了需要映射的信息元素。此处未列出的[Msg Fmt]标头应原封不动地传递。
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
3GPP MMS Version |N/A |N/A |X-Mms-3GPP-MMS
| | | -Version:
_________________|_________________|________________|______________
Message Type |N/A |N/A |X-Mms-Message-
(of PDU) | | | Type:
_________________|_________________|________________|______________
Transaction ID |N/A |N/A |X-Mms-Transact
| | | ion-Id:
_________________|_________________|________________|______________
Message ID |N/A |Message-ID: |Message-ID:
_________________|_________________|________________|______________
Recipient |RCPT TO |To:, Cc:, or |To:, Cc:, Bcc:
address(es) |address(es) |omitted (Bcc) |
_________________|_________________|________________|______________
Sender's address |MAIL FROM |From: |From:
|address if | |
|user-originated; | |
|MUST set MAIL | |
|FROM to null | |
|("<>") for all | |
|automatically- | |
|generated MMs | |
_________________|_________________|________________|______________
Content type |N/A |Content-Type: |Content-type:
| | |
| |For voice mes- |
| |sages compliant |
| |to [VPIM], see |
| |Note 2 |
_________________|_________________|________________|______________
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
3GPP MMS Version |N/A |N/A |X-Mms-3GPP-MMS
| | | -Version:
_________________|_________________|________________|______________
Message Type |N/A |N/A |X-Mms-Message-
(of PDU) | | | Type:
_________________|_________________|________________|______________
Transaction ID |N/A |N/A |X-Mms-Transact
| | | ion-Id:
_________________|_________________|________________|______________
Message ID |N/A |Message-ID: |Message-ID:
_________________|_________________|________________|______________
Recipient |RCPT TO |To:, Cc:, or |To:, Cc:, Bcc:
address(es) |address(es) |omitted (Bcc) |
_________________|_________________|________________|______________
Sender's address |MAIL FROM |From: |From:
|address if | |
|user-originated; | |
|MUST set MAIL | |
|FROM to null | |
|("<>") for all | |
|automatically- | |
|generated MMs | |
_________________|_________________|________________|______________
Content type |N/A |Content-Type: |Content-type:
| | |
| |For voice mes- |
| |sages compliant |
| |to [VPIM], see |
| |Note 2 |
_________________|_________________|________________|______________
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
Message class |Class=auto: |MAY set 'Prece |X-Mms-Message-
|MUST set MAIL | dence: bulk' | Class:
|FROM to null |on class=auto |
|("<>"). | |
_________________|_________________|________________|______________
Date and time |N/A |Date: |Date:
of submission | | |
_________________|_________________|________________|______________
Time of expiry |DELIVER-BY |N/A |X-Mms-Expiry:
|[Deliver-By] | |
_________________|_________________|________________|______________
Earliest deliv- |(only for submis-|N/A |X-Mms-Delivery
ery time |sion; not relay) | | -Time:
_________________|_________________|________________|______________
Delivery report |DSN [DSN-SMTP] |N/A |X-Mms-Delivery
request |SHOULD also | | -Report:
|specify recip- | |
|ient address as | |
|ORCPT; SHOULD | |
|also specify | |
|ENVID | |
_________________|_________________|________________|______________
Importance (a/k/a|N/A |Importance: |X-Mms-
"priority") | | | Priority:
| | |
| | |
_________________|_________________|________________|______________
Sender visib- |(not currently |(not currently |X-Mms-Sender-
ility |supported) |supported) | Visibility:
_________________|_________________|________________|______________
Read reply |N/A |Disposition- |X-Mms-Read-
request | | Notification | Reply:
| | -To: [MDN] |
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging:
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging-
deadline | | | Deadline:
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging-
limitation | | | Size:
_________________|_________________|________________|______________
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
Message class |Class=auto: |MAY set 'Prece |X-Mms-Message-
|MUST set MAIL | dence: bulk' | Class:
|FROM to null |on class=auto |
|("<>"). | |
_________________|_________________|________________|______________
Date and time |N/A |Date: |Date:
of submission | | |
_________________|_________________|________________|______________
Time of expiry |DELIVER-BY |N/A |X-Mms-Expiry:
|[Deliver-By] | |
_________________|_________________|________________|______________
Earliest deliv- |(only for submis-|N/A |X-Mms-Delivery
ery time |sion; not relay) | | -Time:
_________________|_________________|________________|______________
Delivery report |DSN [DSN-SMTP] |N/A |X-Mms-Delivery
request |SHOULD also | | -Report:
|specify recip- | |
|ient address as | |
|ORCPT; SHOULD | |
|also specify | |
|ENVID | |
_________________|_________________|________________|______________
Importance (a/k/a|N/A |Importance: |X-Mms-
"priority") | | | Priority:
| | |
| | |
_________________|_________________|________________|______________
Sender visib- |(not currently |(not currently |X-Mms-Sender-
ility |supported) |supported) | Visibility:
_________________|_________________|________________|______________
Read reply |N/A |Disposition- |X-Mms-Read-
request | | Notification | Reply:
| | -To: [MDN] |
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging:
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging-
deadline | | | Deadline:
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging-
limitation | | | Size:
_________________|_________________|________________|______________
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
Reply charging |(not currently |(not currently |X-Mms-Reply-
usage request |supported) |supported) | Charging-
| | | Id:
_________________|_________________|________________|______________
Reply charging |(not currently |(not currently |X-Mms-Reply-
usage reference |supported) |supported) | Charging:
_________________|_________________|________________|______________
Subject |N/A |Subject: |Subject:
_________________|_________________|________________|______________
Previously-sent |N/A |Resent-From: |X-Mms-Previous
by | | | ly-Sent-By:
_________________|_________________|________________|______________
Previously-sent |N/A |Resent-Date: |X-Mms-
date | | | Previously-
| | | Sent-Date-
| | | and-Time:
_________________|_________________|________________|______________
Hop/host trace |N/A |Received: |(Not sup-
| | |ported)
_________________|_________________|________________|______________
Sensitivity |N/A |Sensitivity: see|N/A
| |Note 1 |
_________________|_________________|________________|______________
Content |N/A |<message body> |<message body>
=================|=================|================|==============
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
Reply charging |(not currently |(not currently |X-Mms-Reply-
usage request |supported) |supported) | Charging-
| | | Id:
_________________|_________________|________________|______________
Reply charging |(not currently |(not currently |X-Mms-Reply-
usage reference |supported) |supported) | Charging:
_________________|_________________|________________|______________
Subject |N/A |Subject: |Subject:
_________________|_________________|________________|______________
Previously-sent |N/A |Resent-From: |X-Mms-Previous
by | | | ly-Sent-By:
_________________|_________________|________________|______________
Previously-sent |N/A |Resent-Date: |X-Mms-
date | | | Previously-
| | | Sent-Date-
| | | and-Time:
_________________|_________________|________________|______________
Hop/host trace |N/A |Received: |(Not sup-
| | |ported)
_________________|_________________|________________|______________
Sensitivity |N/A |Sensitivity: see|N/A
| |Note 1 |
_________________|_________________|________________|______________
Content |N/A |<message body> |<message body>
=================|=================|================|==============
Note 1: The [VPIM] 'Sensitivity' header element indicates the privacy requested by the message originator (values are "personal" or "private"); per [VPIM], a message recipient MUST NOT forward a message with a 'Sensitivity' header. Since sensitivity is not an MMS feature, any messages that contain a 'Sensitivity:' header SHOULD NOT be sent to an MMS system.
注1:[VPIM]“敏感度”标题元素表示消息发起人请求的隐私（值为“个人”或“私人”）；根据[VPIM]，邮件收件人不得转发带有“敏感度”标题的邮件。由于敏感度不是彩信功能，因此任何包含“敏感度：”标题的邮件都不应发送到彩信系统。
Note 2: [VPIM] specifies how conforming messages are identified.
注2:[VPIM]指定如何识别符合性消息。
3GPP MMS Version
3GPP彩信版本
The 'X-Mms-3GPP-MMS-Version:' header, if present, SHOULD be removed.
如果存在“X-Mms-3GPP-Mms-Version:”标题，则应将其删除。
Message Type (of PDU)
（PDU的）消息类型
The 'X-Mms-Message-Type:' header, if present, SHOULD be removed.
“X-Mms-Message-Type:”标题（如果存在）应删除。
Transaction ID
事务ID
The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed.
如果存在“X-Mms-Transaction-Id:”标头，则应将其删除。
Message ID
消息ID
The 'Message-Id:' header MUST be retained. If not present, it MUST be created, with a unique value, per [Msg-Fmt].
必须保留“消息Id:”标题。如果不存在，则必须按照[Msg Fmt]创建一个唯一值。
To facilitate the case where an MMS message traverses the Internet prior to returning to an MMS system, implementations might wish to retain the 'X-Mms-Message-Id:' header. Such systems should be aware that headers that begin with "X-" might be removed during transit through Internet MTAs.
为了便于MMS消息在返回到MMS系统之前通过互联网，实现可能希望保留“X-MMS-message-Id:”标头。此类系统应注意，在通过Internet MTA传输期间，可能会删除以“X-”开头的标题。
Recipient(s) address
收件人地址
The address of each recipient MUST be transmitted in the [SMTP] envelope as a RCPT TO value. All disclosed recipients SHOULD also appear in a 'To:' or 'Cc:' header. At least one 'To:', 'Cc:', or 'Bcc:' header MUST be present. If none are present, a 'To:' header SHOULD be created using empty group syntax whose name gives an indication to a human reader, for example, 'To: undisclosed-recipients:;'.
每个收件人的地址必须作为RCPT TO值在[SMTP]信封中传输。所有披露的收件人也应出现在“收件人”或“抄送”标题中。必须至少存在一个“收件人”、“抄送：”或“密件抄送：”标头。如果不存在“收件人：”标题，则应使用空组语法创建“收件人：”标题，空组语法的名称指示人工读取器，例如“收件人：未公开的收件人：；”。
The 'To:' header SHOULD NOT appear more than once. The 'Cc:' header SHOULD NOT appear more than once.
“收件人：”标题不应出现多次。“Cc:”标题不应出现多次。
Each recipient address MUST obey the length restrictions per [SMTP].
每个收件人地址必须遵守[SMTP]的长度限制。
Current Internet Message format requires that only 7-bit US-ASCII characters be present in headers. Non-7-bit characters in an address domain must be encoded with [IDN]. If there are any non-7-bit characters in the local part of an address, the message MUST be rejected. Non-7-bit characters elsewhere in a header MUST be encoded according to [Hdr-Enc].
当前的Internet消息格式要求标题中仅包含7位US-ASCII字符。地址域中的非7位字符必须用[IDN]编码。如果地址的本地部分有任何非7位字符，则必须拒绝该消息。头中其他位置的非7位字符必须根据[Hdr Enc]进行编码。
All recipient addresses in the [SMTP] envelope must be fully-qualified in accordance with [SMTP]. In particular, messages MUST NOT be sent to an Internet mail system with an unqualified E.164 number (i.e., a number with no domain) instead of a fully-qualified domain name.
[SMTP]信封中的所有收件人地址必须完全符合[SMTP]的要求。特别是，不得使用不合格的E.164号码（即没有域名的号码）而不是完全合格的域名将邮件发送到Internet邮件系统。
All addresses in 'To:', 'Cc:', and 'Bcc:' headers MUST be in the form of fully-qualified domains. Unqualified E.164 numbers MUST NOT be used.
“收件人：”、“抄送：”、和“密件抄送：”标头中的所有地址必须采用完全限定域的形式。不得使用不合格的E.164编号。
Sender address
送地址
The address of the message sender SHOULD appear in the 'From:' header.
邮件发件人的地址应显示在“发件人：”标题中。
The address of the message sender for all user-generated messages ('X-Mms-Message-Class: Personal') SHOULD be transmitted in the [SMTP] envelope as the MAIL FROM value.
所有用户生成的邮件的邮件发件人地址（“X-Mms-message-Class:Personal”）应作为邮件发件人值在[SMTP]信封中传输。
The return addresses in the [SMTP] envelope must be fully-qualified in accordance with [SMTP]. In particular, messages MUST NOT be sent to an Internet mail system with an E.164 number instead of a fully-qualified domain name. Note that qualified E.164 numbers, that is, those that contain an E.164 number as the local-part of an address that also includes a domain, are acceptable.
[SMTP]信封中的返回地址必须完全符合[SMTP]的要求。特别是，不得使用E.164号码而不是完全限定的域名将邮件发送到Internet邮件系统。请注意，合格的E.164编号，即包含E.164编号作为地址（也包括域）的本地部分的编号是可以接受的。
The address(es) in the 'From:' header SHOULD be in the form of fully-qualified domains. Unqualified E.164 numbers SHOULD NOT be used.
“发件人：”标头中的地址应采用完全限定域的形式。164.E不应使用不合格的数字。
Because of the risk of mail loops, it is critical that the MAIL FROM be set to null ("<>") for all automatically-generated MMs (such as 'X-Mms-Message-Class: Auto'). The MAIL FROM value MUST be set to null for all automatically-generated messages. This includes reports, "out-of-office" replies, etc.
由于存在邮件循环的风险，对于所有自动生成的彩信（如“X-MMs-Message-Class:Auto”），将来自的邮件设置为null（<>”）至关重要。对于所有自动生成的邮件，邮件发件人值必须设置为null。这包括报告、“外出”回复等。
Current Internet message format requires that only 7-bit US-ASCII characters be present in headers. Non-7-bit characters in an address domain must be encoded with [IDN]. If there are any Non-7-bit characters in the local part of an address, the message MUST be rejected. Non-7-bit characters elsewhere in a header MUST be encoded according to [Hdr-Enc]. Note that it would be possible to define an [SMTP] extension to permit transmission of unencoded 8-bit characters, but in the absence of such an extension [Hdr-Enc] MUST be used.
当前的Internet消息格式要求标题中仅包含7位US-ASCII字符。地址域中的非7位字符必须用[IDN]编码。如果地址的本地部分有任何非7位字符，则必须拒绝该消息。头中其他位置的非7位字符必须根据[Hdr Enc]进行编码。请注意，可以定义[SMTP]扩展以允许传输未编码的8位字符，但在没有此类扩展的情况下，必须使用[Hdr Enc]。
The sender address MUST obey the length restrictions of [SMTP].
发件人地址必须遵守[SMTP]的长度限制。
Content type
内容类型
The 'Content-Type:' header SHOULD be preserved.
应保留“内容类型：”标题。
Message class
消息类
The 'X-Mms-Message-Class:' header MAY be retained in order to provide information on the source of the message. A 'Precedence: bulk' header MAY be inserted for class=auto or class=advertisement. See 'Sender Address' above. (Class=personal and class=informational do not require special handling.)
可以保留“X-Mms-Message-Class:”标题，以提供有关消息来源的信息。可以为class=auto或class=advision插入“priority:bulk”标题。请参阅上面的“发件人地址”。（类=个人和类=信息不需要特殊处理。）
Time of Expiry
有效期
The 'X-Mms-Expiry:' header, if present, SHOULD be removed.
如果存在“X-Mms-Expiry:”标头，则应将其删除。
The remaining time until the message is considered expired SHOULD be transmitted in the [SMTP] envelope by using the DELIVER-BY extension with a by-mode of "R", as specified in [Deliver-By].
邮件被视为过期之前的剩余时间应使用[DELIVER by]中指定的“R”模式的DELIVER-by分机在[SMTP]信封中传输。
Note that the [SMTP] DELIVER-BY extension carries time remaining until expiration; each server decrements the value by the amount of time it has possessed the message. The 'X-Mms-Expiry:' header may contain either the absolute time at which the message is considered expired or the relative time until the message is considered expired.
请注意，[SMTP]DELIVER-BY分机包含到期前的剩余时间；每台服务器都会按其拥有消息的时间量递减该值。“X-Mms-Expiry:”标头可能包含消息被视为过期的绝对时间或消息被视为过期之前的相对时间。
Earliest delivery time
最早交货时间
The 'X-Mms-Delivery-Time:' header, if present, SHOULD be removed.
“X-Mms-Delivery-Time:”标题（如果存在）应删除。
Future delivery is a message submission (e.g., [Submission]), not message relay feature.
未来交付是一种消息提交（例如，[submission]），而不是消息中继功能。
Delivery report request
交付报告请求
Requests for delivery status notifications (DSNs) SHOULD be transmitted in the [SMTP] envelope by using the DSN extension as specified in [DSN-SMTP] to request "success" or "none" notification (depending on the value of the 'X-Mms-Delivery-Report' header). When the NOTIFY extension is used, the unaltered recipient address SHOULD be transmitted as the ORCPT value.
传递状态通知（DSN）请求应使用[DSN-SMTP]中指定的DSN扩展名在[SMTP]信封中传输，以请求“成功”或“无”通知（取决于“X-Mms-delivery-Report”标头的值）。使用NOTIFY扩展时，未更改的收件人地址应作为ORCPT值传输。
The 'X-Mms-Delivery-Report:' header, if present, SHOULD be removed.
应删除“X-Mms-Delivery-Report:”标题（如果存在）。
Importance
重要性
The message sender's importance value (also called "priority", although this can be confused with class-of-service values) SHOULD be transmitted using an 'Importance:' header.
消息发送者的重要性值（也称为“优先级”，尽管这可能与服务值的类别混淆）应使用“重要性：”标头进行传输。
Suggested mappings are shown in Table 2:
建议的映射如表2所示：
---------------------------|------------------
'X-Mms-Priority: High' |'Importance: High'
---------------------------|------------------
'X-Mms-Priority: Normal' |[omit]
---------------------------|------------------
'X-Mms-Priority: Low' |'Importance: Low'
---------------------------|------------------
---------------------------|------------------
'X-Mms-Priority: High' |'Importance: High'
---------------------------|------------------
'X-Mms-Priority: Normal' |[omit]
---------------------------|------------------
'X-Mms-Priority: Low' |'Importance: Low'
---------------------------|------------------
Normal importance messages should omit the 'Importance:' header.
正常重要性消息应省略“重要性：”标题。
The 'X-Mms-Priority:' header, if present, SHOULD be removed.
如果存在“X-Mms-Priority:”标题，则应将其删除。
Sender visibility
发送者可见性
Support for sender address hiding is not currently supported.
当前不支持对发件人地址隐藏的支持。
A message that contains an 'X-Mms-Sender-Visibility:' header with a value of 'Hide' SHOULD be rejected.
应拒绝包含“X-Mms-Sender-Visibility:”标题且值为“Hide”的邮件。
The 'X-Mms-Sender-Visibility:' header, if present, SHOULD be removed.
“X-Mms-Sender-Visibility:”标题（如果存在）应删除。
Read reply request
阅读回复请求
A request for a read reply SHOULD be transmitted using a 'Disposition-Notification-To:' header as specified in [MDN].
应使用[MDN]中指定的“Disposition Notification To:”标头传输读取回复请求。
The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed.
“X-Mms-Read-Reply:”标题（如果存在）应删除。
Reply charging
回复收费
Reply charging permission and acceptance are complex issues requiring both user agent and server support. Misapplied reply charging may cause incorrect billing. Until the security issues have been properly addressed, reply charging SHOULD NOT be honored when using this interface.
回复收费权限和接受是一个复杂的问题，需要用户代理和服务器支持。不正确的回复收费可能会导致不正确的计费。在安全问题得到正确解决之前，使用此接口时不应接受回复收费。
The 'X-Mms-Reply-Charging:', 'X-Mms-Reply-Charging-Deadline:', 'X-Mms-Reply-Charging-Size:', and 'X-Mms-Reply-Charging-Id:' headers MAY be removed. Messages containing a reply-charging usage request ('X-Mms-Reply-Charging-Id:' and 'X-Mms-Reply-Charging: accepted' or 'X-Mms-Reply-Charging: accepted (text only)' headers) SHOULD be rejected.
可以删除“X-Mms-Reply-Charging:”、“X-Mms-Reply-Charging-Deadline:”、“X-Mms-Reply-Charging-Size:”和“X-Mms-Reply-Charging-Id:”标题。应拒绝包含回复计费使用请求（“X-Mms-reply-charging-Id:”和“X-Mms-reply-charging:已接受”或“X-Mms-reply-charging:已接受（仅文本）”标题的邮件。
Subject
主题
The 'Subject:' header MUST be preserved. The current Internet message format requires that only 7-bit US-ASCII characters be present. Other characters MUST be encoded according to [Hdr-Enc]. Note that it is possible for an [SMTP] extension to be defined that would permit transmission of unencoded 8-bit characters, but in the absence of such an extension, [Hdr-Enc] MUST be used.
必须保留“主题：”标题。当前的Internet消息格式要求仅显示7位US-ASCII字符。其他字符必须根据[Hdr Enc]进行编码。请注意，可以定义允许传输未编码8位字符的[SMTP]扩展名，但在没有此类扩展名的情况下，必须使用[Hdr Enc]。
Resending
重发
A message may be resent to one or more new recipients. It may be resent more than once, each time new 'Resent-' headers are added at the top of the existing headers. Thus, if more than one series of 'Resent-' headers are present, the original series is the last; the most recent is the first.
邮件可能会重新发送给一个或多个新收件人。每次在现有头的顶部添加新的“resent-”头时，它可能会被重新发送多次。因此，如果存在多个“Resent-”头序列，则原始序列是最后一个；最近的是第一次。
Forward counter
正向计数器
An 'X-Mms-Forward-Counter:' header, if present, SHOULD be removed. The 'Resent-Count:' header is NOT RECOMMENDED. Loop control is usually done by counting 'Received' headers, which are more general than 'Resent-' headers.
如果存在“X-Mms-Forward-Counter:”标题，则应删除。不建议使用“重新发送计数：”标题。循环控制通常通过计算“已接收”头来完成，这比“重新发送”头更通用。
Previously-Sent Information
以前发送的信息
MMS lists the resending history of a message in two headers: 'X-Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date-and-Time:'. 'X-Mms-Previously-Sent-By:' contains a number followed by one or more addresses. 'X-Mms-Previously-Sent-Date-and-Time:' contains a number followed by a date-time. With both headers, the number "0" is used for the entry that corresponds to the original submission of the message, with higher values being used for each subsequent resending. The final (most recent) resending information is in the 'From:' and 'Date:' headers. There is also an 'X-Mms-Forward-Counter:' that indicates how many times the message has been resent.
彩信在两个标题中列出了邮件的重新发送历史记录：“X-MMS-Previous-Sent-By:”和“X-MMS-Previous-Sent-Date-and-Time:”X-Mms-Previous-Sent-By:'包含后跟一个或多个地址的数字。'X-Mms-Previous-Sent-Date-and-Time:'包含后跟日期时间的数字。对于这两个标头，数字“0”用于与原始邮件提交相对应的条目，较高的值用于后续每次重新发送。最后（最近）的重发信息位于“发件人：”和“日期：”标题中。还有一个“X-Mms-Forward-Counter:”指示消息被重新发送的次数。
Any 'X-Mms-Previously-Sent-By:', 'X-Mms-Previously-Sent-Date-and-Time:', and 'X-Mms-Forward-Counter:' headers, if present, SHOULD be removed. The information contained in them SHOULD be translated into [Msg-Fmt] headers as follows:
应删除任何“X-Mms-Previous-Sent-By:”、“X-Mms-Previous-Sent-Date-and-Time:”和“X-Mms-Forward-Counter:”标题（如果存在）。其中包含的信息应翻译为[Msg Fmt]标题，如下所示：
The 'X-Mms-Previously-Sent-Date-and-Time:' header whose value starts with "0" SHOULD be used to create a 'Date:' header, converting the date and time from HTTP-date [HTTP] to date-time [Msg-Fmt]. The 'X-Mms-Previously-Sent-By:' header whose value starts with "0" SHOULD be used to create a 'From:' header.
应使用值以“0”开头的“X-Mms-Previous-Sent-Date-and-Time:”标头创建“Date:”标头，将日期和时间从HTTP日期[HTTP]转换为日期时间[Msg Fmt]。值以“0”开头的“X-Mms-Previous-Sent-By:”标头应用于创建“From:”标头。
A 'To:' header SHOULD be created using list syntax with a value of "unrecoverable-recipients" and no mailboxes.
“收件人：”标头应使用值为“不可恢复收件人”且无邮箱的列表语法创建。
A 'Message-ID:' header SHOULD be created.
应创建“消息ID:”标题。
Any 'X-Mms-Previously-Sent-Date-and-Time:' headers whose value starts with "1" or a larger value are mapped to 'Resent-Date:' headers. Any 'X-Mms-Previously-Sent-By:' headers whose value starts with "1" or a larger value are mapped to 'Resent-By:' headers.
任何值以“1”或更大值开头的“X-Mms-Previous-Sent-Date-and-Time:”标头都会映射到“Recent Date:”标头。任何值以“1”或更大值开头的“X-Mms-Previous-Sent-By:”标头都会映射到“Recent By:”标头。
The 'From:', 'To:', 'Date:', and 'Message-ID:' headers are mapped to 'Resent-From:', 'Resent-To:', 'Resent-Date:', and 'Resent-Message-ID:' headers in the top-most block of 'Resent-*' headers.
“发件人：”、“收件人：”、“日期：”、和“邮件ID:”标题映射到“重新发送发件人：”、“重新发送至：”、“重新发送日期：”、和“重新发送邮件ID:”标题在“重新发送-*”标题的最顶部块中。
Example:
例子：
The MMS message:
彩信：
X-Mms-Forward-Counter: 2
X-Mms-Previously-Sent-Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT
X-Mms-Previously-Sent-By: 0, General Failure <mfail@example.mil>
X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT
X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 18:02:03 -0800
From: L. Eva Message <lem@example.org>
To: b1ff@mms.example.com
Message-ID: <99887766.112233@mail.example.org>
X-Mms-Forward-Counter: 2
X-Mms-Previously-Sent-Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT
X-Mms-Previously-Sent-By: 0, General Failure <mfail@example.mil>
X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT
X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 18:02:03 -0800
From: L. Eva Message <lem@example.org>
To: b1ff@mms.example.com
Message-ID: <99887766.112233@mail.example.org>
is mapped to an Internet mail message:
已映射到Internet邮件：
Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800
Resent-From: L. Eva Message <lem@example.org>
Resent-To: b1ff@mms.example.com
Resent-Message-ID: <99887766.112233@mail.example.org>
Resent-Date: Fri, 1 Apr 2005 08:02:03 +0000
Resent-From: Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 06:02:03 +0000
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <000.000.000@gateway.example.org>
Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800
Resent-From: L. Eva Message <lem@example.org>
Resent-To: b1ff@mms.example.com
Resent-Message-ID: <99887766.112233@mail.example.org>
Resent-Date: Fri, 1 Apr 2005 08:02:03 +0000
Resent-From: Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 06:02:03 +0000
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <000.000.000@gateway.example.org>
'Received:' Headers
'已收到：'标题
When a message is gatewayed from MMS to Internet mail, a 'Received:' header MUST be added as per [SMTP]. The "with" clause should specify "MMS".
当邮件通过网关从彩信发送到Internet邮件时，必须按照[SMTP]添加“Received:”标头。“with”子句应指明“MMS”。
A message MAY be rejected if the number of 'Received:' headers exceeds a locally-defined maximum, which MUST conform to [SMTP] Section 6.2 and SHOULD be no less than 100.
如果“Received:”标头的数量超过本地定义的最大值，则邮件可能会被拒绝，该最大值必须符合[SMTP]第6.2节的规定，并且不得小于100。
Privacy
隐私
Note that MMS systems do not currently support the 'Privacy' header field as described by [VPIM].
请注意，MMS系统目前不支持[VPIM]所述的“隐私”标题字段。
Content
所容纳之物
The message content appears in the message body. Note that Internet
message format requires that line endings be encoded as US-ASCII CR
LF octets; thus, charset encodings that do not have this property
cannot be used in text/* body parts. (They may be used in other body
parts, but only when they are suitably encoded or when binary
transmission has been negotiated, e.g., [BINARY].) In particular,
MMS allows UTF-16, whereas the Internet message format does not.
UTF-16 encoding MUST be translated to UTF-8 or another charset and
encoding that is suitable for use in Internet message
format/protocols.
The message content appears in the message body. Note that Internet
message format requires that line endings be encoded as US-ASCII CR
LF octets; thus, charset encodings that do not have this property
cannot be used in text/* body parts. (They may be used in other body
parts, but only when they are suitably encoded or when binary
transmission has been negotiated, e.g., [BINARY].) In particular,
MMS allows UTF-16, whereas the Internet message format does not.
UTF-16 encoding MUST be translated to UTF-8 or another charset and
encoding that is suitable for use in Internet message
format/protocols.
3GPP MMS Version
3GPP彩信版本
An 'X-Mms-3GPP-MMS-Version:' header SHOULD be added.
应添加“X-Mms-3GPP-Mms-Version:”标题。
Message Type (of PDU)
（PDU的）消息类型
An 'X-Mms-Message-Type:' header SHOULD be used in accordance with the specific MMS interface (e.g., MM1, MM4).
“X-Mms-Message-Type:”标头应根据特定的Mms接口（例如MM1、MM4）使用。
Transaction ID
事务ID
An 'X-Mms-Transaction-Id:' header SHOULD be used in accordance with the specific MMS interface (e.g., MM1, MM4).
“X-Mms-Transaction-Id:”标头应根据特定的Mms接口使用（例如，MM1、MM4）。
Message ID
消息ID
The 'Message-Id:' header MUST be retained. If not present, it MUST be created, with a unique value.
必须保留“消息Id:”标题。如果不存在，则必须使用唯一的值创建它。
Recipient(s) address
收件人地址
'To:' and 'Cc:' headers MUST be retained.
“收件人：”和“抄送：”标题必须保留。
Each recipient contained in the [SMTP] envelope (RCPT TO values) MUST be considered a recipient of the message. Recipients who appear in address headers but not the [SMTP] envelope MUST be ignored. Recipients who appear in the [SMTP] envelope but do not appear in headers are considered "blind" (Bcc) recipients; such recipients MUST NOT be added to message headers (including address and trace headers) unless there is only one recipient total.
[SMTP]信封（RCPT TO values）中包含的每个收件人都必须视为邮件的收件人。必须忽略出现在地址头中而不是[SMTP]信封中的收件人。出现在[SMTP]信封中但未出现在邮件头中的收件人被视为“盲”（密件抄送）收件人；除非总共只有一个收件人，否则不得将此类收件人添加到邮件标题（包括地址和跟踪标题）。
Sender address
送地址
The 'From:' header MUST be retained.
必须保留“发件人：”标题。
Content type
内容类型
The complete 'Content-Type:' header (including any parameters) SHOULD be preserved.
应保留完整的“内容类型：”标题（包括任何参数）。
Message class
消息类
An 'X-Mms-Message-Class: personal' header MAY be created for all received messages with a non-null return path (MAIL FROM value in the SMTP envelope). An 'X-Mms-Message-Class: auto' header MAY be created for messages with a null return path.
可以为所有接收到的具有非空返回路径（SMTP信封中的“邮件发件人”值）的邮件创建“X-Mms-Message-Class:personal”标头。可以为返回路径为空的邮件创建“X-Mms-Message-Class:auto”标头。
Time of Expiry
有效期
An 'X-Mms-Expiry:' header SHOULD be created if the message contains a relative time to expiration in the DELIVER-BY extension with a by-mode of "R", as specified in [Deliver-By].
如果消息在[传送方式]中指定的“传送方式”模式为“R”的“传送方式”扩展中包含相对到期时间，则应创建“X-Mms-Expiry:”标头。
If the by-mode is "N", a "relayed" DSN MUST be issued per [Deliver-By] and an 'X-Mms-Expiry:' header SHOULD NOT be created.
如果by模式为“N”，则必须根据[Deliver by]发出“中继”DSN，并且不应创建“X-Mms-Expiry:”标头。
Delivery report request
交付报告请求
An 'X-Mms-Delivery-Report:' header SHOULD be created for messages that request 'success' or 'none' delivery status notification by use of the DSN extension as specified in [DSN-SMTP]. Requests for 'delay' notifications or non-default actions, such as that only the message headers should be returned, cannot be mapped onto MMS headers and thus SHOULD be ignored.
应使用[DSN-SMTP]中指定的DSN扩展为请求“成功”或“无”传递状态通知的邮件创建“X-Mms-Delivery-Report:”标头。对于“延迟”通知或非默认操作的请求（例如仅应返回消息头）无法映射到MMS头，因此应忽略。
Importance
重要性
The message sender's importance value (also called "priority", although this can be confused with class-of-service values) is expressed with an 'Importance:' header. Historically, some clients used the older and non-standard 'X-Priority:' header for this purpose. As a result, some clients generate both.
消息发送者的重要性值（也称为“优先级”，尽管这可能与服务值的类别混淆）用“重要性：”头表示。历史上，一些客户端为此使用了较旧的非标准“X-Priority:”头。因此，一些客户机会同时生成这两个。
An 'X-Priority:' or 'Importance:' header, if present, SHOULD be replaced with an 'X-Mms-Priority:' header. If both headers are present, 'Importance:' SHOULD be used. Suggested mappings are shown in Table 3:
“X-Priority:”或“Importance:”标头（如果存在）应替换为“X-Mms-Priority:”标头。如果两个标题都存在，则应使用“重要性”。建议的映射如表3所示：
-------------------------------|----------------------
'X-Priority: 1 (highest)' |'X-Mms-Priority: High'
-------------------------------|----------------------
'X-Priority: 2 (high)' |'X-Mms-Priority: High'
-------------------------------|----------------------
'Importance: High' |'X-Mms-Priority: High'
-------------------------------|----------------------
'X-Priority: 3 (normal)' | [omitted]
-------------------------------|----------------------
'Importance: Normal' | [omitted]
-------------------------------|----------------------
'X-Priority: 4 (low)' |'X-Mms-Priority: Low'
-------------------------------|----------------------
'Importance: Low' |'X-Mms-Priority: Low'
-------------------------------|----------------------
'X-Priority: 5 (lowest)' |'X-Mms-Priority: Low'
-------------------------------|----------------------
-------------------------------|----------------------
'X-Priority: 1 (highest)' |'X-Mms-Priority: High'
-------------------------------|----------------------
'X-Priority: 2 (high)' |'X-Mms-Priority: High'
-------------------------------|----------------------
'Importance: High' |'X-Mms-Priority: High'
-------------------------------|----------------------
'X-Priority: 3 (normal)' | [omitted]
-------------------------------|----------------------
'Importance: Normal' | [omitted]
-------------------------------|----------------------
'X-Priority: 4 (low)' |'X-Mms-Priority: Low'
-------------------------------|----------------------
'Importance: Low' |'X-Mms-Priority: Low'
-------------------------------|----------------------
'X-Priority: 5 (lowest)' |'X-Mms-Priority: Low'
-------------------------------|----------------------
Normal importance messages SHOULD omit the 'X-Mms-Priority:' header.
正常重要信息应省略“X-Mms-Priority:”标题。
Sender visibility
发送者可见性
Support for sender address hiding is not currently supported.
当前不支持对发件人地址隐藏的支持。
Read reply request
阅读回复请求
A request for a read reply contained in a 'Disposition-Notification-To:' header as specified in [MDN] SHOULD be replaced with an 'X-Mms-Read-Reply:' header.
[MDN]中指定的“处置通知收件人：”标题中包含的读取回复请求应替换为“X-Mms-read-reply:”标题。
Subject
主题
The 'Subject:' header MUST be preserved.
必须保留“主题：”标题。
Resending
重发
Mapping from 'Resent-' and other [Msg-Fmt] headers to 'X-Mms-Previously-Sent-' headers SHOULD be done as follows:
从“重新发送-”和其他[Msg Fmt]头到“X-Mms-Previous-Sent-”头的映射应按如下方式完成：
The original 'From:' header is mapped to an 'X-Mms-Previously-Sent-By:' header with a leading "0" value. The value of the top-most 'Resent-From:' header is mapped to the 'From:' header. The value of each subsequent 'Resent-From:' header is mapped to an 'X-Mms-Previously-Sent-By:' header with the next larger leading value.
原始“发件人：”标头映射到“X-Mms-Previous-Sent-By:”标头，前导值为“0”。最顶端的“重新发送自：”标头的值映射到“自：”标头。每个后续“Recent From:”标头的值都映射到具有下一个较大前导值的“X-Mms-Previous-Sent-By:”标头。
The original 'Date:' header is mapped to an 'X-Mms-Previously-Sent-Date-and-Time:' header with a leading "0" value. Note that the value is also converted from date-time syntax [Msg-Fmt] to HTTP-date syntax [HTTP]. The value of the top-most 'Resent-Date:' header is mapped to the 'Date:' header. The value of each subsequent 'Date:' header is mapped to an 'X-Mms-Previously-Sent-Date-and-Time:' header with the next larger leading value.
原始的“日期：”标头映射到前导值为“0”的“X-Mms-Previous-Sent-Date-and-Time:”标头。请注意，该值还从日期时间语法[Msg Fmt]转换为HTTP日期语法[HTTP]。最顶端的“重新发送日期：”标头的值映射到“日期：”标头。每个后续“日期：”标头的值都映射到具有下一个较大前导值的“X-Mms-Previous-Sent-Date-and-Time:”标头。
If one or more 'Resent-Message-ID:' headers are present, the top-most one SHOULD be mapped to 'Message-ID:'; otherwise, the 'Message-ID:' header should be retained.
如果存在一个或多个“重新发送邮件ID:”标头，则最顶端的标头应映射到“邮件ID:”；否则，应保留“消息ID:”标题。
An 'X-Mms-Forward-Counter:' header SHOULD be created when 'Resent-' headers have been mapped to 'X-Mms-Previously-Sent-' headers. Its value SHOULD be the number of 'Resent-' blocks that existed prior to mapping.
当“重新发送-”标头映射到“X-Mms-Previous-Sent-”标头时，应创建“X-Mms-Forward-Counter:”标头。它的值应该是映射之前存在的“Resent-”块数。
Example:
例子：
The original message:
原始信息：
Date: Fri, 1 Apr 2005 14:02:03 -0800
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <msg123@mail.example.mil>
Date: Fri, 1 Apr 2005 14:02:03 -0800
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <msg123@mail.example.mil>
Is resent by Colonel Corn to L. Eva Message:
Corn上校对L.Eva表示不满消息：
Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800
Resent-From: Colonel Corn <gcorn@example.mil>
Resent-To: L. Eva Message <lem@example.org>
Resent-Message-ID: <msg234@mail.example.mil>
Date: Fri, 1 Apr 2005 14:02:03 -0800
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <msg123@mail.example.mil>
Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800
Resent-From: Colonel Corn <gcorn@example.mil>
Resent-To: L. Eva Message <lem@example.org>
Resent-Message-ID: <msg234@mail.example.mil>
Date: Fri, 1 Apr 2005 14:02:03 -0800
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <msg123@mail.example.mil>
L. Eva then resends to her MMS device:
L.Eva然后重新发送到她的彩信设备：
Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800
Resent-From: L. Eva Message <lem@example.org>
Resent-To: b1ff@mms.example.com
Resent-Message-ID: <99887766.112233@mail.example.org>
Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800
Resent-From: Colonel Corn <gcorn@example.mil>
Resent-To: L. Eva Message <lem@example.org>
Resent-Message-ID: <msg234@mail.example.mil>
Date: Fri, 1 Apr 2005 14:02:03 -0800
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <msg123@mail.example.mil>
Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800
Resent-From: L. Eva Message <lem@example.org>
Resent-To: b1ff@mms.example.com
Resent-Message-ID: <99887766.112233@mail.example.org>
Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800
Resent-From: Colonel Corn <gcorn@example.mil>
Resent-To: L. Eva Message <lem@example.org>
Resent-Message-ID: <msg234@mail.example.mil>
Date: Fri, 1 Apr 2005 14:02:03 -0800
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <msg123@mail.example.mil>
This would be mapped to an MMS message as:
这将映射到彩信，如下所示：
X-Mms-Forward-Counter: 2
X-Mms-Previously-Sent-Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT
X-Mms-Previously-Sent-By: 0, General Failure <mfail@example.mil>
X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT
X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 18:02:03 -0800
From: L. Eva Message <lem@example.org>
To: b1ff@mms.example.com
Message-ID: <99887766.112233@mail.example.org>
X-Mms-Forward-Counter: 2
X-Mms-Previously-Sent-Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT
X-Mms-Previously-Sent-By: 0, General Failure <mfail@example.mil>
X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT
X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 18:02:03 -0800
From: L. Eva Message <lem@example.org>
To: b1ff@mms.example.com
Message-ID: <99887766.112233@mail.example.org>
Note that the original 'From:' and 'Date:' values were moved to 'X-Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date-and-Time:' headers with a leading "0" value. The first 'Resent-From:' and 'Resent-Date:' values were moved to a second set of 'X-Mms-Previously-Sent-' headers, with a leading "1" value. The third set of 'Resent-' headers were moved to the 'Date:', 'To:', and 'From:' headers.
请注意，原始的“From:”和“Date:”值已移动到“X-Mms-previous-Sent-By:”和“X-Mms-previous-Sent-Date-and-Time:”标题，前导值为“0”。第一个“Resent From:”和“Resent Date:”值被移动到第二组“X-Mms-previous-Sent-”头中，前导值为“1”。第三组“重新发送-”标题已移动到“日期：”、“收件人：”、和“发件人：”标题。
Note also that the format of the date and time differs between the 'Date:' / 'Resent-Date:' and the 'X-Mms-Previously-Sent-Date-and-Time:' headers, in that the latter use HTTP-date [HTTP] instead of date-time [Msg-Fmt].
还请注意，“日期：”/“重新发送日期：”和“X-Mms-Previous-Sent-date-and-time:”头之间的日期和时间格式不同，后者使用HTTP日期[HTTP]而不是日期时间[Msg Fmt]。
'Received:' Headers
'已收到：'标题
Each system that processes a message SHOULD add a 'Received:' header as per [SMTP]. A message MAY be rejected if the number of 'Received:' headers exceeds a locally-defined maximum, which MUST conform to [SMTP] Section 6.2 and SHOULD be no less than 100.
处理邮件的每个系统应根据[SMTP]添加“Received:”标头。如果“Received:”标头的数量超过本地定义的最大值，则邮件可能会被拒绝，该最大值必须符合[SMTP]第6.2节的规定，并且不得小于100。
Sensitivity
体贴
The 'Sensitivity:' header field (value = "personal" or "private") [VPIM] indicates the desire of a voice message originator to send the message contents to the original recipient list with assurance that the message will not be forwarded further by either the messaging system or the actual message recipient(s). Since sensitivity is not an MMS feature, any messages that contain a 'Sensitivity:' header MUST NOT be sent to an MMS system. The associated negative delivery status report MUST include the extended status code [RESP] 5.6.0 as specified in [VPIM] ("Other or undefined protocol status") indicating that privacy could not be ensured.
“敏感度：”标题字段（value=“personal”或“private”）[VPIM]表示语音消息发起人希望将消息内容发送到原始收件人列表，并确保消息不会被消息系统或实际消息收件人进一步转发。由于敏感度不是彩信功能，因此任何包含“敏感度：”标题的邮件都不得发送到彩信系统。相关的负面交付状态报告必须包括[VPIM]中规定的扩展状态代码[RESP]5.6.0（“其他或未定义的协议状态”），表明无法确保隐私。
Content
所容纳之物
The message content appears in the message body.
消息内容将显示在消息正文中。
Internet message systems use the multipart/report MIME type for delivery and disposition reports as specified in [Report-Fmt]. This format is a two- or three-part MIME message; one part is a structured format describing the event being reported in an easy-to-parse format. Specific reports have a format that is built on [Report-Fmt]. Delivery reports are specified in [DSN-Msg]. Message disposition reports, which include read reports, are specified in [MDN].
互联网消息系统使用[报告Fmt]中指定的多部分/报告MIME类型进行传递和处置报告。这种格式是由两部分或三部分组成的MIME消息；其中一部分是结构化格式，以易于解析的格式描述正在报告的事件。特定报告的格式基于[Report Fmt]。交付报告在[DSN Msg]中指定。[MDN]中指定了包含读取报告的消息处置报告。
By contrast, MMS reports are plain text, with no defined structure specified. This makes it difficult to convert from an MMS report to a standard Internet report.
相比之下，彩信报告是纯文本的，没有指定定义的结构。这使得从彩信报告转换为标准互联网报告变得困难。
An implementation conforming to this specification MUST convert reports received from one side (MMS or Internet mail) destined for the other. In addition, reports MUST be generated as appropriate for messages received from either side. For example, if an MM to be sent via Internet mail is not deliverable, a delivery status MM shall be generated. Likewise, if an Internet message is received that cannot be further relayed or delivered, a delivery status report [DSN-Msg] MUST be generated.
符合本规范的实现必须转换从一方接收到的报告（彩信或互联网邮件），并发送给另一方。此外，必须针对从任何一方收到的消息生成适当的报告。例如，如果通过互联网邮件发送的MM不可交付，则应生成交付状态MM。同样，如果接收到无法进一步中继或传递的Internet消息，则必须生成传递状态报告[DSN Msg]。
When creating delivery or disposition reports from MMS reports, the MMS report should be parsed to determine the reported event and time, status, and the headers of the referenced (original) message. These elements, once determined, are used to populate the subparts of the delivery or disposition report. The first subpart is of type text/plain, and contains a human-readable explanation of the event. This text may include a statement that the report was synthesized
从MMS报告创建传递或处置报告时，应分析MMS报告，以确定报告的事件、时间、状态以及引用（原始）消息的标题。一旦确定，这些元素将用于填充交付或处置报告的子部分。第一个子部分为text/plain类型，包含事件的可读解释。该文本可能包括报告是综合的声明
based on an MMS report. The second subpart is of type report/delivery-status (for delivery reports) or report/disposition-notification (for disposition reports). This second part contains a structured itemization of the event. The optional third subpart is of type message/rfc822 and includes the headers and optionally the body of the referenced (original) message. Note that, per [DSN-Msg], the 'DSN-Gateway:' field in delivery reports MUST be created.
基于彩信报告。第二个子部分为报告/交付状态（对于交付报告）或报告/处置通知（对于处置报告）类型。第二部分包含事件的结构化项目。可选的第三个子部分为message/rfc822类型，包括引用（原始）消息的标题和正文（可选）。请注意，根据[DSN Msg]，必须在交付报告中创建“DSN网关：”字段。
Below, Table 4 maps information elements from MMS delivery reports to the format specified in [DSN-Msg].
下表4将MMS交付报告中的信息元素映射为[DSN Msg]中指定的格式。
======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem |
======================|============|===================================
ID of message whose |Message-Id: |'Message-ID:' preserved in third
delivery status is | |subpart of delivery report.
being reported | |
----------------------|------------|-----------------------------------
Recipient address of |From: |'Final-Recipient' field of the
the original message | |per-recipient section.
(object of delivery | |
report) | |
----------------------|------------|-----------------------------------
Destination address of|To: |'To:' header field value of top-
report | |level.
----------------------|------------|-----------------------------------
Date and time the |Date: |'Date:' header field value of top-
message was handled | |level.
----------------------|------------|-----------------------------------
======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem |
======================|============|===================================
ID of message whose |Message-Id: |'Message-ID:' preserved in third
delivery status is | |subpart of delivery report.
being reported | |
----------------------|------------|-----------------------------------
Recipient address of |From: |'Final-Recipient' field of the
the original message | |per-recipient section.
(object of delivery | |
report) | |
----------------------|------------|-----------------------------------
Destination address of|To: |'To:' header field value of top-
report | |level.
----------------------|------------|-----------------------------------
Date and time the |Date: |'Date:' header field value of top-
message was handled | |level.
----------------------|------------|-----------------------------------
======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem |
======================|============|===================================
Delivery status of |X-Mms- |Action and Status fields of
original message to | Status: |per-recipient section.
each recipient | |
| |The 'Action' field indicates if the
| |message was delivered.
| |
| |For failed delivery, an appropriate
| |'Status' value shall be included
| |per [DSN-Msg].
| |
| |The Action field is set to one of
| |the following values:
| |
| |* delivered (used for MMS status
| |values 'retrieved' and 'rejected',
| |depending on 'Status' code).
| |
| |* failed (used for MMS status
| |values 'expired' and 'unreachable')
| |
| |* delayed MAY be used for MMS
| |status value 'deferred'
| |
| |* relayed (used for MMS status
| |value 'indeterminate')
| |
| |* expanded (SHOULD NOT be used)
----------------------|------------|-----------------------------------
Status Text | |Text in first part (human-readable
| |part).
----------------------|------------|-----------------------------------
======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem |
======================|============|===================================
Delivery status of |X-Mms- |Action and Status fields of
original message to | Status: |per-recipient section.
each recipient | |
| |The 'Action' field indicates if the
| |message was delivered.
| |
| |For failed delivery, an appropriate
| |'Status' value shall be included
| |per [DSN-Msg].
| |
| |The Action field is set to one of
| |the following values:
| |
| |* delivered (used for MMS status
| |values 'retrieved' and 'rejected',
| |depending on 'Status' code).
| |
| |* failed (used for MMS status
| |values 'expired' and 'unreachable')
| |
| |* delayed MAY be used for MMS
| |status value 'deferred'
| |
| |* relayed (used for MMS status
| |value 'indeterminate')
| |
| |* expanded (SHOULD NOT be used)
----------------------|------------|-----------------------------------
Status Text | |Text in first part (human-readable
| |part).
----------------------|------------|-----------------------------------
When an MMS Relay/Server generates a [DSN-Msg] in response to a message received using [SMTP] on MM3:
当MMS中继/服务器生成[DSN Msg]以响应在MM3上使用[SMTP]接收的消息时：
* Top-level header field 'To:' SHOULD be the [SMTP] return-path of the message whose status is being reported.
* 顶级标头字段“To:”应为正在报告其状态的邮件的[SMTP]返回路径。
* Top-level header field 'From:' SHOULD be the address of the recipient that the delivery-report concerns.
* 顶级标题字段“发件人：”应为与传递报告相关的收件人的地址。
* The first part of the [DSN-Msg] SHOULD include the MM Status Text field that would have been generated for an MM1 delivery-report.
* [DSN Msg]的第一部分应包括为MM1交付报告生成的MM Status文本字段。
Below, Table 5 maps information elements from a delivery report as specified in [DSN-Msg] to the format of an MMS delivery report. Note that a single DSN that reports multiple recipients will result in several MMS delivery reports.
下表5将[DSN Msg]中指定的交付报告中的信息元素映射为MMS交付报告的格式。请注意，报告多个收件人的单个DSN将生成多个彩信发送报告。
===================|==================|================================
Information Element|MMS Delivery |[DSN-Msg] Element
|Report Element |
===================|==================|================================
ID of the original |Message-Id: |'Message-ID:' header preserved
message (object of | |in third sub-part of report.
delivery report) | |
-------------------|------------------|--------------------------------
Recipient address |From: |If available, the 'Original
of the original | |-Recipient' field of the per-
message (object of | |recipient section should be
delivery report) | |used; otherwise, the 'Final-
| |Recipient' field of the per-
| |recipient section is used.
-------------------|------------------|--------------------------------
Destination address|To: |'To:' header field value of
of report | |top-level.
| |
| |Value taken from [SMTP] envelope
| |return-path of message being
| |reported, not its 'From:' header
| |field.
-------------------|------------------|--------------------------------
Date and time the |Date: |'Date:' header field value of
message was handled| |top-level.
-------------------|------------------|--------------------------------
===================|==================|================================
Information Element|MMS Delivery |[DSN-Msg] Element
|Report Element |
===================|==================|================================
ID of the original |Message-Id: |'Message-ID:' header preserved
message (object of | |in third sub-part of report.
delivery report) | |
-------------------|------------------|--------------------------------
Recipient address |From: |If available, the 'Original
of the original | |-Recipient' field of the per-
message (object of | |recipient section should be
delivery report) | |used; otherwise, the 'Final-
| |Recipient' field of the per-
| |recipient section is used.
-------------------|------------------|--------------------------------
Destination address|To: |'To:' header field value of
of report | |top-level.
| |
| |Value taken from [SMTP] envelope
| |return-path of message being
| |reported, not its 'From:' header
| |field.
-------------------|------------------|--------------------------------
Date and time the |Date: |'Date:' header field value of
message was handled| |top-level.
-------------------|------------------|--------------------------------
===================|==================|================================
Information Element|MMS Delivery |[DSN-Msg] Element
|Report Element |
===================|==================|================================
Delivery status of |X-Mms-Status: |'Action' and 'Status' fields of
original message | |per-recipient section.
|Set to one of the |
|following values: |
| |
|'retrieved' (used |
|for 'Action' value|
|'delivered'). |
| |
|'unreachable' |
|(used for 'Action'|
|value 'failed') |
| |
|'forwarded' (used |
|for 'Action' value|
|'relayed') |
| |
|'deferred' MUST |
|NOT be used |
|(ignore DSNs with |
|'Action' value |
|'delayed') |
-------------------|------------------|--------------------------------
Status Text | |Text in first part (human-
| |readable part).
===================|==================|================================
===================|==================|================================
Information Element|MMS Delivery |[DSN-Msg] Element
|Report Element |
===================|==================|================================
Delivery status of |X-Mms-Status: |'Action' and 'Status' fields of
original message | |per-recipient section.
|Set to one of the |
|following values: |
| |
|'retrieved' (used |
|for 'Action' value|
|'delivered'). |
| |
|'unreachable' |
|(used for 'Action'|
|value 'failed') |
| |
|'forwarded' (used |
|for 'Action' value|
|'relayed') |
| |
|'deferred' MUST |
|NOT be used |
|(ignore DSNs with |
|'Action' value |
|'delayed') |
-------------------|------------------|--------------------------------
Status Text | |Text in first part (human-
| |readable part).
===================|==================|================================
Below, Table 6 maps information elements from MMS read reports to the format specified in [MDN].
下表6将MMS读取报告中的信息元素映射为[MDN]中指定的格式。
======================|============|===================================
Information Element |MMS Delivery|[MDN] Element
|Report Elem |
======================|============|===================================
ID of the original |Message-Id: |'Message-ID:' header preserved in
message (object of | |third part of report.
read report) | |
----------------------|------------|-----------------------------------
Recipient address of |From: |'Final-Recipient' field.
the original message | |
======================|============|===================================
Information Element |MMS Delivery|[MDN] Element
|Report Elem |
======================|============|===================================
ID of the original |Message-Id: |'Message-ID:' header preserved in
message (object of | |third part of report.
read report) | |
----------------------|------------|-----------------------------------
Recipient address of |From: |'Final-Recipient' field.
the original message | |
======================|============|===================================
Information Element |MMS Delivery|[MDN] Element
|Report Elem |
======================|============|===================================
Destination address of|To: |'To:' header field value of top-
report | |level.
| |
| |Value taken from 'Disposition-
| |Notification-To:' header field of
| |message being reported, not its
| |'From:' header field.
----------------------|------------|-----------------------------------
Date and time the |Date: |'Date:' header field value of top-
message was handled | |level.
----------------------|------------|-----------------------------------
Disposition of message|X-Mms-Read- |Disposition-field
being reported | Status: |
| |For X-MMS-Read-Status value 'read',
| |use 'disposition-type' value
| |'displayed'; for X-MMS-Read-Status
| |value 'Deleted without being read',
| |use 'disposition-type' value
| |'deleted').
----------------------|------------|-----------------------------------
Status Text | |Text in first part (human-readable
| |part).
======================|============|===================================
======================|============|===================================
Information Element |MMS Delivery|[MDN] Element
|Report Elem |
======================|============|===================================
Destination address of|To: |'To:' header field value of top-
report | |level.
| |
| |Value taken from 'Disposition-
| |Notification-To:' header field of
| |message being reported, not its
| |'From:' header field.
----------------------|------------|-----------------------------------
Date and time the |Date: |'Date:' header field value of top-
message was handled | |level.
----------------------|------------|-----------------------------------
Disposition of message|X-Mms-Read- |Disposition-field
being reported | Status: |
| |For X-MMS-Read-Status value 'read',
| |use 'disposition-type' value
| |'displayed'; for X-MMS-Read-Status
| |value 'Deleted without being read',
| |use 'disposition-type' value
| |'deleted').
----------------------|------------|-----------------------------------
Status Text | |Text in first part (human-readable
| |part).
======================|============|===================================
When an MMS Relay/Server generates an [MDN] in response to a message received using [SMTP] on MM3:
当MMS中继/服务器生成[MDN]以响应在MM3上使用[SMTP]接收的邮件时：
* Top-level header field 'To:' SHOULD be the value of the 'Disposition-Notification-To:' header field of the message whose disposition is being reported.
* 顶级标题字段“收件人：”应为正在报告其处置的邮件的“处置通知收件人：”标题字段的值。
* Top-level header field 'From:' SHOULD be the address of the recipient that the read report concerns.
* 顶级标题字段“发件人：”应为与读取报告相关的收件人的地址。
Below, Table 7 maps information elements from a disposition report as specified in [MDN] to the format of an MMS read report.
下表7将[MDN]中指定的处置报告中的信息元素映射为MMS读取报告的格式。
2.1.4.4.1. Table 7: Disposition Report Mappings (Internet Message to MMS)
2.1.4.4.1. 表7：处置报告映射（互联网消息到彩信）
===================|==================|================================
Information Element|MMS Read Report |[MDN] Element
|Element |
===================|==================|================================
ID of the original |Message-Id: |'Message-ID:' header preserved
message (object of | |in third subpart of report.
disposition report)| |
-------------------|------------------|--------------------------------
Recipient address |From: |'Final-Recipient' field.
of the original | |
message | |
-------------------|------------------|--------------------------------
Destination address|To: |'To:' header field value of
of report | |top-level.
| |
| |Value taken from 'Disposition-
| |Notification-To:' header field
| |of message being reported, not
| |its 'From:' header field.
-------------------|------------------|--------------------------------
Date and time the |Date: |'Date:' header field value of
message was handled| |top-level.
-------------------|------------------|--------------------------------
Disposition of |X-Mms-Read-Status:|disposition-field.
message being | |
reported |Set to one of the |
|following values: |
| |
|'read' (used for |
|disposition-type |
|value 'displayed')|
| |
|'Deleted without |
|being read' (used |
|for disposition- |
|types 'deleted', |
|'denied' and |
|'failed' when |
|action-mode is |
|'automatic- |
|action') |
-------------------|------------------|--------------------------------
Status Text | |Text in first part (human-
| |readable part).
===================|==================|================================
===================|==================|================================
Information Element|MMS Read Report |[MDN] Element
|Element |
===================|==================|================================
ID of the original |Message-Id: |'Message-ID:' header preserved
message (object of | |in third subpart of report.
disposition report)| |
-------------------|------------------|--------------------------------
Recipient address |From: |'Final-Recipient' field.
of the original | |
message | |
-------------------|------------------|--------------------------------
Destination address|To: |'To:' header field value of
of report | |top-level.
| |
| |Value taken from 'Disposition-
| |Notification-To:' header field
| |of message being reported, not
| |its 'From:' header field.
-------------------|------------------|--------------------------------
Date and time the |Date: |'Date:' header field value of
message was handled| |top-level.
-------------------|------------------|--------------------------------
Disposition of |X-Mms-Read-Status:|disposition-field.
message being | |
reported |Set to one of the |
|following values: |
| |
|'read' (used for |
|disposition-type |
|value 'displayed')|
| |
|'Deleted without |
|being read' (used |
|for disposition- |
|types 'deleted', |
|'denied' and |
|'failed' when |
|action-mode is |
|'automatic- |
|action') |
-------------------|------------------|--------------------------------
Status Text | |Text in first part (human-
| |readable part).
===================|==================|================================
Within Internet mail, when [SMTP] is used and delivery reports are requested [DSN-SMTP], delivery is considered to be acceptance of a message by the final server, that is, the server closest to the recipient. When an MMS Relay/Server receives a message using [SMTP] and a delivery report is requested, the MMS Relay/Server MAY consider the message delivered when it has been sent to the MMS User Agent.
在Internet邮件中，当使用[SMTP]并请求传递报告[DSN-SMTP]时，传递被视为最终服务器（即离收件人最近的服务器）接受邮件。当MMS中继/服务器使用[SMTP]接收消息并请求传递报告时，MMS中继/服务器可以考虑发送到MMS用户代理时所传递的消息。
Both MMS and Internet mail have their own set of security risks and considerations. This document specifies how to exchange messages between these two environments, so it is only appropriate to discuss considerations specific to this functionality, not those inherent in either environment.
彩信和互联网邮件都有各自的安全风险和注意事项。本文档指定了如何在这两个环境之间交换消息，因此只适合讨论特定于此功能的注意事项，而不是任何环境中固有的注意事项。
When a message uses end-to-end security mechanisms such as [PGP] or S/MIME [SMIME], servers MUST be careful not to accidently destroy the integrity of the protected content (for example, by altering any text within the region covered by a signature while mapping between MMS and email). [Mime-Sec-gw] discusses issues with use of such mechanisms in gateways.
当邮件使用端到端安全机制（如[PGP]或S/MIME[SMIME]）时，服务器必须小心，不要意外破坏受保护内容的完整性（例如，在MMS和电子邮件之间映射时，更改签名覆盖区域内的任何文本）。[Mime Sec gw]讨论在网关中使用此类机制的问题。
Some MMS features contain inherently more risk than others, including reply charging and sender address hiding. Support for these mechanisms is not included in this document.
一些彩信功能固有的风险比其他功能更大，包括回复收费和发件人地址隐藏。本文件不包括对这些机制的支持。
IANA has added "MMS" as one of the "WITH protocol types" under its "MAIL Parameters" registry. The description is "Multimedia Messaging Service"; the reference is to this document.
IANA在其“邮件参数”注册表下添加了“MMS”作为“具有协议类型”之一。描述为“多媒体消息服务”；参考文件是指本文件。
A number of people contributed to this document, especially the members of the IETF Lemonade working group, including Greg Vaudreuil. John Klensin did a very thorough and helpful review. Greg White caught a large number of nits. Ted Hardie was very helpful. Alexey Melnikov and Chris Newman sent very useful and detailed comments.
许多人对此文件做出了贡献，特别是IETF柠檬水工作组的成员，包括Greg Vaudreuil。约翰·克伦辛做了一次非常彻底和有益的回顾。格雷格·怀特抓到了大量的虱子。泰德·哈迪非常乐于助人。阿列克谢·梅尔尼科夫和克里斯·纽曼发表了非常有用和详细的评论。
[DSN-Msg] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN Msg]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSN-SMTP]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[Hdr-Enc] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.
[Hdr Enc]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[IDN] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDN]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[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月。
[MDN] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[MDN]Hansen，T.和G.Vaudreuil，“消息处置通知”，RFC 3798，2004年5月。
[Msg-Fmt] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[Msg Fmt]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[Report-Fmt] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[Report Fmt]Vaudreuil，G.，“邮件系统管理消息报告的多部分/报告内容类型”，RFC 3462，2003年1月。
[RESP] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RESP]Vaudreuil，G.“增强邮件系统状态代码”，RFC 3463，2003年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[OMA] OMA specifications are available at the OMA web site <http://www.openmobilealliance.org>.
[OMA]OMA规范可在OMA网站上获得<http://www.openmobilealliance.org>.
[OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C
[OMA-MMS]OMA-WAP-MMS-ENC-V1_2-20040323-C
[3GPP2] 3GPP2 specifications are available at the 3GPP2 (Third Generation Partnership Project 2) web site <http://www.3gpp2.org>.
[3GPP2]3GPP2规范可在3GPP2（第三代合作伙伴关系项目2）网站上获得<http://www.3gpp2.org>.
[3GPP] 3GPP specifications are available at the 3GPP (Third
Generation Partnership Project) web site
<http://www.3gpp.org>
[3GPP] 3GPP specifications are available at the 3GPP (Third
Generation Partnership Project) web site
<http://www.3gpp.org>
[Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310
[第三阶段]“使用OMA/WAP的MMS MM1第三阶段”，X.S0016-310
"MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016- 340
“MMS MM4第3阶段载波间互通”，X.S0016-340
"Multimedia Messaging Service: Functional description; Stage 2", TS 23.140 Release 5.
“彩信服务：功能说明；第2阶段”，TS 23.140第5版。
[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[BINARY]Vaudreuil，G.，“用于传输大型和二进制MIME消息的SMTP服务扩展”，RFC 3030，2000年12月。
[Deliver-By] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[Delivery By]Newman，D.，“通过SMTP服务扩展进行交付”，RFC 2852000年6月。
[Hdrs] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[Hdrs]Palme，J.，“通用互联网消息头”，RFC 2076，1997年2月。
[Mime-Sec-gw] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.
[Mime Sec gw]弗里德，N.，“网关和Mime安全多部分”，RFC 2480，1999年1月。
[PGP] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[PGP]Elkins，M.，Del Torto，D.，Levien，R.，和T.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
[SMIME] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[SMIME]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[Submission] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[提交]Gellens，R.和J.Klensin，“信息提交”，RFC 24761998年12月。
[VPIM] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIM]Vaudreuil，G.和G.Parsons，“互联网邮件语音配置文件-第2版（VPIMv2）”，RFC 38012004年6月。
[Overview] "Multimedia Messaging Services (MMS) Overview", X.S0016-000
[概述]“彩信服务（MMS）概述”，X.S0016-000
[Stage_1] "Multimedia Messaging Services (MMS); Stage 1", Requirements, October 2002, S.R0064-0.
[第1阶段]“多媒体信息服务（MMS）；第1阶段”，要求，2002年10月，S.R0064-0。
[Stage_2] "Multimedia Messaging Service (MMS); Stage 2", Functional Specification, April 2003, X.S0016-200.
[第二阶段]“多媒体信息服务（MMS）；第二阶段”，功能规范，2003年4月，X.S0016-200。
"Multimedia Messaging Service; Media formats and codecs", TS26.140Release 5.
“多媒体信息服务；媒体格式和编解码器”，TS26.1405版。
Author's Address
作者地址
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121
Randall Gellens高通公司，美国加利福尼亚州圣地亚哥Morehouse大道5775号，邮编92121
EMail: randy@qualcomm.com
EMail: randy@qualcomm.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。