メインコンテンツまでスキップ

RFC 6531 - SMTP Extension for Internationalized Email

  • ステータス: Proposed Standard
  • 発行日: February 2012
  • ストリーム: IETF
  • 廃止: RFC5336
  • エラッタ: エラッタなし

Document Information​

  • RFC Number: 6531
  • Title: SMTP Extension for Internationalized Email
  • Authors: J. Yao, W. Mao
  • Date: February 2012
  • Category: Standards Track
  • Obsoletes: RFC 5336
  • ISSN: 2070-1721

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. このドキュメントはInternet Engineering Task Force（IETF）の製品です。これはIETFコミュニティの総意を表しています。公開レビューを受け、Internet Engineering Steering Group（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 (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Copyright (c) 2012 IETF Trustおよびドキュメントの著者として特定された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETF Trustの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust法的規定のセクション4.eで説明されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseで説明されているように保証なしで提供されます。

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. このドキュメントには、2008年11月10日より前に公開または一般公開されたIETFドキュメントまたはIETF寄稿からの資料が含まれている場合があります。この資料の一部の著作権を管理する人物は、IETF標準化プロセス外でそのような資料の変更を許可する権利をIETF Trustに付与していない可能性があります。そのような資料の著作権を管理する人物から適切なライセンスを取得しない限り、このドキュメントはIETF標準化プロセス外で変更することはできず、RFCとして公開するためにフォーマットする場合や英語以外の言語に翻訳する場合を除き、IETF標準化プロセス外でその派生作品を作成することはできません。

Table of Contents​

  1. Introduction
  2. Overview of Operation
  3. Mail Transport-Level Protocol
  4. IANA Considerations
  5. Security Considerations
  6. Acknowledgements
  7. References

1. Introduction​

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]を受け入れて処理する機能をアドバタイズできるように、Simple Mail Transfer Protocol [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. 国際化された電子メールアドレスと電子メールヘッダーの拡張モデルの拡張概要は、RFC 6530 [RFC6530]に記載されており、この仕様では「フレームワークドキュメント」と呼ばれています。

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. この仕様を理解し実装するには、そのドキュメントおよび基本的なインターネット電子メール仕様[RFC5321] [RFC5322]の情報を十分に理解する必要があります。

1.1. Terminology​

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. 用語「UTF-8文字列」または「UTF-8文字」は、標準のUnicodeエンコーディング形式であるUTF-8 [RFC3629]において、ASCIIサブセットのメンバーであるかどうかにかかわらず、Unicode文字を指すために使用されます。

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]. 特に、「ASCIIアドレス」、「国際化された電子メールアドレス」、「非ASCIIアドレス」、「SMTPUTF8」、「国際化されたメッセージ」、および「メッセージ」という用語は、フレームワークドキュメント[RFC6530]の定義に従ってこのドキュメントで使用されます。

Strings referred to in this document, including ASCII strings, MUST be expressed in UTF-8. このドキュメントで参照される文字列は、ASCII文字列を含め、UTF-8で表現されなければなりません（MUST）。

This specification uses Augmented BNF (ABNF) rules [RFC5234]. この仕様では、Augmented BNF（ABNF）ルール[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]. このドキュメントのいくつかの基本的なルールは、セクション3.3で、RFC 5234 [RFC5234]、RFC 5321 [RFC5321]、RFC 5890 [RFC5890]、またはRFC 6532 [RFC6532]で（同じ名前で）定義されているものとして識別されます。

1.2. Changes Made to Other Specifications​

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. この仕様は、RFC 5321で定義されているいくつかの構文規則を拡張し、エンベロープおよびトレースフィールドでの国際化された電子メールアドレスを許可しますが、RFC 5321は変更しません。

It permits data formats defined in RFC 6532 [RFC6532], but it does not modify RFC 5322. RFC 6532 [RFC6532]で定義されているデータ形式を許可しますが、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. SMTPUTF8対応SMTPサーバーによって8BITMIME拡張[RFC6152]がアナウンスされ、SMTPUTF8対応SMTPクライアントによって "BODY=8BITMIME" とともに使用されることを要求しますが、8BITMIME仕様はいかなる方法でも変更しません。

This specification replaces an earlier, experimental, approach to the same problem [RFC5336]. この仕様は、同じ問題に対する以前の実験的なアプローチ[RFC5336]を置き換えます。

Section 6 of RFC 6530 [RFC6530] describes the changes in approach between RFC 5336 [RFC5336] and this specification. RFC 6530 [RFC6530]のセクション6では、RFC 5336 [RFC5336]とこの仕様の間のアプローチの変更について説明しています。

