[要約] RFC 5336は、国際化されたメールアドレスのためのSMTP拡張に関する規格です。このRFCの目的は、国際化されたメールアドレスをサポートするために、SMTPプロトコルに必要な変更を提案することです。
Network Working Group J. Yao, Ed.
Request for Comments: 5336 W. Mao, Ed.
Updates: 2821, 2822, 4952 CNNIC
Category: Experimental September 2008
SMTP Extension for Internationalized Email Addresses
国際化された電子メールアドレスのSMTP拡張
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Abstract
概要
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952.
このドキュメントは、国際化された電子メールアドレスまたはヘッダー情報を使用した電子メールメッセージの輸送と配信のためのSMTP拡張機能を指定します。この仕様を実装していないシステムとの通信は、別のドキュメントで指定されています。このドキュメントは、RFC 2821およびRFC 2822で定義されているいくつかの構文とルールを更新し、RFC 4952を更新するいくつかの資料を備えています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of This Specification . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 4
3.1. Framework for the Internationalization Extension . . . . . 4
3.2. The UTF8SMTP Extension . . . . . . . . . . . . . . . . . . 5
3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7
3.4. The ALT-ADDRESS Parameter . . . . . . . . . . . . . . . . 9
3.5. ALT-ADDRESS Parameter Usage and Response Codes . . . . . . 10
3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 11
3.7. Additional ESMTP Changes and Clarifications . . . . . . . 11
3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 12
3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 12
3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 12
3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Material Updating RFC 4952 . . . . . . . . . . . . . 20
A.1. Conventional Message and Internationalized Message . . . . 20
A.2. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 20
A.4. Implementation Advice . . . . . . . . . . . . . . . . . . 20
A.5. Applicability of SMTP Extension to Additional Uses . . . . 21
An internationalized email address includes two parts, the local part and the domain part. The ways email addresses are used by protocols are different from the ways domain names are used. The most critical difference is that emails are delivered through a chain of clients and servers, while domain names are resolved by name servers looking up those names in their own tables. In addition to this, the Simple Mail Transfer Protocol [RFC2821] provides a negotiation mechanism about service extension with which clients can discover server capabilities and make decisions for further processing. An extended overview of the extension model for internationalized addresses and headers appears in [RFC4952], referred to as "the framework document" or just as "Framework" elsewhere in this specification. This document specifies an SMTP extension to permit internationalized email addresses in envelopes, and UNICODE characters (encoded in UTF-8) [RFC3629] in headers.
国際化されたメールアドレスには、ローカルパーツとドメインパーツの2つの部分が含まれています。プロトコルでメールアドレスが使用される方法は、ドメイン名の使用方法とは異なります。最も重大な違いは、クライアントとサーバーのチェーンを介して電子メールが配信され、ドメイン名が名前サーバーが独自のテーブルでそれらの名前を検索することで解決されることです。これに加えて、Simple Mail Transfer Protocol [RFC2821]は、クライアントがサーバー機能を発見し、さらなる処理の決定を下すことができるサービス拡張に関するネゴシエーションメカニズムを提供します。国際化されたアドレスとヘッダーの拡張モデルの拡張概要は、[RFC4952]に登場し、「フレームワークドキュメント」と呼ばれるか、この仕様の他の場所に「フレームワーク」と呼ばれます。このドキュメントは、封筒の国際化された電子メールアドレスを許可するSMTP拡張機能を指定し、ヘッダーでUnicode文字（UTF-8でエンコード）[RFC3629]を許可します。
The framework document specifies the requirements for, and describes components of, full internationalization of electronic mail. A thorough understanding of the information in that document and in the base Internet email specifications [RFC2821] [RFC2822] is necessary to understand and implement this specification.
フレームワークドキュメントは、電子メールの完全な国際化の要件を指定し、コンポーネントを説明します。このドキュメントとベースのインターネット電子メール仕様[RFC2821] [RFC2822]の情報を完全に理解することは、この仕様を理解して実装するために必要です。
This document specifies an element of the email internationalization work, specifically the definition of an SMTP extension [RFC2821] for internationalized email address transport delivery.
このドキュメントは、電子メール国際化作業の要素、特に国際化された電子メールアドレス輸送配信のためのSMTP拡張[RFC2821]の定義を指定します。
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 "conventional message" and "internationalized message" are defined in an appendix to this specification. The terms "UTF-8 string" or "UTF-8 character" are used informally to refer to Unicode characters encoded in UTF-8 [RFC3629]. All other specialized terms used in this specification are defined in the framework document or in the base Internet email specifications [RFC2821] [RFC2822]. In particular, the terms "ASCII address", "internationalized email address", "non-ASCII address", "i18mail address", "UTF8SMTP", "message", and "mailing list" are used in this document according to the definitions in the framework document.
「従来のメッセージ」と「国際化されたメッセージ」という用語は、この仕様の付録に定義されています。「UTF-8文字列」または「UTF-8文字」という用語は、UTF-8 [RFC3629]でエンコードされたUnicode文字を参照するために非公式に使用されます。この仕様で使用される他のすべての専門用語は、フレームワークドキュメントまたはベースインターネットメール仕様[RFC2821] [RFC2822]で定義されています。特に、「ASCIIアドレス」、「国際化された電子メールアドレス」、「非ASCIIアドレス」、「I18mailアドレス」、「UTF8SMTP」、「メッセージ」という用語は、定義に従ってこのドキュメントで使用されています。フレームワークドキュメント。
This specification defines only those Augmented BNF (ABNF) [RFC5234] syntax rules that are different from those of the base email specifications [RFC2821][RFC2822] and, where the earlier rules are upgraded or extended, gives them new names. When the new rule is a small modification to the older one, it is typically given a name starting with "u". Rules that are undefined here may be found in the base email specifications under the same names.
この仕様では、基本メール仕様[RFC2821] [RFC2822]とは異なる拡張されたBNF（ABNF）[RFC5234]の構文ルールのみを定義し、以前のルールがアップグレードまたは拡張されている場合、新しい名前を提供します。新しいルールが古いルールの小さな変更である場合、通常は「u」から始まる名前が付けられます。ここで未定義のルールは、同じ名前のベースメール仕様に記載されている場合があります。
This specification describes an optional extension to the email transport mechanism that permits non-ASCII [ASCII] characters in both the envelope and header fields of messages, which are encoded with UTF-8 [RFC3629] characters. The extension is identified with the token "UTF8SMTP". In order to provide information that may be needed in downgrading, an optional alternate ASCII address may be needed if an SMTP client attempts to transfer an internationalized message and encounters a server that does not support this extension.
この仕様は、UTF-8 [RFC3629]文字でエンコードされたメッセージのエンベロープとヘッダーフィールドの両方で、非ASCII [ASCII]文字を許可する電子メールトランスポートメカニズムへのオプションの拡張機能です。拡張機能は、トークン「UTF8SMTP」で識別されます。ダウングレードに必要な情報を提供するために、SMTPクライアントが国際化されたメッセージを転送しようとし、この拡張機能をサポートしないサーバーに遭遇する場合、オプションの代替ASCIIアドレスが必要になる場合があります。
The EAI UTF-8 header specification [RFC5335] provides the details of how and where non-ASCII characters are permitted in the header fields of messages. The context for this specification is described in the framework document.
EAI UTF-8ヘッダー仕様[RFC5335]は、メッセージのヘッダーフィールドでASCII以外の文字が許可されている方法と場所の詳細を提供します。この仕様のコンテキストは、フレームワークドキュメントで説明されています。
The following service extension is defined:
次のサービス拡張機能が定義されています。
1. The name of the SMTP service extension is "Email Address Internationalization".
1. SMTPサービス拡張機能の名前は「電子メールアドレスInternationalization」です。
2. The EHLO keyword value associated with this extension is "UTF8SMTP".
2. この拡張機能に関連付けられているEhloキーワード値は「UTF8SMTP」です。
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 that keyword. Clients MUST ignore any parameters; that is, clients MUST behave as if the parameters do not appear. If a server includes UTF8SMTP in its EHLO response, it MUST be fully compliant with this version of this specification.
3. このEhloキーワード値に対してパラメーター値は定義されていません。将来（予期しない）拡張を許可するために、EHLO応答には、そのキーワードのパラメーターを含めてはなりません。クライアントはパラメーターを無視する必要があります。つまり、クライアントはパラメーターが表示されないかのように振る舞う必要があります。サーバーにEHLO応答にUTF8SMTPが含まれている場合、この仕様のこのバージョンに完全に準拠する必要があります。
4. One optional parameter, ALT-ADDRESS, is added to the MAIL and RCPT commands of SMTP. ALT-ADDRESS specifies an all-ASCII address which can be used as a substitute for the corresponding primary (i18mail) address when downgrading. More discussion of the use of this parameter appears in [RFC4952] and [Downgrade].
4. 1つのオプションのパラメーター、Alt-AddressがSMTPのメールとRCPTコマンドに追加されます。Alt-Addressは、ダウングレード時に対応するプライマリ（I18mail）アドレスの代替として使用できるAll-ASCIIアドレスを指定します。このパラメーターの使用に関する詳細は、[RFC4952]および[ダウングレード]に表示されます。
5. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN commands. The parameter UTF8REPLY has no value. The parameter indicates that the SMTP client can accept Unicode characters in UTF-8 encoding in replies from the VRFY and EXPN commands.
5. 1つのオプションのパラメーター「UTF8REPLY」がVRFYおよびEXPNコマンドに追加されます。パラメーターUTF8REPLYには値がありません。このパラメーターは、SMTPクライアントがVRFYおよびEXPNコマンドからの応答でUTF-8エンコードのUnicode文字を受け入れることができることを示しています。
6. No additional SMTP verbs are defined by this extension.
6. この拡張機能によって追加のSMTP動詞は定義されていません。
7. Servers offering this extension MUST provide support for, and announce, the 8BITMIME extension [RFC1652].
7. この拡張機能を提供するサーバーは、8bitmime拡張機能[RFC1652]のサポートを提供し、発表する必要があります。
8. 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).
8. SMTPメールおよびRCPTコマンドの逆パスとフォワードパスは、メールボックス名（アドレス）でUTF-8でエンコードされるUnicode文字を許可するように拡張されます。
9. The mail message body is extended as specified in [RFC5335].
9. メールメッセージ本文は、[RFC5335]で指定されているように拡張されています。
10. The maximum length of MAIL and RCPT command lines is increased by 460 characters by the possible addition of the ALT-ADDRESS keyword and value.
10. MailおよびRCPTコマンドラインの最大長は、Alt-Addressキーワードと値を追加することにより、460文字増加します。
11. The UTF8SMTP extension is valid on the submission port [RFC4409].
11. UTF8SMTP拡張は、提出ポート[RFC4409]で有効です。
An SMTP server that announces this extension MUST be prepared to accept a UTF-8 string [RFC3629] in any position in which RFC 2821 specifies that a mailbox can appear. That string MUST be parsed only as specified in RFC 2821, i.e., by separating the mailbox into source route, local part, and domain part, using only the characters colon (U+003A), comma (U+002C), and at-sign (U+0040) as specified there. Once isolated by this parsing process, the local part MUST be treated as opaque unless the SMTP server is the final delivery Mail Transfer Agent (MTA). Any domain names that are to be looked up in the DNS MUST first be processed into the form specified in "Internationalizing Domain Names in Applications (IDNA)" [RFC3490] by means of the ToASCII() operation unless they are already in that form. Any domain names that are to be compared to local strings SHOULD be checked for validity and then MUST be compared as specified in Section 3.4 of IDNA.
この拡張機能を発表するSMTPサーバーは、RFC 2821がメールボックスが表示されることを指定する任意の位置で、UTF-8文字列[RFC3629]を受け入れるように準備する必要があります。その文字列は、RFC 2821で指定されているように、つまり、電子メールボックスをソースルート、ローカル部分、およびドメイン部分に分離し、文字コロン（U 003a）、コンマ（U 002C）、およびAT-SIGN（u 0040）そこで指定されています。この解析プロセスによって分離されたら、SMTPサーバーが最終配信メール転送エージェント（MTA）でない限り、ローカル部分は不透明として扱わなければなりません。DNSで検索するドメイン名は、最初に「アプリケーションの国際化ドメイン名（IDNA）」[RFC3490]で指定されたフォームに処理する必要があります。ローカル文字列と比較するドメイン名は、有効性を確認し、IDNAのセクション3.4で指定されているように比較する必要があります。
An SMTP client that receives the UTF8SMTP 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 [RFC5335] (which may also include mailbox names in UTF-8). It MAY transmit the domain parts of mailbox names within SMTP commands or the message header as either ACE (ASCII Compatible Encoding) labels (as specified in IDNA [RFC3490]) or UTF-8 strings. All labels in domain parts of mailbox names which are IDNs (either UTF-8 or ACE strings) MUST be valid. If the original client submits a message to a Message Submission Server ("MSA") [RFC4409], it is the responsibility of the MSA that all domain labels are valid; otherwise, it is the original client's responsibility. The presence of the UTF8SMTP extension does not change the requirement of RFC 2821 that servers relaying mail MUST NOT attempt to parse, evaluate, or transform the local part in any way.
EHLOコマンドに応じてUTF8SMTP拡張機能キーワードを受信するSMTPクライアントは、UTF-8フォームの国際的な文字列としてSMTPコマンド内のメールボックス名を送信できます。UTF-8ヘッダー[RFC5335]を送信する場合があります（UTF-8にメールボックス名も含まれる場合があります）。SMTPコマンド内のメールボックス名のドメイン部分を送信するか、メッセージヘッダーをACE（ASCII互換エンコード）ラベル（IDNA [RFC3490]で指定）またはUTF-8文字列として送信できます。IDNS（UTF-8またはACE文字列のいずれか）であるメールボックス名のドメイン部分のすべてのラベルが有効でなければなりません。元のクライアントがメッセージ提出サーバー（ "MSA"）[RFC4409]にメッセージを送信する場合、すべてのドメインラベルが有効であることはMSAの責任です。そうでなければ、それは元のクライアントの責任です。UTF8SMTP拡張機能の存在は、メールをリレーするサーバーがローカル部分をいかなる方法で解析、評価、または変換しようとしてはならないRFC 2821の要件を変更しません。
If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP client MUST NOT transmit an internationalized address and MUST NOT transmit a mail message containing internationalized mail headers as described in [RFC5335] at any level within its MIME structure. (For this paragraph, the internationalized domain name in the form of ACE labels as specified in IDNA [RFC3490] is not considered as "internationalized".) Instead, if an SMTP client (SMTP sender) attempts to transfer an internationalized message and encounters a server that does not support the extension, it MUST make one of the following four choices:
UTF8SMTP SMTP拡張機能がサーバーによって提供されていない場合、SMTPクライアントは国際化された住所を送信してはならず、[RFC5335]に記載されているように、MIME構造内の任意のレベルで国際化されたメールヘッダーを含むメールメッセージを送信してはなりません。（この段落では、IDNA [RFC3490]で指定されているACEラベルの形での国際化されたドメイン名は、「国際化」と見なされません。）代わりに、SMTPクライアント（SMTP送信者）が国際化されたメッセージの転送を試み、出会いを試み、拡張機能をサポートしていないサーバーは、次の4つの選択のいずれかを作成する必要があります。
1. If and only if the SMTP client (sender) is a Message Submission Server ("MSA") [RFC4409], it MAY, consistent with the general provisions for changes by such servers, rewrite the envelope, headers, or message material to make them entirely ASCII and consistent with the provisions of RFC 2821 [RFC2821] and RFC 2822 [RFC2822].
1. SMTPクライアント（送信者）がメッセージ送信サーバー（ "MSA"）[RFC4409]である場合にのみ、そのようなサーバーによる変更の一般的な規定と一致して、エンベロープ、ヘッダー、またはメッセージ素材を書き直して完全にASCIIであり、RFC 2821 [RFC2821]およびRFC 2822 [RFC2822]の規定と一致しています。
2. It may either reject the message during the SMTP transaction or accept the message and then generate and transmit a notification of non-deliverability. Such notification MUST be done as specified in RFC 2821 [RFC2821], RFC 3464 [RFC3464], and the EAI delivery status notification (DSN) specification [RFC5337].
2. SMTPトランザクション中にメッセージを拒否するか、メッセージを受け入れてから、非配信可能性の通知を生成および送信する場合があります。このような通知は、RFC 2821 [RFC2821]、RFC 3464 [RFC3464]、およびEAI配信ステータス通知（DSN）仕様[RFC5337]で指定されているように行う必要があります。
3. It may find an alternate route to the destination that permits UTF8SMTP. That route may be discovered by trying alternate Mail eXchanger (MX) hosts (using preference rules as specified in RFC 2821) or using other means available to the SMTP-sender.
3. UTF8SMTPを許可する宛先への代替ルートが見つかる場合があります。そのルートは、代替メール交換機（MX）ホストを試して（RFC 2821で指定されているように優先ルールを使用）、またはSMTPセンダーが利用できる他の手段を使用することで発見される場合があります。
4. If and only if ASCII addresses are available for all addresses that appear in the return path and the specific forward paths being attempted, it may downgrade the message to an all-ASCII form as specified in [Downgrade]. An ASCII address is considered to be "available" for a particular address if the original address in the envelope is in ASCII or if an ALT-ADDRESS parameter is specified for a UTF8SMTP address.
4. ASCIIアドレスがリターンパスに表示されるすべてのアドレスと試行される特定のフォワードパスで利用可能である場合にのみ、[ダウングレード]で指定されているように、メッセージをAll-ASSIIフォームにダウングレードする場合があります。ASCIIアドレスは、封筒の元のアドレスがASCIIにある場合、またはUTF8SMTPアドレスにAlt-Addressパラメーターが指定されている場合、特定のアドレスで「利用可能」であると見なされます。
The difference between choice 1 and choice 4 is that choice 1 is constrained by Message Submission [RFC4409], while choice 4 is constrained by [Downgrade].
選択肢1と選択4の違いは、選択肢1がメッセージ送信[RFC4409]によって制約され、選択4は[ダウングレード]によって制約されることです。
RFC 2821, Section 4.1.2, defines the syntax of a mailbox entirely in terms of ASCII characters, using the production for a mailbox and those productions on which it depends.
RFC 2821、セクション4.1.2は、メールボックスの制作とそれが依存するプロダクションを使用して、ASCII文字の観点から、メールボックスの構文を完全に定義します。
The key changes made by this specification are, informally, to
この仕様によってなされた重要な変更は、非公式に、
o Change the definition of "sub-domain" to permit either the definition above or a UTF-8 string representing a DNS label that is conformant with IDNA [RFC3490].
o 「サブドメイン」の定義を変更して、IDNA [RFC3490]に適合しているDNSラベルを表す上記の定義またはUTF-8文字列を許可します。
o Change the definition of "Atom" to permit either the definition above or a UTF-8 string. That string MUST NOT contain any of the ASCII characters (either graphics or controls) that are not permitted in "atext"; it is otherwise unrestricted.
o 「Atom」の定義を変更して、上記の定義またはUTF-8文字列のいずれかを許可します。その文字列には、「atext」で許可されていないASCII文字（グラフィックまたはコントロール）のいずれかを含めるべきではありません。それ以外の場合は無制限です。
According to the description above, the syntax of an internationalized email mailbox name (address) is defined in ABNF [RFC5234] as follows.
上記の説明によると、国際化された電子メールメールボックス名（アドレス）の構文は、次のようにABNF [RFC5234]で定義されています。
uMailbox = uLocal-part "@" uDomain ; Replace Mailbox in RFC 2821, Section 4.1.2
umailbox = local-part "@" udomain;RFC 2821、セクション4.1.2のメールボックスを交換します
uLocal-part = uDot-string / uQuoted-string ; MAY be case-sensitive ; Replace Local-part in RFC 2821, Section 4.1.2
local-part = udot-string / uquoted-string;症例に敏感な場合があります。RFC 2821、セクション4.1.2のローカルパートを交換します
uDot-string = uAtom *("." uAtom)
; Replace Dot-string in RFC 2821, Section 4.1.2
uAtom = 1*ucharacter
; Replace Atom in RFC 2821, Section 4.1.2
ucharacter = atext / UTF8-non-ascii
atext = <See Section 3.2.4 of RFC 2822>
uQuoted-string = DQUOTE *uqcontent DQUOTE ; Replace Quoted-string in RFC 2821, Section 4.1.2
uquoted-string = dquote *uqcontent dquote;RFC 2821、セクション4.1.2の引用符で引用されたストリングを交換します
DQUOTE = <See appendix B.1 of RFC 5234>
uqcontent = qcontent / UTF8-non-ascii
qcontent = <See Section 3.2.5 of RFC 2822>
uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal
; Replace Domain in RFC 2821, Section 4.1.2
address-literal = <See Section 4.1.2 of RFC 2822>
sub-udomain = uLet-dig [uLdh-str] ; Replace sub-domain in RFC 2821, Section 4.1.2
sub-udomain = ulet-dig [uldh-str];RFC 2821、セクション4.1.2のサブドメインを交換します
uLet-dig = Let-dig / UTF8-non-ascii
Let-dig = <See Section 4.1.3 of RFC 2821>
uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig
; Replace Ldh-str in RFC 2821, Section 4.1.3
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <See Section 4 of RFC 3629>
UTF8-3 = <See Section 4 of RFC 3629>
UTF8-4 = <See Section 4 of RFC 3629>
The value of "uDomain" SHOULD be verified by applying the tests specified as part of IDNA [RFC3490]. If that verification fails, the email address with that uDomain MUST NOT be regarded as a valid email address.
「udomain」の値は、IDNA [RFC3490]の一部として指定されたテストを適用して検証する必要があります。その検証が失敗した場合、そのudomainの電子メールアドレスは、有効な電子メールアドレスと見なされてはなりません。
If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and RCPT commands is extended to support the optional esmtp-keyword "ALT-ADDRESS". That keyword specifies an alternate all-ASCII address that may be used when downgrading. If the ALT-ADDRESS esmtp-keyword is used, it MUST have an associated esmtp-value (ALT-ADDRESS-esmtp-value, which is defined below).
UTF8SMTP拡張機能が提供されている場合、SMTPメールとRCPTコマンドの構文が拡張され、オプションのESMTPキーワード「Alt-Address」をサポートします。そのキーワードは、ダウングレード時に使用できる代替の全ASCIIアドレスを指定します。Alt-Address ESMTP-KeyWordが使用される場合、関連するESMTP値（以下に定義されているAlt-Address-ESMTP-Value）が必要です。
While it may be tempting to consider ALT-ADDRESS as a general-purpose second-chance address, such behavior is not defined here. Instead, in this specification ALT-ADDRESS only has meaning when the associated primary address is non-ASCII and the message is downgraded. This restriction allows for future extension of the specification even though no such extensions are currently anticipated.
Alt-Addressを汎用の第2チャンスアドレスと見なすのは魅力的かもしれませんが、このような動作はここでは定義されていません。代わりに、この仕様では、Alt-Addressは、関連する一次アドレスが非ASCIIであり、メッセージが格下げされている場合にのみ意味があります。この制限により、そのような拡張は現在予想されていない場合でも、仕様の将来の拡張が可能になります。
Based on the definition of mail-parameters in [RFC2821], the ALT-ADDRESS parameter usage in the commands of MAIL and RCPT is defined as follows. The following definitions are given in the same format as used in RFC 2821.
[RFC2821]のメールパラメーターの定義に基づいて、メールとRCPTのコマンドでのAlt-Addressパラメーターの使用法は、次のように定義されます。次の定義は、RFC 2821で使用されるのと同じ形式で示されています。
"MAIL FROM:" ("<>" / uReverse-path) [ SP Mail-parameters ] CRLF
; Update the MAIL command in RFC 2821, Section 4.1.1.2.
; A new parameter defined by the ABNF non-terminal
; <ALT-ADDRESS-parameter> is added. It complies
; with the syntax specified for <esmtp-param> in RFC 2821.
"RCPT TO:" ("<Postmaster@" uDomain ">" / "<Postmaster>" /
uForward-path) [ SP Rcpt-parameters ] CRLF
; Update RCPT command in RFC 2821, Section 4.1.1.3.
; A new parameter defined by the ABNF non-terminal
; <ALT-ADDRESS-parameter> is added. It complies
; with the syntax specified for <esmtp-param>.
; uDomain is defined in Section 3.3 of this document.
uReverse-path = uPath ; Replace Reverse-path in RFC 2821, Section 4.1.2.
ureverse-path = upath;RFC 2821、セクション4.1.2のリバースパスを交換します。
uForward-path = uPath ; Replace Forward-path in RFC 2821, Section 4.1.2.
uforward-path = upath;RFC 2821、セクション4.1.2のフォワードパスを交換します。
uPath = "<" [ A-d-l ":" ] uMailbox ">" ; Replace Path in RFC 2821, Section 4.1.2. ; uMailbox is defined in Section 3.3 of this document.
upath = "<" [a-d-l "："] umailbox ">";RFC 2821、セクション4.1.2のパスを交換します。;Umailboxは、このドキュメントのセクション3.3で定義されています。
A-d-l = <See Section 4.1.2 of RFC 2821>
ALT-ADDRESS-parameter = "ALT-ADDRESS=" ALT-ADDRESS-value
alt-address-parameter = "alt-address =" alt-address-value
ALT-ADDRESS-value = xtext ; The value is a mailbox name encoded as xtext.
alt-address-value = xtext;値は、XTEXTとしてエンコードされたメールボックス名です。
xtext = <See Section 4.2 of RFC 3461>
The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL or RCPT command. ALT-ADDRESS-esmtp-value MUST be an all-ASCII email address before xtext encoding.
Alt-Address-Parameterは、メールまたはRCPTコマンドに複数回表示してはなりません。Alt-Address-ESMTP-Valueは、XTEXTエンコーディングの前にすべてASCIIの電子メールアドレスでなければなりません。
An "internationalized message" as defined in the appendix of this specification MUST NOT be sent to an SMTP server that does not support UTF8SMTP. Such a message MAY be rejected by a server if it lacks ALT-ADDRESSes as discussed in Section 3.2 of this specification.
この仕様の付録で定義されている「国際化されたメッセージ」は、UTF8SMTPをサポートしていないSMTPサーバーに送信してはなりません。この仕様のセクション3.2で説明したように、このようなメッセージは、Alt-Addressesがない場合、サーバーによって拒否される場合があります。
The three-digit reply codes used in this section are consistent with their meanings as defined in RFC 2821.
このセクションで使用されている3桁の返信コードは、RFC 2821で定義されている意味と一致しています。
When messages are rejected because the RCPT command requires an ALT-ADDRESS, the response code 553 is used with the meaning "mailbox name not allowed". When messages are rejected for other reasons, such as the MAIL command requiring an ALT-ADDRESS, the response code 550 is used with the meaning "mailbox unavailable". When the server supports enhanced mail system status codes [RFC3463], response code "X.6.7" [RFC5248] is used, meaning that "The ALT-ADDRESS is required but not specified".
RCPTコマンドにAlt-Addressが必要であるためにメッセージが拒否されると、応答コード553は「許可されていないメールボックス名」という意味で使用されます。Alt-Addressを必要とするメールコマンドなど、他の理由でメッセージが拒否されると、「メールボックスが利用できない」という意味で応答コードが使用されます。サーバーが拡張されたメールシステムステータスコード[RFC3463]をサポートする場合、応答コード "x.6.7" [RFC5248]が使用されます。つまり、「Alt-Addressは必要ですが、指定されていません」。
If the response code is issued after the final "." of the DATA command, the response code "554" is used with the meaning "Transaction failed". When the server supports enhanced mail system status codes [RFC3463], response code "X.6.9" [RFC5248] is used, meaning that "UTF8SMTP downgrade failed".
応答コードが決勝後に発行された場合。」データコマンドの場合、応答コード「554」は、「トランザクションが失敗した」という意味で使用されます。サーバーが拡張されたメールシステムステータスコード[RFC3463]をサポートすると、応答コード「X.6.9」[RFC5248]が使用されます。つまり、「UTF8SMTPダウングレードが失敗しました」。
There is no ESMTP parameter to assert that a message is an internationalized message. An SMTP server that requires accurate knowledge of whether a message is internationalized is required to parse all message header fields and MIME header fields in the message body.
メッセージが国際化されたメッセージであると主張するESMTPパラメーターはありません。メッセージボディのすべてのメッセージヘッダーフィールドとMIMEヘッダーフィールドを解析するには、メッセージが国際化されているかどうかの正確な知識を必要とするSMTPサーバーが必要です。
While this specification requires that servers support the 8BITMIME extension [RFC1652] to ensure that servers have adequate handling capability for 8-bit data and to avoid a number of complex encoding problems, the use of internationalized addresses obviously does not require non-ASCII body parts in the MIME message. The UTF8SMTP extension MAY be used with the BODY=8BITMIME parameter if that is appropriate given the body content or, with the BODY=BINARYMIME parameter, if the server advertises BINARYMIME [RFC3030] and that is appropriate.
この仕様では、サーバーが8ビットマイム拡張機能[RFC1652]をサポートする必要がありますが、サーバーが8ビットデータに適切な処理機能を備えていることを確認し、複雑なエンコード問題を回避するために、国際化アドレスの使用には明らかに非ASCII体の部分の部分が必要ありません。マイムメッセージで。UTF8SMTP拡張は、ボディの含有量を考慮して適切な場合、またはサーバーがバイナリマイム[RFC3030]を宣伝する場合、ボディ=バイナリマイムパラメーターで適切な場合、ボディ= 8ビットマイムパラメーターで使用できます。
Assuming that the server advertises UTF8SMTP and 8BITMIME, and receives at least one non-ASCII address, with or without ALT-ADDRESS, the precise interpretation of 'No BODY parameter', "BODY=8BITMIME", and "BODY=BINARYMIME" in the MAIL command is:
サーバーがUTF8SMTPと8BitMimeを宣伝し、Alt-Addressの有無にかかわらず少なくとも1つの非ASCIIアドレスを受け取ると仮定すると、「ボディパラメーターなし」、「ボディ= 8Bitmime」、および「body = binarymime」の正確な解釈がメールコマンドは次のとおりです。
1. If there is no BODY parameter, the header contains UTF-8 characters, but all the body parts are in ASCII (possibly as the result of a content-transfer-encoding).
1. ボディパラメーターがない場合、ヘッダーにはUTF-8文字が含まれていますが、すべての体の部分はASCIIにあります（おそらくコンテンツ転移エンコードの結果として）。
2. If a BODY=8BITMIME parameter is present, the header contains UTF-8 characters, and some or all of the body parts contain 8-bit line-oriented data.
2. Body = 8Bitmimeパラメーターが存在する場合、ヘッダーにはUTF-8文字が含まれており、一部またはすべてのボディパーツには8ビットライン指向のデータが含まれています。
3. If a BODY=BINARYMIME parameter is present, the header contains UTF-8 characters, and some or all body parts contain binary data without restriction as to line lengths or delimiters.
3. Body = binaryMimeパラメーターが存在する場合、ヘッダーにはUTF-8文字が含まれ、一部またはすべてのボディパーツには、ラインの長さまたは区切り文字に関して制限なしにバイナリデータが含まれています。
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 2821 specifies a mailbox, this specification expects UTF-8 to be used for the entire string; when RFC 2821 specifies a domain name, the name SHOULD be in the form of ACE labels if its raw form is non-ASCII.
メールトランスポートプロセスに掲載されている情報には、メールおよびRCPTコマンドに加えて、さまざまなコンテキストでのアドレス（「メールボックス」）とドメイン名が含まれ、代替案が拡張されます。一般に、ルールは、RFC 2821がメールボックスを指定するとき、この仕様はUTF-8が文字列全体に使用されることを期待するということです。RFC 2821がドメイン名を指定する場合、生のフォームが非ASCIIである場合、名前はACEラベルの形式である必要があります。
The following subsections list and discuss all of the relevant cases.
次のサブセクションリストに関連するすべてのケースについて説明します。
When an SMTP connection is opened, the server normally sends a "greeting" response consisting of the 220 response code and some information. The client then sends the EHLO command. Since the client cannot know whether the server supports UTF8SMTP until after it receives the response from EHLO, any domain names that appear in this dialogue, or in responses to EHLO, MUST be in the hostname form, i.e., internationalized ones MUST be in the form of ACE labels.
SMTP接続が開かれると、サーバーは通常、220の応答コードといくつかの情報で構成される「グリーティング」応答を送信します。その後、クライアントはEhloコマンドを送信します。クライアントは、サーバーがEHLOから応答を受信するまでUTF8SMTPをサポートするかどうかを知ることができないため、このダイアログに表示されるドメイン名、またはEHLOへの応答は、ホスト名フォーム、つまり国際化された形式でなければなりません。エースラベルの。
Organizations often authorize multiple servers to accept mail addressed to them. For example, the organization may itself operate more than one server, and may also or instead have an agreement with other organizations to accept mail as a backup. Authorized servers are generally listed in MX records as described in RFC 2821. When more than one server accepts mail for the domain-part of a mailbox, it is strongly advised that either all or none of them support the UTF8SMTP extension. Otherwise, surprising downgrades can happen during temporary failures, which users might perceive as a serious reliability issue.
組織は、多くの場合、複数のサーバーにアドレス指定されたメールを受け入れることを許可します。たとえば、組織自体が複数のサーバーを運用する場合があり、代わりに、または他の組織とバックアップとしてメールを受け入れるように合意する場合があります。一般に、RFC 2821に記載されているように、認定サーバーは一般にMXレコードにリストされています。複数のサーバーがメールボックスのドメインパートのメールを受け入れると、それらのどれもUTF8SMTP拡張機能をサポートしていないことを強くお勧めします。それ以外の場合、驚くべき格下げは一時的な失敗中に発生する可能性があり、ユーザーは深刻な信頼性の問題として認識される場合があります。
When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content. "Time stamp" or "Received" appears in the form of "Received:" lines. The most important use of Received: lines is for debugging mail faults. When the delivery SMTP server makes the "final delivery" of a message, it inserts a Return-path line at the beginning of the mail data. The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For the trace information, this memo updates the time stamp line and the return path line [RFC2821] formally defined as follows:
SMTPサーバーが配信またはさらなる処理のためのメッセージを受信した場合、メッセージコンテンツの先頭にトレース（「タイムスタンプ」または「受信」）情報を挿入する必要があります。「タイムスタンプ」または「受信」は、「受信」の形で表示されます。受信の最も重要な使用法：行は、メールの障害をデバッグするためのものです。配信SMTPサーバーがメッセージの「最終配信」を作成すると、メールデータの開始時にリターンパスラインを挿入します。リターンパスの主な目的は、非配信またはその他のメールシステムの障害を示すメッセージを送信するアドレスを指定することです。トレース情報の場合、このメモはタイムスタンプラインとリターンパスライン[RFC2821]を次のように正式に定義します。
uReturn-path-line = "Return-Path:" FWS uReverse-path <CRLF>
; Replaces Return-path-line in Section 4.4 of RFC 2821
; uReverse-path is defined in Section 3.3 of this document
uTime-stamp-line = "Received:" FWS uStamp <CRLF>
; Replaces Time-stamp-line in Section 4.4 of RFC 2821
uStamp = From-domain By-domain uOpt-info ";" FWS date-time ; Replaces Stamp in Section 4.4 of RFC 2821
ustamp = from-domain by-domain uopt-info ";"FWS日付。RFC 2821のセクション4.4のスタンプを置き換えます
uOpt-info = [Via] [With] [ID] [uFor]
; Replaces Opt-info in Section 4.4 of RFC 2821
; The protocol value for With will allow a UTF8SMTP value
uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS
; Replaces For in Section 4.4 of RFC 2821
; uPath and uMailbox are defined in Sections 2.4 and
; 2.3, respectively, of this document
Note: The FOR parameter has been changed to match the definition in [RFC2821bis], permitting only one address in the For clause. The group working on that document reached mailing list consensus that the syntax in [RFC2821] that permitted more than one address was simply a mistake.
注：[RFC2821bis]の定義に一致するようにパラメーターが変更されており、節の1つのアドレスのみが許可されています。そのドキュメントに取り組んでいるグループは、複数の住所を許可した[RFC2821]の構文が単なる間違いであるというメーリングリストのコンセンサスに到達しました。
Except in the 'uFor' clause and 'uReverse-path' value where non-ASCII domain names may be used, internationalized domain names in Received fields MUST be transmitted in the form of ACE labels. The protocol value of the WITH clause when this extension is used is one of the UTF8SMTP values specified in the "IANA Considerations" section of this document.
非ASCIIドメイン名を使用できる「UFOR」句と「ureverse-path」値を除き、受信したフィールドの国際化ドメイン名はACEラベルの形で送信する必要があります。このドキュメントの「IANA考慮事項」セクションで指定されているUTF8SMTP値の1つは、この拡張機能が使用されている場合のWith句のプロトコル値です。
If the client issues a RCPT command containing non-ASCII characters, the SMTP server is permitted to use UTF-8 characters in the email address associated with 251 and 551 response codes.
クライアントが非ASCII文字を含むRCPTコマンドを発行した場合、SMTPサーバーは251および551の応答コードに関連付けられた電子メールアドレスでUTF-8文字を使用することができます。
If an SMTP client follows this specification and sends any RCPT commands containing non-ASCII addresses, it MUST be able to accept and process 251 or 551 responses containing UTF-8 email addresses. If a given RCPT command does not include a non-ASCII envelope address, the 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 addresses.
SMTPクライアントがこの仕様に従い、非ASCIIアドレスを含むRCPTコマンドを送信する場合、UTF-8の電子メールアドレスを含む251または551の応答を受け入れて処理できる必要があります。特定のRCPTコマンドに非ASSASCIIエンベロープアドレスが含まれていない場合、サーバーはASCII以外のメールボックスを含む251または551の応答を返してはなりません。代わりに、そのような応答をアドレスを含まない250または550の応答に変換する必要があります。
If the VRFY and EXPN commands are transmitted with an optional parameter "UTF8REPLY", it indicates the client can accept UTF-8 strings in replies from those commands. This allows the server to use UTF-8 strings in mailbox names and full names that occur in replies without concern that the client might be confused by them. An SMTP client that conforms to this specification MUST accept and correctly process replies from the VRFY and EXPN commands that contain UTF-8 strings. However, the SMTP server MUST NOT use UTF-8 strings in replies if the SMTP client does not specifically allow such replies by transmitting this parameter. Most replies do not require that a mailbox name be included in the returned text, and therefore UTF-8 is not needed in them. Some replies, notably those resulting from successful execution of the VRFY and EXPN commands, do include the mailbox, making the provisions of this section important.
VRFYコマンドとEXPNコマンドがオプションのパラメーター「UTF8REPLY」で送信された場合、クライアントがそれらのコマンドからの応答でUTF-8文字列を受け入れることができることを示します。これにより、サーバーは、クライアントがそれらに混乱する可能性があることを懸念なく、返信で発生するメールボックス名とフルネームでUTF-8文字列を使用できます。この仕様に準拠するSMTPクライアントは、UTF-8文字列を含むVRFYおよびEXPNコマンドから返信を受け入れ、正しく処理する必要があります。ただし、SMTPクライアントがこのパラメーターを送信してそのような応答を特異的に許可していない場合、SMTPサーバーは応答でUTF-8文字列を使用しないでください。ほとんどの返信では、メールボックス名を返されたテキストに含める必要はないため、UTF-8は必要ありません。いくつかの返信、特にVRFYコマンドとEXPNコマンドの実行が成功したことから生じるものは、メールボックスを含め、このセクションの規定を重要にします。
VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:
検証（vrfy）および展開（expn）コマンド構文は次のように変更されます。
"VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF ; uLocal-part and uMailbox are defined in ; Section 3.3 of this document.
"vrfy" sp（local-part / umailbox）[sp "utf8reply"] crlf;Ulocal-PartおよびUmailboxはで定義されています。このドキュメントのセクション3.3。
"EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF ; uLocal-part and uMailbox are defined in ; Section 3.3 of this document.
"expn" sp（local-part / umailbox）[sp "utf8reply"] crlf;Ulocal-PartおよびUmailboxはで定義されています。このドキュメントのセクション3.3。
The "UTF8REPLY" parameter does not use a value. If the reply to a VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8, but the SMTP client does not use the "UTF8REPLY" parameter, then the server MUST use either the response code 252 or 550. Response code 252, defined in [RFC2821], means "Cannot VRFY user, but will accept the message and attempt the delivery". Response code 550, also defined in [RFC2821], means "Requested action not taken: mailbox unavailable". When the server supports enhanced mail system status codes [RFC3463], the enhanced response code as specified below is used. Using the "UTF8REPLY" parameter with a VERIFY (VRFY) or EXPAND (EXPN) command enables UTF-8 replies for that command only.
「UTF8REPLY」パラメーターは値を使用しません。検証（VRFY）または展開（Expn）コマンドへの返信にUTF-8が必要ですが、SMTPクライアントは「UTF8REPLY」パラメーターを使用しない場合、サーバーは応答コード252または550を使用する必要があります。応答コード252、[rfc2821]で定義されていることは、「ユーザーをvrfyできないが、メッセージを受け入れて配信を試みます」を意味します。[RFC2821]でも定義されている応答コード550は、「要求されたアクションが実行されない：メールボックスが利用できない」を意味します。サーバーが拡張されたメールシステムステータスコード[RFC3463]をサポートする場合、以下に指定された拡張応答コードが使用されます。検証（vrfy）または展開（expn）コマンドを使用して「utf8reply」パラメーターを使用して、そのコマンドのみの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 <uMailbox> ; uMailbox is defined in Section 3.3 of this document. ; User Name can contain non-ASCII characters.
ユーザー名<umailbox>;Umailboxは、このドキュメントのセクション3.3で定義されています。;ユーザー名には、ASCII以外の文字を含めることができます。
uMailbox ; uMailbox is defined in Section 3.3 of this document.
umailbox;Umailboxは、このドキュメントのセクション3.3で定義されています。
If the SMTP reply requires UTF-8 strings, but UTF-8 is not allowed in the reply, and the server supports enhanced mail system status codes [RFC3463], the enhanced response code is either "X.6.8" or "X.6.10" [RFC5248], 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 client".
SMTPの返信にUTF-8文字列が必要であるが、REPLYでUTF-8が許可されておらず、サーバーが拡張されたメールシステムステータスコード[RFC3463]をサポートする場合、拡張された応答コードは「X.6.8」または「X.6.10のいずれかです。「[RFC5248]、「UTF-8文字列を含む返信がメールボックス名を表示するために必要ですが、その形式の応答はクライアントによって許可されていません」を意味します。
If the SMTP client does not support the UTF8SMTP 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 crash. Internationalized messages in replies are only allowed in the commands under the situations described above. Under any other circumstances, UTF-8 text MUST NOT appear in the reply.
SMTPクライアントがUTF8SMTP拡張機能をサポートしていないが、返信でUTF-8文字列を受信した場合、ユーザーへの返信を適切に報告できず、一部のクライアントがクラッシュする可能性があります。返信の国際化されたメッセージは、上記の状況に基づくコマンドでのみ許可されています。他の状況では、UTF-8テキストが返信に表示されてはなりません。
Although UTF-8 is needed to represent email addresses in responses under the rules specified in this section, this extension does not permit the use of UTF-8 for any other purposes. SMTP servers MUST NOT include non-ASCII characters in replies except in the limited cases specifically permitted in this section.
UTF-8は、このセクションで指定されたルールに基づいて応答の電子メールアドレスを表すために必要ですが、この拡張機能は他の目的でUTF-8の使用を許可しません。SMTPサーバーは、このセクションで特に許可されている限られたケースを除き、応答にASCII以外の文字を含めるべきではありません。
IANA has added a new value "UTF8SMTP" to the SMTP Service Extension subregistry of the Mail Parameters registry, according to the following data:
IANAは、次のデータに従って、Mail ParametersレジストリのSMTPサービスエクステンションサブレジストリに新しい値「UTF8SMTP」を追加しました。
+----------+---------------------------------+-----------+
| Keywords | Description | Reference |
+----------+---------------------------------+-----------+
| UTF8SMTP | Internationalized email address | [RFC5336] |
+----------+---------------------------------+-----------+
This document adds new values to the SMTP Enhanced Status Code subregistry of the Mail Parameters registry, following the guidance in Sections 3.5 and 3.7.4.2 of this document, and being based on [RFC5248]. The registration data is as follows:
このドキュメントでは、このドキュメントのセクション3.5および3.7.4.2のガイダンスに従って、[RFC5248]に基づいて、Mail ParametersレジストリのSMTP強化ステータスコードサブレジストリに新しい値を追加します。登録データは次のとおりです。
Code: X.6.7 Sample Text: The ALT-ADDRESS is required but not specified Associated basic status code: 553, 550 Description: This indicates the reception of a MAIL or RCPT command that required an ALT-ADDRESS parameter but such parameter was not present. Defined: RFC 5336 (Experimental track) Submitter: Jiankang YAO Change controller: IESG.
コード：X.6.7サンプルテキスト：Alt-Addressは必要ですが、特定されていない関連する基本ステータスコード：553、550説明：これは、Alt-Addressパラメーターを必要とするメールまたはRCPTコマンドの受信を示しますが、そのようなパラメーターは存在しませんでした。定義：RFC 5336（実験トラック）提出者：Jiankang Yao Change Controller：Iesg。
Code: X.6.8 Sample Text: UTF-8 string reply is required, but not permitted by the client Associated basic status code: 553, 550 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 client. Defined: RFC 5336. (Experimental track) Submitter: Jiankang YAO Change controller: IESG.
コード：X.6.8サンプルテキスト：UTF-8文字列応答は必要ですが、クライアントに関連する基本ステータスコードでは許可されていません。、しかし、その形式の応答はクライアントによって許可されていません。定義：RFC5336。（実験的なトラック）提出者：Jiankang Yao Change Controller：Iesg。
Code: X.6.9 Sample Text: UTF8SMTP downgrade failed Associated basic status code: 550 Description: This indicates that transaction failed after the final "." of the DATA command. Defined: RFC 5336. (Experimental track) Submitter: Jiankang YAO Change controller: IESG.
コード：X.6.9サンプルテキスト：UTF8SMTPダウングレードに失敗した関連する基本ステータスコード：550説明：これは、トランザクションがファイナルの後に失敗したことを示しています。データコマンドの。定義：RFC5336。（実験的なトラック）提出者：Jiankang Yao Change Controller：Iesg。
Code: X.6.10 Sample Text: UTF-8 string reply is required, but not permitted by the client Associated basic status code: 252 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 client. Defined: RFC 5336. (Experimental track) Submitter: Jiankang YAO Change controller: IESG.
コード：X.6.10サンプルテキスト：UTF-8文字列返信は必要ですが、クライアントに関連する基本ステータスコードで許可されていません。その形式の応答は、クライアントによって許可されていません。定義：RFC5336。（実験的なトラック）提出者：Jiankang Yao Change Controller：Iesg。
The "Mail Transmission Types" registry under the Mail Parameters registry is requested to be updated to include the following new entries:
メールパラメータレジストリの下にある「メール送信タイプ」レジストリは、次の新しいエントリを含めるように更新するように要求されます。
+---------------+----------------------------+----------------------+
| WITH protocol | Description | Reference |
| types | | |
+---------------+----------------------------+----------------------+
| UTF8SMTP | UTF8SMTP with Service | [RFC5336] |
| | Extensions | |
| UTF8SMTPA | UTF8SMTP with SMTP AUTH | [RFC4954] [RFC5336] |
| UTF8SMTPS | UTF8SMTP with STARTTLS | [RFC3207] [RFC5336] |
| UTF8SMTPSA | UTF8SMTP with both | [RFC3207] [RFC4954] |
| | STARTTLS and SMTP AUTH | [RFC5336] |
+---------------+----------------------------+----------------------+
See the extended security considerations discussion in the framework document [RFC4952].
フレームワークドキュメント[RFC4952]の拡張セキュリティに関する考慮事項の議論を参照してください。
Much of the text in the initial version of this specification was derived or copied from [Emailaddr] with the permission of the author. Significant comments and suggestions were received from Xiaodong LEE, Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET team and were incorporated into the specification. Additional important comments and suggestions, and often specific text, were contributed by many members of the WG 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, and Lars Eggert. Of course, none of the individuals are necessarily responsible for the combination of ideas represented here.
この仕様の初期バージョンのテキストの多くは、著者の許可を得て[emailaddr]から派生またはコピーされました。Xiaodong Lee、Nai-Wen Hsu、Yangwoo Ko、Yoshiro Youneya、およびJetチームの他のメンバーから重要なコメントと提案が受け取られ、仕様に組み込まれました。追加の重要なコメントと提案、および多くの場合、特定のテキストは、WGおよびデザインチームの多くのメンバーから寄付されました。これらの貢献には、ジョン・C・クレンシン、チャールズ・リンジー、デイブ・クロッカー、ハラルド・トヴェイト・アルベスランド、マルコス・サンツ、クリス・ニューマン、マーティン・ドゥースト、エドモン・チョン、トニー・フィンチ、カリ・ハートタ、ランドール・ゲレンズ、フランク・エレルマン、アレクシー・メルニコフ、ペテ・レスニコフの資料が含まれます。Moonesamy、Soobok Lee、Shawn Steele、Alfred Hoenes、Miguel Garcia、Magnus Westerlund、およびLars Eggert。もちろん、ここに示されているアイデアの組み合わせに対して必ずしも責任者はいません。
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.
[ASCII] American National Standards Institute（以前の米国標準研究所）、「米国情報交換のコード」、ANSI X3.4-1968、1968。
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[RFC1652] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「8bit-MimetransportのSMTPサービス拡張」、RFC 1652、1994年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC3461] Moore、K。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status通知（DSNS）」、RFC 3461、2003年1月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RFC3463] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、2003年1月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC3464] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、RFC 4409、2006年4月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952] Klensin、J。およびY. Ko、「国際化された電子メールの概要とフレームワーク」、RFC 4952、2007年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008.
[RFC5248] Hansen、T。およびJ. Klensin、「SMTP強化されたメールシステムステータスコードのレジストリ」、BCP 138、RFC 5248、2008年6月。
[RFC5335] Abel, Y., Ed., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335] Abel、Y.、ed。、「Internationalized Email Headers」、RFC 5335、2008年9月。
[RFC5337] Newman, C. and A. Melnikov, Ed., "Internationalized Delivery Status and Disposition Notifications", RFC 5337, September 2008.
[RFC5337] Newman、C。and A. Melnikov、ed。、「国際化された配送状況と処分通知」、RFC 5337、2008年9月。
[Downgrade] Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for Email Address Internationalization", Work in Progress, July 2008.
[ダウングレード] Fujiwara、K。およびY. Youneya、「電子メールアドレス国際化のためのダウングレードメカニズム」、2008年7月の作業。
[Emailaddr] Klensin, J., "Internationalization of Email Addresses", Work in Progress, July 2005.
[Emailaddr] Klensin、J。、「電子メールアドレスの国際化」、2005年7月、進行中の作業。
[RFC0974] Partridge, C., "Mail routing and the domain system", RFC 974, January 1986.
[RFC0974] Partridge、C。、「メールルーティングとドメインシステム」、RFC 974、1986年1月。
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[RFC2033] Myers、J。、「ローカルメール転送プロトコル」、RFC 2033、1996年10月。
[RFC2821bis] Klensin, J., "Simple Mail Transfer Protocol", Work in Progress, July 2008.
[RFC2821BIS] Klensin、J。、「Simple Mail Transfer Protocol」、2008年7月の作業。
[RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[RFC3030] Vaudreuil、G。、「大型およびバイナリMIMEメッセージの送信用SMTPサービス拡張」、RFC 3030、2000年12月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207] Hoffman、P。、「輸送層セキュリティ上の安全なSMTPのSMTPサービス拡張」、RFC 3207、2002年2月。
[RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[RFC4954] Siemborski、R.、ed。and A. Melnikov編、「認証のためのSMTPサービス拡張」、RFC 4954、2007年7月。
RFC 4952, the overview and framework document covering this set of extensions for internationalized email, was completed before this specification, which specifies a particular part of the protocol set. This appendix, which is normative, contains material that would have been incorporated into RFC 4952 had it been delayed until the work described in the rest of this specification was completed. This material should be included in any update to RFC 4952.
RFC 4952、国際化された電子メールのこの一連の拡張機能をカバーする概要とフレームワークドキュメントは、プロトコルセットの特定の部分を指定するこの仕様の前に完了しました。規範的なこの付録には、この仕様の残りの部分で説明されている作業が完了するまで遅延していれば、RFC 4952に組み込まれていたであろう材料が含まれています。この資料は、RFC 4952の更新に含める必要があります。
o A conventional message is one that does not use any extension defined in this document or in the UTF-8 header specification [RFC5335], and which is strictly conformant to RFC 2822 [RFC2822].
o 従来のメッセージとは、このドキュメントまたはUTF-8ヘッダー仕様[RFC5335]で定義されている拡張機能を使用しないものであり、RFC 2822 [RFC2822]に厳密に適合しています。
o An internationalized message is a message utilizing one or more of the extensions defined in this specification or in the UTF-8 header specification [RFC5335], so that it is no longer conformant to the RFC 2822 specification of a message.
o 国際化されたメッセージは、この仕様またはUTF-8ヘッダー仕様[RFC5335]で定義されている1つ以上の拡張機能を使用したメッセージであるため、メッセージのRFC 2822仕様に適合しなくなります。
LMTP [RFC2033] may be used as the final delivery agent. In such cases, LMTP may be arranged to deliver the mail to the mail store. The mail store may not have UTF8SMTP capability. LMTP needs to be updated to deal with these situations.
LMTP [RFC2033]は、最終配信剤として使用できます。そのような場合、LMTPはメールストアにメールを配信するように手配できます。メールストアにはUTF8SMTP機能がない場合があります。これらの状況に対処するには、LMTPを更新する必要があります。
The existing Draft Standard regarding delivery status notifications (DSNs) [RFC3461] is limited to ASCII text in the machine readable portions of the protocol. "International Delivery Status and Disposition Notifications" [RFC5337] adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. If an SMTP server advertises both the UTF8SMTP and the DSN extension, that server MUST implement EAI DSN [RFC5337] including support for the ORCPT parameter.
配信ステータス通知（DSNS）[RFC3461]に関する既存のドラフト標準は、プロトコルの読み取り可能な部分のASCIIテキストに限定されています。「国際配信ステータスと気質通知」[RFC5337]は、国際的な電子メールアドレスの新しいアドレスタイプを追加するため、ASCII以外の文字を持つ元の受信者アドレスを格下げ後でも正しく保存できます。SMTPサーバーがUTF8SMTPとDSN拡張機能の両方を宣伝する場合、そのサーバーはORCPTパラメーターのサポートを含むEAI DSN [RFC5337]を実装する必要があります。
In the absence of this extension, SMTP clients and servers are constrained to using only those addresses permitted by RFC 2821. The local parts of those addresses MAY be made up of any ASCII characters, although some of them MUST be quoted as specified there. It is notable in an internationalization context that there is a long history on some systems of using overstruck ASCII characters (a character, a backspace, and another character) within a quoted string to approximate non-ASCII characters. This form of internationalization SHOULD be phased out as this extension becomes widely deployed, but backward-compatibility considerations require that it continue to be supported.
この拡張機能がない場合、SMTPクライアントとサーバーは、RFC 2821で許可されているアドレスのみを使用するように制約されています。これらのアドレスのローカル部分は、ASCII文字で構成されている場合がありますが、それらのいくつかはそこに指定されているとおり引用する必要があります。国際化の文脈では、引用された文字列内のオーバーストラックASCIIキャラクター（キャラクター、バックスペース、および別のキャラクター）を使用して、ASCII以外の文字を近似するシステムを使用するシステムに長い歴史があることが注目に値します。この形式の国際化は、この拡張機能が広く展開されるため、段階的に廃止されるべきですが、後方互換性の考慮事項は引き続きサポートされる必要があります。
Among other protocol changes, the SMTP extension allows an optional alternate address to be supplied with the MAIL and RCPT commands. For the purposes of this set of specifications, this alternate address only has meaning when the primary address contains UTF-8 characters and the message is downgraded. While it may be tempting to consider the alternate address as a general-purpose second-chance address to be used whenever the primary address is rejected, such behavior is not defined here. This restriction allows for future extensions to be developed which create such a general-purpose second-chance address, although no specific work on such an extension is currently anticipated. Note that any such extension needs to consider the question of what the [RFC0974] sequencing rules mean when different possible servers support different sets of ESMTP options (or, in this case, addresses). The answer to this question may also imply updates to [RFC2821].
他のプロトコルの変更の中でも、SMTP拡張により、オプションの代替アドレスをメールおよびRCPTコマンドで提供できます。この一連の仕様の目的のために、この代替アドレスには、プライマリアドレスにUTF-8文字が含まれ、メッセージが格下げされている場合にのみ意味があります。代替アドレスを、主要なアドレスが拒否されるたびに使用される汎用の第2チャンスアドレスと見なすのは魅力的かもしれませんが、そのような動作はここでは定義されていません。この制限により、このような汎用のセカンドチャンスアドレスを作成する将来の拡張機能を開発することができますが、このような拡張に関する特定の作業は現在予想されていません。このような拡張機能は、異なる可能性のあるサーバーがESMTPオプションの異なるセットをサポートしている場合（またはこの場合、アドレス）、[RFC0974]シーケンスルールが何を意味するかを考慮する必要があることに注意してください。この質問に対する答えは、[RFC2821]の更新も意味する場合があります。
Authors' Addresses
著者のアドレス
Jiankang YAO (editor) CNNIC No.4 South 4th Street, Zhongguancun Beijing
Jiankang Yao（編集者）CNNIC No.4 South 4th Street、Zhongguancun Beijing
Phone: +86 10 58813007
EMail: yaojk@cnnic.cn
Wei MAO (editor) CNNIC No.4 South 4th Street, Zhongguancun Beijing
Wei Mao（編集者）CNNIC No.4 South 4th Street、Zhongguancun Beijing
Phone: +86 10 58812230
EMail: maowei_ietf@cnnic.cn
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。