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
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）として知られているサービスを定義しています。このサービスは、に似ていますが、インターネットメールで使用されるものから、キーの点で異なりフォーマットとプロトコルを使用しています。
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とインターネットメールとの間の1つの重要な違いは、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やインターネットメッセージのヘッダーで使用されているから、ヘッダーなどの配信と処分の報告を、マッピング情報要素を含め、これらの2つのサービス間でメッセージを交換する方法を指定します。
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
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].
この文書は、インターネットメールシステム（[3GPP] [3GPP2] [OMA]で定義されている）（つまり、[SMTP]、で、[MSG-FMT]）マルチメディアメッセージングサービス（MMS）システム間でメッセージを交換する方法について説明します。これは、メッセージフォーマット、メッセージヘッダ要素、メッセージ配信レポート[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.
この文書は、インターネットメール[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はまた、ショートメッセージサービス（SMS）と（例えばボイスメールシステムなど）外部のメールストアへのアクセスなどのインターネットメール以外の「外部」（非MMS）システムとのインターワーキングのために使用することができることに注意してください。本明細書では、これらの他の用途又は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].
キーワード「REQUIRED」、「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、要件レベルを示すためにRFCで使用のためのキーワード」で説明したように、この文書に解釈されるべきである「MAY」 「[キーワード]。
--------------------|----------------------------------------------
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.
--------------------|----------------------------------------------
--------|----------------------------------------------------------
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（要求）Stage_1]とステージ2（アーキテクチャと抽象メッセージ）[Stage_2]、及び3GPP / 3GPP2ステージ3の内容に精通していると仮定されます（プロトコル）[Stage_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.
このセクションでは、ネイティブ[SMTP]を使用して、MMSリレー/サーバと外部サーバとの間のインターワーキングを規定します。すなわち、情報要素は、例えば[HDRS]のもののような標準的なインターネット・メッセージ[MSG-FMT]ヘッダフィールド、および標準の[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およびインターネットメール拡張は、配信レポート、メッセージの有効期限、およびオプション機能のためのサーバーのサポートの発見などの機能のために使用されています。
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].
インターネットメールシステムにメッセージを送信するときに、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リレー/サーバは、転送プロトコルのために必要な制御情報（インターネットメッセージヘッダフィールドとSMTPエンベロープ値）を定義するために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- *ヘッダーとインターネットメッセージヘッダフィールドと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.
配信とレポートのMMは、標準のインターネットメッセージレポート形式（マルチパート/レポート）に変換する必要があります読んで。インターネットメッセージレポートの変換に加えて、MMSリレー/サーバは、配信を生成し、必要に応じて、受信したメッセージのレポートのMMを読まなければなりません。詳細については、セクション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.
インターネットメールシステムからメッセージを受信すると、MMSリレー/サーバは、受信システム内で使用されるMM形式に受信メッセージを変換します。
The MMS Relay/Server converts control information received from the Internet mail server into appropriate information elements of an MM.
MMSリレー/サーバは、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- *ヘッダーとインターネットメッセージヘッダフィールドと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.
標準のインターネットメッセージレポート形式（マルチパート/レポート）メッセージは、必要に応じて、送達または読み取りレポートのMMに変換することができます。レポート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 /インターネット・メッセージ・エレメント（[SMTP]パラメータ、[MSG-FMT]ヘッダー、および[DSN-MSG]フィールド）との間のマッピングは、以下の表1に要約し、そしてその後のセクションに詳述されています。 "MMSヘッダは、" [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
=================|=================|================|==============
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>
=================|=================|================|==============
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]あたり、メッセージ受信者は、「感度」ヘッダを含むメッセージを転送してはいけません。感度はMMSの機能ではありませんので、含まれているすべてのメッセージ「感度：」ヘッダはMMSシステムに送るべきではありません。
Note 2: [VPIM] specifies how conforming messages are identified.
注2：[VPIM]準拠のメッセージが識別されている方法を指定します。
3GPP MMS Version
3GPP MMSバージョン
The 'X-Mms-3GPP-MMS-Version:' header, if present, SHOULD be removed.
'X-MMS-3GPP-MMS-バージョン：' ヘッダは、存在する場合、除去されるべきです。
Message Type (of PDU)
（PDUの）メッセージタイプ
The 'X-Mms-Message-Type:' header, if present, SHOULD be removed.
「X-MMS-メッセージタイプ：」ヘッダーは、存在する場合、除去されるべきです。
Transaction ID
トランザクションID
The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed.
'X-MMS-トランザクション-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-メッセージ-ID」を保持することを望むかもしれません。このようなシステムは、「X-」で始まるヘッダがインターネットのMTAを通過する間削除される可能性があることを認識する必要があります。
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:;'.
各受信者のアドレスが値TO RCPTとして[SMTP]封筒で送信されなければなりません。すべての開示された受信者はまたに表示されるべきである「に：」または「Ccの」ヘッダー。 「に」少なくとも一つの、C-C「：」、または「のBcc：」ヘッダが存在しなければなりません。いずれも存在しない場合は、「に」ヘッダには、例えば、名前が人間の読者に指示を与える空のグループ構文を使用して作成する必要があり、「に：未公開、受信者:;」。
The 'To:' header SHOULD NOT appear more than once. The 'Cc:' header SHOULD NOT appear more than once.
「に」ヘッダが複数回表示されません。 C-C「：」ヘッダが複数回表示されません。
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].
現在のインターネットメッセージ形式は、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番号（即ち、なしドメインと数）の代わりに、完全修飾ドメイン名とインターネット・メール・システムに送信してはいけません。
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.
すべてのアドレス「に：」、「Ccを：」、および「のBcc：」ヘッダは完全修飾ドメインの形式でなければなりません。非修飾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-メッセージクラス：Personalは」）値FROMメールとして[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番号でインターネットメールシステムに送ってはいけません。その修飾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.
「から」のアドレス（ES）ヘッダは、完全修飾ドメインの形態であるべきです。非修飾E.164番号を使用しないでください。
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.
そのため、メールループのリスクのために、それは、MAIL FROMが（たとえば「：自動X-MMS-のメッセージクラス」など）は、すべて自動的に生成さのMMのために（「<>」）を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.
現在のインターネットメッセージ形式は、7ビットUS-ASCII文字がヘッダーに存在している必要があります。アドレスドメイン内の非7ビット文字は[IDN]で符号化されなければなりません。アドレスのローカル部分における任意の非7ビット文字がある場合は、メッセージを拒絶しなければなりません。ヘッダ内の他の場所に非7ビット文字は、[HDR-ENC]に従って符号化されなければなりません。エンコードされていない8ビット文字の送信を可能にするために、[SMTP]拡張を定義することが可能であることに留意されたいが、そのような拡張の非存在下で、[HDR-ENC]を使用しなければなりません。
The sender address MUST obey the length restrictions of [SMTP].
送信者のアドレスは、[SMTP]の長さの制限に従わなければなりません。
Content type
コンテンツの種類
The 'Content-Type:' header SHOULD be preserved.
「Content-type：」とヘッダが保存されなければなりません。
Message class
Messageクラス
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-メッセージクラス：」ヘッダは、メッセージのソースに関する情報を提供するために保持することができます。 「優先順位：バルク」ヘッダは、クラス= autoまたはクラス=広告のために挿入されてもよいです。上記の「送信者アドレス」を参照してください。 （クラス=個人およびクラス=情報は、特別な処理を必要としません。）
Time of Expiry
有効期限の時間
The 'X-Mms-Expiry:' header, if present, SHOULD be removed.
「X-MMS-期限：」ヘッダは、存在する場合、除去されるべきです。
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].
[配信バイ]で指定されたメッセージが期限切れと見なされるまでの残り時間は、「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-期限：」メッセージが期限切れと見なされるまで、ヘッダーはメッセージが期限切れとみなさされる絶対時間又は相対時間のいずれかを含んでいてもよいです。
Earliest delivery time
最早納期
The 'X-Mms-Delivery-Time:' header, if present, SHOULD be removed.
「X-MMS配信タイム：」ヘッダは、存在する場合、除去されるべきです。
Future delivery is a message submission (e.g., [Submission]), not message relay feature.
将来の配信は、メッセージの送信（例えば、[提出]）、しないメッセージ中継機能です。
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-配信-レポート」ヘッダ）。 NOTIFY拡張が使用される場合、変更されていない受信者アドレスがORCPT値として送信されるべきです。
The 'X-Mms-Delivery-Report:' header, if present, SHOULD be removed.
「X-MMS-送達報告」ヘッダは、存在する場合、除去されるべきです。
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'
---------------------------|------------------
Normal importance messages should omit the 'Importance:' header.
ヘッダ：通常の重要度のメッセージは「重要性」を省略しなければなりません。
The 'X-Mms-Priority:' header, if present, SHOULD be removed.
「X-MMS-優先度：」ヘッダは、存在する場合、除去されるべきです。
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-送信者可視性：「隠す」の値を持つヘッダが拒否されるべきです。
The 'X-Mms-Sender-Visibility:' header, if present, SHOULD be removed.
「X-MMS-送信者可視性：」ヘッダは、存在する場合、除去されるべきです。
Read reply request
回答リクエストを読みます
A request for a read reply SHOULD be transmitted using a 'Disposition-Notification-To:' header as specified in [MDN].
[MDN]で指定されるように、ヘッダ：リード応答のための要求は、「処分-NOTIFICATION-に」を使用して送信されるべきです。
The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed.
「X-MMS-読み取り応答：」ヘッダは、存在する場合、除去されるべきです。
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-返信-充電：'、 'X-MMS-返信-充電締切：'、 'X-MMS-返信充電-サイズ：'、および「X-MMS-返信充電-ID： 「ヘッダを除去することができます。返信充電利用要求（含むメッセージ 'X-MMS-返信充電-IDを' と 'X-MMS-返信充電：受け入れ' または 'X-MMS-返信充電：受け付け（テキストのみ）' ヘッダ）拒絶されるべきです。
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.
「件名：」ヘッダが保存されなければなりません。現在のインターネットメッセージ形式は、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.
メッセージは、1つまたは複数の新しい受信者に再送信することができます。それが複数回再送してもよいし、その都度、新しい「は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フォワード・カウンタ：」ヘッダは、存在する場合、除去されるべきです。 「憤慨し-数：」ヘッダはお勧めしません。ループ制御は、通常、「はResent-」のヘッダーよりも一般的です「受信」ヘッダを、カウントすることによって行われます。
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.
MMSは、2つのヘッダ内のメッセージの再送履歴一覧表示されます：「X-MMS-以前に送信され-から：」と「X-MMS-以前に送信され-日時：」。 「X-MMSが-以前-により送信された：」1つ以上のアドレスに続く番号が含まれています。 「X-MMS-以前に送信され-日時は：」日時続く番号が含まれています。両方のヘッダと、数字「0」は、より高い値が後続の各再送のために使用されていると、メッセージの元の提出に対応するエントリのために使用されます。 ：最後の（最新の）再送情報「から」中には「日」のヘッダー。 「X-MMS-フォワード・カウンタ：」もあり、それは、メッセージが再送されている回数を示します。
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-以前に送信されたバイ：'、 'X-MMS-以前に送信され-日時：'、および 'X-MMS-フォワード・カウンター：' ヘッダが存在する場合、削除する必要があります。次のようにそれらに含まれる情報は、[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.
「X-MMS-送信済み-日時：」値「0」で始まるヘッダが「日」を作成するために使用されるべきで[HTTP]にHTTP-日から日付と時刻を変換し、ヘッダを日時[MSG-FMT]。 「X-MMS-送信済みバイ：」値が「0」は「から：」を作成するために使用されるべきで始まるヘッダヘッダ。
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.
任意「X-MMSは、送信済み-日時：」：ヘッダ値「1」以上の値で始まり「憤慨-日」にマッピングされるヘッダー。任意「X-MMS-送信済みバイ：」値が「1」以上の値にマッピングされる始まるヘッダー「憤慨バイ：」ヘッダー。
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：' ヘッダはにマッピングされている 'のResent-から：'、 'のResent-TO：'、 'のResent-日：'、および '再送 - メッセージID：のResent- * 『ヘッダ」の最上位ブロック内のヘッダー』。
Example:
例：
The MMS message:
MMSメッセージ：
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-フォワード-カウンター：2 X-MMS-以前に送信され-日時：0、金、2005年4月1日は、午前6時02分03秒GMTのX-MMS-以前に送信されたバイ：0、一般的なエラー<mfail@example.mil> X-MMS-以前に送信され-日時：1、金、2005年4月1日午前8時02分03秒GMT X-MMS-以前に送信されたバイ：1、大佐コーン<gcorn @ example.mil>日付：金、2005年4月1日18時02分03秒-0800から：L.エヴァメッセージ<lem@example.org>へ：b1ff@mms.example.comメッセージ-ID：<99887766.112233@mail。 example.org>
is mapped to an Internet mail message:
インターネットメールメッセージにマップされます。
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>
再送-日付：金、2005年4月1日午前18時02分03秒-0800のResent-から：L.エヴァメッセージ<lem@example.org>のResent-TO：b1ff@mms.example.com憤慨し、メッセージ-ID：<99887766.112233 @ mail.example.org>のResent-日：金、2005年4月1日午前八時02分03秒0000のResent-から：大佐コーン<gcorn@example.mil>日付：金、2005年4月1日午前6時02分03秒0000投稿者：一般的なエラー<mfail@example.mil>宛先：大佐コーン<gcorn@example.mil>メッセージ-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".
メッセージは、MMSからインターネットメールをゲートウェイ処理された場合、「受信」ヘッダは[SMTP]あたりとして追加する必要があります。句「で」「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.
ヘッダー[SMTP]セクション6.2に従わなければなりません、そして、100以上であってはならないローカルに定義された最大値を超えています。：「受信」の数があれば、メッセージは拒否されるかもしれません
Privacy
プライバシー
Note that MMS systems do not currently support the 'Privacy' header field as described by [VPIM].
[VPIM]によって記載されているようにMMSシステムは現在、「プライバシー]ヘッダフィールドをサポートしていないことに注意してください。
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.
3GPP MMS Version
3GPP MMSバージョン
An 'X-Mms-3GPP-MMS-Version:' header SHOULD be added.
'X-MMS-3GPP-MMS-バージョン：' ヘッダが追加されるべきです。
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-メッセージタイプ：」ヘッダは特定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-トランザクション-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.
C-C「：」と：「から」ヘッダが保持されなければなりません。
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）に含まれる各受信者は、メッセージの受信者と見なされなければなりません。 [SMTP]封筒を無視しなければなりませんアドレスヘッダに表示されなく受信者。 [SMTP]封筒に表示されますが、ヘッダーに表示されていない受信者は、「ブラインド」（BCC）の受信者と考えられています。唯一の受信者の合計がない限り、このような受信者は、（アドレスとトレースヘッダを含む）メッセージヘッダに追加してはいけません。
Sender address
送信者アドレス
The 'From:' header MUST be retained.
「から：」ヘッダーが保持されなければなりません。
Content type
コンテンツの種類
The complete 'Content-Type:' header (including any parameters) SHOULD be preserved.
完全「のContent-Type：」（任意のパラメータを含む）ヘッダが保存されるべきです。
Message class
Messageクラス
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.
「X-MMS-のメッセージクラス：個人的な」ヘッダーはすべてのために作成することができるnull以外のリターンパス（SMTPエンベロープの値FROM MAIL）とメッセージを受け取りました。 「X-MMS-のメッセージクラス：オート」ヘッダがnullのリターンパスとのメッセージのために作成することができます。
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].
「X-MMS-期限：」メッセージが「R」のバイモードにDELIVER-BY拡張に満了に対して時間が含まれている場合、[配信バイ]で指定されるように、ヘッダは、作成されるべきです。
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.
バイモード「N」である場合、DSNはごとに発行しなければならない「中継」[配信バイ]をし、「X-MMS-期限：」ヘッダが作成されるべきではありません。
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.
「X-MMS-配信 - レポート：」ヘッダーは[DSN-SMTP]で指定されたDSN拡張子を使用して「成功」か「なし」配信ステータス通知を要求するメッセージのために作成する必要があります。 「遅延」の通知や、メッセージヘッダーだけが返されるべきであることなどの非デフォルトアクションの要求は、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-優先順位」を使用しました。その結果、一部のクライアントは両方を生成します。
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-優先度：」または「重要：」ヘッダ、存在する場合、置き換えてください「X-MMS-優先度：」ヘッダ。両方のヘッダが存在する場合は、「重要：」使用されるべきです。推奨マッピングは、表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'
-------------------------------|----------------------
Normal importance messages SHOULD omit the 'X-Mms-Priority:' header.
ヘッダ：通常の重要度のメッセージは「X-MMS-優先順位」を省略すべきです。
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-読み取り返信」で置き換えられるべきである：「処分-NOTIFICATION-には」に含まれるリード応答要求。
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:
次のように「X-MMS-以前にSent-」ヘッダが行われるべきであると「はResent-」および他の[MSG-FMT]ヘッダーからマッピング：
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-送信済みバイ：」先頭の「0」の値を持つヘッダ。ヘッダ：ヘッダ「から」にマッピングされている：最上位「憤慨-からは」の値。各後続「憤慨-から：」の値は、ヘッダにマッピングされている「X-MMSは、送信済みバイ：」ヘッダを次に大きい先頭値と。
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.
オリジナル「日付は：」ヘッダはにマッピングされる「X-MMS-送信済み-日時：」先頭の「0」の値を持つヘッダ。 [HTTP] HTTP-日付構文に[MSG-FMT]値も日時構文から変換されたことに留意されたいです。最上位の値が「憤慨-日：」：ヘッダヘッダは、「日」にマッピングされます。各後続の値「日」：次に大きい先頭値を持つヘッダヘッダは、「X-MMSは、送信済み、日付・時間」にマッピングされます。
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フォワード・カウンタ：」「はResent-」ヘッダが「X-MMS-以前にSent-」ヘッダーにマッピングされたときにヘッダが作成されるべきです。その値は、マッピングの前に存在していた「の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>
日付：金、2005年4月1日午後2時02分03秒-0800から：一般的なエラー<mfail@example.mil>宛先：大佐コーン<gcorn@example.mil>メッセージ-ID：<msg123@mail.example.mil>
Is resent by Colonel Corn to L. Eva Message:
L.エヴァメッセージに大佐トウモロコシで再送されます。
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>
再送-日付：金、2005年4月1日16時02分03秒-0800のResent-から：大佐コーン<gcorn@example.mil>のResent-TO：L.エヴァメッセージ<lem@example.org>のResent-のMessage-ID： <msg234@mail.example.mil>日付：金、2005年4月1日午後02時02分03秒-0800から：一般的なエラー<mfail@example.mil>宛先：大佐コーン<gcorn@example.mil>メッセージ-ID：< msg123@mail.example.mil>
L. Eva then resends to her MMS device:
L.エヴァは、彼女のMMSデバイスに再送します：
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>
再送-日付：金、2005年4月1日午前18時02分03秒-0800のResent-から：L.エヴァメッセージ<lem@example.org>のResent-TO：b1ff@mms.example.com憤慨し、メッセージ-ID：<99887766.112233 @ mail.example.org>のResent-日：金、2005年4月1日午前16時02分03秒-0800のResent-から：大佐コーン<gcorn@example.mil>のResent-TO：L.エヴァメッセージ<lem@example.org >憤慨し、メッセージ-ID：<msg234@mail.example.mil>日付：金、2005年4月1日午後02時02分03秒-0800から：一般的なエラー<mfail@example.mil>宛先：大佐コーン<gcorn @例。ミル>メッセージ-ID：<msg123@mail.example.mil>
This would be mapped to an MMS message as:
これは、MMSメッセージにマッピングされます。
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-フォワード-カウンター：2 X-MMS-以前に送信され-日時：0、金、2005年4月1日は、午前6時02分03秒GMTのX-MMS-以前に送信されたバイ：0、一般的なエラー<mfail@example.mil> X-MMS-以前に送信され-日時：1、金、2005年4月1日午前8時02分03秒GMT X-MMS-以前に送信されたバイ：1、大佐コーン<gcorn @ example.mil>日付：金、2005年4月1日18時02分03秒-0800から：L.エヴァメッセージ<lem@example.org>へ：b1ff@mms.example.comメッセージ-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.
なお、オリジナルの「から：」と「日」の値がに移動された「X-MMS-以前に送信されたバイ：」と「X-MMS-以前に送信され-日時：」大手とヘッダ"0" の値。第「から憤慨-：」と「のResent-日は：」の値は先頭の「1」値を用いて、「X-MMS-以前にSent-」ヘッダの第二セットに移しました。 「から：」、およびヘッダ「に」、「日付」「はResent-」のヘッダーの第三セットはに移動しました。
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].
/：日付と時刻の形式が「日」の間で異なることにも注意してください「のResent-日：」と「X-MMS-送信済み-日時：」ヘッダ、後者を使用することでHTTP -date [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]に従ってヘッダ：メッセージを処理し、各システムには、「受信」を追加する必要があります。ヘッダー[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.
「感度：」ヘッダフィールド（値=「個人」または「プライベート」）[VPIM]メッセージによりさらに転送されないことを保証して、元の受信者リストにメッセージの内容を送信する音声メッセージの発信者の欲求を示しメッセージングシステムまたは実際のメッセージ受信者（単数または複数）のいずれか。感度はMMSの機能ではありませんので、含まれているすべてのメッセージ「感度：」ヘッダはMMSシステムに送ってはいけません。関連負配信状態報告は、[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タイプを使用します。このフォーマットは、2次元または3パートMIMEメッセージです。一方の部分は簡単に解析形式で報告されたイベントを記述する構造化されたフォーマットです。特定のレポートは、[レポート-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.
これとは対照的に、MMSのレポートは、指定されていない定義された構造を持つプレーンテキスト、です。これは、標準のインターネットレポートにMMSレポートから変換することを困難にしています。
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.
レポートを変換する必要があり、この仕様に準拠した実装は、他の宛ての片側（MMSまたはインターネットメール）から受け取りました。また、報告書は、どちらの側から受信したメッセージに応じて生成されなければなりません。例えば、MMは、インターネットメール経由で送信する場合、配信状態MMが生成されなければならない、成果物ではありません。インターネットメッセージはさらに中継または配信できない受信された場合、同様に、配信状態報告[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 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.
MMSレポートから送達または配置レポートを作成する場合、MMSレポートが報告されたイベントと時刻、ステータス、および参照（元の）メッセージのヘッダーを決定するために解析されるべきです。これらの要素は、一度決定、配信または処分レポートのサブパートを移植するために使用されています。最初のサブパートはタイプtext / plainでのものであり、イベントの人間が読めるの説明が含まれています。このテキストは、レポートがMMS報告に基づいて合成した文を含んでいてもよいです。第二のサブパートは、タイプ（配信レポートの）レポート/配送状況又は（配置レポートの）レポート/気質通知です。この第二部では、イベントの構造化された箇条書きが含まれています。任意の第三サブパートタイプメッセージ/ RFC822であり、必要に応じてヘッダーと参照（元の）メッセージの本体を含みます。 「DSN-ゲートウェイ：」、[DSN-MSG]ごとに、なお配信レポート内のフィールドを作成する必要があります。
Below, Table 4 maps information elements from MMS delivery reports to the format specified in [DSN-Msg].
以下、表4は、[DSN-MSG]で指定された形式にMMS配信レポートから情報要素をマッピングします。
======================|============|===================================
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).
----------------------|------------|-----------------------------------
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.
*トップ・レベル・ヘッダフィールド「に」[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ステータステキストフィールドを含むべきです。
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.
MMS配信レポートのフォーマットに[DSN-MSG]で指定されるように、以下の表5は、配信レポートから情報要素をマッピングします。複数の受信者を報告し、単一のDSNは、いくつかのMMSの配信レポートになることに注意して下さい。
===================|==================|================================
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).
===================|==================|================================
Below, Table 6 maps information elements from MMS read reports to the format specified in [MDN].
以下は、MMSから表6のマップ情報要素は、[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 |
======================|============|===================================
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]を生成するときに[SMTP] MM3に使用して、受信しました：
* Top-level header field 'To:' SHOULD be the value of the 'Disposition-Notification-To:' header field of the message whose disposition is being reported.
配置が報告されているメッセージのヘッダフィールド：「処分-NOTIFICATION-TO」の値にすべきである：「に」*トップ・レベル・ヘッダー・フィールド。
* 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.
MMS読み取りレポートのフォーマットに[MDN]で指定されるように以下の表7は、配置レポートから情報要素をマッピングします。
2.1.4.4.1. Table 7: Disposition Report Mappings (Internet Message to MMS)
2.1.4.4.1。表7：処分報告書マッピング（MMSへのインターネットメッセージ）
===================|==================|================================
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.
インターネットメールの中で、[DSN-SMTP]、[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.
両方ともMMSとインターネットメールは、セキュリティリスクと考慮事項の独自のセットを持っています。この文書では、これら2つの環境間でメッセージを交換する方法を指定するので、この機能は、いずれの環境に固有のないものに固有の考慮事項を議論するためにのみ適切です。
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とEメールとの間のマッピング中）。 [マイム-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.
いくつかのMMS機能は、応答充電と送信者アドレスの隠蔽など、他のものより本質的なリスクを、含まれています。これらのメカニズムのサポートは、この文書に含まれていません。
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は、その「MAILパラメータ」レジストリの下に「WITHプロトコルタイプ」の一つとして、「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レモネードのメンバーはグレッグボードルイ含めて、ワーキンググループは、この文書に貢献しました。ジョン・クレンシンは非常に徹底し、有用見直しを行いました。グレッグ・ホワイトは、ニットの多数をキャッチ。テッドハーディーは非常に有用でした。アレクセイ・メルニコフとクリス・ニューマンは非常に有用で、詳細なコメントを送りました。
[DSN-Msg] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN-MSG]ムーア、K.とG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、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]ムーア、K.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、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]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非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.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[IDN] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDN] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[MDN] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[MDN]ハンセン、T.およびG.ボードルイ、 "メッセージ気質通知"、RFC 3798、2004年5月。
[Msg-Fmt] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[MSG-FMT]レズニック、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.
[レポート-FMT]ヴォードルイユ、G.、RFC 3462「メールシステムの管理メッセージの報告のための複合/レポートのコンテンツタイプ」、2003年1月。
[RESP] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RESP]ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、RFC 3463、2003年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[OMA] OMA specifications are available at the OMA web site <http://www.openmobilealliance.org>.
[OMA] OMA仕様は、OMAのWebサイト<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（第3世代パートナーシッププロジェクト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仕様は、3GPP（第3世代パートナーシッププロジェクト）のウェブサイトで入手できます。<http://www.3gpp.org>
[Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310
[Stage_3] "OMA / WAPを使用してMMS MM1ステージ3"、X.S0016-310
"MMS MM4 Stage 3 Inter-Carrier Interworking", 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]ヴォードルイユ、G.、RFC 3030、2000年12月 "大規模およびバイナリMIMEメッセージの送信のためのSMTPサービス拡張"。
[Deliver-By] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[お届けバイ]ニューマン、D.、RFC 2852、2000年6月 "SMTPサービス拡張により、お届け"。
[Hdrs] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[HDRS]パルメ、J.、 "一般的なインターネットメッセージヘッダ"、RFC 2076、1997年2月。
[Mime-Sec-gw] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.
[マイム-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]エルキンズ、M.、デルTorto、D.、Levien、R.、およびT.レスラー、 "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.、RFC 3851、2004年7月 "/多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様を固定します"。
[Submission] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[提出] Gellens、R.及びJ. Klensin、 "メッセージ送信"、RFC 2476、1998年12月。
[VPIM] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIM]ヴォードルイユ、G.とG.パーソンズ、 "インターネットメール用の音声プロファイル - バージョン2（VPIMv2）"、RFC 3801、2004年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.
[Stage_1] "マルチメディアメッセージングサービス（MMS）;ステージ1"、要件、2002年10月、S.R0064-0。
[Stage_2] "Multimedia Messaging Service (MMS); Stage 2", Functional Specification, April 2003, X.S0016-200.
[Stage_2] "マルチメディアメッセージングサービス（MMS）;ステージ2"、機能仕様、2003年4月、X.S0016-200。
"Multimedia Messaging Service; Media formats and
codecs", TS26.140Release 5.
Author's Address
著者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121
ランドールGellens QUALCOMM Incorporatedの5775モアハウスドライブサンディエゴ、CA 92121
EMail: randy@qualcomm.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。