Anyone trying to convert an implementation from the experimental specification to the specification in this document will need to review those changes carefully. 実験的な仕様からこのドキュメントの仕様に実装を変換しようとする人は、それらの変更を注意深く確認する必要があります。

2. Overview of Operation​

This document specifies an element of the email internationalization work, specifically the definition of an SMTP extension for internationalized email. このドキュメントは、電子メール国際化作業の要素、具体的には国際化された電子メールのためのSMTP拡張の定義を指定します。

The extension is identified with the token "SMTPUTF8". この拡張は、トークン "SMTPUTF8" で識別されます。

The internationalized email headers specification [RFC6532] provides the details of email header features enabled by this extension. 国際化された電子メールヘッダー仕様[RFC6532]は、この拡張によって有効になる電子メールヘッダー機能の詳細を提供します。

3. Mail Transport-Level Protocol​

3.1. Framework for the Internationalization Extension​

The following service extension is defined: 以下のサービス拡張が定義されています。

  1. The name of the SMTP service extension is "Internationalized Email".

  2. SMTPサービス拡張の名前は "Internationalized Email" です。

  3. The EHLO keyword value associated with this extension is "SMTPUTF8".

  4. この拡張に関連付けられたEHLOキーワード値は "SMTPUTF8" です。

  5. 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.

  6. このEHLOキーワード値にはパラメータ値が定義されていません。将来の（予期しないものではありますが）拡張を許可するために、EHLO応答にはこのキーワードのパラメータを含めてはなりません（MUST NOT）。SMTPUTF8対応SMTPクライアントは、このキーワードにパラメータが表示される場合、それらを無視しなければなりません（MUST）。つまり、SMTPUTF8対応SMTPクライアントは、パラメータが表示されないかのように振る舞わなければなりません（MUST）。SMTPサーバーがEHLO応答にSMTPUTF8を含める場合、この仕様のこのバージョンに完全に準拠していなければなりません（MUST）。

  7. 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.

  8. MAILコマンドに1つのOPTIONALパラメータ、SMTPUTF8が追加されます。このパラメータは値を受け入れません。このパラメータがMAILコマンドで設定されている場合、SMTPクライアントがSMTPUTF8対応であることを示します。その存在はまた、エンベロープに非ASCIIアドレスが含まれていること、送信されるメッセージが国際化されたメッセージであること、または送信されるメッセージがSMTPUTF8サポートを必要としていることを主張します。

  9. The maximum length of a MAIL command line is increased by 10 characters to accommodate the possible addition of the SMTPUTF8 parameter.

  10. MAILコマンドラインの最大長は、SMTPUTF8パラメータの追加の可能性に対応するために10文字増加します。

  11. 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.

  12. VERIFY（VRFY）およびEXPAND（EXPN）コマンドに1つのOPTIONALパラメータ、SMTPUTF8が追加されます。SMTPUTF8パラメータは値を受け入れません。このパラメータは、SMTPクライアントがVRFYおよびEXPNコマンドからの応答でUTF-8エンコーディングのUnicode文字を受け入れることができることを示します。

  13. No additional SMTP verbs are defined by this extension.

  14. この拡張によって追加のSMTP動詞は定義されません。

  15. Servers offering this extension MUST provide support for, and announce, the 8BITMIME extension [RFC6152].

  16. この拡張を提供するサーバーは、8BITMIME拡張[RFC6152]のサポートを提供し、アナウンスしなければなりません（MUST）。

  17. 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).

  18. SMTP MAILおよびRCPTコマンドのリバースパスおよびフォワードパスは、メールボックス名（アドレス）でUTF-8でエンコードされたUnicode文字を許可するように拡張されます。

  19. The mail message body is extended as specified in RFC 6532 [RFC6532].

  20. メールメッセージ本文は、RFC 6532 [RFC6532]で指定されているように拡張されます。

  21. 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].

  22. SMTPUTF8拡張は、サブミッションポート[RFC6409]で有効です。Local Mail Transfer Protocol（LMTP）[RFC2033]とともに使用することもできます。これらのプロトコルが使用される場合、その使用はトレースフィールドのWITHキーワードに適宜反映されるべきです[RFC3848]。

