[要約] RFC 5337は、国際化された配信状況と処理通知に関する標準仕様です。この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
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
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）は、電子メールシステムの正しい操作に重要です。ただし、既存のドラフト標準（RFC 3461、RFC 3462、RFC 3464）は、現在、プロトコルの機械可読部分のUS-ASCIIテキストに限定されています。この仕様には、国際的な電子メールアドレスの新しいアドレスタイプが追加されるため、ダウングレード後でもUS-ASCII以外の文字を持つ元の受信者アドレスを正しく保存できます。これにより、新しいアドレスタイプの使用をサポートするために、配信ステータス通知とメッセージ処分通知の更新されたコンテンツリターンメディアタイプも提供します。
This document experimentally extends RFC 3461, RFC 3464, and RFC 3798.
このドキュメントは、RFC 3461、RFC 3464、およびRFC 3798を実験的に拡張します。
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
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]拡張機能と国際化された電子メールヘッダー[RFC5335]を使用して電子メールメッセージが送信されると、メッセージを返したり、メッセージ処分通知（MDN）[RFC3798]を生成する必要があります。複数の受信者に送信されたメッセージが各受信者のステータスと気質通知を生成できるため、クライアントが提供された受信者アドレスに基づいてこれらの通知を相関させることができれば役立ちます。したがって、元の受信者の保存が重要です。この仕様には、元の受信者を保存する方法について説明し、MDNおよびDSN形式を更新して新しいアドレスタイプをサポートします。
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 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].
正式な構文は、RFC 5234 [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 [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.
配信ステータス通知[RFC3464]の拡張可能なメッセージ形式は、アドレスタイプの概念を定義します。国際化されたメールヘッダー[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.
UTF8SMTP拡張[RFC5336]とDSN拡張機能[RFC3461]の両方を宣伝するSMTP [RFC2821]サーバーは、8ビットUTF-8文字を含むORCPTパラメーターのUTF-8アドレスタイプを受け入れる必要があります。このアドレスタイプには、メッセージ/配信ステータスボディパーツでの使用に適した7ビットエンコードまたはUTF8SMTPを宣伝しないSMTPサーバーに送信されたORCPTパラメーターも含まれています。
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.
このアドレスタイプには、UTF-8-ADDR-XTEXT、UTF-8-ADDR-UNITEXT、およびUTF-8-ADDRESSの3つのフォームがあります。最初の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 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.
UTF-8-Addressフォームは、8ビット文字のネイティブ表現が可能な新たに定義されたプロトコルでの使用にのみ適しています。つまり、SMTPサーバーがUTF8SMTPのサポートを宣伝していない場合、またはSMTPサーバーがUTF8SMTPをサポートしている場合、UTF-8-ADDRESSフォームはORCPTパラメーターで使用しないでください。（たとえば、ORCPTパラメーターは、エンコードされていないSPおよび=文字を禁止しています）、またはメッセージ/配信ステータスオリジナルレシピエントまたは最終レシピエントフィールドを含む7ビット輸送環境で。前者の場合、代わりにUTF-8-ADDR-XTEXTフォーム（以下を参照）を使用する必要があります。後者の場合、UTF-8-ADDR-UNITEXTフォームを使用する必要があります。SMTPサーバーがUTF8SMTPのサポートも宣伝する場合、UTF-8-AddressフォームはORCPTパラメーターで使用できます。メッセージがUTF8SMTPメッセージである場合、メッセージ/グローバル配信スタタスの元のレシピエントまたは最終的なレシピエントDSNフィールド、または元のレシピエントヘッダーフィールド[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 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アドレスタイプでは、[RFC3461]で説明されているようにXTEXTエンコードを使用して、US-ASCII CTLS、SP、\、、および= = =エンコードする必要があります。これは、以下のABNFのUTF-8-ADDR-XTEXTフォームによって説明されています。Unicode文字は、 "\ x {hexpoint}" syntax（embeddedunicodechar）を使用してUTF-8アドレスタイプに含めることができます。ここでは、Hexpointは2〜6ヘクサデシマル桁です。UTF8SMTP対応サーバーにデータを送信する場合、以下の詳細について説明するEmbedDunicodeChar構文の代わりに、ネイティブUTF-8文字を使用する必要があります。UTF8SMTPを宣伝していない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 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パラメーターがメッセージ/グローバル配信ステータスオリジナルレシピエントフィールドに配置されている場合、UTF-8アドレスタイプのUTF-8-ADDR-XTEXTフォームをUTF-8アドレスフォームに変換する必要があります（以下のABNF）最初にすべてのXTEXTエンコード（UTF-8-ADDR-UNITEXTフォームになります）を削除し、続いてUniteXTエンコードの削除を行います。ただし、アドレスに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エンコーディングで文字をエンコードする機能は、移行メカニズムと見なす必要があります。UTF8SMTPのサポートを欠くシステムが時間とともに一般的ではないようになるにつれて、これらのエンコーディングが最終的に段階的に廃止されることが期待されています。
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 = uMailbox [ 1*WSP "<" Mailbox ">" ] ; uMailbox is defined in [RFC5336]. ; Mailbox is defined in [RFC2821].
utf-8-address = umailbox [1*wsp "<" mailbox ">"];Umailboxは[RFC5336]で定義されています。;メールボックスは[RFC2821]で定義されています。
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 = xtext
; xtext is defined in [RFC3461].
; When xtext encoding is removed,
; the syntax MUST conform to
; utf-8-addr-unitext.
utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar)
; MUST follow utf-8-address ABNF when
; dequoted
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
EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}"
; starts with "\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
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 [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]コンテナがあります。最初の部分はエラーを説明する人間の読み取り可能なテキストです。2番目の部分は7ビットのみのメッセージ/配信ステータスです、およびオプションの3番目の部分は、コンテンツ（メッセージ/RFC822）またはヘッダー（テキスト/RFC822ヘッダー）リターンに使用されます。現在のDSN形式では、配信不可能な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を参照）。特に、UTF8SMTP [RFC5336]に記載されているように、診断コードフィールドにはUTF-8が含まれている場合があります。診断コードフィールドはi-Default Language [DefaultLang]である必要があります。第二に、メッセージ/グローバル配信スタッサスボディパーツを生成するシステムは、US-ASCIIレパートリーの外側の文字を含むすべてのアドレスにUTF-8アドレス形式のUTF-8アドレスタイプを使用する必要があります。これらのシステムは、UTF-8アドレスタイプのUTF-8-ADDR-UNITEXTフォームのUTF-8アドレス形式のUTF-8アドレスタイプにUTF-8-ADDR-XTEXTまたはUTF-8-ADDR-Unitextフォームをアップしている必要があります。元のレシピエントフィールドで。第三に、ローカライズダグニスティックと呼ばれる新しいオプションフィールドが追加されます。各インスタンスには言語タグ[langtags]が含まれており、指定された言語にテキストが含まれています。これは、診断コードフィールドのテキスト部分と同等です。ローカライズされた診断のすべてのインスタンスは、異なる言語タグを使用する必要があります。メッセージ/グローバル配信ステータスの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]の付録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.
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.
generic-address =/ utf-8-enc-addr
; Only allowed with the "utf-8" address-type.
;
; 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 [LANGTAGS].
extension-field =/ extension-field-name ":" *utf8-text
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.
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 [RFC5335].
utf8-non-ascii = utf8-2 / utf8-3 / utf8-4コンテンツの返却に使用される2番目のタイプは、UTF-8ヘッダーを含むメッセージが含まれている場合を除き、メッセージ / RFC822に似たメッセージ /グローバルです。このメディアタイプは[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番目のタイプは、メッセージ/グローバルヘッダーであり、メッセージのUTF-8ヘッダーフィールドのみが含まれています（UTF8SMTPメッセージの最初の空白行の前のすべての行）。メッセージ/グローバルとは異なり、この身体部分は現在のインフラストラクチャに困難を与えません。
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.
MultiPart/Report [RFC3462]コンテナに関する限り、メッセージ/グローバル配信ステータス、メッセージ/グローバル、およびメッセージ/グローバルヘッダーは、メッセージ/配信ステータス、メッセージ/RFC822、およびテキスト/RFC822ヘッダー。つまり、MultiPart/レポートMIMEタイプ内に上記の6つのMIMEタイプの組み合わせを処理する必要があるMultiPART/レポートが予想される必要があります。
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ビット」コンテンツ転送エンコードを使用します。（すべてのコンテンツが7ビットである場合、配信ステータス通知の同等の従来のタイプを使用できます。たとえば、メッセージ/グローバル配信ステータスパーツの情報をメッセージ/配信としての情報を損なうことなく表現できる場合 - ステータス、次に、メッセージ/配信ステータス本体の部分を使用できます。）[RFC5335]は、新しい「メッセージ」サブタイプでのコンテンツ転送エンコードの使用に関するMIME [RFC2046]の制限を緩和したことに注意してください。この仕様により、メッセージ/グローバルヘッダーとメッセージ/グローバル配信のステータスでのコンテンツ転送エンコードを明示的に使用できます。これらの新しいMIMEタイプは、8ビットMIMEおよびUTF-8ヘッダーを完全にサポートする新しいシステムが主に使用することを目的としているため、これは問題があるとは考えられていません。
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サーバーが、配信不可能なUTF8SMTPメッセージを返す必要がある場合、対応するMultiPART/レポートを生成するときにUTF8SMTPメッセージをダウングレードしてはなりません。リターンパスSMTPサーバーがUTF8SMTPをサポートしていない場合、セクションで詳述されているように、「Base64」や「引用プリント」[RFC2045]などの7ビットコンテンツ転送エンコードを使用して、配信不可能なボディパーツとヘッダーをエンコードする必要があります。4.それ以外の場合、「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.
メッセージ処分通知[RFC3798]は、DSNSと同様の設計と構造を持っています。その結果、同じ基本的な返品形式を使用します。UTF-8ヘッダーメッセージのMDNを生成する場合、MultiPart/レポートの3番目の部分には、DSNSと同じように、返されたコンテンツ（メッセージ/グローバル）またはヘッダー（メッセージ/グローバルヘッダー）が含まれます。MultiPart/レポートの2番目の部分では、新しいメディアタイプ、メッセージ/グローバル配置 - 解釈を使用しています。これには、2つの変更を伴うメッセージ/気質 - 解釈の構文があります。まず、メッセージ/グローバルディスポジションノティフィケーションのcharsetはutf-8です。したがって、どのフィールドにも必要な場合はUTF-8文字が含まれる場合があります（以下のABNFを参照）。（特に、故障フィールド、エラーフィールド、および警告フィールドにはUTF-8が含まれている場合があります。これらのフィールドはi-default言語[defaultlang]である必要があります。）次に、メッセージ/グローバルディスポジションを生成するシステム - 通知機関（通常、メールユーザーエージェント）は、US-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仕様は、配信時にORCPTの内容のコピーが追加された元のレシピエントヘッダーフィールドも定義します。元のレシピエントヘッダーフィールドを生成する場合、ネイティブ形式でUTF-8ヘッダーメッセージを書くデリバリーエージェントは、UTF-8-ADDR-XTEXTまたはUTF-8-ADDR-UNITEXT形式のUTF-8アドレスタイプを変換する必要があります。対応する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仕様は、アドレスヘッダーである処分と解釈のヘッダーも定義するため、UTF-8ヘッダーメッセージで使用した場合の「From」および "to"などの他のアドレスヘッダーと同じ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.
error-field = "Error" ":" *utf8-text
; "utf8-text" is defined in Section 4 of this document.
warning-field = "Warning" ":" *utf8-text
; "utf8-text" is defined in Section 4 of this document.
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 RFC 3464. The registration template response follows:
メールアドレスタイプレジストリはRFC 3464によって作成されました。登録テンプレート応答は次のとおりです。
(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.
(c) このタイプのアドレスが、US-ASCIIレパートリーのグラフィック文字で完全に構成されていない場合、DSNの元のレシピエントまたは最終的なレシピエントDSNフィールドのグラフィックUS-ASCII文字としてエンコードされる方法の仕様。
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.
このアドレスタイプには、UTF-8- AddR-Xtext、UTF-8-ADDR-Unitext、およびUTF-8-Addressの3つのフォーム（セクション3で定義されています）があります。最初の2つのフォームは7ビット安全です。
The utf-8-address form MUST NOT be used
UTF-8-Addressフォームを使用してはなりません
1. in the ORCPT parameter when the SMTP server doesn't advertise support for UTF8SMTP;
1. SMTPサーバーがUTF8SMTPのサポートを宣伝しないORCPTパラメーターで。
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パラメーターで許可されていないUS-ASCII文字が含まれています（たとえば、ORCPTパラメーターSPおよび=文字を禁止）。
3. or in a 7-bit transport environment including a message/ delivery-status Original-Recipient or Final-Recipient field.
3. または、メッセージ/配信ステータスの元のレシピエントまたは最終レシピエントフィールドを含む7ビット輸送環境で。
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フォームを使用する必要があります。UTF-8-ADDR-Unitextフォームは、他の2つのケースで使用する必要があります。SMTPサーバーがUTF8SMTPのサポートも宣伝する場合、UTF-8-AddressフォームはORCPTパラメーターで使用できます。
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.
メッセージ/グローバル配信スタタスオリジナルレシピエントまたは最終的なレシピエントDSNフィールド。または、メッセージがUTF8SMTPメッセージである場合、元のレシピエントヘッダーフィールド[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フォームを使用できます。
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.
メール診断タイプレジストリはRFC 3464によって作成されました。「SMTP」診断タイプの登録は、RFC 3464に加えてRFC 5337を参照するように更新する必要があります。
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 [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.
考慮事項のエンコード：このメディアタイプには、メッセージ本文のない国際化された電子メールヘッダー[RFC5335]が含まれています。可能な場合はいつでも、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 downconvert this media type to the text/rfc822-header media type, such conversion is discouraged as it loses information.
相互運用性の考慮事項：このメディアタイプがUTF-8以外のcharsetに変換されないことが重要です。その結果、実装は、このメディアタイプのcharsetパラメーターを含めてはなりません。このメディアタイプをText/RFC822-Headerメディアタイプにダウンコンセントすることは可能かもしれませんが、そのような変換は情報を失って阻止されます。
Published specification: RFC 5337 Applications that use this media type: UTF8SMTP servers and email clients that support multipart/report generation or parsing.
公開された仕様：このメディアタイプを使用するRFC 5337アプリケーション：UTF8SMTPサーバーと、マルチパート/レポートの生成または解析をサポートするクライアントに電子メールを送信します。
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 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.
セキュリティの考慮事項：セクション7の相互運用性の考慮事項を参照してください。このメディアタイプは、電子メールメッセージの返信情報のメッセージ/配信ステータスコンテンツタイプと同様の機能を提供します。以前の形式のクライアントは、新しい形式を解釈するためにアップグレードする必要があります。ただし、新しいメディアタイプにより、違いを簡単に特定できます。
Published specification: RFC 5337
公開された仕様：RFC 5337
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 5337
公開された仕様：RFC 5337
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]のセキュリティ上の考慮事項が適用されます。
[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月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[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月。
[RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[RFC3462] Vaudreuil、G。、「メールシステム管理メッセージのレポートのためのマルチパート/レポートコンテンツタイプ」、RFC 3462、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の増強」、STD 68、RFC 5234、2008年1月。
[RFC5335] Yang, A., Ed., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335] Yang、A.、ed。、「Internationalized Email Headers」、RFC 5335、2008年9月。
[RFC5336] Yao, J., Ed. and W. Mao, Ed., "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.
[RFC5336] Yao、J.、ed。and W. Mao、ed。、「国際化された電子メールアドレスのSMTP拡張」、RFC 5336、2008年9月。
[LANGTAGS] Phillips, A. and M. Davis, "Tags for Identifying Languages", RFC 4646, September 2006.
[Langtags] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、RFC 4646、2006年9月。
[DEFAULTLANG] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277, January 1998.
[DefaultLang] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、RFC 2277、1998年1月。
[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月。
[DOWNGRADE] Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for Email Address Internationalization", Work in Progress, July 2008.
[ダウングレード] Fujiwara、K。およびY. Youneya、「電子メールアドレス国際化のためのダウングレードメカニズム」、2008年7月の作業。
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.
ピート・レストニック、ジェームズ・ガルビン、ネッド・フリード、ジョン・クレンシン、ハラルド・アルベスランド、フランク・エルマン、SM、およびEAI WGのメンバーがこの提案を固めるのを支援してくれた意見に感謝します。
Authors' Addresses
著者のアドレス
Chris Newman Sun Microsystems 800 Royal Oaks Monrovia, CA 91016-6347 US
クリスニューマンサンマイクロシステムズ800ロイヤルオークスモンロビア、CA 91016-6347 US
EMail: chris.newman@sun.com
Alexey Melnikov (editor) 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。