[要約] RFC 6533は、国際化された配信状況と処理通知に関する標準仕様です。このRFCの目的は、電子メールの配信状況と処理結果を国際化に対応させるための方法を提供することです。
Internet Engineering Task Force (IETF) T. Hansen, Ed.
Request for Comments: 6533 AT&T Laboratories
Obsoletes: 5337 C. Newman
Updates: 3461, 3464, 3798, 6522 Oracle
Category: Standards Track A. Melnikov
ISSN: 2070-1721 Isode Ltd
February 2012
Internationalized Delivery Status and Disposition Notifications
国際化された配送状況と処分通知
Abstract
概要
Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3464, RFC 6522) are presently limited to 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-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）は、電子メールシステムの正しい操作に重要です。ただし、既存のドラフト標準（RFC 3461、RFC 3464、RFC 6522）は、現在、プロトコルの機械可読部分のASCIIテキストに限定されています。この仕様には、国際的な電子メールアドレスの新しいアドレスタイプが追加されるため、ASCII以外の文字を持つオリジナルの受信者アドレスは、ダウングレード後も正しく保存できます。これにより、新しいアドレスタイプの使用をサポートするために、配信ステータス通知とメッセージ処分通知の更新されたコンテンツリターンメディアタイプも提供します。
This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522.
このドキュメントは、RFC 3461、RFC 3464、RFC 3798、およびRFC 6522を拡張します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6533.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6533で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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. The message/global-delivery-status Media Type . . . . . . 6
4.2. The message/global Media Type . . . . . . . . . . . . . . 8
4.3. The message/global-headers Media Type . . . . . . . . . . 8
4.4. Using These Media Types with multipart/report . . . . . . 8
4.5. Additional Requirements on SMTP Servers . . . . . . . . . 9
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 . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Changes since RFC 5337 . . . . . . . . . . . . . . . 18
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18
When an email message is transmitted using the SMTPUTF8 [RFC6531] extension and Internationalized Email Headers [RFC6532], 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.
SMTPUTF8 [RFC6531]拡張機能と国際化された電子メールヘッダー[RFC6532]を使用して電子メールメッセージを送信すると、そのメッセージを返したり、メッセージ処分通知（MDN）[RFC3798]を生成する必要があります。複数の受信者に送信されたメッセージが各受信者のステータスと気質通知を生成できるため、クライアントが提供された受信者アドレスに基づいてこれらの通知を相関させることができれば役立ちます。したがって、元の受信者の保存が重要です。この仕様には、元の受信者を保存する方法について説明し、MDNおよびDSN形式を更新して新しいアドレスタイプをサポートします。
NOTE: While this specification updates the experimental versions of this protocol by removing certain constructs (e.g., the "<addr <addr>>" address syntax is no longer permitted), the name of the Address Type "UTF-8" and the media type names message/global, message/global-delivery-status, and message/global-headers have not been changed.
注：この仕様は、特定のコンストラクトを削除してこのプロトコルの実験バージョンを更新しますが（例：「<addr <addr >>」アドレス構文は許可されなくなりました）、アドレスタイプ「UTF-8」の名前とメディアタイプ名メッセージ/グローバル、メッセージ/グローバルデリバリーステータス、およびメッセージ/グローバルヘッダーは変更されていません。
This specification is a revision of and replacement for [RFC5337]. Section 6 of [RFC6530] describes the change in approach between this specification and the previous version.
この仕様は、[RFC5337]の改訂と交換です。[RFC6530]のセクション6では、この仕様と以前のバージョンの間のアプローチの変更について説明します。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation including the core rules defined in Appendix B of [RFC5234] and the UTF-8 syntax rules in Section 4 of [RFC3629].
正式な構文では、[RFC5234]の付録Bで定義されているコアルールと[RFC3629]セクション4のUTF-8構文規則を含む、拡張されたバックスノールフォーム（ABNF）[RFC5234]表記を使用します。
"An Extensible Message Format for Delivery Status Notifications" [RFC3464] defines the concept of an address type. The address format introduced in "Internationalized Email Headers" [RFC6532] 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.
「配信ステータス通知の拡張可能なメッセージ形式」[RFC3464]は、アドレスタイプの概念を定義します。「国際化された電子メールヘッダー」[RFC6532]で導入されたアドレス形式は、新しいアドレスタイプです。ステータス通知のコンテキストでの新しいアドレスタイプの構文は、このセクションの最後に指定されています。
An SMTP [RFC5321] server that advertises both the SMTPUTF8 extension [RFC6531] 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 SMTPUTF8.
SMTPUTF8拡張機能[RFC6531]とDSN拡張機能[RFC3461]の両方を宣伝するSMTP [RFC5321]サーバーは、8ビットUTF-8文字を含むORCPTパラメーターのUTF-8アドレスタイプを受け入れる必要があります。このアドレスタイプには、メッセージ/配信ステータスボディパーツでの使用に適した7ビットエンコードまたはSMTPUTF8を宣伝しないSMTPサーバーに送信されたORCPTパラメーターも含まれています。
This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext, and utf-8-address. Only the first form is 7-bit safe (only uses ASCII characters [ASCII]).
このアドレスタイプには、UTF-8-ADDR-XTEXT、UTF-8-ADDR-UNITEXT、およびUTF-8-ADDRESSの3つのフォームがあります。最初のフォームのみが7ビットセーフです（ASCII文字[ASCII]のみを使用します）。
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:
UTF-8-Addressフォームは、8ビット文字のネイティブ表現が可能な新たに定義されたプロトコルでの使用にのみ適しています。つまり、UTF-8-Addressフォームを使用してはなりません。
1. in the ORCPT parameter when the SMTP server doesn't advertise support for SMTPUTF8 (utf-8-addr-xtext MUST be used instead); or
1. SMTPサーバーがSMTPUTF8のサポートを宣伝しないORCPTパラメーターでまた
2. if the SMTP server supports SMTPUTF8, but the address contains ASCII characters not permitted in the ORCPT parameter (e.g., the ORCPT parameter forbids unencoded SP and the '=' character), (either utf-8-addr-unitext or utf-8-addr-xtext MUST be used instead); or
2. SMTPサーバーがSMTPUTF8をサポートしているが、アドレスにORCPTパラメーターで許可されていないASCII文字が含まれている場合（たとえば、ORCPTパラメーターはENCODED SPおよび '='文字を禁止しています）（UTF-8-ADDR-UnitextまたはUTF-8-のいずれか代わりにaddr-xtextを使用する必要があります）;また
3. in a 7-bit transport environment including a message/ delivery-status "Original-Recipient:" or "Final-Recipient:" field, (utf-8-addr-xtext MUST be used instead).
3. メッセージ/配信ステータス「Original-Recipient：」または「Final-Recipient：」フィールドを含む7ビット輸送環境では、（代わりにUTF-8-ADDR-XTEXTを使用する必要があります）。
The utf-8-address form MAY be used in the ORCPT parameter when the SMTP server also advertises support for SMTPUTF8 and the address doesn't contain any 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 SMTPUTF8 message.
SMTPサーバーがSMTPUTF8のサポートも宣伝する場合、UTF-8-AddressフォームはORCPTパラメーターで使用できます。メッセージ/Global-Divery-Status「Original-Recipient：」または「final-Recipient：」DSNフィールド、または「Original-Recipient：」というメッセージがSMTPUTF8メッセージの場合は、「Original-Recipient：」ヘッダーフィールド[RFC3798]で使用する必要があります。。
In addition, the utf-8-addr-unitext form can be used anywhere where the utf-8-address form is allowed.
さらに、UTF-8-Addressフォームが許可される場所では、UTF-8-ADDR-Unitextフォームをどこでも使用できます。
When used in the ORCPT parameter, the UTF-8 address type requires that ASCII CTLs, SP, '\', '+', and '=' be encoded using 'unitext' encoding (see below). This is described by the utf-8-addr-xtext and utf-8-addr-unitext forms in the ABNF below. The 'unitext' encoding uses "\x{HEXPOINT}" syntax (EmbeddedUnicodeChar in the ABNF below) for encoding any Unicode character outside of ASCII range, as well as for encoding CTLs, SP, '\', '+', and '='. HEXPOINT is 2 to 6 hexadecimal digits. This encoding avoids the need to use the xtext encoding described in [RFC3461], as any ASCII characters that need to be escaped using xtext encoding never appear in any unitext-encoded string. When sending data to a SMTPUTF8-capable server, native UTF-8 characters SHOULD be used instead of the EmbeddedUnicodeChar syntax described below. When sending data to an SMTP server that does not advertise SMTPUTF8, then the EmbeddedUnicodeChar syntax MUST be used instead of UTF-8.
ORCPTパラメーターで使用する場合、UTF-8アドレスタイプでは、ASCII CTLS、sp、 '\'、 ''、および '='が「unitext」エンコードを使用してエンコードする必要があります（以下を参照）。これは、以下のABNFにあるUTF-8-ADDR-XTEXTおよびUTF-8-ADDR-UNITEXTフォームによって説明されています。「unitext」エンコーディングは、ascii範囲外のユニコード文字をエンコードするために、 "\ x {hexpoint}" syntax（下のabnfの埋め込み式）を使用します。'。Hexpointは2〜6匹の16進数桁です。このエンコードは、[RFC3461]で説明されているXTEXTエンコードを使用する必要性を回避します。XTEXTエンコードを使用して逃げる必要があるASCII文字は、unitextエンコード文字列には表示されないためです。SMTPUTF8対応サーバーにデータを送信する場合、以下に説明するEmbedDunicodeChar構文の代わりに、ネイティブUTF-8文字を使用する必要があります。SMTPUTF8を宣伝していないSMTPサーバーにデータを送信する場合、UTF-8の代わりにEmbedDunicodeChar構文を使用する必要があります。
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 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パラメーターがメッセージ/ Global-Divery-Status「Original-Recipient：」に配置されている場合、UTF-8アドレスタイプのUTF-8-ADDR-XTEXTフォームはUTF-8-Addressフォームに変換する必要があります（以下のABNFを参照）unitextエンコードを削除します。ただし、アドレスにUTF-8アドレスタイプにラベルが付けられているが、UTF-8構文に準拠していない場合、変更せずにメッセージ/グローバル配信ステータスフィールドにコピーする必要があります。
The ability to encode characters with the EmbeddedUnicodeChar encodings should be viewed as a transitional mechanism and avoided when possible. It is hoped that as systems lacking support for SMTPUTF8 become less common over time, these encodings can eventually be phased out.
EmbedDunicodeCharエンコーディングで文字をエンコードする機能は、移行メカニズムと見なされ、可能な場合は回避する必要があります。SMTPUTF8のサポートがないシステムが時間とともに一般的ではなくなるにつれて、これらのエンコードが最終的に段階的に廃止されることが期待されています。
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]の付録B、[RFC3629]のセクション4、または[RFC3464]で定義されています。
utf-8-type-addr = "utf-8;" utf-8-enc-addr
UTF-8-TYPE-ADDR = "UTF-8;"UTF-8-ENC-ADDR
utf-8-address = Mailbox ; Mailbox as defined in [RFC6531].
UTF-8-ADDRESS = MailBox;[RFC6531]で定義されているメールボックス。
utf-8-enc-addr = utf-8-addr-xtext / utf-8-addr-unitext / utf-8-address
UTF-8-ENC-ADDR = UTF-8-ADDR-XTEXT / UTF-8-ADDR-UNITEXT / UTF-8-ADDRESS
utf-8-addr-xtext = 1*(QCHAR / EmbeddedUnicodeChar)
; 7bit form of utf-8-addr-unitext.
; Safe for use in the ORCPT [RFC3461]
; parameter even when SMTPUTF8 SMTP
; extension is not advertised.
utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar)
; MUST follow utf-8-address ABNF when
; dequoted.
; Safe for using in the ORCPT [RFC3461]
; parameter when SMTPUTF8 SMTP extension
; is also advertised.
QCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e
; ASCII printable characters except
; CTLs, SP, '\', '+', '='.
QUCHAR = QCHAR / UTF8-2 / UTF8-3 / UTF8-4
; ASCII printable characters except
; CTLs, SP, '\', '+' and '=', plus
; other Unicode characters encoded in UTF-8
EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}"
; starts with "\x"
HEXPOINT = ( ( "0"/"1" ) %x31-39 ) / "10" / "20" /
"2B" / "3D" / "7F" / ; all xtext-specials
"5C" / (HEXDIG8 HEXDIG) / ; 2-digit forms
( NZHEXDIG 2(HEXDIG) ) / ; 3-digit forms
( NZDHEXDIG 3(HEXDIG) ) / ; 4-digit forms excluding
( "D" %x30-37 2(HEXDIG) ) / ; ... surrogate
( NZHEXDIG 4(HEXDIG) ) / ; 5-digit forms
( "10" 4*HEXDIG ) ; 6-digit forms
; represents either "\" or a Unicode code point outside
; the ASCII repertoire
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"
A traditional delivery status notification [RFC3464] comes in a three-part multipart/report [RFC6522] 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 standard DSN format does not permit the return of undeliverable SMTPUTF8 messages, three new media types have been defined. ([RFC5337] introduced experimental versions of these media types.)
従来の配信ステータス通知[RFC3464]には、3部構成のマルチパート/レポート[RFC6522]コンテナがあります。最初の部分はエラーを説明する人間の読み取り可能なテキストです。2番目の部分は7ビットのみのメッセージ/配信ステータスです、およびオプションの3番目の部分は、コンテンツ（メッセージ/RFC822）またはヘッダー（TEXT/RFC822-HEADERS）リターンに使用されます。現在の標準のDSN形式では、配信不可能なSMTPUTF8メッセージの返品が許可されていないため、3つの新しいメディアタイプが定義されています。（[RFC5337]は、これらのメディアタイプの実験バージョンを導入しました。）
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 SMTPUTF8 [RFC6531]; the "Diagnostic-Code:" field SHOULD be in i-default language [RFC2277]. Second, systems generating a message/global-delivery-status body part SHOULD use the utf-8-address
最初のタイプであるメッセージ/グローバル配信ステータスには、3つの変更を伴うメッセージ/配信ステータスの構文があります。まず、メッセージ/グローバル配信ステータスのcharsetはutf-8です。したがって、どのフィールドにも必要な場合はUTF-8文字が含まれる場合があります（以下のABNFを参照）。特に、「診断コード：」フィールドには、SMTPUTF8 [RFC6531]に記載されているようにUTF-8が含まれる場合があります。「診断コード：」フィールドはi-default言語[RFC2277]である必要があります。第二に、メッセージを生成するシステム/グローバルデリバリーステータスボディパーツは、UTF-8-Addressを使用する必要があります
form of the UTF-8 address type for all addresses containing characters outside the 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, an optional field called "Localized-Diagnostic:" is added. Each instance includes a language tag [RFC5646] 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.
ASCIIレパートリー以外の文字を含むすべてのアドレスのUTF-8アドレスタイプの形式。これらのシステムは、UTF-8アドレスタイプのUTF-8-ADDR-UNITEXTフォームのUTF-8-ADDRESSフォームのUTF-8アドレス形式のUTF-8アドレスタイプにUTF-8-ADDR-XTEXTまたはUTF-8-ADDR-UNITEXT形式をアップする必要があります。「オリジナルレシピエント：」フィールド。第三に、「ローカライズされた診断：」と呼ばれるオプションのフィールドが追加されます。各インスタンスには言語タグ[RFC5646]が含まれており、指定された言語にテキストが含まれています。これは、「診断コード：」フィールドのテキスト部分と同等です。「ローカライズされた診断：」のすべてのインスタンスは、異なる言語タグを使用する必要があります。メッセージ/グローバル配信ステータスの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]. Note that <text-fixed> is the same as <text> from [RFC5322], but without <obs-text>. If or when RFC 5322 is updated to disallow <obs-text>, <text-fixed> should become just <text>. Also, if or when RFC 5322 is updated to disallow control characters in <text>, <text-fixed> should become a reference to that update instead.
以下のABNFでは、このドキュメントで定義されていないすべてのプロダクションは、[RFC5234]の付録B、[RFC3629]のセクション4、または[RFC3464]で定義されています。<Text-Fixed>は[RFC5322]の<text>と同じですが、<obs-text>はありません。RFC 5322が更新されて<Obstext>を許可するように更新された場合、<Text-Fixed>は<text>になるはずです。また、RFC 5322が更新されて、<text>で制御文字を許可するように更新された場合、<text-fixed>は代わりにその更新への参照になるはずです。
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.
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 ]
[ final-log-id-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.
generic-address =/ utf-8-enc-addr
; Only allowed with the "utf-8" address-type.
; Updates Section 3.2.3 of RFC 3798.
;
; This indirectly updates "original-recipient-field"
; and "final-recipient-field".
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 [RFC5646].
locialized-diagnostic-text-field = "locialized-diagnostic" "：" Language-tag ";"*utf8-text;「言語タグ」は、[RFC5646]で定義されている言語タグです。
extension-field =/ extension-field-name ":" *utf8-text
; Updates Section 7 of RFC3798
text-fixed = %d1-9 / ; Any ASCII character except for NUL,
%d11 / ; CR, and LF.
%d12 / ; See note above about <text-fixed>
%d14-127
utf8-text = text-fixed / UTF8-non-ascii
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
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 [RFC6532].
コンテンツの返品に使用される2番目のタイプは、メッセージ/グローバルであり、これはメッセージ/RFC822に似ていますが、UTF-8ヘッダーを含むメッセージが含まれています。このメディアタイプは[RFC6532]で説明されています。
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 SMTPUTF8 message). Unlike message/global, this body part provides no difficulties for the present infrastructure.
ヘッダーの返却に使用される3番目のタイプは、メッセージ/グローバルヘッダーであり、メッセージのUTF-8ヘッダーフィールドのみが含まれています（SMTPUTF8メッセージの最初の空白行の前のすべての行）。メッセージ/グローバルとは異なり、この身体部分は現在のインフラストラクチャに困難を与えません。
Note that as far as a multipart/report [RFC6522] 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,
マルチパート/レポート[RFC6522]コンテナに関する限り、メッセージ/グローバル配信ステータス、メッセージ/グローバル、およびメッセージ/グローバルヘッダーは、メッセージ/配信ステータス、メッセージ/RFC822に相当するものとして扱わなければならないことに注意してください。およびText/RFC822-Headers。あれは、
implementations processing multipart/report MUST expect any combinations of the 6 media types mentioned above inside a multipart/ report media type.
実装の処理マルチパート/レポートは、マルチパート/レポートメディアタイプ内に上記の6つのメディアタイプの組み合わせを期待する必要があります。
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 a 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 [RFC6532] relaxed a restriction from MIME [RFC2046] regarding the use of Content-Transfer-Encoding in new "message" subtypes. This specification explicitly allows the use of Content-Transfer-Encoding in message/global-headers and message/ global-delivery-status. This is not believed to be problematic as these new media types are intended primarily for use by newer systems with full support for 8-bit MIME and UTF-8 headers.
通常、3つの新しいタイプはすべて、「8ビット」コンテンツ転送エンコードを使用します。（すべてのコンテンツが7ビットである場合、配信ステータス通知に相当する従来のタイプが使用される場合があります。たとえば、メッセージ/グローバルデリバリーステータスパーツの情報をメッセージ/配信として情報を損なうことなく表現できる場合-STATUS、次に、メッセージ/配信ステータス本体の部分を使用できます。）[RFC6532]は、新しい「メッセージ」サブタイプでのコンテンツ転送エンコードの使用に関してMIME [RFC2046]からの制限を緩和したことに注意してください。この仕様により、メッセージ/グローバルヘッダーとメッセージ/グローバルデリバリーステータスでのコンテンツ転送エンコードを明示的に使用できます。これらの新しいメディアタイプは、主に8ビットMIMEおよびUTF-8ヘッダーを完全にサポートする新しいシステムが使用することを目的としているため、これは問題があるとは考えられていません。
If an SMTP server that advertises both SMTPUTF8 and DSN needs to return an undeliverable SMTPUTF8 message, then it has two choices for encapsulating the SMTPUTF8 message when generating the corresponding multipart/report:
SMTPUTF8とDSNの両方を宣伝するSMTPサーバーが、配信不可能なSMTPUTF8メッセージを返す必要がある場合、対応するMultiPART/レポートを生成するときにSMTPUTF8メッセージをカプセル化するための2つの選択肢があります。
If the return-path SMTP server does not support SMTPUTF8, 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.
Return-Path SMTPサーバーがSMTPUTF8をサポートしていない場合、リラバレイ不可能なボディパーツとヘッダーは、「base64」や「Quoted-Printable」[RFC2045]などの7ビットコンテンツ転送エンコードを使用してエンコードする必要があります。セクション4。
Otherwise, "8bit" Content-Transfer-Encoding can be used.
それ以外の場合、「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
メッセージ処分通知[RFC3798]は、DSNSと同様の設計と構造を持っています。その結果、同じ基本的な返品形式を使用します。UTF-8ヘッダーメッセージのMDNを生成する場合、MultiPart/レポートの第3部には、DSNSと同じように、返されたコンテンツ（メッセージ/グローバル）またはヘッダー（メッセージ/グローバルヘッダー）が含まれます。MultiPart/レポートの2番目の部分では、新しいメディアタイプ、メッセージ/グローバル配置 - 解釈を使用しています。これには、2つの変更を伴うメッセージ/気質 - 解釈の構文があります。まず、メッセージ/グローバルディスポジションノティフィケーションのcharsetはutf-8です。したがって、どのフィールドにも必要な場合はUTF-8文字が含まれる場合があります（以下のABNFを参照）。（特に、故障フィールド、エラーフィールド、および警告場にはUTF-8が含まれている可能性があります。これらのフィールドはi-defaultにある必要があります
language [RFC2277].) 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 ASCII repertoire.
言語[RFC2277]。）第二に、メッセージ/グローバル - 分散型 - ノティフィケーションボディパーツ（通常はメールユーザーエージェント）を生成するシステムは、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-Recipient：」ヘッダーフィールドも定義します。ヘッダーフィールドは、配信時にORCPTの内容のコピーが追加されています。「Original-Recipient：」ヘッダーフィールドを生成する場合、ネイティブ形式でUTF-8ヘッダーメッセージを書くデリバリーエージェントは、UTF-8-ADDR-XTEXTまたはUTF-8-ADDR-UNITEXT形式を変換する必要があります。ORCPTパラメーターのアドレスタイプは、対応するUTF-8-Addressフォームに。
The MDN specification also defines the "Disposition-Notification-To:" header field, which is an address header field and thus follows the same 8-bit rules as other address header fields such as "From:" and "To:" when used in a UTF-8 header message.
MDN仕様は、「気質 - notification-to」ヘッダーフィールドを定義します。これはアドレスヘッダーフィールドであるため、「from：」や「to：」などの他のアドレスヘッダーフィールドと同じ8ビットルールに従います。UTF-8ヘッダーメッセージ。
; 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.
failure-field = "Failure" ":" *utf8-text ; "utf8-text" is defined in Section 4 of this document.
faily-field = "fails" "：" *utf8-text;「UTF8-Text」は、このドキュメントのセクション4で定義されています。
error-field = "Error" ":" *utf8-text ; "utf8-text" is defined in Section 4 of this document.
error-field = "error" "：" *utf8-text;「UTF8-Text」は、このドキュメントのセクション4で定義されています。
warning-field = "Warning" ":" *utf8-text ; "utf8-text" is defined in Section 4 of this document.
Warning-field = "警告" "：" *utf8-text;「UTF8-Text」は、このドキュメントのセクション4で定義されています。
This specification does not create any new IANA registries. However, the following items have been registered as a result of this document.
この仕様では、新しいIANAレジストリは作成されません。ただし、このドキュメントの結果として、次の項目が登録されています。
The mail address type registry was created by [RFC3464]. The registration template response follows:
メールアドレスタイプレジストリは[RFC3464]によって作成されました。登録テンプレート応答は次のとおりです。
(a) The 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 ASCII repertoire, a specification for how they are to be encoded as graphic ASCII characters in an "Original-Recipient:" or "Final-Recipient:" DSN field.
(c) このタイプのアドレスがASCIIレパートリーのグラフィック文字で完全に構成されていない場合、「オリジナルレシピエント」または「最終的なレシピエント：」DSNフィールドのグラフィックASCII文字としてエンコードされる方法の仕様。
This address type has 3 forms (as defined in Section 3): utf-8-addr-xtext, utf-8-addr-unitext, and utf-8-address. Only the first form is 7-bit safe.
このアドレスタイプには、UTF-8-ADDR-XTEXT、UTF-8-ADDR-UNITEXT、およびUTF-8-ADDRESSの3つのフォーム（セクション3で定義されています）があります。最初のフォームのみが7ビットセーフです。
The mail diagnostic type registry was created by [RFC3464] and updated by [RFC5337]. This specification replaces [RFC5337]. The registration for the 'smtp' diagnostic type has been updated to reference RFC 6533 in addition to [RFC3464] and to remove the reference to [RFC5337].
メール診断タイプのレジストリは[RFC3464]によって作成され、[RFC5337]によって更新されました。この仕様は[RFC5337]を置き換えます。[SMTP]診断タイプの登録は、[RFC3464]に加えてRFC 6533を参照し、[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」診断タイプがメッセージ/ Global-Divery-Statusボディパーツのコンテキストで使用される場合、コードは同じままですが、テキスト部分にはUTF-8文字が含まれている場合があります。
Type name: message
タイプ名：メッセージ
Subtype name: global-headers
サブタイプ名：グローバルヘッダー
Required parameters: none
必要なパラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: This media type contains Internationalized Email Headers [RFC6532] 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.
考慮事項のエンコード：このメディアタイプには、メッセージ本文のない国際化された電子メールヘッダー[RFC6532]が含まれています。可能な場合はいつでも、8ビットコンテンツ転送エンコードを使用する必要があります。このメディアタイプが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 down-convert this media type to the text/rfc822-header media type, such conversion is discouraged as it loses information.
相互運用性の考慮事項：このメディアタイプがUTF-8以外のcharSetに変換されないことが重要です。その結果、実装は、このメディアタイプのcharsetパラメーターを含めてはなりません。このメディアタイプをテキスト/RFC822ヘッダーメディアタイプにダウンコンバージョンすることは可能かもしれませんが、そのような変換は情報を失って阻止されます。
Published specification: RFC 6533
公開された仕様：RFC 6533
Applications that use this media type: SMTPUTF8 servers and email clients that support multipart/report generation or parsing.
このメディアタイプを使用するアプリケーション：SMTPUTF8サーバーと、マルチパート/レポートの生成または解析をサポートするクライアントにメールします。
Additional information:
追加情報：
Magic number(s): none
マジックナンバー：なし
File extension(s): In the event this is saved to a file, the extension ".u8hdr" is suggested.
ファイル拡張子：これがファイルに保存された場合、拡張機能「.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".
Macintoshファイルタイプコード：このタイプのファイルは通常、診断目的で使用され、UTF-8を認識したテキストエディターでの分析に適しているため、「テキスト」タイプコードが提案されます。「public.utf8-email-message-header」の均一な型識別子（uti）が提案されています。このタイプは、「public.utf8-plain-text」および「public.plain-text」に準拠しています。
Person & email address to contact for further information: See the Authors' Addresses section of this document.
詳細については、個人とメールアドレスをお問い合わせください。このドキュメントの著者のアドレスセクションを参照してください。
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.
著者：このドキュメントの著者のアドレスセクションを参照してください。
Change controller: IETF Standards Process
Change Controller：IETF標準プロセス
Type name: message
タイプ名：メッセージ
Subtype name: global-delivery-status
サブタイプ名：Global-Divery-Status
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に配信ステータス通知属性が含まれています。8ビットコンテンツ転送エンコードは、7ビットの輸送環境を介して送信されない限り、このコンテンツタイプで使用する必要があります。
Security considerations: See Section 7
セキュリティ上の考慮事項：セクション7を参照してください
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.
相互運用性の考慮事項：このメディアタイプは、電子メールメッセージ返信情報のメッセージ/配信ステータスコンテンツタイプと同様の機能を提供します。以前の形式のクライアントは、新しい形式を解釈するためにアップグレードする必要があります。ただし、新しいメディアタイプにより、違いを簡単に特定できます。
Published specification: RFC 6533
公開された仕様：RFC 6533
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
マジックナンバー：なし
File extension(s): The extension ".u8dsn" is suggested.
ファイル拡張子：拡張機能 ".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".
Macintoshファイルタイプコード：「public.utf8-email-message-delivery-status」の均一なタイプ識別子（uti）が提案されています。このタイプは、「public.utf8-plain-text」に準拠しています。
Person & email address to contact for further information: See the Authors' Addresses section of this document.
詳細については、個人とメールアドレスをお問い合わせください。このドキュメントの著者のアドレスセクションを参照してください。
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This is expected to be the second part of a multipart/report.
使用法の制限：これは、マルチパート/レポートの第2部になると予想されます。
Author: See the Authors' Addresses section of this document.
著者：このドキュメントの著者のアドレスセクションを参照してください。
Change controller: IETF Standards Process
Change Controller：IETF標準プロセス
Type name: message
タイプ名：メッセージ
Subtype name: global-disposition-notification
サブタイプ名：Global-disposition-notification
Required parameters: none
必要なパラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
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に処分通知属性が含まれています。8ビットコンテンツ転送エンコードは、7ビットの輸送環境を介して送信されない限り、このコンテンツタイプで使用する必要があります。
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.
相互運用性の考慮事項：このメディアタイプは、電子メールメッセージの処分情報のメッセージ/気質 - 解釈コンテンツタイプと同様の機能を提供します。以前の形式のクライアントは、新しい形式を解釈するためにアップグレードする必要があります。ただし、新しいメディアタイプにより、違いを簡単に特定できます。
Published specification: RFC 6533
公開された仕様：RFC 6533
Applications that use this media type: Email clients or servers that support message disposition notification generation or parsing.
このメディアタイプを使用するアプリケーション：メッセージ処分通知の生成または解析をサポートするクライアントまたはサーバーに電子メールを送信します。
Additional information:
追加情報：
Magic number(s): none
マジックナンバー：なし
File extension(s): The extension ".u8mdn" is suggested.
ファイル拡張子：拡張機能 ".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".
Macintoshファイルタイプコード：「public.utf8-email-message-disposition-notification」の均一なタイプ識別子（UTI）が提案されています。このタイプは、「public.utf8-plain-text」に準拠しています。
Person & email address to contact for further information: See the Authors' Addresses section of this document.
詳細については、個人とメールアドレスをお問い合わせください。このドキュメントの著者のアドレスセクションを参照してください。
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This is expected to be the second part of a multipart/report.
使用法の制限：これは、マルチパート/レポートの第2部になると予想されます。
Author: See the Authors' Addresses section of this document.
著者：このドキュメントの著者のアドレスセクションを参照してください。
Change controller: IETF Standards Process
Change Controller：IETF標準プロセス
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.
電子メールシステムの悪意のあるユーザーは、Forged Envelope Return Pathsでメッセージを定期的に送信し、これらのメッセージはインターネット上の大量の不要なトラフィックをもたらす配信ステータスレポートをトリガーします。多くのユーザーは、通常、偽造メッセージからの「ブローバック」の結果であるため、配信ステータスの通知を無視することを選択します。その結果、電子メールインフラストラクチャが信頼できるままである場合、送信されたメッセージとの伝達ステータスとメッセージ処分通知メッセージのサポートは、メールクライアントと場合によってはメールストアの重要な機能になりました。短期的には、単純に相関するメッセージIDでは、真のステータス通知を鍛造オリジネーターアドレスから生じるものと区別するのに十分な場合があります。しかし、ステータス通知を元のメッセージに安全に関連付けることができる暗号化署名資料を含む長期的には、推奨されます。
As this specification permits UTF-8 in additional fields, the security considerations of UTF-8 [RFC3629] apply.
この仕様により、追加の分野でUTF-8が許可されるため、UTF-8 [RFC3629]のセキュリティに関する考慮事項が適用されます。
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.
[ASCII] American National Standards Institute（以前のアメリカ合衆国標準研究所）、「米国情報インターチェンジのコード」、ANSI X3.4-1968、1968。
ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.
ANSI X3.4-1968は、わずかな変更で新しいバージョンに置き換えられましたが、1968年のバージョンはインターネットで決定的なままです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC3461] Moore、K。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status通知（DSNS）」、RFC 3461、2003年1月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC3464] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[RFC3798] Hansen、T。およびG. Vaudreuil、「メッセージ処分通知」、RFC 3798、2004年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、BCP 47、RFC 5646、2009年9月。
[RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages", STD 73, RFC 6522, January 2012.
[RFC6522] Kucherawy、M.、ed。、「メールシステム管理メッセージのレポートのためのマルチパート/レポートメディアタイプ」、STD 73、RFC 6522、2012年1月。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
[RFC6530] Klensin、J。およびY. Ko、「国際化された電子メールの概要とフレームワーク」、RFC 6530、2012年2月。
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, February 2012.
[RFC6531] Yao、J。およびW. Mao、「国際化された電子メールのSMTP拡張」、RFC 6531、2012年2月。
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.
[RFC6532] Yang、A.、Steele、S。、およびN. Freed、「国際化されたメールヘッダー」、RFC 6532、2012年2月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 5337, September 2008.
[RFC5337] Newman、C。およびA. Melnikov、「国際化された配送状況と処分通知」、RFC 5337、2008年9月。
Changes were made to move from Experimental to Standards Track. The most significant was the removal of an embedded alternative ASCII address within a utf-8-address, and the reflections of the ABNF changes in [RFC6531].
実験的なものから標準の追跡に移行するために変更が加えられました。最も重要なのは、UTF-8-Address内に埋め込まれた代替ASCIIアドレスの除去と、[RFC6531]のABNF変化の反射でした。
Fixed description of utf-8-addr-xtext and utf-8-addr-unitext.
UTF-8-ADDR-XTEXTおよびUTF-8-ADDR-UNITEXTの説明を修正しました。
References to Downgrade and uMailbox removed/fixed.
ダウングレードおよびUmailboxへの参照は削除/修正されました。
ABNF changes and fixed errata submitted by Alfred Hoenes.
ABNFは、Alfred Hoenesによって提出された固定ERRATAを変更し、固定しました。
Minor changes to MIME type references.
MIMEタイプ参照のマイナーな変更。
Other minor corrections.
その他の軽微な修正。
Many thanks for input provided by Pete Resnick, James Galvin, Ned Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, Alfred Hoenes, Kazunori Fujiwara, and members of the EAI working group to help solidify this proposal.
ピート・レストニック、ジェームズ・ガルビン、ネッド・フリード、ジョン・クレンシン、ハラルド・アルベスランド、フランク・エラーマン、SM、アルフレッド・ホーネス、カズノリ・フジワラ、およびEAIワーキンググループのメンバーがこの提案を固めるのを助けることから提供してくれた意見に感謝します。
Authors' Addresses
著者のアドレス
Tony Hansen (editor) AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 US
トニー・ハンセン（編集者）AT＆Tラボレーター200ローレルアベニュー、ミドルタウン、ニュージャージー州07748米国
EMail: tony+eaidsn@maillennium.att.com
Chris Newman Oracle 800 Royal Oaks Monrovia, CA 91016-6347 US
クリスニューマンオラクル800ロイヤルオークスモンロビア、カリフォルニア91016-6347 US
EMail: chris.newman@oracle.com
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Alexey.Melnikov@isode.com