3.2. The SMTPUTF8 Extension​

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. SMTPUTF8拡張をアナウンスするSMTPサーバーは、RFC 5321が <mailbox> が出現できると指定している任意の位置でUTF-8文字列[RFC3629]を受け入れる準備ができていなければなりません（MUST）。

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]. <local-part> 内の文字には非ASCII文字を含めることが許可されていますが、<local-part> の実際の解析と使用される区切り文字は、基本的な電子メール仕様[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]. DNSで検索されるドメイン名は、Internationalizing Domain Names in Applications（IDNA）[RFC5890]で指定されているように準拠し、処理されなければなりません（MUST）。

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クライアントまたはサーバーは、Unicode対応DNSライブラリを使用するか、RFC 5890 [RFC5890]で指定されているように、国際化ドメイン名をAラベル形式（つまり、1つ以上のAラベルを含むがUラベルを含まない完全修飾ドメイン名）に変換しなければなりません（MUST）。

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. EHLOコマンドへの応答としてSMTPUTF8拡張キーワードを受信するSMTPクライアントは、SMTPコマンド内のメールボックス名をUTF-8形式の国際化文字列として送信してもよいです（MAY）。

It MAY send a UTF-8 header [RFC6532] (which may also include mailbox names in UTF-8). UTF-8ヘッダー[RFC6532]（UTF-8のメールボックス名も含む場合があります）を送信してもよいです（MAY）。

It MAY transmit the domain parts of mailbox names within SMTP commands or the message header as A-labels or U-labels [RFC5890]. SMTPコマンドまたはメッセージヘッダー内のメールボックス名のドメイン部分をAラベルまたはUラベル[RFC5890]として送信してもよいです（MAY）。

The presence of the SMTPUTF8 extension does not change the server-relaying behaviors described in RFC 5321. 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]. SMTPUTF8 SMTP拡張がSMTPサーバーによって提供されていない場合、SMTPUTF8対応SMTPクライアントは、国際化された電子メールアドレスを送信してはならず（MUST NOT）、RFC 6532 [RFC6532]で説明されている国際化されたメールヘッダーを含むメールメッセージを、そのMIME構造[RFC2045]内のいかなるレベルでも送信してはなりません（MUST NOT）。

(For this paragraph, the internationalized domain name in A-label form as specified in IDNA definitions [RFC5890] is not considered to be "internationalized".) （この段落では、IDNA定義[RFC5890]で指定されているAラベル形式の国際化ドメイン名は、「国際化」されているとは見なされません。）

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. 代わりに、SMTPUTF8対応SMTPクライアント（送信者）が国際化されたメッセージを転送しようとし、拡張をサポートしていないSMTPサーバーに遭遇した場合、取るべき最善のアクションは他の条件によって異なります。

In particular: 具体的には：

  • 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]である場合、RFC 6409で許可されているアドレスの変更やその他のメッセージの修正および変換に関する広範な裁量を使用して、このシナリオに対処する独自の方法を選択してもよいです（MAY）。結果として得られるメッセージがRFC 5321の要件（つまり、SMTPUTF8拡張なし）に準拠している限り、その変換の詳細は、このドキュメントの範囲外です。

  • 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拡張を必要としないメッセージに変換することを選択しない場合、メッセージを拒否すべきです（SHOULD）。通常通り、これはSMTPトランザクション中に適切な応答を生成するか、メッセージを受け入れてから配信不能通知を生成して送信することによって行うことができます。後者の選択が行われた場合、通知プロセスはRFC 5321、RFC 3464 [RFC3464]、およびRFC 6533 [RFC6533]の要件に準拠しなければなりません（MUST）。

  • 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で指定されているように、追加情報や特別な状況に関する知識を持つSMTPクライアントは、そのセクションで指定されているように、メッセージを再キューイングして後で試行したり、代替のMXホストを試行したりすることを選択してもよいです（MAY）。

This document applies when an SMTPUTF8-aware SMTP client or server supports the SMTPUTF8 extension. このドキュメントは、SMTPUTF8対応SMTPクライアントまたはサーバーがSMTPUTF8拡張をサポートしている場合に適用されます。

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拡張を必要としないアドレスとメッセージについては、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サーバーがDelivery Status Notification（DSN）[RFC3461]拡張をアドバタイズする場合、RFC 6533 [RFC6533]を実装しなければなりません（MUST）。

3.3. Extended Mailbox Address Syntax​

RFC 5321, Section 4.1.2, defines the syntax of a <Mailbox> entirely in terms of ASCII characters. RFC 5321のセクション4.1.2では、<Mailbox> の構文を完全にASCII文字で定義しています。

