Internet Engineering Task Force (IETF) J. Yao
Request for Comments: 6531 W. Mao
Obsoletes: 5336 CNNIC
Category: Standards Track February 2012
ISSN: 2070-1721
SMTP Extension for Internationalized Email
Abstract
抽象
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information.
この文書では、国際化電子メールアドレスまたはヘッダー情報を輸送し、電子メールメッセージの配信のためのSMTPの拡張子を指定します。
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/rfc6531.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6531で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Changes Made to Other Specifications . . . . . . . . . . . 3
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 4
3.1. Framework for the Internationalization Extension . . . . . 4
3.2. The SMTPUTF8 Extension . . . . . . . . . . . . . . . . . . 5
3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7
3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 8
3.5. Non-ASCII Addresses and Reply-Codes . . . . . . . . . . . 9
3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9
3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10
3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10
3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 10
3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11
3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
4.1. SMTP Service Extensions Registry . . . . . . . . . . . . . 13
4.2. SMTP Enhanced Status Code Registry . . . . . . . . . . . . 13
4.3. WITH Protocol Types Sub-Registry of the Mail
Transmission Types Registry . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 18
The document defines a Simple Mail Transfer Protocol [RFC5321] extension so servers can advertise the ability to accept and process internationalized email addresses (see Section 1.1) and internationalized email headers [RFC6532].
サーバは、国際化電子メールアドレス（セクション1.1を参照）、国際化電子メールのヘッダ[RFC6532]を受け入れて処理する能力を宣伝することができますので、文書は簡易メール転送プロトコル[RFC5321]の拡張を定義します。
An extended overview of the extension model for internationalized email addresses and the email header appears in RFC 6530 [RFC6530], referred to as "the framework document" in this specification. A thorough understanding of the information in that document and in the base Internet email specifications [RFC5321] [RFC5322] is necessary to understand and implement this specification.
国際電子メールアドレスとメールヘッダは、RFC 6530に表示される[RFC6530]の拡張モデルの拡張の概要は、本明細書では「フレームワーク文書」と呼びます。その文書で、ベースのインターネット電子メールの仕様の情報を完全に理解[RFC5321] [RFC5322]はこの仕様を理解し、実施する必要があります。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The terms "UTF-8 string" or "UTF-8 character" are used to refer to Unicode characters, which may or may not be members of the ASCII subset, in UTF-8 [RFC3629], a standard Unicode Encoding Form. All other specialized terms used in this specification are defined in the framework document or in the base Internet email specifications. In particular, the terms "ASCII address", "internationalized email address", "non-ASCII address", "SMTPUTF8", "internationalized message", and "message" are used in this document according to the definitions in the framework document [RFC6530].
用語「UTF-8文字列」または「UTF-8文字は」UTF-8 [RFC3629]、標準のUnicodeエンコーディング形式では、ASCIIまたはサブセットのメンバーであってもなくてもよいUnicode文字を指すために使用されます。本明細書において使用される他のすべての専門用語は、フレームワーク文書にまたはベースのインターネット電子メールの仕様で定義されています。特に、用語「ASCIIアドレス」、「国際化メールアドレス」、「非ASCIIアドレス」、「SMTPUTF8」、「国際化メッセージ」、および「メッセージ」は、[フレームワーク文書の定義に従って、この文書で使用されていますRFC6530]。
Strings referred to in this document, including ASCII strings, MUST be expressed in UTF-8.
ASCII文字列を含め、本文書で言及した文字列は、UTF-8で表現されなければなりません。
This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some basic rules in this document are identified in Section 3.3 as being defined (under the same names) in RFC 5234 [RFC5234], RFC 5321 [RFC5321], RFC 5890 [RFC5890], or RFC 6532 [RFC6532].
この仕様は、拡張BNF（ABNF）規則[RFC5234]を使用します。 RFC 5234 [RFC5234]、RFC 5321 [RFC5321]、RFC 5890 [RFC5890]に（同じ名前で）定義された、またはRFC 6532 [RFC6532]されているものとしてこの文書に記載されているいくつかの基本的なルールは、セクション3.3で特定されます。
This specification extends some syntax rules defined in RFC 5321 and permits internationalized email addresses in the envelope and in trace fields, but it does not modify RFC 5321. It permits data formats defined in RFC 6532 [RFC6532], but it does not modify RFC 5322. It does require that the 8BITMIME extension [RFC6152] be announced by the SMTPUTF8-aware SMTP server and used with "BODY=8BITMIME" by the SMTPUTF8-aware SMTP client, but it does not modify the 8BITMIME specification in any way.
この仕様はRFC 5321で定義されたいくつかの構文規則を拡張し、封筒にとトレースフィールドにおける国際化電子メールアドレスを許可するが、それはそれは、RFC 6532 [RFC6532]で定義されたデータ形式を許可するRFC 5321.を変更しませんが、それはRFC 5322を変更しません。これは、8BITMIME拡張[RFC6152] SMTPUTF8対応のSMTPサーバが発表したとSMTPUTF8対応のSMTPクライアントで「BODY = 8BITMIME」で使用することを必要としないが、それはどのような方法で8BITMIMEの仕様を変更しません。
This specification replaces an earlier, experimental, approach to the same problem [RFC5336]. Section 6 of RFC 6530 [RFC6530] describes the changes in approach between RFC 5336 [RFC5336] and this specification. Anyone trying to convert an implementation from the experimental specification to the specification in this document will need to review those changes carefully.
この仕様は、同じ問題が[RFC5336]に以前、実験的アプローチを置き換えます。 RFC 6530 [RFC6530]のセクション6は、RFC 5336 [RFC5336]と本明細書との間のアプローチの変化を記述する。このドキュメントの仕様に実験的な仕様から実装を変換しようと誰もが慎重にそれらの変更を検討する必要があります。
This document specifies an element of the email internationalization work, specifically the definition of an SMTP extension for internationalized email. The extension is identified with the token "SMTPUTF8".
この文書は、電子メールの国際化作業の要素、国際化電子メールのSMTP拡張の、具体的な定義を指定します。拡張子は、トークン「SMTPUTF8」で識別されます。
The internationalized email headers specification [RFC6532] provides the details of email header features enabled by this extension.
国際メール・ヘッダー仕様[RFC6532]はこの拡張により対応eメールヘッダー機能の詳細を提供します。
The following service extension is defined:
以下のサービス拡張が定義されています。
1. The name of the SMTP service extension is "Internationalized Email".
1. SMTPサービス拡張の名前は、「国際電子メール」です。
2. The EHLO keyword value associated with this extension is "SMTPUTF8".
2.この拡張子に関連付けられているEHLOキーワード値は「SMTPUTF8」です。
3. No parameter values are defined for this EHLO keyword value. In order to permit future (although unanticipated) extensions, the EHLO response MUST NOT contain any parameters for this keyword. The SMTPUTF8-aware SMTP client MUST ignore any parameters if they appear for this keyword; that is, the SMTPUTF8-aware SMTP client MUST behave as if the parameters do not appear. If an SMTP server includes SMTPUTF8 in its EHLO response, it MUST be fully compliant with this version of this specification.
3.ませパラメータ値は、このEHLOキーワード値のために定義されていません。未来を可能にするためには拡張子（予期せぬが）、EHLO応答では、このキーワードのいずれかのパラメータを含めることはできません。彼らはこのキーワードに対して表示された場合SMTPUTF8対応のSMTPクライアントは、任意のパラメータを無視しなければなりません。つまり、SMTPUTF8対応のSMTPクライアントは、パラメータが表示されないかのように動作しなければなりません。 SMTPサーバがEHLO応答でSMTPUTF8が含まれている場合、それは、この仕様書のこのバージョンに完全に準拠しなければなりません。
4. One OPTIONAL parameter, SMTPUTF8, is added to the MAIL command. The parameter does not accept a value. If this parameter is set in the MAIL command, it indicates that the SMTP client is SMTPUTF8-aware. Its presence also asserts that the envelope includes the non-ASCII address, the message being sent is an internationalized message, or the message being sent needs the SMTPUTF8 support.
4.一つのオプションのパラメータ、SMTPUTF8は、MAILコマンドに追加されます。パラメータが値を受け付けません。このパラメータがMAILコマンドで設定されている場合は、SMTPクライアントがSMTPUTF8-認識していることを示しています。その存在はまた、エンベロープが送信されるメッセージは、国際化されたメッセージである、または送信されたメッセージがSMTPUTF8のサポートを必要とし、非ASCIIアドレスが含まれていることを主張します。
5. The maximum length of a MAIL command line is increased by 10 characters to accommodate the possible addition of the SMTPUTF8 parameter.
5. MAILコマンドラインの最大長はSMTPUTF8パラメータの可能な添加を収容するために10文字だけ増加させます。
6. One OPTIONAL parameter, SMTPUTF8, is added to the VERIFY (VRFY) and EXPAND (EXPN) commands. The SMTPUTF8 parameter does not accept a value. The parameter indicates that the SMTP client can accept Unicode characters in UTF-8 encoding in replies from the VRFY and EXPN commands.
6.一つのオプションのパラメータ、SMTPUTF8は、VERIFY（VRFY）に添加し、（EXPN）コマンドを展開しています。 SMTPUTF8パラメータが値を受け付けません。パラメータは、SMTPクライアントはVRFYとEXPNコマンドからの返信でUTF-8エンコーディングでUnicode文字を受け入れることができることを示します。
8. Servers offering this extension MUST provide support for, and announce, the 8BITMIME extension [RFC6152].
サポートを提供し、発表しなければならないこの拡張機能を提供8.サーバー、8BITMIME拡張[RFC6152]。
9. The reverse-path and forward-path of the SMTP MAIL and RCPT commands are extended to allow Unicode characters encoded in UTF-8 in mailbox names (addresses).
9.逆パスおよびSMTPメールとRCPTコマンドのフォワードパスは、メールボックス名（アドレス）にUTF-8でエンコードされたUnicode文字を許可するように拡張されます。
10. The mail message body is extended as specified in RFC 6532 [RFC6532].
RFC 6532 [RFC6532]で指定されるように前記メールメッセージ本体が拡張されます。
11. The SMTPUTF8 extension is valid on the submission port [RFC6409]. It may also be used with the Local Mail Transfer Protocol (LMTP) [RFC2033]. When these protocols are used, their use should be reflected in the trace field WITH keywords as appropriate [RFC3848].
11. SMTPUTF8拡張子はサブミッションポート[RFC6409]で有効です。また、ローカルメール転送プロトコル（LMTP）[RFC2033]と共に使用することができます。これらのプロトコルが使用される場合、それらの使用は、適切な[RFC3848]などのキーワードでトレースフィールドに反映されるべきです。
An SMTP server that announces the SMTPUTF8 extension MUST be prepared to accept a UTF-8 string [RFC3629] in any position in which RFC 5321 specifies that a <mailbox> can appear. Although the characters in the <local-part> are permitted to contain non-ASCII characters, the actual parsing of the <local-part> and the delimiters used are unchanged from the base email specification [RFC5321]. Any domain name to be looked up in the DNS MUST conform to and be processed as specified for Internationalizing Domain Names in Applications (IDNA) [RFC5890]. When doing lookups, the SMTPUTF8-aware SMTP client or server MUST either use a Unicode-aware DNS library, or transform the internationalized domain name to A-label form (i.e., a fully-qualified domain name that contains one or more A-labels but no U-labels) as specified in RFC 5890 [RFC5890].
SMTPUTF8拡張を発表しましたSMTPサーバは、RFC 5321に<メールボックス>が現れることができることを指定した任意の位置でのUTF-8文字列[RFC3629]を受け入れるように準備しなければなりません。 <ローカル部分>の文字が非ASCII文字を含むことが許されているが、<ローカル部分>の実際の解析および使用される区切り文字は、基本メール仕様[RFC5321]から変化していません。任意のドメイン名は、[RFC5890]をに従わなければなりませんし、（IDNA）アプリケーションにおけるドメイン名の国際化のために指定されるように処理されるDNSで検索します。検索を行うとき、SMTPUTF8対応のSMTPクライアントまたはサーバは、Unicode対応のDNSライブラリを使用、またはラベルの形（すなわち、1つ以上のA-ラベルが含まれて完全修飾ドメイン名に国際化ドメイン名を変換する必要がありますどちらかしかし、RFC 5890 [RFC5890]で指定されないU-標識）。
An SMTP client that receives the SMTPUTF8 extension keyword in response to the EHLO command MAY transmit mailbox names within SMTP commands as internationalized strings in UTF-8 form. It MAY send a UTF-8 header [RFC6532] (which may also include mailbox names in
SMTPは、UTF-8形式でのように国際化された文字列をコマンド内EHLOコマンドに応答してSMTPUTF8拡張キーワードを受け取り、SMTPクライアントがメールボックス名を送信してもよいです。また、メールボックス名にを含むことがUTF-8ヘッダ[RFC6532]を（送るかもしれ
UTF-8). It MAY transmit the domain parts of mailbox names within SMTP commands or the message header as A-labels or U-labels [RFC5890]. The presence of the SMTPUTF8 extension does not change the server-relaying behaviors described in RFC 5321.
UTF-8）。これは、ラベルまたはU-ラベル[RFC5890]としてSMTPコマンドまたはメッセージヘッダ内のメールボックス名のドメイン部分を送信することができます。 SMTPUTF8拡張の存在は、RFC 5321に記載サーバ中継動作を変更しません。
If the SMTPUTF8 SMTP extension is not offered by the SMTP server, the SMTPUTF8-aware SMTP client MUST NOT transmit an internationalized email address and MUST NOT transmit a mail message containing internationalized mail headers as described in RFC 6532 [RFC6532] at any level within its MIME structure [RFC2045]. (For this paragraph, the internationalized domain name in A-label form as specified in IDNA definitions [RFC5890] is not considered to be "internationalized".) Instead, if an SMTPUTF8-aware SMTP client (sender) attempts to transfer an internationalized message and encounters an SMTP server that does not support the extension, the best action for it to take depends on other conditions. In particular:
SMTPUTF8 SMTP拡張がSMTPサーバーによって提供されていない場合は、SMTPUTF8対応のSMTPクライアントは、国際化電子メールアドレスを送信してはならないとRFC 6532で説明したようにその内の任意のレベルで[RFC6532]国際メールヘッダーを含む電子メールメッセージを送信してはなりませんMIME構造[RFC2045]。 （この段落では、ラベル形式の国際化ドメイン名「国際化」であるとは考えられないIDNA定義[RFC5890]で指定されている。）その代わり、SMTPUTF8対応のSMTPクライアント（送信者）が国際化されたメッセージを転送しようとした場合そして、拡張をサポートしていないSMTPサーバーに遭遇し、それが取るための最善の行動は、他の条件に依存します。特に：
o If it is a Message Submission Agent (MSA) [RFC6409] [RFC5598], it MAY choose its own way to deal with this scenario using the wide discretion for changing addresses or otherwise fixing up and transforming messages allowed by RFC 6409. As long as the resulting message conforms to the requirements of RFC 5321 (i.e., without the SMTPUTF8 extension), the details of that transformation are outside the scope of this document.
それはメッセージ服従エージェント（MSA）[RFC6409] [RFC5598]である場合には、O、それはアドレスを変更するか、そうでない場合は、最大固定し、長いとしてRFC 6409.によって許可されたメッセージを変換するための広い裁量を使用して、このシナリオに対処する独自の方法を選ぶかもしれ得られたメッセージは、RFC 5321の要件（すなわち、SMTPUTF8拡張子なし）に準拠したように、その変換の詳細は、この文書の範囲外です。
o If it is not an MSA or is an MSA and does not choose to transform the message to one that does not require the SMTPUTF8 extension, it SHOULD reject the message. As usual, this can be done either by generating an appropriate reply during the SMTP transaction or by accepting the message and then generating and transmitting a non-delivery notification. If the latter choice is made, the notification process MUST conform to the requirements of RFC 5321, RFC 3464 [RFC3464], and RFC 6533 [RFC6533].
それはMSAではないか、MSAで、SMTPUTF8拡張を必要としないものにメッセージを変換することを選択していない場合は、O、それはメッセージを拒否すべきです。いつものように、これは、SMTPトランザクション中に適切な応答を生成することにより、またはメッセージを受け入れ、次に配信不能通知を生成して送信することによってのいずれかで行うことができます。後者の選択がなされた場合、通知プロセスは、RFC 5321、RFC 3464 [RFC3464]の要件に適合しなければならない、およびRFC 6533 [RFC6533]。
o As specified in Section 2.2.3 of RFC 5321, an SMTP client with additional information and/or knowledge of special circumstances MAY choose to requeue the message and try later and/or try an alternate MX host as specified in that section.
RFC 5321のセクション2.2.3で指定されるように、O、付加的な情報及び/又は特別な状況の知識を持つSMTPクライアントは、メッセージをキューに再登録し、以降試みる、および/またはそのセクションで指定されるように交互のMXホストを試みることを選ぶかもしれ。
This document applies when an SMTPUTF8-aware SMTP client or server supports the SMTPUTF8 extension. For all other cases, and for addresses and messages that do not require an SMTPUTF8 extension, SMTPUTF8-aware SMTP clients and servers do not change the behavior specified in RFC 5321 [RFC5321].
SMTPUTF8対応のSMTPクライアントやサーバがSMTPUTF8拡張をサポートしている場合は、この文書では、適用されます。他のすべてのケースでは、とSMTPUTF8拡張を必要としないアドレスとメッセージに対して、SMTPUTF8対応のSMTPクライアントとサーバは、RFC 5321 [RFC5321]で指定された動作を変更しないでください。
If an SMTPUTF8-aware SMTP server advertises the Delivery Status Notification (DSN) [RFC3461] extension, it MUST implement RFC 6533 [RFC6533].
SMTPUTF8対応のSMTPサーバーは、配信状態通知（DSN）[RFC3461]の拡張をアドバタイズする場合は、RFC 6533 [RFC6533]を実装しなければなりません。
RFC 5321, Section 4.1.2, defines the syntax of a <Mailbox> entirely in terms of ASCII characters. This document extends <Mailbox> to add support of non-ASCII characters.
RFC 5321、セクション4.1.2は、完全にASCII文字の面で<メールボックス>の構文を定義します。この文書では、<メールボックス>非ASCII文字のサポートを追加するために拡張します。
The key changes made by this specification include:
この仕様で作られたキーの変更は、次のとおりです。
o The <Mailbox> ABNF rule is imported from RFC 5321 and updated in order to support the internationalized email address. Other related rules are imported from RFC 5321, RFC 5234, RFC 5890, and RFC 6532, or are extended in this document.
O <メールボックス> ABNF規則は、RFC 5321から輸入し、国際化電子メールアドレスをサポートするために更新されます。その他の関連規則は、RFC 5321、RFC 5234、RFC 5890、およびRFC 6532から輸入され、または本文書に延びています。
o The definition of <sub-domain> is extended to permit both the RFC 5321 definition and a UTF-8 string in a DNS label that conforms with IDNA definitions [RFC5890].
0 <サブドメイン>の定義は、RFC 5321の定義とIDNA定義[RFC5890]に準拠したDNSラベルでUTF-8の文字列の両方を可能にするように拡張されます。
o The definition of <atext> is extended to permit both the RFC 5321 definition and a UTF-8 string. That string MUST NOT contain any of the ASCII graphics or control characters.
0 <atext>の定義は、RFC 5321の定義とUTF-8文字列の両方を可能にするように拡張されます。その文字列は、ASCIIグラフィックや制御文字のいずれかを含めることはできません。
The following ABNF rules imported from RFC 5321, Section 4.1.2, are updated directly or indirectly by this document:
RFC 5321、セクション4.1.2から輸入し、次のABNF規則は、本文書によって直接的または間接的に更新されます。
o <Mailbox>
O <メールボックス>
o <Local-part>
O <ローカル部分>
o <Dot-string>
O <ドット文字列>
o <Quoted-string>
O <引用符で囲まれた文字列>
o <QcontentSMTP>
お ＜ＱこんてんｔＳＭＴＰ＞
o <Domain>
O <ドメイン>
o <Atom>
お ＜あとｍ＞
The following ABNF rule will be imported from RFC 6532, Section 3.1, directly:
以下のABNF規則は、直接、セクション3.1、RFC 6532からインポートされます。
o <UTF8-non-ascii>
または<UTF8-非ASCII>
The following ABNF rule will be imported from RFC 5234, Appendix B.1, directly:
以下のABNF規則は、直接、RFC 5234、付録B.1からインポートされます。
o <DQUOTE>
O <DQUOTE>
The following ABNF rule will be imported from RFC 5890, Section 2.3.2.1, directly:
以下のABNF規則は、直接、セクション2.3.2.1、RFC 5890からインポートされます。
o <U-label>
O <U-ラベル>
The following rules are extended in ABNF [RFC5234] as follows.
以下の規則は、次のようにABNF [RFC5234]に拡張されます。
sub-domain =/ U-label ; extend the definition of sub-domain in RFC 5321, Section 4.1.2
サブドメイン= / Uラベル。 RFC 5321、セクション4.1.2にサブドメインの定義を拡張
atext =/ UTF8-non-ascii ; extend the implicit definition of atext in ; RFC 5321, Section 4.1.2, which ultimately points to ; the actual definition in RFC 5322, Section 3.2.3
atext = / UTF8-非ASCII;中atextの暗黙的な定義を拡張します。最終的に指し示すRFC 5321、セクション4.1.2。 RFC 5322で実際の定義、3.2.3項
qtextSMTP =/ UTF8-non-ascii ; extend the definition of qtextSMTP in RFC 5321, Section 4.1.2
qtextSMTP = / UTF8-非ASCII; RFC 5321、セクション4.1.2にqtextSMTPの定義を拡張
esmtp-value =/ UTF8-non-ascii ; extend the definition of esmtp-value in RFC 5321, Section 4.1.2
ESMTP値= / UTF8-非ASCII; RFC 5321、セクション4.1.2にESMTP値の定義を拡張
If the envelope or message being sent requires the capabilities of the SMTPUTF8 extension, the SMTPUTF8-aware SMTP client MUST supply the SMTPUTF8 parameter with the MAIL command. If this parameter is provided, it MUST not accept a value. If the SMTPUTF8-aware SMTP client is aware that neither the envelope nor the message being sent requires any of the SMTPUTF8 extension capabilities, it SHOULD NOT supply the SMTPUTF8 parameter with the MAIL command.
送信されているエンベロープまたはメッセージがSMTPUTF8拡張の機能を必要とする場合、SMTPUTF8対応のSMTPクライアントは、MAILコマンドでSMTPUTF8パラメータを供給しなければなりません。このパラメータが用意されている場合は、値を受け入れてはいけません。 SMTPUTF8対応のSMTPクライアントが封筒にも送信されるメッセージのいずれもSMTPUTF8拡張機能のいずれかが必要であることを認識している場合、それはMAILコマンドでSMTPUTF8パラメータを提供しません。
Because there is no guarantee that a next-hop SMTP server will support the SMTPUTF8 extension, use of the SMTPUTF8 extension always carries a risk of transmission failure. In fact, during the early stages of deployment for the SMTPUTF8 extension, the risk will be quite high. Hence, there is a distinct near-term advantage for ASCII-only messages to be sent without using this extension. The long-term advantage of casting ASCII [ASCII] characters (0x7f and below) as UTF-8 form is that it permits pure-Unicode environments.
ネクストホップSMTPサーバがSMTPUTF8拡張をサポートするという保証はありませんので、SMTPUTF8拡張の使用は、常に送信失敗のリスクを伴います。実際には、SMTPUTF8拡張の展開の初期段階で、リスクが非常に高くなります。従って、この拡張機能を使用せずに送信するASCIIのみのメッセージのための別個の短期的な利点があります。 UTF-8形式としてASCII [ASCII]文字（下から0x7fとを）鋳造の長期的な利点は、それが純粋なユニコード環境を可能にすることです。
An SMTPUTF8-aware SMTP client MUST NOT send an internationalized message to an SMTP server that does not support SMTPUTF8. If the SMTP server does not support this option, then the SMTPUTF8-aware SMTP client has three choices according to Section 3.2 of this specification.
SMTPUTF8対応のSMTPクライアントがSMTPUTF8をサポートしていないSMTPサーバーに国際化されたメッセージを送ってはいけません。 SMTPサーバがこのオプションをサポートしていない場合は、SMTPUTF8対応のSMTPクライアントは、この仕様書の3.2節に応じて3つの選択肢があります。
The three-digit reply-codes used in this section are based on their meanings as defined in RFC 5321.
RFC 5321で定義されるように、このセクションで使用される3桁の返信コードは、それらの意味に基づいています。
When messages are rejected because the RCPT command requires an ASCII address, the reply-code 553 is returned with the meaning "mailbox name not allowed". When messages are rejected because the MAIL command requires an ASCII address, the reply-code 550 is returned with the meaning "mailbox unavailable". When the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], reply-code "X.6.7" [RFC5248] (see Section 4) is used, meaning "Non-ASCII addresses not permitted for that sender/recipient".
RCPTコマンドはASCIIアドレスを必要とするため、メッセージが拒否された場合、回答コード553は、意味の「許可されていないメールボックス名」と返されます。 MAILコマンドはASCIIアドレスを必要とするため、メッセージが拒否された場合、回答コード550は、意味の「使用できないメールボックス」と返されます。 SMTPUTF8対応のSMTPサーバはメールシステムステータスコード[RFC3463]拡張サポートしている場合、「X.6.7」[RFC5248]コードを返信「その送信者/受信者のために許可されていない非ASCIIアドレス」を意味、使用されている（第4章を参照してください） 。
When messages are rejected for other reasons, the server follows the model of the base email specification in RFC 5321; this extension does not change those circumstances or reply messages.
メッセージは他の理由で拒否された場合、サーバーは、RFC 5321でベースの電子メールの仕様のモデルに従います。この拡張機能は、それらの状況を変更したり、メッセージを返信しません。
If a message is rejected after the final "." of the DATA command because one or more recipients are unable to accept and process a message with internationalized email headers, the reply-code "554" is used with the meaning "Transaction failed". If the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], reply code "X.6.9" [RFC5248] (see Section 4) is used to indicate this condition, meaning "UTF-8 header message cannot be transmitted to one or more recipients, so the message must be rejected".
メッセージは、最終的な後に拒否された場合、「」 1人または複数の受信者が国際化電子メールのヘッダを持つメッセージを受け入れて処理することができないので、DATAコマンドの、応答コード「554」は、「トランザクションが失敗しました」の意味で使用されています。 SMTPUTF8対応SMTPサーバは、拡張メールシステムステータスコード[RFC3463]をサポートしている場合は、[RFC5248]（セクション4を参照）は「UTF-8ヘッダーメッセージはに送信することができない意味、この状態を示すために使用されるコード「X.6.9」を返信1人または複数の受信者は、そのメッセージが」拒否されなければなりません。
The SMTPUTF8-aware SMTP servers are encouraged to detect that recipients cannot accept internationalized messages and generate an error after the RCPT command rather than waiting until after the DATA command to issue an error.
SMTPUTF8対応のSMTPサーバーは、受信者が国際化されたメッセージを受け入れ、むしろエラーを発行するために、DATAコマンドの後まで待つよりも、RCPTコマンドの後にエラーを発生させることができないことを検出することが推奨されています。
The MAIL command parameter SMTPUTF8 asserts that a message is an internationalized message or the message being sent needs the SMTPUTF8 support. There is still a chance that a message being sent via the MAIL command with the SMTPUTF8 parameter is not an internationalized message. An SMTPUTF8-aware SMTP client or server that requires accurate knowledge of whether a message is internationalized needs to parse all message header fields and MIME header fields [RFC2045] in the message body. However, this specification does not require that the SMTPUTF8-aware SMTP client or server inspects the message.
MAILコマンドパラメータSMTPUTF8は、メッセージが国際化されたメッセージであるか、または送信されるメッセージはSMTPUTF8サポートを必要と主張しています。 SMTPUTF8パラメータをMAILコマンドを経由して送信されたメッセージが国際化されたメッセージではない可能性がまだあります。メッセージがすべてのメッセージヘッダフィールドおよびメッセージ本文にMIMEヘッダフィールド[RFC2045]を解析する国際必要であるかどうかの正確な知識を必要とSMTPUTF8対応SMTPクライアントまたはサーバ。しかし、この仕様はSMTPUTF8対応のSMTPクライアントやサーバがメッセージを検査する必要はありません。
Although this specification requires that SMTPUTF8-aware SMTP servers support the 8BITMIME extension [RFC6152] to ensure that servers have adequate handling capability for 8-bit data, it does not require non-ASCII body parts in the MIME message as specified in RFC 2045. The SMTPUTF8 extension MAY be used as follows (assuming it is appropriate given the body content):
この仕様はSMTPUTF8対応のSMTPサーバはサーバが8ビットのデータのための十分な処理能力を持っていることを確実にするために、8BITMIME拡張[RFC6152]をサポートすることを必要としますが、RFC 2045で指定されているように、MIMEメッセージ内の非ASCII本体の部品を必要としません。 SMTPUTF8拡張は、（それが本文コンテンツ所与適切であると仮定して）次のように使用され得ます。
- with the BODY=8BITMIME parameter [RFC6152], or
- BODY = 8BITMIMEパラメータ[RFC6152]と、又は
- with the BODY=BINARYMIME parameter, if the SMTP server advertises BINARYMIME [RFC3030].
- BODY = BINARYMIMEパラメータを使用して、SMTPサーバがBINARYMIMEをアドバタイズする場合、[RFC3030]。
The information carried in the mail transport process involves addresses ("mailboxes") and domain names in various contexts in addition to the MAIL and RCPT commands and extended alternatives to them. In general, the rule is that, when RFC 5321 specifies a mailbox, this SMTP extension requires UTF-8 form to be used for the entire string. When RFC 5321 specifies a domain name, the internationalized domain name SHOULD be in U-label form if the SMTPUTF8 extension is supported; otherwise, it SHOULD be in A-label form.
メール輸送過程で運ばれた情報は、MAILとRCPTコマンドとそれらに拡張された代替品に加えて、さまざまなコンテキストでのアドレス（「メールボックス」）とドメイン名を必要とします。一般的に、ルールは、RFC 5321のメールボックスを指定した場合、このSMTP拡張は、文字列全体に使用されるUTF-8形式を必要とする、ということです。 RFC 5321には、ドメイン名を指定するとSMTPUTF8拡張機能がサポートされている場合、国際化ドメイン名は、U-ラベル形式でなければなりません。それ以外の場合は、ラベルの形式でなければなりません。
The following subsections list and discuss all of the relevant cases.
以下のサブセクションでは、リストと関連する例すべてを議論します。
When an SMTP connection is opened, the SMTP server sends a "greeting" response consisting of the 220 reply-code and some information. The SMTP client then sends the EHLO command. Since the SMTP client cannot know whether the SMTP server supports SMTPUTF8 until after it receives the response to the EHLO, the SMTPUTF8-aware SMTP client MUST send only ASCII (LDH label or A-label [RFC5890]) domains in the EHLO command. If the SMTPUTF8-aware SMTP server provides domain names in the EHLO response, they MUST be in the form of LDH labels or A-labels.
SMTP接続が開かれたときに、SMTPサーバ220は、応答コードといくつかの情報からなる「挨拶」応答を送信します。 SMTPクライアントは、EHLOコマンドを送信します。 SMTPクライアントがSMTPサーバーは、それがEHLOに対する応答を受信するまでSMTPUTF8をサポートしているかどうかを知ることができないので、SMTPUTF8対応のSMTPクライアントはASCII（LDHラベルまたはラベル[RFC5890]）EHLOコマンドでドメインを送らなければなりません。 SMTPUTF8対応のSMTPサーバーがEHLO応答でドメイン名を提供する場合、彼らはLDHのラベルやA-ラベルの形式でなければなりません。
If multiple DNS MX records are used to specify multiple servers for a domain (as described in Section 5 of RFC 5321 [RFC5321]), it is strongly advised that all or none of them SHOULD support the SMTPUTF8 extension. Otherwise, unexpected rejections can happen during temporary or permanent failures, which users might perceive as serious reliability issues.
複数のDNSのMXレコードが（RFC 5321のセクション5 [RFC5321]で説明したように）ドメインの複数のサーバを指定するために使用されている場合は、強く、全てまたはそれらのどれもがSMTPUTF8拡張をサポートすべきであることをお勧めします。それ以外の場合は、予想外の拒否は、ユーザーが深刻な信頼性の問題として認識する可能性がある、一時的または恒久的な障害時に発生する可能性があります。
The trace information <Return-path-line>, <Time-stamp-line>, and their related rules are defined in Section 4.4 of RFC 5321 [RFC5321]. This document updates <Mailbox> and <Domain> to support non-ASCII characters. When the SMTPUTF8 extension is used, the 'Reverse-path' clause of the Return-path-line may include an internationalized domain name that uses the U-label form. Also, the 'Stamp' clause of the Time-stamp-line may include an internationalized domain name that uses the U-label form.
トレース情報<リターンパスライン>、<タイムスタンプライン>、およびそれらに関連するルールは、RFC 5321のセクション4.4 [RFC5321]で定義されています。この文書では、アップデート<メールボックス>と<ドメイン>非ASCII文字をサポートします。 SMTPUTF8拡張を使用する場合、リターンパスラインの「リバースパスを」句は、Uラベルフォームを使用する国際化ドメイン名を含むことができます。また、タイムスタンプ・ラインの「スタンプ」句は、U-ラベルのフォームを使用して国際化ドメイン名を含むことができます。
If the messages that include trace fields are sent by an SMTPUTF8- aware SMTP client or relay server without the SMTPUTF8 parameter included in the MAIL commands, trace field values must conform to RFC 5321 regardless of the SMTP server's capability.
トレースフィールドを含むメッセージは、MAILコマンドに含まSMTPUTF8パラメータなしSMTPUTF8-意識SMTPクライアントまたはリレーサーバによって送信された場合は、トレースフィールドの値にかかわらず、SMTPサーバーの能力のRFC 5321に準拠する必要があります。
When an SMTPUTF8-aware SMTP server adds a trace field to a message that was or will be transmitted with the SMTPUTF8 parameter included in the MAIL commands, that server SHOULD use the U-label form for internationalized domain names in the new trace field.
SMTPUTF8対応のSMTPサーバがあったか、またはMAILコマンドに含まSMTPUTF8パラメータで送信されるメッセージにトレースフィールドを追加すると、そのサーバーは、新しいトレースフィールドにおける国際化ドメイン名のためにU-ラベルの形式を使用すべきです。
The protocol value of the 'WITH' clause when this extension is used is one of the SMTPUTF8 values specified in the "IANA Considerations" section of this document.
この拡張が使用される句「WITH」のプロトコルの値は、この文書の「IANAの考慮事項」の項で指定さSMTPUTF8値の一つです。
If an SMTP client follows this specification and sends any MAIL commands containing the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server is permitted to use UTF-8 characters in the email address associated with 251 and 551 reply-codes, and the SMTP client MUST be able to accept and process them. If a given MAIL command does not include the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server MUST NOT return a 251 or 551 response containing a non-ASCII mailbox. Instead, it MUST transform such responses into 250 or 550 responses that do not contain non-ASCII addresses.
SMTPクライアントはこの仕様に従い、SMTPUTF8パラメータを含む任意のMAILコマンドを送信した場合、SMTPUTF8対応のSMTPサーバーは、251と551返信コードに関連付けられているメールアドレスにUTF-8文字の使用を許可され、SMTPクライアントでなければなりませんそれらを受け入れ、処理することができます。与えられたMAILコマンドはSMTPUTF8パラメータが含まれていない場合は、SMTPUTF8対応のSMTPサーバーは、非ASCIIのメールボックスを含む251か551応答を返してはなりません。代わりに、非ASCIIアドレスが含まれていない250や550レスポンスにそのような応答を変換する必要があります。
If the SMTPUTF8 parameter is transmitted with the VRFY and EXPN commands, it indicates that the SMTP client can accept UTF-8 strings in replies to those commands. The parameter with the VRFY and EXPN commands SHOULD only be used after the SMTP client sees the EHLO response with the SMTPUTF8 keyword. This allows an SMTPUTF8-aware SMTP server to use UTF-8 strings in mailbox names and full names that occur in replies, without concern that the SMTP client might be confused by them. An SMTP client that conforms to this specification MUST accept and correctly process replies to the VRFY and EXPN commands that contain UTF-8 strings. However, an SMTPUTF8-aware SMTP server MUST NOT use UTF-8 strings in replies if the SMTP client does not specifically allow such replies by transmitting this parameter with the VRFY and EXPN commands.
SMTPUTF8パラメータはVRFYとEXPNコマンドで送信されている場合は、SMTPクライアントがこれらのコマンドへの応答でUTF-8文字列を受け入れることができることを示します。 VRFYとEXPNを持つパラメータはSMTPクライアントがSMTPUTF8キーワードとのEHLO応答を見た後にのみ使用するコマンド。これはSMTPUTF8対応のSMTPサーバーは、SMTPクライアントがそれらによって混同される可能性があることを気にせずに、メールボックス名と応答で発生フルネームでUTF-8文字列を使用することができます。この仕様に準拠したSMTPクライアントが受け入れなければならないと、正しくプロセスがUTF-8文字列を含むVRFYとEXPNコマンドに応答します。 SMTPクライアントは、具体的VRFYとEXPNコマンドでこのパラメータを送信することにより、このような応答を許可しない場合は、SMTPUTF8対応のSMTPサーバが応答でUTF-8文字列を使用してはなりません。
Most replies do not require that a mailbox name be included in the returned text, and therefore a UTF-8 string is not needed in them. Some replies, notably those resulting from successful execution of the VRFY and EXPN commands, do include the mailbox.
ほとんどの回答は、メールボックス名が返されたテキストに含まれていることを必要としないので、UTF-8文字列は、それらに必要とされていません。いくつかの回答、VRFYとEXPNコマンドの実行が成功したときの結果、特にこれらは、メールボックスが含まれません。
VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:
（VRFY）を確認し、EXPAND（EXPN）コマンドの構文は次のように変更されています。
vrfy = "VRFY" SP String [ SP "SMTPUTF8" ] CRLF ; String may include Non-ASCII characters
VRFY = "VRFY" SP文字列[SP "SMTPUTF8"] CRLF。文字列は、非ASCII文字を含むことができ
expn = "EXPN" SP String [ SP "SMTPUTF8" ] CRLF ; String may include Non-ASCII characters
EXPN = "EXPN" SP文字列[SP "SMTPUTF8"] CRLF。文字列は、非ASCII文字を含むことができ
The SMTPUTF8 parameter does not accept a value. If the reply to a VRFY or EXPN command requires a UTF-8 string, but the SMTP client did not use the SMTPUTF8 parameter, then the SMTPUTF8-aware SMTP server MUST use either the reply-code 252 or 550. Reply-code 252, defined in RFC 5321 [RFC5321], means "Cannot VRFY user, but will accept the message and attempt the delivery". Reply-code 550, also defined in RFC 5321 [RFC5321], means "Requested action not taken: mailbox unavailable". When the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], the enhanced reply-code as specified below is used. Using the SMTPUTF8 parameter with a VRFY or EXPN command enables UTF-8 replies for that command only.
SMTPUTF8パラメータが値を受け付けません。 VRFYまたはEXPNコマンドへの応答がUTF-8文字列が必要ですが、SMTPクライアントがSMTPUTF8パラメータを使用しなかった場合は、SMTPUTF8対応のSMTPサーバは、応答コード252または550返信コード252のいずれかを使用しなければなりませんRFC 5321 [RFC5321]で定義され、「VRFYユーザーことはできませんが、メッセージを受け入れ、配信を試みます」という意味。応答コード550、また、RFC 5321 [RFC5321]で定義され、「：利用できないメールボックスに要求されたアクションは取られない」を意味します。以下指定されているようSMTPUTF8対応のSMTPサーバーは、強化されたメールシステムステータスコード[RFC3463]、強化返信コードをサポートしているときに使用されています。 VRFYまたはEXPNコマンドでSMTPUTF8パラメータを使用するとのみ、そのコマンドのUTF-8の応答を可能にします。
If a normal success response (i.e., 250) is returned, the response MAY include the full name of the user and MUST include the mailbox of the user. It MUST be in either of the following forms:
通常の成功応答（すなわち、250）が返された場合、応答は、ユーザーのフルネームを含むことができ、ユーザーのメールボックスを含まなければなりません。これは、次のいずれかの形式でなければなりません。
User Name <Mailbox> ; Mailbox is defined in Section 3.3 of this document. ; User Name can contain non-ASCII characters.
ユーザー名<メールボックス>。メールボックスは、このドキュメントのセクション3.3で定義されています。 ;ユーザー名は非ASCII文字を含めることができます。
Mailbox ; Mailbox is defined in Section 3.3 of this document.
メールボックス;メールボックスは、このドキュメントのセクション3.3で定義されています。
If the SMTP reply requires UTF-8 strings, but a UTF-8 string is not allowed in the reply, and the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], the enhanced reply-code is "X.6.8" [RFC5248] (see Section 4), meaning "A reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the SMTP client".
SMTP応答は、UTF-8文字列が必要ですが、UTF-8文字列が応答で許可され、かつSMTPUTF8対応のSMTPサーバーが強化されたメールシステムステータスコード[RFC3463]をサポートしていない、強化返信コードが「X.6.8ある場合"[RFC5248]を意味し、（4章を参照してください）『』UTF-8文字列を含む応答がメールボックス名を表示するために必要ですが、応答の形式は、SMTPクライアントによって許可されていません。
If the SMTP client does not support the SMTPUTF8 extension, but receives a UTF-8 string in a reply, it may not be able to properly report the reply to the user, and some clients might mishandle that reply. Internationalized messages in replies are only allowed in the commands under the situations described above.
SMTPクライアントがSMTPUTF8拡張をサポートしていますが、返信にUTF-8文字列を受信しない場合は、適切にユーザーに返信を報告することができないかもしれない、といくつかのクライアントは、その返信を誤用することがあります。回答では国際化されたメッセージは、上記のような状況の下でのコマンドで許可されています。
Although UTF-8 strings are needed to represent email addresses in responses under the rules specified in this section, this extension does not permit the use of UTF-8 strings for any other purposes. SMTPUTF8-aware SMTP servers MUST NOT include non-ASCII characters in replies except in the limited cases specifically permitted in this section.
UTF-8文字列は、このセクションで指定されたルールの下での応答に電子メールアドレスを表現するために必要とされますが、この拡張機能は、他の目的のためにUTF-8文字列の使用を許可していません。 SMTPUTF8対応のSMTPサーバーでは、特にこのセクションでは許可限られた場合を除いて回答に非ASCII文字を含んではいけません。
IANA has added a new value "SMTPUTF8" to the "SMTP Service Extension" registry of the "Mail Parameters" registry, according to the following data:
IANAは、次のデータによると、「メールパラメータ」レジストリの「SMTPサービス拡張」レジストリに新しい値「SMTPUTF8」を追加しました：
+----------+---------------------------------+-----------+
| Keywords | Description | Reference |
+----------+---------------------------------+-----------+
| SMTPUTF8 | Internationalized email address | [RFC6531] |
+----------+---------------------------------+-----------+
The code definitions in this document replace those specified in RFC 5336, following the guidance in Sections 3.5 and 3.7.4.2 of this document, and based on RFC 5248 [RFC5248]. IANA has updated the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry" with the following data:
このドキュメントのコード定義はセクション3.5と、この文書の3.7.4.2でのガイダンスに従って、RFC 5336で指定されたものを交換し、RFC 5248 [RFC5248]に基づきます。 IANAは、次のデータを「簡易メール転送プロトコル（SMTP）強化されたステータスコードレジストリを」更新しました：
Code: X.6.7 Sample Text: Non-ASCII addresses not permitted for that sender/recipient Associated basic status code: 550, 553 Description: This indicates the reception of a MAIL or RCPT command that non-ASCII addresses are not permitted. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: ima@ietf.org
コード：X.6.7サンプルテキスト：その送信者/受信者関連する基本的なステータスコードのために許可されていない非ASCIIアドレス：550、553説明：これは、非ASCIIアドレスが許可されていないことをMAILやRCPTコマンドを受信したことを示します。定義された：RFC 6531（標準化過程）投稿者：Jiankang YAO変更コントローラ：ima@ietf.org
Code: X.6.8 Sample Text: UTF-8 string reply is required, but not permitted by the SMTP client Associated basic status code: 252, 550, 553 Description: This indicates that a reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the SMTP client. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: ima@ietf.org
コード：X.6.8サンプルテキスト：UTF-8文字列の応答が必要ですが、基本的なステータスコード関連SMTPクライアントによって許可されていない：252、550、553説明：これは、UTF-8文字列を含む応答を示すことが必要であることを示しメールボックス名が、応答の形式は、SMTPクライアントによって許可されていません。定義された：RFC 6531（標準化過程）投稿者：Jiankang YAO変更コントローラ：ima@ietf.org
Code: X.6.9 Sample Text: UTF-8 header message cannot be transferred to one or more recipients, so the message must be rejected Associated basic status code: 550 Description: This indicates that transaction failed after the final "." of the DATA command. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: ima@ietf.org
コード：サンプルテキストX.6.9：UTF-8ヘッダーメッセージは、1人のまたは複数の受信者に転送することができないので、メッセージは、関連する基本的なステータスコードを拒否しなければならない：550説明：これは、そのトランザクションが最終の後に失敗したことを示し、「」 DATAコマンドの。定義された：RFC 6531（標準化過程）投稿者：Jiankang YAO変更コントローラ：ima@ietf.org
Code: X.6.10 Description: This is a duplicate of X.6.8 and is thus deprecated.
コード：X.6.10説明：これはX.6.8の複製であるため、推奨されていません。
4.3. WITH Protocol Types Sub-Registry of the Mail Transmission Types Registry
4.3. メール送信タイプレジストリのプロトコルタイプサブレジストリWITH
IANA has modified or added the following entries in the "WITH protocol types" sub-registry under the "Mail Transmission Types" registry.
IANAは、修飾されたまたは「メール送信タイプ」レジストリ下の「プロトコルタイプと」サブレジストリに次のエントリを追加しました。
+--------------+------------------------------+---------------------+
| WITH | Description | Reference |
| protocol | | |
| types | | |
+--------------+------------------------------+---------------------+
| UTF8SMTP | ESMTP with SMTPUTF8 | [RFC6531] |
| UTF8SMTPA | ESMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] |
| UTF8SMTPS | ESMTP with SMTPUTF8 and | [RFC3207] [RFC6531] |
| | STARTTLS | |
| UTF8SMTPSA | ESMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] |
| | STARTTLS and AUTH | [RFC6531] |
| UTF8LMTP | LMTP with SMTPUTF8 | [RFC6531] |
| UTF8LMTPA | LMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] |
| UTF8LMTPS | LMTP with SMTPUTF8 and | [RFC3207] [RFC6531] |
| | STARTTLS | |
| UTF8LMTPSA | LMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] |
| | STARTTLS and AUTH | [RFC6531] |
+--------------+------------------------------+---------------------+
The extended security considerations discussion in the framework document [RFC6530] applies here.
フレームワークドキュメント[RFC6530]の拡張セキュリティの考慮事項の議論はここに適用されます。
More security considerations are discussed below:
その他のセキュリティの考慮事項は、以下で説明されています。
Beyond the use inside the email global system (in SMTP envelopes and message headers), internationalized email addresses will also show up inside other cases, in particular:
（SMTPエンベロープやメッセージヘッダ内）、電子メールグローバル・システム内の使用以外にも、国際化電子メールアドレスは、他の場合、特に内側に表示されます：
o the logging systems of SMTP transactions and other logs to monitor the email systems;
SMTPトランザクションおよび電子メールシステムを監視するために他のログのロギングシステムO;
o the trouble ticket systems used by security teams to manage security incidents, when an email address is involved;
電子メールアドレスが含まれている場合は、セキュリティインシデントを管理するためのセキュリティチームが使用するトラブルチケットシステムO;
In order to avoid problems that could cause loss of data, this will likely require extending these systems to support full UTF-8, or require providing an adequate mechanism for mapping non-ASCII strings to ASCII.
データの損失を引き起こす可能性の問題を避けるために、これはおそらく完全なUTF-8をサポートする、またはASCIIに非ASCII文字列をマッピングするための適切なメカニズムを提供する必要がために、これらのシステムを拡張する必要があります。
Another security aspect to be considered is related to the ability by security team members to quickly understand, read, and identify email addresses from the logs, when they are tracking an incident. Mechanisms to automatically and quickly provide the origin or ownership of an internationalized email address SHALL be implemented for use by log readers that cannot easily read non-ASCII information.
考慮すべきもう一つのセキュリティ面を素早く理解読んで、そして、彼らは事件を追跡しているとき、ログからの電子メールアドレスを識別するためのセキュリティチームのメンバーによって能力に関連しています。自動的にかつ迅速に国際化電子メールアドレスの起源や所有権を提供するためのメカニズムを簡単に非ASCII情報を読み取ることができないログ・リーダーで使用するために実施されなければなりません。
The SMTP commands VRFY and EXPN are sometimes used in SMTP transactions where there is no message to transfer (by tools used to take automated actions in case potential spam messages are identified). Sections 3.5 and 7.3 of RFC 5321 give detailed descriptions of use and possible behaviors. Implementation of internationalized addresses can also affect logs and actions by these tools.
SMTPは、（潜在的なスパムメッセージが識別されている場合には自動化された行動をとるために使用されるツールで）転送するメッセージがないところVRFYとEXPNが時々SMTPトランザクションで使用されるコマンド。セクション3.5およびRFC 5321の7.3には、使用し、可能な行動の詳細な説明を与えます。国際アドレスの実装は、これらのツールによって、ログや行動に影響を与えることができます。
This document revises RFC 5336 [RFC5336] based on the result of the Email Address Internationalization (EAI) working group's discussion. Many EAI working group members did tests and implementations to move this document to the Standards Track. Significant comments and suggestions were received from Xiaodong LEE, Nai-Wen HSU, Yangwoo KO, Yoshiro YONEYA, and other members of JET and were incorporated into the specification. Additional important comments and suggestions, and often specific text, were contributed by many members of the working group and design team. Those contributions include material from John C. Klensin, Charles Lindsey, Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, Joseph Yee, and Lars Eggert. Of course, none of the individuals are necessarily responsible for the combination of ideas represented here.
この文書では、メールアドレスの国際化（EAI）ワーキンググループの議論の結果に基づいて、RFC 5336 [RFC5336]を改訂します。多くのEAIワーキンググループのメンバーは標準化過程にこの文書を移動するためのテストと実装を行いました。重要なコメントや提案は暁東LEE、ナイ・ウェンHSU、Yangwoo KO、義郎米谷、及びJETの他のメンバーから受信し、明細書に組み込まれました。追加の重要なコメントや提案、そして多くの場合、特定のテキストは、ワーキンググループとデザインチームの多くのメンバーによって寄与されました。これらの貢献は、ジョンC. Klensin、チャールズリンジー、デイブ・クロッカー、ハラルド・トバイット・アルベストランド、マルコス・サンス、クリス・ニューマン、マーティンDuerst、エドモンチャン、トニー・フィンチ、カリHurtta、ランドールGellens、フランクEllermann、アレクセイ・メルニコフ、ピートレズニックからの材料を含みますS. Moonesamy、Soobokリー、ショーン・スティール、アルフレッドHoenes、ミゲル・ガルシア、マグヌスウェスター、ジョセフ・イー、およびラースエッゲルト。もちろん、個人のいずれもが、必ずしもここに表さアイデアの組み合わせの責任ではありません。
Thanks a lot to Dave Crocker for his comments and helping with ABNF refinement.
おかげデイブクロッカーに多くの彼のコメントとABNFの洗練を手伝っ。
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.
[ASCII]米国規格協会（アメリカ規格協会の旧米国）、「情報交換用米国コード」、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC3461]ムーア、K.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、RFC 3461、2003年1月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RFC3463]ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、RFC 3463、2003年1月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC3464]ムーア、K.とG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、RFC 3464、2003年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 3629、2003年11月。
[RFC3848] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004.
[RFC3848]ニューマン、C.、 "ESMTPとLMTP伝送タイプの登録"、RFC 3848、2004年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", RFC 5248, June 2008.
[RFC5248]ハンセン、T.およびJ. Klensin、 "SMTP拡張メールシステムステータスコードのレジストリ"、RFC 5248、2008年6月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。
[RFC5890] Klensin, J., "Internationalizing Domain Names in Applications (IDNA definitions)", RFC 5890, June 2010.
[RFC5890] Klensin、J.、 "アプリケーション（IDNA定義）における国際化ドメイン名"、RFC 5890、2010年6月。
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.
[RFC6152] Klensin、J.、フリード、N.、ローズ、M.、およびD.クロッカー、 "8ビットMIMEトランスポートのためのSMTPサービス拡張"、STD 71、RFC 6152、2011年3月。
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.
[RFC6409] Gellens、R.及びJ. Klensin、 "メール用のメッセージ送信"、STD 72、RFC 6409、2011年11月。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
[RFC6530] Klensin、J.とY.コ、 "国際電子メールのための概要とフレームワーク"、RFC 6530、2012年2月。
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.
[RFC6532]ヤン、A.、スティール、S.、およびN.フリード、 "国際電子メールヘッダ"、RFC 6532、2012年2月。
[RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., "Internationalized Delivery Status and Disposition Notifications", RFC RFC6533, February 2012.
[RFC6533]ハンセン、T.、エド。、ニューマン、C.、およびA.メルニコフ、エド。、 "国際配送状況や処分通知"、RFC RFC6533、2012年2月。
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[RFC2033]マイヤーズ、J.、 "ローカルメール転送プロトコル"、RFC 2033、1996年10月。
[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）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[RFC3030]ヴォードルイユ、G.、RFC 3030、2000年12月 "大規模およびバイナリMIMEメッセージの送信のためのSMTPサービス拡張"。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207]ホフマン、P.、 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"、RFC 3207、2002年2月。
[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[RFC4954] Siemborski、R.とA.メルニコフ、 "認証のためのSMTPサービス拡張子"、RFC 4954、2007年7月。
[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.
[RFC5336]八尾、J.とW.真央、 "国際化メールアドレスのSMTP拡張"、RFC 5336、2008年9月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598]クロッカー、D.、 "インターネットメールのアーキテクチャ"、RFC 5598、2009年7月。
Authors' Addresses
著者のアドレス
Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China
J私の健康Y AO CNNICの4番南4TH通り、Z肉眼インチ北京中国
Phone: +86 10 58813007 EMail: yaojk@cnnic.cn
電話：+86 10 58813007 Eメール：yaojk@cnnic.cn
Wei MAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China
魏真央CNNICの4番南4TH通り、Zマクロインチ北京中国
Phone: +86 10 58812230 EMail: maowei_ietf@cnnic.cn
電話：+86 10 58812230 Eメール：maowei_ietf@cnnic.cn