RFC5337 日本語訳
5337 Internationalized Delivery Status and Disposition Notifications.C. Newman, A. Melnikov, Ed.. September 2008. (Format: TXT=36324 bytes) (Updates RFC3461, RFC3462, RFC3464, RFC3798) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Newman
Request for Comments: 5337 Sun Microsystems
Updates: 3461, 3464, 3798 A. Melnikov, Ed.
Category: Experimental Isode Ltd
September 2008
コメントを求めるワーキンググループC.ニューマン要求をネットワークでつないでください: 5337のサン・マイクロシステムズアップデート: 3461 3464 3798 エドA.メリニコフ、カテゴリ: 実験的なIsode Ltd2008年9月
Internationalized Delivery Status and Disposition Notifications
国際化している配送状態と気質通知
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.
配送状態通知(DSNs)はメールシステムの正しい操作に重要です。 しかしながら、既存のDraft Standards(RFC3461、RFC3462、RFC3464)は現在、プロトコルの機械可読な部分の米国-ASCIIテキストに制限されます。 この仕様は、格下げの後にさえ正しく非米国のASCII文字とのオリジナルの受取人アドレスを保存できるように国際的なEメールアドレスのための新しいアドレスタイプを加えます。 また、配送状態通知とメッセージ気質通知が新しいアドレスタイプの使用を支持するように、これはアップデートされた満足しているリターンメディアタイプを提供します。
This document experimentally extends RFC 3461, RFC 3464, and RFC 3798.
このドキュメントは実験的にRFC3461、RFC3464、およびRFC3798を広げています。
Newman & Melnikov Experimental [Page 1] RFC 5337 Internationalized DSN and MDNs September 2008
[1ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . . 3
4. UTF-8 Delivery Status Notifications . . . . . . . . . . . . . 6
4.1. Additional Requirements on SMTP Servers . . . . . . . . . 8
5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 10
6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 11
6.3. message/global-headers . . . . . . . . . . . . . . . . . . 11
6.4. message/global-delivery-status . . . . . . . . . . . . . . 12
6.5. message/global-disposition-notification . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 コンベンションは本書では.3 3を使用しました。 UTF-8はタイプ. . . . . . . . . . . . . . . . . . . . . . 3 4に演説します。 UTF-8配送状態通知. . . . . . . . . . . . . 6 4.1。 SMTPプロトコルのサーバ. . . . . . . . . 8 5に関する追加要件。 UTF-8メッセージ気質通知. . . . . . . . . . . 9 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 10 6.1。 UTF-8はアドレスタイプ登録. . . . . . . . . . . 10 6.2を郵送します。 .137に'smtp'Diagnostic Type Registration. . . . . . 11 6.3のグローバルなメッセージ/ヘッダーの.116.4のグローバルな配送メッセージ/状態に.126.5のグローバルな気質メッセージ/通知をアップデートしてください。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 15 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 15 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 16付録A.承認. . . . . . . . . . . . . . . . . . 17
Newman & Melnikov Experimental [Page 2] RFC 5337 Internationalized DSN and MDNs September 2008
[2ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
1. Introduction
1. 序論
When an email message is transmitted using the UTF8SMTP [RFC5336] extension and Internationalized Email Headers [RFC5335], it is sometimes necessary to return that message or generate a Message Disposition Notification (MDN) [RFC3798]. As a message sent to multiple recipients can generate a status and disposition notification for each recipient, it is helpful if a client can correlate these notifications based on the recipient address it provided; thus, preservation of the original recipient is important. This specification describes how to preserve the original recipient and updates the MDN and DSN formats to support the new address types.
メールメッセージがUTF8SMTP[RFC5336]拡張子とInternationalizedメールHeaders[RFC5335]を使用することで送られるとき、そのメッセージを返すか、またはMessage Disposition Notification(MDN)[RFC3798]を発生させるのが時々必要です。 複数の受取人に送られたメッセージが各受取人のために状態と気質通知を発生させることができるので、クライアントがそれが提供した受取人アドレスに基づくこれらの通知を関連させることができるなら、役立っています。 したがって、オリジナルの受取人の保存は重要です。 この仕様は、オリジナルの受取人を保存する方法を説明して、新しいアドレスタイプを支持するためにMDNとDSN形式をアップデートします。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] notation including the core rules defined in Appendix B of RFC 5234 [RFC5234] and the UTF-8 syntax rules in Section 4 of [RFC3629].
正式な構文はRFC5234[RFC5234]のAppendix Bで定義されたコア規則と[RFC3629]のセクション4のUTF-8シンタックス・ルールを含むAugmented BN記法(ABNF)[RFC5234]記法を使用します。
3. UTF-8 Address Type
3. UTF-8アドレスタイプ
An Extensible Message Format for Delivery Status Notifications [RFC3464] defines the concept of an address type. The address format introduced in Internationalized Email Headers [RFC5335] is a new address type. The syntax for the new address type in the context of status notifications is specified at the end of this section.
Delivery Status Notifications[RFC3464]のためのExtensible Message Formatはアドレスタイプの概念を定義します。 InternationalizedメールHeaders[RFC5335]で紹介されたアドレス形式は新しいアドレスタイプです。 状態通知の文脈の新しいアドレスタイプのための構文はこのセクションの端で指定されます。
An SMTP [RFC2821] server that advertises both the UTF8SMTP extension [RFC5336] and the DSN extension [RFC3461] MUST accept a UTF-8 address type in the ORCPT parameter including 8-bit UTF-8 characters. This address type also includes a 7-bit encoding suitable for use in a message/delivery-status body part or an ORCPT parameter sent to an SMTP server that does not advertise UTF8SMTP.
8ビットのUTF-8キャラクタを含んでいて、UTF8SMTP拡張子[RFC5336]とDSN拡張子[RFC3461]の両方の広告を出すSMTP[RFC2821]サーバはORCPTパラメタでUTF-8アドレスタイプを受け入れなければなりません。 また、このアドレスタイプは配送メッセージ/状態身体の場所かORCPTパラメタにおける使用に適したコード化がUTF8SMTPの広告を出さないSMTPサーバーに送った7ビットを入れます。
This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext, and utf-8-address. The first 2 forms are 7-bit safe.
このアドレスタイプには、3つのフォームがあります: utf-8-addr-xtext、utf-8-addr-unitext、およびutf8アドレス。 最初の2つのフォームが7ビットの金庫です。
The utf-8-address form is only suitable for use in newly defined protocols capable of native representation of 8-bit characters. That is, the utf-8-address form MUST NOT be used in the ORCPT parameter when the SMTP server doesn't advertise support for UTF8SMTP or the SMTP server supports UTF8SMTP, but the address contains US-ASCII characters not permitted in the ORCPT parameter (e.g., the ORCPT parameter forbids unencoded SP and the = character), or in a 7-bit
utf8アドレスフォームは単に8ビットのキャラクタの固有の表現ができる新たに定義されたプロトコルにおける使用に適しています。 SMTPサーバーがUTF8SMTPのサポートの広告を出さないか、またはSMTPサーバーがUTF8SMTPを支持するとき、ORCPTパラメタですなわち、utf8アドレスフォームを使用してはいけませんが、アドレスはORCPTパラメタ(例えば、ORCPTパラメタは暗号化されていないSPと=キャラクタを禁じる)、または7ビットで受入れられなかった米国-ASCII文字を含みます。
Newman & Melnikov Experimental [Page 3] RFC 5337 Internationalized DSN and MDNs September 2008
[3ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
transport environment including a message/delivery-status Original- Recipient or Final-Recipient field. In the former case, the utf-8- addr-xtext form (see below) MUST be used instead; in the latter case, the utf-8-addr-unitext form MUST be used. The utf-8-address form MAY be used in the ORCPT parameter when the SMTP server also advertises support for UTF8SMTP and the address doesn't contain any US-ASCII characters not permitted in the ORCPT parameter. It SHOULD be used in a message/global-delivery-status Original-Recipient or Final- Recipient DSN field, or in an Original-Recipient header field [RFC3798] if the message is a UTF8SMTP message.
配送メッセージ/状態Original受取人かFinal-受取人分野を含む環境を輸送してください。 前の場合では、代わりに、utf-8addr-xtextのフォーム(以下を見る)を使用しなければなりません。 後者の場合では、utf-8-addr-unitextフォームを使用しなければなりません。 また、SMTPサーバーがUTF8SMTPのサポートの広告を出して、アドレスがORCPTパラメタで受入れられなかった少しの米国-ASCII文字も含まないとき、utf8アドレスフォームはORCPTパラメタで使用されるかもしれません。 それ、SHOULDはグローバルな配送メッセージ/状態Original-受取人かFinal受取人DSN分野で使用されるか、またはメッセージがUTF8SMTPメッセージであるならOriginal-受取人ヘッダーで[RFC3798]をさばきます。
In addition, the utf-8-addr-unitext form can be used anywhere where the utf-8-address form is allowed.
さらに、どこでもutf8アドレスフォームが許容されているutf-8-addr-unitextフォームを使用できます。
When using in the ORCPT parameter, the UTF-8 address type requires
that US-ASCII CTLs, SP, \, +, and = be encoded using xtext encoding
as described in [RFC3461]. This is described by the utf-8-addr-xtext
form in the ABNF below. Unicode characters MAY be included in a
UTF-8 address type using a "\x{HEXPOINT}" syntax
(EmbeddedUnicodeChar), where HEXPOINT is 2 to 6 hexadecimal digits.
When sending data to a UTF8SMTP-capable server, native UTF-8
characters SHOULD be used instead of the EmbeddedUnicodeChar syntax
described in details below. When sending data to an SMTP server that
does not advertise UTF8SMTP, then the EmbeddedUnicodeChar syntax MUST
be used instead of UTF-8.
ORCPTパラメタで使用するとき、UTF-8アドレスタイプは、米国-ASCII CTLs、SP、\、+、および=が[RFC3461]で説明されるようにxtextコード化を使用することでコード化されるのを必要とします。 これは以下のABNFのutf-8-addr-xtextフォームによって説明されます。 「ユニコード文字は」 \x HEXPOINTを使用しているUTF-8アドレスタイプで含まれているかもしれなく」構文(EmbeddedUnicodeChar)。(そこでは、HEXPOINTが2〜6つの16進数字です)。 UTF8SMTPできるサーバ、ネイティブのUTF-8キャラクタSHOULDにデータを送る、以下の詳細に説明されたEmbeddedUnicodeChar構文の代わりに、使用されてください。 UTF8SMTPの広告を出さないSMTPサーバーにデータを送ると、UTF-8の代わりにEmbeddedUnicodeChar構文を使用しなければなりません。
When the ORCPT parameter is placed in a message/ global-delivery-status Original-Recipient field, the utf-8-addr-xtext form of the UTF-8 address type SHOULD be converted to the utf-8- address form (see the ABNF below) by removing all xtext encoding first (which will result in the utf-8-addr-unitext form), followed by removal of the unitext encoding. However, if an address is labeled with the UTF-8 address type but does not conform to utf-8 syntax, then it MUST be copied into the message/global-delivery-status field without alteration.
ORCPTパラメタがグローバルな配送メッセージ/状態Original-受取人分野に置かれるとき、1(utf-8-addr-unitextフォームをもたらす)番目をコード化するすべてのxtextを取り外すことによってutf-8アドレスのフォーム(以下のABNFを見る)に変換されて、unitextコード化の取り外しがあとに続いていて、UTF-8アドレスのutf-8-addr-xtextフォームはSHOULDをタイプします。 しかしながら、アドレスがUTF-8アドレスタイプでラベルされますが、utf-8構文に従わないなら、変更なしでグローバルな配送メッセージ/状態分野にそれをコピーしなければなりません。
The ability to encode characters with the EmbeddedUnicodeChar encodings should be viewed as a transitional mechanism. It is hoped that as systems lacking support for UTF8SMTP become less common over time, these encodings can eventually be phased out.
EmbeddedUnicodeChar encodingsと共にキャラクタをコード化する能力は過渡的なメカニズムとして見なされるべきです。 UTF8SMTPのサポートを欠いているシステムが時間がたつにつれてより一般的でなくなるとき結局これらのencodingsを段階的に廃止することができることが望まれています。
In the ABNF below, all productions not defined in this document are defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in [RFC3464].
以下のABNFでは、本書では定義されなかったすべての創作が[RFC5234]のAppendix B、[RFC3629]のセクション4、または[RFC3464]で定義されます。
Newman & Melnikov Experimental [Page 4] RFC 5337 Internationalized DSN and MDNs September 2008
[4ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
utf-8-type-addr = "utf-8;" utf-8-enc-addr
utf8タイプaddrは"utf-8"と等しいです。 utf-8-enc-addr
utf-8-address = uMailbox [ 1*WSP "<" Mailbox ">" ]
; uMailbox is defined in [RFC5336].
; Mailbox is defined in [RFC2821].
utf8アドレスはuMailbox[1*WSP"<"メールボックス">"]と等しいです。 uMailboxは[RFC5336]で定義されます。 ; メールボックスは[RFC2821]で定義されます。
utf-8-enc-addr = utf-8-addr-xtext /
utf-8-addr-unitext /
utf-8-address
utf-8-enc-addrはutf8utf-8-addr-xtext/utf-8-addr-unitext/アドレスと等しいです。
utf-8-addr-xtext = xtext
; xtext is defined in [RFC3461].
; When xtext encoding is removed,
; the syntax MUST conform to
; utf-8-addr-unitext.
utf-8-addr-xtextはxtextと等しいです。 xtextは[RFC3461]で定義されます。 ; xtextであるときに、コード化を取り除きます。 構文が従わなければならない、。 utf-8-addr-unitext。
utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar)
; MUST follow utf-8-address ABNF when
; dequoted
utf-8-addr-unitextは1*(QUCHAR / EmbeddedUnicodeChar)と等しいです。 いつutf8アドレスABNFは続かなければならないか。 反引用しました。
QUCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e /
UTF8-2 / UTF8-3 / UTF8-4
; US-ASCII printable characters except
; CTLs, SP, '\', '+' and '=', plus
; other Unicode characters in UTF-8
QUCHAR=%x21-2a/%x2c-3c/%x3e-5b/%x5d-7e/UTF8-2/UTF8-3/UTF8-4。 米国-ASCIIの印刷可能なキャラクタは除きます。 'CTLs、SP、'\'、+ ''='、プラス。 UTF-8の他のユニコード文字
EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}"
; starts with "\x"
EmbeddedUnicodeChar=%x5C.78、「"HEXPOINT"、」、。 \x」から「始めます」。
HEXPOINT = "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms
( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms
( NZDHEXDIG 3(HEXDIG) ) /
( "D" %x30-37 2(HEXDIG) ) /
; 4 digit forms excluding surrogate
( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms
( "10" 4*HEXDIG ) ; 6 digit forms
; represents either "\" or a Unicode code point outside the
; US-ASCII repertoire
HEXPOINTは「5C」/(HEXDIG8 HEXDIG)/と等しいです。 2ケタは(NZHEXDIG2(HEXDIG))/を形成します。 3ケタは(NZDHEXDIG3(HEXDIG))/(「D」%x30-37 2(HEXDIG))/を形成します。 4ケタは除外代理(NZHEXDIG4(HEXDIG))の/を形成します。 5ケタが形成される、(「10インチの4*HEXDIG)」、。 6ケタは形成されます。 外に「\」かユニコードコード・ポイントのどちらかを表す、。 米国-ASCIIレパートリー
HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F"
; HEXDIG excluding 0-7
NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F"
; HEXDIG excluding "0"
NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F"
; HEXDIG excluding "0" and "D"
HEXDIG8は%x38-39/「A」/「B」/「C」/「D」/「E」/「F」と等しいです。 /「B」/x31-39/「C」/「D」/「E」/「F」を0-7NZHEXDIG=%除くHEXDIG。 「0インチのNZDHEXDIGは%x31-39/「A」/「B」/「C」/「E」/「F」と等しいこと」を除いたHEXDIG。 「0インチと「D」」を除いたHEXDIG
Newman & Melnikov Experimental [Page 5] RFC 5337 Internationalized DSN and MDNs September 2008
[5ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
4. UTF-8 Delivery Status Notifications
4. UTF-8配送状態通知
A traditional delivery status notification [RFC3464] comes in a three-part multipart/report [RFC3462] container, where the first part is human-readable text describing the error, the second part is a 7-bit-only message/delivery-status, and the optional third part is used for content (message/rfc822) or header (text/rfc822-headers) return. As the present DSN format does not permit returning of undeliverable UTF8SMTP messages, three new media types are needed.
伝統的な配送状態通知[RFC3464]は3部分の複合/レポート[RFC3462]容器に入ります、そして、第二部は7ビットだけ配送メッセージ/状態です、そして、3番目の任意の部分は内容(メッセージ/rfc822)かヘッダー(rfc822テキスト/ヘッダー)リターンに使用されます。(そこでは、最初の部分が誤りについて説明する人間読み込み可能なテキストです)。 現在のDSN形式が、undeliverable UTF8SMTPメッセージに戻ることを許可しないとき、3つのニューメディアタイプが必要です。
The first type, message/global-delivery-status, has the syntax of message/delivery-status with three modifications. First, the charset for message/global-delivery-status is UTF-8, and thus any field MAY contain UTF-8 characters when appropriate (see the ABNF below). In particular, the Diagnostic-Code field MAY contain UTF-8 as described in UTF8SMTP [RFC5336]; the Diagnostic-Code field SHOULD be in i-default language [DEFAULTLANG]. Second, systems generating a message/global-delivery-status body part SHOULD use the utf-8-address form of the UTF-8 address type for all addresses containing characters outside the US-ASCII repertoire. These systems SHOULD up- convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a UTF-8 address type in the ORCPT parameter to the utf-8-address form of a UTF-8 address type in the Original-Recipient field. Third, a new optional field called Localized-Diagnostic is added. Each instance includes a language tag [LANGTAGS] and contains text in the specified language. This is equivalent to the text part of the Diagnostic-Code field. All instances of Localized-Diagnostic MUST use different language tags. The ABNF for message/ global-delivery-status is specified below.
最初のタイプ(グローバルな配送メッセージ/状態)には、配送メッセージ/状態の構文が3つの変更と共にあります。 まず最初に、グローバルな配送メッセージ/状態へのcharsetはUTF-8です、そして、適切であるときに、その結果、どんな分野もUTF-8キャラクタを含むかもしれません(以下のABNFを見てください)。 特に、Diagnostic-コード分野はUTF8SMTP[RFC5336]で説明されるようにUTF-8を含むかもしれません。 i-デフォルト言語でDiagnostic-コード分野SHOULDはこと[DEFAULTLANG]です。 2番目に、グローバルな配送メッセージ/状態身体のパートSHOULDを発生させるシステムは米国-ASCIIレパートリーの外にキャラクタを含むすべてのアドレスにUTF-8アドレスタイプのutf8アドレスフォームを使用します。 SHOULDが上げるこれらのシステムはOriginal-受取人分野のUTF-8アドレスタイプのutf8アドレスフォームへのUTF-8アドレスタイプのORCPTパラメタのutf-8-addr-xtextかutf-8-addr-unitextフォームを変換します。 3番目に、Localized診断していると呼ばれる新しい任意の分野は加えられます。 各例は、言語タグ[LANGTAGS]を含んでいて、指定された言語のテキストを含んでいます。 これはDiagnostic-コード分野のテキスト地域に同等です。 Localized-病気の特徴のすべての例が異なった言語タグを使用しなければなりません。 グローバルな配送メッセージ/状態へのABNFは以下で指定されます。
In the ABNF below, all productions not defined in this document are defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in [RFC3464].
以下のABNFでは、本書では定義されなかったすべての創作が[RFC5234]のAppendix B、[RFC3629]のセクション4、または[RFC3464]で定義されます。
utf-8-delivery-status-content = per-message-fields
1*( CRLF utf-8-per-recipient-fields )
; "per-message-fields" remains unchanged from the definition
; in RFC 3464, except for the "extension-field"
; which is updated below.
utf8配送状態内容がメッセージ分野単位で等しい、1*(受取人分野あたりのCRLF utf8)。 「メッセージ分野」は定義から変わりがありません。 「拡大分野」を除いたRFC3464で。 以下では、アップデートします。
Newman & Melnikov Experimental [Page 6] RFC 5337 Internationalized DSN and MDNs September 2008
[6ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
utf-8-per-recipient-fields =
[ original-recipient-field CRLF ]
final-recipient-field CRLF
action-field CRLF
status-field CRLF
[ remote-mta-field CRLF ]
[ diagnostic-code-field CRLF
*(localized-diagnostic-text-field CRLF) ]
[ last-attempt-date-field CRLF ]
[ will-retry-until-field CRLF ]
*( extension-field CRLF )
; All fields except for "original-recipient-field",
; "final-recipient-field", "diagnostic-code-field"
; and "extension-field" remain unchanged from
; the definition in RFC 3464.
受取人分野あたりのutf8は最終受理者分野CRLF動作分野CRLF状態分野CRLF[遠く離れたmta分野CRLF][診断コード分野CRLF*(局所化された診断テキストフィールドCRLF)][最後の試み年月日欄CRLF][分野まで再試行しているCRLF]*(拡大分野CRLF)と等しいです[元の受取人分野CRLF]。 「元の受取人分野」を除いたすべての分野。 「最終受理者分野」、「診断コード分野」。 そして、「拡大分野」は変わりがないままで残っています。 RFC3464との定義。
generic-address =/ utf-8-enc-addr
; Only allowed with the "utf-8" address-type.
;
; This indirectly updates "original-recipient-field"
; and "final-recipient-field"
一般的なアドレス=/utf-8-enc-addr。 「utf-8インチのアドレスタイプ」で許容されているだけです。 ; ; これは間接的に「元の受取人分野」をアップデートします。 そして、「最終受理者分野」
diagnostic-code-field =
"Diagnostic-Code" ":" diagnostic-type ";" *text-fixed
「診断コード分野は「診断コード」と等しい」:、」 「診断タイプ」;、」 *テキストで、修理されています。
localized-diagnostic-text-field =
"Localized-Diagnostic" ":" Language-Tag ";" *utf8-text
; "Language-Tag" is a language tag as defined in [LANGTAGS].
「局所化された診断テキストフィールドは「局所化された病気の特徴」と等しい」:、」 「言語タグ」;、」 *utf8-テキスト。 「言語タグ」は[LANGTAGS]で定義されるように言語タグです。
extension-field =/ extension-field-name ":" *utf8-text
「拡大分野拡大=/フィールド名」:、」 *utf8-テキスト
text-fixed = %d1-9 / ; Any Unicode character except for NUL,
%d11 / ; CR and LF, encoded in UTF-8
%d12 /
%d14-127
; Same as <text> from [RFC2822], but without <obs-text>.
; If/when RFC 2822 is updated to disallow <obs-text>,
; this should become just <text>
; Also, if/when RFC 2822 is updated to disallow control characters
; this should become a reference to RFC 2822upd instead.
テキストで固定された=%d1-9/。 NUL以外のどんなユニコード文字、%d11/も。 UTF-8%d12/%d14-127でコード化されたCRとLF。 [RFC2822]にもかかわらず、<obs-テキスト>なしで<テキスト>と同じです。 ; RFC2822であるときに、<obs-テキスト>を禁じるために/をアップデートするなら。 これはまさしく<テキスト>になるべきです。 RFC2822であるときに、制御文字を禁じるためにまた、/をアップデートするなら。 これは代わりにRFC 2822updの参照になるべきです。
utf8-text = text-fixed / UTF8-non-ascii
utf8-テキストはテキストで固定された/UTF8非ASCIIと等しいです。
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8非ASCIIはUTF8-2/UTF8-3/UTF8-4と等しいです。
Newman & Melnikov Experimental [Page 7] RFC 5337 Internationalized DSN and MDNs September 2008
[7ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
The second type, used for returning the content, is message/global which is similar to message/rfc822, except it contains a message with UTF-8 headers. This media type is described in [RFC5335].
内容を返すのに使用されるタイプがメッセージ/グローバルである秒に、どれがそれ以外の/rfc822がUTF-8ヘッダーがあるメッセージを含んでいるというメッセージと同様ですか? このメディアタイプは[RFC5335]で説明されます。
The third type, used for returning the headers, is message/ global-headers and contains only the UTF-8 header fields of a message (all lines prior to the first blank line in a UTF8SMTP message). Unlike message/global, this body part provides no difficulties for the present infrastructure.
ヘッダーを返すのに使用される3番目のタイプは、グローバルなメッセージ/ヘッダーであり、メッセージ(UTF8SMTPメッセージにおける最初の空白行の前のすべての線)のUTF-8ヘッダーフィールドだけを含んでいます。 メッセージ/グローバルと異なって、この身体の部分は困難を全く現在のインフラストラクチャに提供しません。
Note that as far as multipart/report [RFC3462] container is concerned, message/global-delivery-status, message/global, and message/global-headers MUST be treated as equivalent to message/ delivery-status, message/rfc822, and text/rfc822-headers. That is, implementations processing multipart/report MUST expect any combinations of the 6 MIME types mentioned above inside a multipart/ report MIME type.
複合/レポート[RFC3462]容器は関係があります、グローバルな配送メッセージ/状態、メッセージ/グローバルであり、グローバルなメッセージ/ヘッダーがグローバルでなければならないのと同じくらい遠くに配送メッセージ/状態、メッセージ/rfc822、およびrfc822テキスト/ヘッダーと同等物として扱われた状態でそれに注意してください。 すなわち、複合/レポートを処理する実現は複合/レポートMIMEの種類の中で前記のように6つのMIMEの種類にどんな組み合わせも予想しなければなりません。
All three new types will typically use the "8bit" Content-Transfer- Encoding. (In the event all content is 7-bit, the equivalent traditional types for delivery status notifications MAY be used. For example, if information in message/global-delivery-status part can be represented without any loss of information as message/ delivery-status, then the message/delivery-status body part may be used.) Note that [RFC5335] relaxed restriction from MIME [RFC2046] regarding use of Content-Transfer-Encoding in new "message" subtypes. This specification explicitly allows use of Content-Transfer-Encoding in message/global-headers and message/global-delivery-status. This is not believed to be problematic as these new MIME types are intended primarily for use by newer systems with full support for 8-bit MIME and UTF-8 headers.
すべての3つの新しいタイプが「8ビット」のContent-転送コード化を通常使用するでしょう。 (出来事では、すべての内容が7ビットである、配送状態通知のための同等な伝統的なタイプは使用されるかもしれません。 例えば、配送メッセージ/状態として情報の少しも損失なしでグローバルな配送メッセージ/状態一部の情報を表すことができるなら、配送メッセージ/状態身体の部分は使用されるかもしれません。) [RFC5335]が新しい「メッセージ」血液型亜型におけるContent転送コード化の使用に関するMIME[RFC2046]から規制を緩和したことに注意してください。 この仕様は明らかにグローバルなメッセージ/ヘッダーとグローバルな配送メッセージ/状態でのContent転送コード化の使用を許します。 これらの新しいMIMEの種類が主として使用のために、より新しいシステムで意図するので、これが8ビットのMIMEとUTF-8ヘッダーの全面的な支援で問題が多いと信じられていません。
4.1. Additional Requirements on SMTP Servers
4.1. SMTPサーバに関する追加要件
If an SMTP server that advertises both UTF8SMTP and DSN needs to return an undeliverable UTF8SMTP message, then it MUST NOT downgrade [DOWNGRADE] the UTF8SMTP message when generating the corresponding multipart/report. If the return path SMTP server does not support UTF8SMTP, then the undeliverable body part and headers MUST be encoded using a 7-bit Content-Transfer-Encoding such as "base64" or "quoted-printable" [RFC2045], as detailed in Section 4. Otherwise, "8bit" Content-Transfer-Encoding can be used.
対応する複合/レポートを作るとき、UTF8SMTPとDSNの両方の広告を出すSMTPサーバーが、undeliverable UTF8SMTPメッセージを返す必要があるなら、それは[DOWNGRADE]UTF8SMTPメッセージを格下げしてはいけません。 リターンパスSMTPサーバがUTF8SMTPを支持しないなら、「base64"か「引用されて印刷可能[RFC2045]で」、セクション4で詳細である」として7ビットのContentがコード化を移しているそのようなものを使用して、「非-提出物」身体の部分とヘッダーをコード化しなければなりません。 さもなければ、「8ビット」のContent転送コード化を使用できます。
Newman & Melnikov Experimental [Page 8] RFC 5337 Internationalized DSN and MDNs September 2008
[8ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
5. UTF-8 Message Disposition Notifications
5. UTF-8メッセージ気質通知
Message Disposition Notifications [RFC3798] have a similar design and structure to DSNs. As a result, they use the same basic return format. When generating an MDN for a UTF-8 header message, the third part of the multipart/report contains the returned content (message/ global) or header (message/global-headers), same as for DSNs. The second part of the multipart/report uses a new media type, message/ global-disposition-notification, which has the syntax of message/ disposition-notification with two modifications. First, the charset for message/global-disposition-notification is UTF-8, and thus any field MAY contain UTF-8 characters when appropriate (see the ABNF below). (In particular, the failure-field, the error-field, and the warning-field MAY contain UTF-8. These fields SHOULD be in i-default language [DEFAULTLANG].) Second, systems generating a message/ global-disposition-notification body part (typically a mail user agent) SHOULD use the UTF-8 address type for all addresses containing characters outside the US-ASCII repertoire.
メッセージDisposition Notifications[RFC3798]は同様のデザインと構造をDSNsに持っています。 その結果、彼らは同じ基本的なリターン形式を使用します。 UTF-8ヘッダーメッセージのためにMDNを発生させるとき、複合/レポートの3番目の部分は返された内容(メッセージ/グローバルな)かヘッダー(グローバルなメッセージ/ヘッダー)を含んでいます、DSNsのように、同じです。 複合/レポートの第二部はニューメディアタイプ、グローバルな気質メッセージ/通知を使用します。(それは、2つの変更と共に気質メッセージ/通知の構文を持っています)。 まず最初に、グローバルな気質メッセージ/通知のためのcharsetはUTF-8です、そして、適切であるときに、その結果、どんな分野もUTF-8キャラクタを含むかもしれません(以下のABNFを見てください)。 特に、失敗分野、誤り分野、および警告分野はUTF-8を含むかもしれません。(i-デフォルト言語でこれらの分野SHOULDはこと[DEFAULTLANG]です。) 2番目に、グローバルな気質メッセージ/通知身体のパート(通常メールユーザエージェント)SHOULDを発生させるシステムは米国-ASCIIレパートリーの外にキャラクタを含むすべてのアドレスにUTF-8アドレスタイプを使用します。
The MDN specification also defines the Original-Recipient header field, which is added with a copy of the contents of ORCPT at delivery time. When generating an Original-Recipient header field, a delivery agent writing a UTF-8 header message in native format SHOULD convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a UTF-8 address type in the ORCPT parameter to the corresponding utf-8- address form.
また、MDN仕様はOriginal-受取人ヘッダーフィールドを定義します。(それは、納期にORCPTのコンテンツのコピーで加えられます)。 Original-受取人ヘッダーフィールド、ネイティブの形式SHOULD転向者のUTF-8ヘッダーメッセージにutf-8-addr-xtextを書く新聞販売店またはUTF-8アドレスのutf-8-addr-unitextフォームを作るときには、対応するutf-8アドレスのフォームにORCPTパラメタをタイプしてください。
The MDN specification also defines the Disposition-Notification-To header, which is an address header and thus follows the same 8-bit rules as other address headers such as "From" and "To" when used in a UTF-8 header message.
また、MDN仕様が定義する、Disposition通知、ヘッダー、UTF-8ヘッダーメッセージで使用されると、どれがアドレスヘッダーであり、その結果、他と同じ8ビットの規則に従うかが“From"や“To"などのヘッダーに演説します。
; ABNF for "original-recipient-header", "original-recipient-field",
; and "final-recipient-field" from RFC 3798 is implicitly updated
; as they use the updated "generic-address" as defined in
; Section 4 of this document.
; 「オリジナルの受取人ヘッダー」のためのABNF、「元の受取人分野」。 そして、それとなくRFC3798からの「最終受理者分野」をアップデートします。 彼らが中で定義されるようにアップデートされた「一般的なアドレス」を使用するので。 このドキュメントのセクション4。
failure-field = "Failure" ":" *utf8-text
; "utf8-text" is defined in Section 4 of this document.
「失敗分野=「失敗」」:、」 *utf8-テキスト。 「utf8-テキスト」はこのドキュメントのセクション4で定義されます。
error-field = "Error" ":" *utf8-text
; "utf8-text" is defined in Section 4 of this document.
「誤り分野=「誤り」」:、」 *utf8-テキスト。 「utf8-テキスト」はこのドキュメントのセクション4で定義されます。
warning-field = "Warning" ":" *utf8-text
; "utf8-text" is defined in Section 4 of this document.
「警告分野=「警告」」:、」 *utf8-テキスト。 「utf8-テキスト」はこのドキュメントのセクション4で定義されます。
Newman & Melnikov Experimental [Page 9] RFC 5337 Internationalized DSN and MDNs September 2008
[9ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
6. IANA Considerations
6. IANA問題
This specification does not create any new IANA registries. However, the following items have been registered as a result of this document.
この仕様はどんな新しいIANA登録も作成しません。 しかしながら、このドキュメントの結果、以下の項目を登録してあります。
6.1. UTF-8 Mail Address Type Registration
6.1. UTF-8郵便の宛先タイプ登録
The mail address type registry was created by RFC 3464. The registration template response follows:
郵便の宛先タイプ登録はRFC3464によって作成されました。 登録テンプレート応答は続きます:
(a) The proposed address-type name.
(a) 提案されたアドレス型名。
UTF-8
UTF-8
(b) The syntax for mailbox addresses of this type, specified using
BNF, regular expressions, ASN.1, or other non-ambiguous language.
(b) BNF、正規表現、ASN.1、または他の非あいまいな言語を使用することで指定されたこのタイプのメールボックスアドレスのための構文。
See Section 3.
セクション3を見てください。
(c) If addresses of this type are not composed entirely of graphic
characters from the US-ASCII repertoire, a specification for how
they are to be encoded as graphic US-ASCII characters in a DSN
Original-Recipient or Final-Recipient DSN field.
このタイプのアドレスがDSN Original-受取人に米国-ASCIIレパートリーからの図形文字、それらがグラフィック米国-ASCII文字としてどうコード化されることになっているかためには仕様に基づき完全に落ち着いていないか、そして、Final-受取人DSNがさばく(c)。
This address type has 3 forms (as defined in Section 3): utf-8-
addr-xtext, utf-8-addr-unitext, and utf-8-address. The first 2
forms are 7-bit safe.
このアドレスタイプには、3つのフォームがあります(セクション3で定義されるように): utf-8addr-xtext、utf-8-addr-unitext、およびutf8アドレス。 最初の2つのフォームが7ビットの金庫です。
The utf-8-address form MUST NOT be used
utf8アドレスフォームを使用してはいけません。
1. in the ORCPT parameter when the SMTP server doesn't advertise
support for UTF8SMTP;
1. SMTPサーバーであるときに、ORCPTでは、パラメタはUTF8SMTPのサポートの広告を出しません。
2. or the SMTP server supports UTF8SMTP, but the address contains
US-ASCII characters not permitted in the ORCPT parameter (e.g.,
the ORCPT parameter forbids SP and the = characters);
または、2.、SMTPサーバーはUTF8SMTPを支持しますが、アドレスはORCPTパラメタで受入れられなかった米国-ASCII文字を含みます(例えば、ORCPTパラメタはSPと=キャラクタを禁じます)。
3. or in a 7-bit transport environment including a message/
delivery-status Original-Recipient or Final-Recipient field.
3.、または、7ビットの輸送環境包含における配送メッセージ/状態Original-受取人かFinal-受取人分野。
The utf-8-addr-xtext form MUST be used instead in the first case; the utf-8-addr-unitext form MUST be used in the other two cases. The utf-8-address form MAY be used in the ORCPT parameter when the SMTP server also advertises support for UTF8SMTP and the address doesn't contain any US-ASCII characters not permitted in the ORCPT parameter;
代わりに前者の場合utf-8-addr-xtextフォームを使用しなければなりません。 他の2つの場合にutf-8-addr-unitextフォームを使用しなければなりません。 また、SMTPサーバーがUTF8SMTPのサポートの広告を出すとき、utf8アドレスフォームはORCPTパラメタで使用されるかもしれません、そして、アドレスはORCPTパラメタで受入れられなかった少しの米国-ASCII文字も含みません。
Newman & Melnikov Experimental [Page 10] RFC 5337 Internationalized DSN and MDNs September 2008
[10ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
in a message/global-delivery-status Original-Recipient or Final- Recipient DSN field; or in an Original-Recipient header field [RFC3798] if the message is a UTF8SMTP message.
グローバルな配送メッセージ/状態Original-受取人かFinal受取人DSN分野で。 または、メッセージがUTF8SMTPメッセージであるならOriginal-受取人ヘッダーで[RFC3798]をさばいてください。
In addition, the utf-8-addr-unitext form can be used anywhere where the utf-8-address form is allowed.
さらに、どこでもutf8アドレスフォームが許容されているutf-8-addr-unitextフォームを使用できます。
6.2. Update to 'smtp' Diagnostic Type Registration
6.2. 診断タイプ登録を'smtp'にアップデートしてください。
The mail diagnostic type registry was created by RFC 3464. The registration for the 'smtp' diagnostic type should be updated to reference RFC 5337 in addition to RFC 3464.
メールの診断タイプ登録はRFC3464によって作成されました。 'smtp'診断タイプのための登録をRFC3464に加えた参照RFC5337にアップデートするべきです。
When the 'smtp' diagnostic type is used in the context of a message/ delivery-status body part, it remains as presently defined. When the 'smtp' diagnostic type is used in the context of a message/ global-delivery-status body part, the codes remain the same, but the text portion MAY contain UTF-8 characters.
'smtp'診断タイプが配送メッセージ/状態身体の部分の文脈で使用されるとき、それは現在定義されているとして残っています。 'smtp'診断タイプがグローバルな配送メッセージ/状態身体の部分の文脈で使用されるとき、コードは同じままで残っていますが、テキスト部分はUTF-8キャラクタを含むかもしれません。
6.3. message/global-headers
6.3. グローバルなメッセージ/ヘッダー
Type name: message
型名: メッセージ
Subtype name: global-headers
Subtypeは以下を命名します。 グローバルなヘッダー
Required parameters: none
必要なパラメタ: なし
Optional parameters: none
任意のパラメタ: なし
Encoding considerations: This media type contains Internationalized
Email Headers [RFC5335] with no message body. Whenever possible,
the 8-bit content transfer encoding SHOULD be used. When this
media type passes through a 7-bit-only SMTP infrastructure it MAY
be encoded with the base64 or quoted-printable content transfer
encoding.
問題をコード化します: このメディアタイプはメッセージ本体なしでInternationalizedメールHeaders[RFC5335]を含んでいます。 可能であることで、8ビットの内容がSHOULDをコード化しながら移されるときはいつも、使用されてください。 このメディアタイプが7ビットだけSMTPインフラストラクチャを通り抜けるとき、それはbase64か引用されて印刷可能な満足している転送コード化でコード化されるかもしれません。
Security considerations: See Section 7.
セキュリティ問題: セクション7を見てください。
Interoperability considerations: It is important that this media
type is not converted to a charset other than UTF-8. As a result,
implementations MUST NOT include a charset parameter with this
media type. Although it might be possible to downconvert this
media type to the text/rfc822-header media type, such conversion
is discouraged as it loses information.
相互運用性問題: このメディアタイプがUTF-8以外のcharsetに変換されないのは、重要です。 その結果、実現はこのメディアタイプがあるcharsetパラメタを含んではいけません。 rfc822テキスト/ヘッダーメディアへのこのメディアタイプがタイプするのが、downconvertに可能であるかもしれませんが、それが情報を失うとき、そのような変換はお勧めできないです。
Published specification: RFC 5337
広められた仕様: RFC5337
Newman & Melnikov Experimental [Page 11] RFC 5337 Internationalized DSN and MDNs September 2008
[11ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
Applications that use this media type: UTF8SMTP servers and email
clients that support multipart/report generation or parsing.
このメディアタイプを使用するアプリケーション: 複合/レポート作成か構文解析を支持するUTF8SMTP serversとメールクライアント。
Additional information:
追加情報:
Magic number(s): none
マジックナンバー(s): なし
File extension(s): In the event this is saved to a file, the
extension ".u8hdr" is suggested.
ファイル拡張子(s): 出来事では、これはファイルに保存されて、拡大".u8hdr"は示されます。
Macintosh file type code(s): The 'TEXT' type code is suggested as
files of this type are typically used for diagnostic purposes and
suitable for analysis in a UTF-8 aware text editor. A uniform
type identifier (UTI) of "public.utf8-email-message-header" is
suggested. This type conforms to "public.utf8-plain-text" and
"public.plain-text".
マッキントッシュファイルタイプは(s)をコード化します: このタイプのファイルが診断目的に通常使用されていてUTF-8の意識しているテキストエディタでの分析に適しているので、'TEXT'タイプコードは示されます。 「public.utf8メールメッセージヘッダー」の一定のタイプ識別子(UTI)は示されます。 このタイプは「public.utf8-プレーンテキスト」と"public.plain-text"に従います。
Person & email address to contact for further information: See the
Authors' Addresses section of this document.
詳細のために連絡する人とEメールアドレス: AuthorsのこのドキュメントのAddresses部を見てください。
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage: This media type contains textual data in the
UTF-8 charset. It typically contains octets with the 8th bit set.
As a result, a transfer encoding is required when a 7-bit
transport is used.
用法における制限: このメディアタイプはUTF-8 charsetに原文のデータを含んでいます。 それは8番目のビットセットによる八重奏を通常含んでいます。 7ビットの輸送が使用されているとき、その結果、転送コード化が必要です。
Author: See the Authors' Addresses section of this document.
以下を書いてください。 AuthorsのこのドキュメントのAddresses部を見てください。
Change controller: IETF Standards Process
コントローラを変えてください: IETF標準化過程
6.4. message/global-delivery-status
6.4. グローバルな配送メッセージ/状態
Type name: message
型名: メッセージ
Subtype name: global-delivery-status
Subtypeは以下を命名します。 グローバルな配送状態
Required parameters: none
必要なパラメタ: なし
Optional parameters: none
任意のパラメタ: なし
Encoding considerations: This media type contains delivery status
notification attributes in the UTF-8 charset. The 8-bit content
transfer encoding MUST be used with this content-type, unless it
is sent over a 7-bit transport environment in which case quoted-
printable or base64 may be necessary.
問題をコード化します: このメディアタイプはUTF-8 charsetに配送状態通知属性を含んでいます。 または、このcontent typeと共に8ビットの満足している転送コード化を使用しなければなりません、それが引用されたどの場合に7ビットの輸送環境の上に送られないか場合印刷可能である、base64が必要であるかもしれません。
Security considerations: See Section 7
セキュリティ問題: セクション7を見てください。
Newman & Melnikov Experimental [Page 12] RFC 5337 Internationalized DSN and MDNs September 2008
[12ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
Interoperability considerations: This media type provides
functionality similar to the message/delivery-status content-type
for email message return information. Clients of the previous
format will need to be upgraded to interpret the new format;
however, the new media type makes it simple to identify the
difference.
相互運用性問題: このメディアタイプはメールメッセージリターン情報に、配送メッセージ/状態content typeと同様の機能性を提供します。 前の形式のクライアントは、新しい形式を解釈するためにアップグレードする必要があるでしょう。 しかしながら、ニューメディアタイプは違いを特定するのを簡単にします。
Published specification: RFC 5337
広められた仕様: RFC5337
Applications that use this media type: SMTP servers and email
clients that support delivery status notification generation or
parsing.
このメディアタイプを使用するアプリケーション: 配送状態が通知世代か構文解析であるとサポートするSMTPサーバーとメールクライアント。
Additional information:
追加情報:
Magic number(s): none
マジックナンバー(s): なし
File extension(s): The extension ".u8dsn" is suggested.
ファイル拡張子(s): 拡大".u8dsn"は示されます。
Macintosh file type code(s): A uniform type identifier (UTI) of
"public.utf8-email-message-delivery-status" is suggested. This
type conforms to "public.utf8-plain-text".
マッキントッシュファイルタイプは(s)をコード化します: 「public.utf8メールメッセージ配送状態」の一定のタイプ識別子(UTI)は示されます。 このタイプは「public.utf8-プレーンテキスト」に従います。
Person & email address to contact for further information: See the
Authors' Addresses section of this document.
詳細のために連絡する人とEメールアドレス: AuthorsのこのドキュメントのAddresses部を見てください。
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage: This is expected to be the second part of a
multipart/report.
用法における制限: これは複合/レポートの第二部であると予想されます。
Author: See the Authors' Addresses section of this document.
以下を書いてください。 AuthorsのこのドキュメントのAddresses部を見てください。
Change controller: IETF Standards Process
コントローラを変えてください: IETF標準化過程
6.5. message/global-disposition-notification
6.5. グローバルな気質メッセージ/通知
Type name: message
型名: メッセージ
Subtype name: global-disposition-notification
Subtypeは以下を命名します。 グローバルな気質通知
Required parameters: none
必要なパラメタ: なし
Optional parameters: none
任意のパラメタ: なし
Newman & Melnikov Experimental [Page 13] RFC 5337 Internationalized DSN and MDNs September 2008
[13ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
Encoding considerations: This media type contains disposition
notification attributes in the UTF-8 charset. The 8-bit content
transfer encoding MUST be used with this content-type, unless it
is sent over a 7-bit transport environment in which case quoted-
printable or base64 may be necessary.
問題をコード化します: このメディアタイプはUTF-8 charsetに気質通知属性を含んでいます。 または、このcontent typeと共に8ビットの満足している転送コード化を使用しなければなりません、それが引用されたどの場合に7ビットの輸送環境の上に送られないか場合印刷可能である、base64が必要であるかもしれません。
Security considerations: See Section 7.
セキュリティ問題: セクション7を見てください。
Interoperability considerations: This media type provides
functionality similar to the message/disposition-notification
content-type for email message disposition information. Clients
of the previous format will need to be upgraded to interpret the
new format; however, the new media type makes it simple to
identify the difference.
相互運用性問題: このメディアタイプはメールメッセージ気質情報に、気質メッセージ/通知content typeと同様の機能性を提供します。 前の形式のクライアントは、新しい形式を解釈するためにアップグレードする必要があるでしょう。 しかしながら、ニューメディアタイプは違いを特定するのを簡単にします。
Published specification: RFC 5337
広められた仕様: RFC5337
Applications that use this media type: Email clients or servers that
support message disposition notification generation or parsing.
このメディアタイプを使用するアプリケーション: そのサポートメッセージ気質通知世代か構文解析をクライアントかサーバにメールしてください。
Additional information:
追加情報:
Magic number(s): none
マジックナンバー(s): なし
File extension(s): The extension ".u8mdn" is suggested.
ファイル拡張子(s): 拡大".u8mdn"は示されます。
Macintosh file type code(s): A uniform type identifier (UTI) of
"public.utf8-email-message-disposition-notification" is suggested.
This type conforms to "public.utf8-plain-text".
マッキントッシュファイルタイプは(s)をコード化します: 「public.utf8メールメッセージ気質通知」の一定のタイプ識別子(UTI)は示されます。 このタイプは「public.utf8-プレーンテキスト」に従います。
Person & email address to contact for further information: See the
Authors' Addresses section of this document.
詳細のために連絡する人とEメールアドレス: AuthorsのこのドキュメントのAddresses部を見てください。
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage: This is expected to be the second part of a
multipart/report.
用法における制限: これは複合/レポートの第二部であると予想されます。
Author: See the Authors' Addresses section of this document.
以下を書いてください。 AuthorsのこのドキュメントのAddresses部を見てください。
Change controller: IETF Standards Process
コントローラを変えてください: IETF標準化過程
Newman & Melnikov Experimental [Page 14] RFC 5337 Internationalized DSN and MDNs September 2008
[14ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
7. Security Considerations
7. セキュリティ問題
Automated use of report types without authentication presents several security issues. Forging negative reports presents the opportunity for denial-of-service attacks when the reports are used for automated maintenance of directories or mailing lists. Forging positive reports may cause the sender to incorrectly believe a message was delivered when it was not.
認証のないレポートタイプの自動化された使用はいくつかの安全保障問題を提示します。 レポートがディレクトリかメーリングリストの自動化されたメインテナンスに使用されるとき、否定的な報告を偽造すると、サービス不能攻撃の機会は提示されます。 それが信じていなかったとき、積極的なレポートを偽造するのに、送付者は、メッセージが提供されたと不当に信じるかもしれません。
Malicious users can generate report structures designed to trigger coding flaws in report parsers. Report parsers need to use secure coding techniques to avoid the risk of buffer overflow or denial-of- service attacks against parser coding mistakes. Code reviews of such parsers are also recommended.
悪意あるユーザーはレポートパーサでコード化欠点の引き金となるように設計されたレポート構造を生成することができます。 レポートパーサが、バッファオーバーフローか否定の危険を避けるのに安全なコーディング技法を使用する必要がある、-、-サービスはパーサコード化誤りに対して攻撃されます。 また、そのようなパーサのコードレビューもお勧めです。
Malicious users of the email system regularly send messages with forged envelope return paths, and these messages trigger delivery status reports that result in a large amount of unwanted traffic on the Internet. Many users choose to ignore delivery status notifications because they are usually the result of "blowback" from forged messages and thus never notice when messages they sent go undelivered. As a result, support for correlation of delivery status and message disposition notification messages with sent-messages has become a critical feature of mail clients and possibly mail stores if the email infrastructure is to remain reliable. In the short term, simply correlating message-IDs may be sufficient to distinguish true status notifications from those resulting from forged originator addresses. But in the longer term, including cryptographic signature material that can securely associate the status notification with the original message is advisable.
メールシステムの悪意あるユーザーは、定期的に偽造封筒リターンがあるメッセージに経路を送って、インターネットで多量の求められていないトラフィックをもたらす引き金の配送現状報告をこれらのメッセージに送ります。 多くのユーザが、それらが通常偽造メッセージからの「ガス圧利用」の結果であるので配送状態通知を無視して、その結果、それらが送ったメッセージがいつ非提供されているのに行くかに決して気付かないのを選びます。 その結果、メールインフラストラクチャが信頼できたままで残るつもりであるなら、送信されたメッセージがある配送状態とメッセージ気質通知メッセージの相関関係のサポートはメールクライアントとことによるとメール店のきわどい特徴になりました。 短期で、メッセージIDを単に関連させるのは、偽造創始者アドレスから生じるものと本当の状態通知を区別するために十分であるかもしれません。 しかし、より長い期間で、しっかりと状態通知をオリジナルのメッセージに関連づけることができる暗号の署名の材料を含んでいるのは賢明です。
As this specification permits UTF-8 in additional fields, the security considerations of UTF-8 [RFC3629] apply.
この仕様が追加分野でUTF-8を可能にするとき、UTF-8[RFC3629]のセキュリティ問題は適用されます。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
Newman & Melnikov Experimental [Page 15] RFC 5337 Internationalized DSN and MDNs September 2008
[15ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status Notifications
(DSNs)", RFC 3461, January 2003.
[RFC3461]ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。
[RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for
the Reporting of Mail System Administrative Messages",
RFC 3462, January 2003.
[RFC3462] ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポートcontent type」、RFC3462、2003年1月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications", RFC 3464,
January 2003.
[RFC3464] ムーアとK.とG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[RFC3798] ハンセン、T.、およびG.ボードルイ(「メッセージ気質通知」、RFC3798)は2004がそうするかもしれません。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年1月。
[RFC5335] Yang, A., Ed., "Internationalized Email Headers",
RFC 5335, September 2008.
[RFC5335] 陽、A.、エド、「国際化しているメールヘッダー」、RFC5335、9月2008日
[RFC5336] Yao, J., Ed. and W. Mao, Ed., "SMTP Extension for
Internationalized Email Addresses", RFC 5336,
September 2008.
エド[RFC5336]八尾、J.、W.マオ、エド、「国際化しているEメールアドレスのためのSMTP拡張子」、RFC5336、9月2008日
[LANGTAGS] Phillips, A. and M. Davis, "Tags for Identifying
Languages", RFC 4646, September 2006.
フィリップス(A.とM.デイヴィス)が「言語を特定するためにタグ付けをする」[LANGTAGS]、RFC4646、2006年9月。
[DEFAULTLANG] Alvestrand, H., "IETF Policy on Character Sets and
Languages", RFC 2277, January 1998.
[DEFAULTLANG] Alvestrand、H.、「文字コードと言語に関するIETF方針」、RFC2277、1998年1月。
8.2. Informative References
8.2. 有益な参照
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types",
RFC 2046, November 1996.
解放された[RFC2046]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[DOWNGRADE] Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for
Email Address Internationalization", Work in Progress,
July 2008.
[DOWNGRADE] フジワラとK.とY.Yoneya、「メールAddress Internationalizationのためにメカニズムを格下げします」、Progress、2008年7月のWork。
Newman & Melnikov Experimental [Page 16] RFC 5337 Internationalized DSN and MDNs September 2008
[16ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
Appendix A. Acknowledgements
付録A.承認
Many thanks for input provided by Pete Resnick, James Galvin, Ned Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, and members of the EAI WG to help solidify this proposal.
ピートレズニック、ジェームス・ガルビン、ネッド・フリード、ジョンKlensin、ハラルドAlvestrand、フランクEllermann、SM、およびメンバーによって提供された入力のためにこの提案を固めるのを助けるEAI WGについてありがとうございます。
Authors' Addresses
作者のアドレス
Chris Newman Sun Microsystems 800 Royal Oaks Monrovia, CA 91016-6347 US
ロイヤルクリスニューマンサン・マイクロシステムズ800Oaksカリフォルニア91016-6347モンロヴィア(米国)
EMail: chris.newman@sun.com
メール: chris.newman@sun.com
Alexey Melnikov (editor) Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexeyメリニコフ(エディタ)Isode Ltd5城のビジネス村の36駅のRoadハンプトン、ミドルセックスTW12 2BXイギリス
EMail: Alexey.Melnikov@isode.com
メール: Alexey.Melnikov@isode.com
Newman & Melnikov Experimental [Page 17] RFC 5337 Internationalized DSN and MDNs September 2008
[17ページ]のRFC5337の国際化しているDSNとMDNs2008年9月に実験的なニューマンとメリニコフ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Newman & Melnikov Experimental [Page 18]
ニューマンとメリニコフExperimentalです。[18ページ]
一覧
スポンサーリンク