This document extends <Mailbox> to add support of non-ASCII characters. このドキュメントでは、<Mailbox> を拡張して、非ASCII文字のサポートを追加します。

The key changes made by this specification include: この仕様による主な変更点は次のとおりです。

  • 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.

  • <Mailbox> ABNFルールはRFC 5321からインポートされ、国際化された電子メールアドレスをサポートするために更新されています。その他の関連ルールは、RFC 5321、RFC 5234、RFC 5890、およびRFC 6532からインポートされるか、このドキュメントで拡張されています。

  • 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].

  • <sub-domain> の定義は拡張され、RFC 5321定義と、IDNA定義[RFC5890]に準拠するDNSラベル内のUTF-8文字列の両方を許可します。

  • 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.

  • <atext> の定義は拡張され、RFC 5321定義とUTF-8文字列の両方を許可します。その文字列には、ASCIIグラフィックまたは制御文字を含めてはなりません（MUST NOT）。

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ルールは、このドキュメントによって直接的または間接的に更新されます。

  • <Mailbox>
  • <Local-part>
  • <Dot-string>
  • <Quoted-string>
  • <QcontentSMTP>
  • <Domain>
  • <Atom>

The following ABNF rule will be imported from RFC 6532, Section 3.1, directly: 以下のABNFルールは、RFC 6532のセクション3.1から直接インポートされます。

  • <UTF8-non-ascii>

The following ABNF rule will be imported from RFC 5234, Appendix B.1, directly: 以下のABNFルールは、RFC 5234の付録B.1から直接インポートされます。

  • <DQUOTE>

The following ABNF rule will be imported from RFC 5890, Section 2.3.2.1, directly: 以下のABNFルールは、RFC 5890のセクション2.3.2.1から直接インポートされます。

  • <U-label>

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

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

qtextSMTP  =/ UTF8-non-ascii
 ; extend the definition of qtextSMTP in RFC 5321, Section 4.1.2

esmtp-value  =/ UTF8-non-ascii
 ; extend the definition of esmtp-value in RFC 5321, Section 4.1.2

3.4. MAIL Command Parameter Usage​

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. 送信されるエンベロープまたはメッセージがSMTPUTF8拡張の機能を必要とする場合、SMTPUTF8対応SMTPクライアントは、MAILコマンドでSMTPUTF8パラメータを提供しなければなりません（MUST）。

If this parameter is provided, it MUST not accept a value. このパラメータが提供される場合、値を受け入れてはなりません（MUST）。

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対応SMTPクライアントが、送信されるエンベロープもメッセージもSMTPUTF8拡張機能を必要としないことを認識している場合、MAILコマンドでSMTPUTF8パラメータを提供すべきではありません（SHOULD NOT）。

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. ネクストホップのSMTPサーバーがSMTPUTF8拡張をサポートするという保証はないため、SMTPUTF8拡張の使用には常に送信失敗のリスクが伴います。

In fact, during the early stages of deployment for the SMTPUTF8 extension, the risk will be quite high. 実際、SMTPUTF8拡張の展開の初期段階では、リスクは非常に高くなります。

Hence, there is a distinct near-term advantage for ASCII-only messages to be sent without using this extension. したがって、ASCIIのみのメッセージをこの拡張を使用せずに送信することには、当面の間、明確な利点があります。

The long-term advantage of casting ASCII [ASCII] characters (0x7f and below) as UTF-8 form is that it permits pure-Unicode environments. ASCII [ASCII]文字（0x7f以下）をUTF-8形式にキャストすることの長期的な利点は、純粋なUnicode環境を許可することです。

3.5. Non-ASCII Addresses and Reply-Codes​

An SMTPUTF8-aware SMTP client MUST NOT send an internationalized message to an SMTP server that does not support SMTPUTF8. SMTPUTF8対応SMTPクライアントは、SMTPUTF8をサポートしていないSMTPサーバーに国際化されたメッセージを送信してはなりません（MUST NOT）。

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. 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. このセクションで使用される3桁の応答コードは、RFC 5321で定義されている意味に基づいています。

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". RCPTコマンドがASCIIアドレスを必要とするためにメッセージが拒否される場合、応答コード553が返され、意味は「メールボックス名が許可されていません」となります。

When messages are rejected because the MAIL command requires an ASCII address, the reply-code 550 is returned with the meaning "mailbox unavailable". MAILコマンドがASCIIアドレスを必要とするためにメッセージが拒否される場合、応答コード550が返され、意味は「メールボックスが利用できません」となります。

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". SMTPUTF8対応SMTPサーバーが拡張メールシステムステータスコード[RFC3463]をサポートしている場合、応答コード "X.6.7" [RFC5248]（セクション4を参照）が使用され、意味は「その送信者/受信者には非ASCIIアドレスは許可されていません」となります。

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". 1つ以上の受信者が国際化された電子メールヘッダーを持つメッセージを受け入れて処理できないために、DATAコマンドの最後の "." の後にメッセージが拒否された場合、応答コード "554" が使用され、意味は「トランザクションに失敗しました」となります。

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". SMTPUTF8対応SMTPサーバーが拡張メールシステムステータスコード[RFC3463]をサポートしている場合、この状態を示すために応答コード "X.6.9" [RFC5248]（セクション4を参照）が使用され、意味は「UTF-8ヘッダーメッセージを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コマンドの後にエラーを生成することが推奨されます。

3.6. Body Parts and SMTP Extensions​

The MAIL command parameter SMTPUTF8 asserts that a message is an internationalized message or the message being sent needs the SMTPUTF8 support. MAILコマンドパラメータSMTPUTF8は、メッセージが国際化されたメッセージであるか、送信されるメッセージがSMTPUTF8サポートを必要としていることを主張します。

There is still a chance that a message being sent via the MAIL command with the SMTPUTF8 parameter is not an internationalized message. SMTPUTF8パラメータを使用したMAILコマンドを介して送信されるメッセージが国際化されたメッセージではない可能性はまだあります。

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. メッセージが国際化されているかどうかについての正確な知識を必要とするSMTPUTF8対応SMTPクライアントまたはサーバーは、メッセージ本文内のすべてのメッセージヘッダーフィールドとMIMEヘッダーフィールド[RFC2045]を解析する必要があります。

However, this specification does not require that the SMTPUTF8-aware SMTP client or server inspects the message. ただし、この仕様では、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. この仕様では、サーバーが8ビットデータの適切な処理能力を持つことを保証するために、SMTPUTF8対応SMTPサーバーが8BITMIME拡張[RFC6152]をサポートすることを要求していますが、RFC 2045で指定されているMIMEメッセージ内の非ASCIIボディパーツは要求していません。

The SMTPUTF8 extension MAY be used as follows (assuming it is appropriate given the body content): SMTPUTF8拡張は次のように使用してもよいです（MAY）（本文の内容を考慮して適切であると仮定して）：

  • with the BODY=8BITMIME parameter [RFC6152], or

  • BODY=8BITMIMEパラメータ[RFC6152]とともに、または

  • with the BODY=BINARYMIME parameter, if the SMTP server advertises BINARYMIME [RFC3030].

  • SMTPサーバーがBINARYMIME [RFC3030]をアドバタイズする場合、BODY=BINARYMIMEパラメータとともに。

3.7. Additional ESMTP Changes and Clarifications​

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. メール転送プロセスで運ばれる情報には、MAILおよびRCPTコマンドとその拡張代替手段に加えて、さまざまなコンテキストでのアドレス（「メールボックス」）およびドメイン名が含まれます。

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. 一般に、ルールは、RFC 5321がメールボックスを指定する場合、このSMTP拡張では文字列全体にUTF-8形式を使用する必要があるということです。

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. RFC 5321がドメイン名を指定する場合、SMTPUTF8拡張がサポートされている場合、国際化ドメイン名はUラベル形式であるべきです（SHOULD）。そうでない場合は、Aラベル形式であるべきです（SHOULD）。

The following subsections list and discuss all of the relevant cases. 以下のサブセクションでは、関連するすべてのケースをリストし、説明します。

3.7.1. The Initial SMTP Exchange​

When an SMTP connection is opened, the SMTP server sends a "greeting" response consisting of the 220 reply-code and some information. SMTP接続が開かれると、SMTPサーバーは220応答コードといくつかの情報で構成される「グリーティング」応答を送信します。

The SMTP client then sends the EHLO command. その後、SMTPクライアントはEHLOコマンドを送信します。

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. SMTPクライアントは、EHLOへの応答を受信するまでSMTPサーバーがSMTPUTF8をサポートしているかどうかを知ることができないため、SMTPUTF8対応SMTPクライアントは、EHLOコマンドでASCII（LDHラベルまたはAラベル[RFC5890]）ドメインのみを送信しなければなりません（MUST）。

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. SMTPUTF8対応SMTPサーバーがEHLO応答でドメイン名を提供する場合、それらはLDHラベルまたはAラベルの形式でなければなりません（MUST）。

3.7.2. Mail eXchangers​

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. 複数のDNS MXレコードを使用してドメインの複数のサーバーを指定する場合（RFC 5321 [RFC5321]のセクション5で説明されているように）、それらのすべてがSMTPUTF8拡張をサポートするか、いずれもサポートしないことを強くお勧めします。

Otherwise, unexpected rejections can happen during temporary or permanent failures, which users might perceive as serious reliability issues. そうしないと、一時的または永続的な障害中に予期しない拒否が発生する可能性があり、ユーザーはこれを深刻な信頼性の問題として認識する可能性があります。

3.7.3. Trace Information​

The trace information <Return-path-line>, <Time-stamp-line>, and their related rules are defined in Section 4.4 of RFC 5321 [RFC5321]. トレース情報 <Return-path-line>, <Time-stamp-line> およびそれらに関連するルールは、RFC 5321 [RFC5321]のセクション4.4で定義されています。

This document updates <Mailbox> and <Domain> to support non-ASCII characters. このドキュメントでは、<Mailbox> と <Domain> を更新して、非ASCII文字をサポートします。

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. SMTPUTF8拡張が使用される場合、Return-path-lineの 'Reverse-path' 句には、Uラベル形式を使用する国際化ドメイン名が含まれる場合があります。

Also, the 'Stamp' clause of the Time-stamp-line may include an internationalized domain name that uses the U-label form. また、Time-stamp-lineの 'Stamp' 句には、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ラベル形式を使用すべきです（SHOULD）。

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値の1つです。

3.7.4. UTF-8 Strings in Replies​

3.7.4.1. MAIL Command​

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. SMTPクライアントがこの仕様に従い、SMTPUTF8パラメータを含むMAILコマンドを送信する場合、SMTPUTF8対応SMTPサーバーは、251および551応答コードに関連付けられた電子メールアドレスでUTF-8文字を使用することが許可され、SMTPクライアントはそれらを受け入れて処理できなければなりません（MUST）。

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. 特定のMAILコマンドにSMTPUTF8パラメータが含まれていない場合、SMTPUTF8対応SMTPサーバーは、非ASCIIメールボックスを含む251または551応答を返してはなりません（MUST NOT）。

Instead, it MUST transform such responses into 250 or 550 responses that do not contain non-ASCII addresses. 代わりに、そのような応答を、非ASCIIアドレスを含まない250または550応答に変換しなければなりません（MUST）。

3.7.4.2. VRFY and EXPN Commands and the SMTPUTF8 Parameter​

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. SMTPUTF8パラメータがVRFYおよびEXPNコマンドとともに送信される場合、それはSMTPクライアントがそれらのコマンドへの応答でUTF-8文字列を受け入れることができることを示します。

The parameter with the VRFY and EXPN commands SHOULD only be used after the SMTP client sees the EHLO response with the SMTPUTF8 keyword. VRFYおよびEXPNコマンドのパラメータは、SMTPクライアントがSMTPUTF8キーワードを含むEHLO応答を確認した後にのみ使用すべきです（SHOULD）。

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. これにより、SMTPUTF8対応SMTPサーバーは、SMTPクライアントがそれらによって混乱する可能性があることを心配することなく、応答に出現するメールボックス名およびフルネームでUTF-8文字列を使用できます。

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. この仕様に準拠するSMTPクライアントは、UTF-8文字列を含むVRFYおよびEXPNコマンドへの応答を受け入れ、正しく処理しなければなりません（MUST）。

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. ただし、SMTPクライアントがVRFYおよびEXPNコマンドでこのパラメータを送信することによってそのような応答を具体的に許可しない場合、SMTPUTF8対応SMTPサーバーは応答でUTF-8文字列を使用してはなりません（MUST NOT）。

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. ほとんどの応答では、返されるテキストにメールボックス名を含める必要がないため、UTF-8文字列は必要ありません。

Some replies, notably those resulting from successful execution of the VRFY and EXPN commands, do include the mailbox. 一部の応答、特にVRFYおよびEXPNコマンドの正常な実行から生じる応答には、メールボックスが含まれます。

VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: VERIFY（VRFY）およびEXPAND（EXPN）コマンドの構文は次のように変更されます。

vrfy = "VRFY" SP String
  [ SP "SMTPUTF8" ] CRLF
 ; String may include Non-ASCII characters

expn = "EXPN" SP String
  [ SP "SMTPUTF8" ] CRLF
 ; String may include Non-ASCII characters

The SMTPUTF8 parameter does not accept a value. SMTPUTF8パラメータは値を受け入れません。

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. VRFYまたはEXPNコマンドへの応答にUTF-8文字列が必要であるが、SMTPクライアントがSMTPUTF8パラメータを使用しなかった場合、SMTPUTF8対応SMTPサーバーは応答コード252または550のいずれかを使用しなければなりません（MUST）。

Reply-code 252, defined in RFC 5321 [RFC5321], means "Cannot VRFY user, but will accept the message and attempt the delivery". RFC 5321 [RFC5321]で定義されている応答コード252は、「ユーザーをVRFYできませんが、メッセージを受け入れて配信を試みます」という意味です。

Reply-code 550, also defined in RFC 5321 [RFC5321], means "Requested action not taken: mailbox unavailable". RFC 5321 [RFC5321]でも定義されている応答コード550は、「要求されたアクションは実行されませんでした：メールボックスが利用できません」という意味です。

When the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], the enhanced reply-code as specified below is used. SMTPUTF8対応SMTPサーバーが拡張メールシステムステータスコード[RFC3463]をサポートしている場合、以下で指定される拡張応答コードが使用されます。

Using the SMTPUTF8 parameter with a VRFY or EXPN command enables UTF-8 replies for that command only. 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. 通常の成功応答（つまり、250）が返される場合、応答にはユーザーのフルネームを含めてもよく（MAY）、ユーザーのメールボックスを含めなければなりません（MUST）。

It MUST be in either of the following forms: 次のいずれかの形式でなければなりません（MUST）。

User Name <Mailbox>
 ; Mailbox is defined in Section 3.3 of this document.
 ; User Name can contain non-ASCII characters.

Mailbox
 ; Mailbox is defined in Section 3.3 of this document.

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. SMTPクライアントがSMTPUTF8拡張をサポートしていないが、応答でUTF-8文字列を受信した場合、その応答をユーザーに適切に報告できない可能性があり、一部のクライアントはその応答を誤って処理する可能性があります。

Internationalized messages in replies are only allowed in the commands under the situations described above. 応答内の国際化されたメッセージは、上記の状況下のコマンドでのみ許可されます。

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. このセクションで指定されたルールの下での応答で電子メールアドレスを表すためにUTF-8文字列が必要ですが、この拡張は他の目的でのUTF-8文字列の使用を許可しません。

SMTPUTF8-aware SMTP servers MUST NOT include non-ASCII characters in replies except in the limited cases specifically permitted in this section. SMTPUTF8対応SMTPサーバーは、このセクションで具体的に許可されている限られた場合を除き、応答に非ASCII文字を含めてはなりません（MUST NOT）。

4. IANA Considerations​

4.1. SMTP Service Extensions Registry​

IANA has added a new value "SMTPUTF8" to the "SMTP Service Extension" registry of the "Mail Parameters" registry, according to the following data: IANAは、以下のデータに従って、「Mail Parameters」レジストリの「SMTP Service Extension」レジストリに新しい値 "SMTPUTF8" を追加しました。

KeywordsDescriptionReference
SMTPUTF8Internationalized email address[RFC6531]

4.2. SMTP Enhanced Status Code Registry​

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]. このドキュメントのコード定義は、このドキュメントのセクション3.5および3.7.4.2のガイダンスに従い、RFC 5248 [RFC5248]に基づいて、RFC 5336で指定されたものを置き換えます。

IANA has updated the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry" with the following data: IANAは、「Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry」を以下のデータで更新しました。

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: [email protected]

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: [email protected]

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: [email protected]

Code: X.6.10 Description: This is a duplicate of X.6.8 and is thus deprecated.

4.3. WITH Protocol Types Sub-Registry of the Mail Transmission Types Registry​

IANA has modified or added the following entries in the "WITH protocol types" sub-registry under the "Mail Transmission Types" registry. IANAは、「Mail Transmission Types」レジストリの下の「WITH protocol types」サブレジストリ内の以下のエントリを変更または追加しました。

WITH protocol typesDescriptionReference
UTF8SMTPESMTP with SMTPUTF8[RFC6531]
UTF8SMTPAESMTP with SMTPUTF8 and AUTH[RFC4954] [RFC6531]
UTF8SMTPSESMTP with SMTPUTF8 and STARTTLS[RFC3207] [RFC6531]
UTF8SMTPSAESMTP with SMTPUTF8 and both STARTTLS and AUTH[RFC3207] [RFC4954] [RFC6531]
UTF8LMTPLMTP with SMTPUTF8[RFC6531]
UTF8LMTPALMTP with SMTPUTF8 and AUTH[RFC4954] [RFC6531]
UTF8LMTPSLMTP with SMTPUTF8 and STARTTLS[RFC3207] [RFC6531]
UTF8LMTPSALMTP with SMTPUTF8 and both STARTTLS and AUTH[RFC3207] [RFC4954] [RFC6531]

5. Security Considerations​

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エンベロープおよびメッセージヘッダー内）での使用を超えて、国際化された電子メールアドレスは他のケースでも表示されます。特に：

  • the logging systems of SMTP transactions and other logs to monitor the email systems;

  • SMTPトランザクションのログシステムおよび電子メールシステムを監視するためのその他のログ。

  • the trouble ticket systems used by security teams to manage security incidents, when an email address is involved;

  • 電子メールアドレスが関係する場合に、セキュリティインシデントを管理するためにセキュリティチームが使用するトラブルチケットシステム。

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. 考慮すべきもう1つのセキュリティの側面は、セキュリティチームのメンバーがインシデントを追跡しているときに、ログから電子メールアドレスをすばやく理解、読み取り、識別する能力に関連しています。

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情報を簡単に読み取ることができないログリーダーが使用するために、国際化された電子メールアドレスの起源または所有権を自動的かつ迅速に提供するメカニズムを実装しなければなりません（SHALL）。

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). SMTPコマンドVRFYおよびEXPNは、転送するメッセージがないSMTPトランザクションで使用されることがあります（潜在的なスパムメッセージが特定された場合に自動アクションを実行するために使用されるツールによって）。

Sections 3.5 and 7.3 of RFC 5321 give detailed descriptions of use and possible behaviors. RFC 5321のセクション3.5および7.3では、使用法と可能な動作について詳細に説明しています。

Implementation of internationalized addresses can also affect logs and actions by these tools. 国際化されたアドレスの実装は、これらのツールによるログやアクションにも影響を与える可能性があります。

6. Acknowledgements​

This document revises RFC 5336 [RFC5336] based on the result of the Email Address Internationalization (EAI) working group's discussion. このドキュメントは、Email Address Internationalization（EAI）ワーキンググループの議論の結果に基づいてRFC 5336 [RFC5336]を改訂します。

Many EAI working group members did tests and implementations to move this document to the Standards Track. 多くのEAIワーキンググループメンバーが、このドキュメントを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. Xiaodong LEE、Nai-Wen HSU、Yangwoo KO、Yoshiro YONEYA、およびJETの他のメンバーから重要なコメントと提案が寄せられ、仕様に組み込まれました。

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. これらの寄稿には、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, および Lars Eggert からの資料が含まれています。

Of course, none of the individuals are necessarily responsible for the combination of ideas represented here. もちろん、個人の誰もがここで表現されたアイデアの組み合わせに必ずしも責任があるわけではありません。

Thanks a lot to Dave Crocker for his comments and helping with ABNF refinement. Dave CrockerのコメントとABNFの改良への協力に感謝します。

7. References​

7.1. Normative References​

  • [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.

  • [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [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 Notifications (DSNs)", RFC 3461, January 2003.

  • [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.

  • [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.

  • [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

  • [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003.

  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003.

  • [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004.

  • [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004.

  • [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

  • [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

  • [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", RFC 5248, June 2008.

  • [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", RFC 5248, June 2008.

  • [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

  • [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

  • [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

  • [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

  • [RFC5890] Klensin, J., "Internationalizing Domain Names in Applications (IDNA definitions)", RFC 5890, June 2010.

  • [RFC5890] Klensin, J., "Internationalizing Domain Names in Applications (IDNA definitions)", RFC 5890, June 2010.

  • [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., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.

  • [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.

  • [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.

  • [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.

  • [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.

  • [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.

  • [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.

  • [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., "Internationalized Delivery Status and Disposition Notifications", RFC RFC6533, February 2012.

  • [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., "Internationalized Delivery Status and Disposition Notifications", RFC RFC6533, February 2012.

7.2. Informative References​

  • [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.

  • [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.

  • [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. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

  • [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.

  • [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.

  • [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.

  • [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.

  • [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.

  • [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.

  • [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.

  • [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.

  • [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.

  • [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.

Authors' Addresses

Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China

Phone: +86 10 58813007 EMail: [email protected]

Wei MAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China

Phone: +86 10 58812230 EMail: [email protected]

に最終更新