RFC5336 日本語訳
5336 SMTP Extension for Internationalized Email Addresses. J. Yao,Ed., W. Mao, Ed.. September 2008. (Format: TXT=48110 bytes) (Updates RFC2821, RFC2822, RFC4952) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Yao, Ed. Request for Comments: 5336 W. Mao, Ed. Updates: 2821, 2822, 4952 CNNIC Category: Experimental September 2008
ワーキンググループJ.八尾、エドをネットワークでつないでください。コメントのために以下を要求してください。 エド5336w.マオ、アップデート: 2821、2822、4952CNNICカテゴリ: 実験的な2008年9月
SMTP Extension for Internationalized Email Addresses
国際化しているEメールアドレスのための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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
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.
このドキュメントは国際化しているEメールアドレスかヘッダー情報があるメールメッセージの輸送と配送のためのSMTP拡張子を指定します。 この仕様を履行しないシステムとのコミュニケーションは別のドキュメントで指定されます。 このドキュメントで、RFC2821とRFC2822で定義されたいくつかの構文と規則をアップデートして、何らかの材料がRFC4952をアップデートします。
Yao & Mao Experimental [Page 1] RFC 5336 EAI SMTP Extension September 2008
[1ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 この仕様. . . . . . . . . . . . . . . . 3 1.2の役割。 用語. . . . . . . . . . . . . . . . . . . . . . . 3 2。 操作. . . . . . . . . . . . . . . . . . . . 4 3の概観。 輸送レベルプロトコル. . . . . . . . . . . . . . . . 4 3.1を郵送してください。 国際化拡大. . . . . 4 3.2のための枠組み。 UTF8SMTP拡張子. . . . . . . . . . . . . . . . . . 5 3.3。 拡張メールボックスアドレス構文. . . . . . . . . . . . . 7 3.4。 ALT-アドレスパラメタ. . . . . . . . . . . . . . . . 9 3.5。 ALT-アドレスパラメタ用法と応答は.103.6をコード化します。 ボディ・パーツとSMTP拡張子. . . . . . . . . . . . . . 11 3.7。 追加ESMTP変化と明確化. . . . . . . 11 3.7.1。 初期のSMTP交換. . . . . . . . . . . . . . 12 3.7.2。 交換器. . . . . . . . . . . . . . . . . . . 12 3.7.3を郵送してください。 情報. . . . . . . . . . . . . . . . . . 12 3.7.4をたどってください。 回答. . . . . . . . . . . . . . . 13 4におけるUTF-8ストリング。 IANA問題. . . . . . . . . . . . . . . . . . . . . 15 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 17 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 17 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 18 7.2。 RFC4952.20A.1をアップデートする有益な参照. . . . . . . . . . . . . . . . . . 19付録A.資料。 従来のメッセージと国際化しているメッセージ. . . . 20A.2。 LMTP. . . . . . . . . . . . . . . . . . . . . . . . . . . 20A.3。 SMTPはDSNs. . . . . . . . . . . . . 20A.4のために拡大を修理します。 実現アドバイス. . . . . . . . . . . . . . . . . . 20A.5。 追加用途. . . . 21へのSMTP拡張子の適用性
Yao & Mao Experimental [Page 2] RFC 5336 EAI SMTP Extension September 2008
[2ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
1. Introduction
1. 序論
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.
国際化しているEメールアドレスは2つの部品、地方の部分、およびドメイン部分を含んでいます。 Eメールアドレスがプロトコルによって使用される方法はドメイン名が使用されている方法と異なっています。 最もきわどい違いはクライアントとサーバのチェーンを通してメールを送るということです、ドメイン名はそれら自身のテーブルのそれらの名前を調べるネームサーバによって決議されていますが。 これに加えて、シンプルメールトランスファプロトコル[RFC2821]はクライアントがサーバ能力を発見して、さらなる処理のための決定をすることができるサービス拡大に関する交渉メカニズムを提供します。 国際化しているアドレスとヘッダーのための拡大モデルの敷衍された概観は「枠組みのドキュメント」と呼ばれた[RFC4952]かちょうど「枠組み」としてこの仕様のほかの場所に現れます。 このドキュメントは、封筒で国際化しているEメールアドレスを可能にして、ヘッダーでユニコード文字(UTF-8では、コード化されます)[RFC3629]を可能にするためにSMTP拡張子を指定します。
1.1. Role of This Specification
1.1. この仕様の役割
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.
このドキュメントはメール国際化仕事(明確に国際化しているEメールアドレス輸送配送のためのSMTP拡張子[RFC2821]の定義)の要素を指定します。
1.2. Terminology
1.2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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]でコード化されたユニコード文字について言及するのに非公式に使用されます。 この仕様で使用される他のすべての専門の用語が枠組みのドキュメントかベースインターネットメール仕様[RFC2821][RFC2822]に基づき定義されます。 本書では枠組みのドキュメントとの定義に従って、特に、用語「ASCIIアドレス」、「国際化しているEメールアドレス」、「非ASCIIのアドレス」、"i18mail address"、"UTF8SMTP"、「メッセージ」、および「メーリングリスト」は使用されます。
Yao & Mao Experimental [Page 3] RFC 5336 EAI SMTP Extension September 2008
[3ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
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]のものと異なったAugmented BNF(ABNF)[RFC5234]シンタックス・ルールだけを定義して、以前の規則がアップグレードするか、または広げられるところに新しい名前をそれらに与えます。 新しい規則が古いものへの小さい変更であるときに、「u」から始まる名前を考えて、それは通常、変更です。 ここで未定義の規則はベースメール仕様で同じ名前の下で見つけられるかもしれません。
2. Overview of Operation
2. 操作の概観
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.
仕様[RFC5335]が非ASCII文字であるどのように、ところに詳細を明らかにするEAI UTF-8ヘッダーはメッセージのヘッダーフィールドで受入れられます。 この仕様のための文脈は枠組みのドキュメントで説明されます。
3. Mail Transport-Level Protocol
3. 輸送レベルプロトコルを郵送してください。
3.1. Framework for the Internationalization Extension
3.1. 国際化拡大のための枠組み
The following service extension is defined:
以下のサービス拡大は定義されます:
1. The name of the SMTP service extension is "Email Address
Internationalization".
1. SMTPサービス拡張子の名前は「Eメールアドレス国際化」です。
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を含んでいるなら、この仕様のこのバージョンで完全に言いなりになっていなければなりません。
Yao & Mao Experimental [Page 4] RFC 5336 EAI SMTP Extension September 2008
[4ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
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)アドレスの代用品として使用できるオール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. "UTF8REPLY"という1つの任意のパラメタがVRFYとEXPNコマンドに追加されます。 パラメタUTF8REPLYには、値が全くありません。 パラメタは、SMTPクライアントがVRFYとEXPNから回答でコマンドをコード化するUTF-8でユニコード文字を受け入れることができるのを示します。
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 MAILとRCPTコマンドの逆経路とフォワードパスは、UTF-8でメールボックス名(アドレス)でコード化されたユニコード文字を許容するために広げられます。
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. 460のキャラクタがALT-ADDRESSキーワードと価値の可能な添加で最大の長さのメールとRCPTコマンドラインを増加させます。
11. The UTF8SMTP extension is valid on the submission port
[RFC4409].
11. UTF8SMTP拡張子は服従ポート[RFC4409]で有効です。
3.2. The UTF8SMTP Extension
3.2. UTF8SMTP拡張子
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.
RFC2821がメールボックスが現れることができると指定するあらゆる位置でUTF-8ストリング[RFC3629]を受け入れるようにこの拡大を発表するSMTPサーバーを準備しなければなりません。 単に指定されるとしてRFC2821でそのストリングを分析しなければなりません、すなわち、そこで指定されるように送信元経路、地方の部分にメールボックスを切り離して、ドメイン部分、キャラクタコロン(U+003A)だけを使用するコンマを(U+002C)と、サインで切り離すことによって(U+0040)。 この構文解析工程でいったん隔離されて、SMTPサーバーが最終的な配送メール配達エージェント(MTA)でないなら地方の部分を不透明なものとして扱わなければなりません。 見られることになっているどんなドメイン名も最初に、DNS MUSTで上昇します。それらがそのフォームに既にない場合、ToASCII()操作によって「アプリケーション(IDNA)におけるドメイン名を国際的にします」で指定されたフォーム[RFC3490]に処理されてください。 地方のストリングと比較されるために、SHOULDとして正当性がないかどうかチェックされて、次に、比較しなければならないということであるどんなドメイン名もIDNAのセクション3.4で指定しました。
Yao & Mao Experimental [Page 5] RFC 5336 EAI SMTP Extension September 2008
[5ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
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.
UTF-8の国際化しているストリングが形成されるとき、EHLOコマンドに対応してUTF8SMTP拡大キーワードを受け取るSMTPクライアントはSMTPコマンドの中でメールボックス名を伝えるかもしれません。 それはUTF-8ヘッダー[RFC5335](また、UTF-8のメールボックス名を含むかもしれない)を送るかもしれません。 それはACE(ASCII Compatible Encoding)ラベル(IDNA[RFC3490]で指定されるように)かUTF-8ストリングのどちらかとしてSMTPコマンドかメッセージヘッダーの中にメールボックス名のドメイン部分を伝えるかもしれません。 IDNs(UTF-8かACEストリングのどちらか)であるメールボックス名のドメイン部分のすべてのラベルが有効であるに違いありません。 オリジナルのクライアントがMessage Submission Server("MSA")[RFC4409]にメッセージを提出するなら、すべてのドメインがラベルするMSAの責任が有効であるということです。 さもなければ、それはオリジナルのクライアントの責任です。 UTF8SMTP拡張子の存在はメールをリレーするサーバが、何らかの方法で地方の部分を分析するか、評価するか、または変えるのを試みてはいけないというRFC2821の要件を変えません。
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拡張子がServerによって提供されないなら、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クライアント(送付者)がMessage Submission Server("MSA")[RFC4409]である場合にだけ、そのようなサーバで変化のための予算総則にMessage Submission Serverであることを書き直すか、または材料を通信させて、彼らをRFC2821[RFC2821]とRFC2822[RFC2822]に関する条項と完全にASCIIで一致するようにしてください。
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取引の間、メッセージを拒絶するか、メッセージを受け入れて、発生して、または伝えるかもしれません。 通知をしなければならないそのようなものはRFC2821[RFC2821]、RFC3464[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を可能にする目的地に代替経路を見つけるかもしれません。 そのルートは、交互のメールeXchanger(MX)ホスト(RFC2821の指定されるとしての優先規則を使用します)を裁くか、または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
4. ASCIIアドレスが試みられて、リターンパスと特定のフォワードパスに現れるすべてのアドレスに利用可能である場合にだけ、それはオールASCIIにメッセージを格下げするかもしれません。
Yao & Mao Experimental [Page 6] RFC 5336 EAI SMTP Extension September 2008
[6ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
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.
[ダウングレード]で指定されるように、形成してください。 ASCIIで封筒のオリジナルのアドレスがあるか、またはALT-ADDRESSパラメタがUTF8SMTPアドレスに指定されるなら、ASCIIアドレスが特定のアドレスに「利用可能である」と考えられます。
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がMessage Submission[RFC4409]によって抑制されるということです、特選している4が[ダウングレード]で強制的ですが。
3.3. Extended Mailbox Address Syntax
3.3. 拡張メールボックスアドレス構文
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.
RFC2821(セクション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]と共にconformantである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 「原子」の定義を変えて、上の定義か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]で定義されます。
Yao & Mao Experimental [Page 7] RFC 5336 EAI SMTP Extension September 2008
[7ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
uMailbox = uLocal-part "@" uDomain
; Replace Mailbox in RFC 2821, Section 4.1.2
uMailboxはuLocal-部分"@"uDomainと等しいです。 RFC2821、セクション4.1.2でメールボックスを取り替えてください。
uLocal-part = uDot-string / uQuoted-string
; MAY be case-sensitive
; Replace Local-part in RFC 2821, Section 4.1.2
uLocal-部分はuQuoted uDot-ストリング/ストリングと等しいです。 大文字と小文字を区別しているかもしれません。 RFC2821、セクション4.1.2で地方の部分を取り替えてください。
uDot-string = uAtom *("." uAtom)
; Replace Dot-string in RFC 2821, Section 4.1.2
uDot-ストリング=uAtom*、(「. 」 uAtom、)、。 RFC2821、セクション4.1.2でドットストリングを取り替えてください。
uAtom = 1*ucharacter
; Replace Atom in RFC 2821, Section 4.1.2
uAtomは1*ucharacterと等しいです。 RFC2821、セクション4.1.2で原子を取り替えてください。
ucharacter = atext / UTF8-non-ascii
ucharacterはatext / UTF8非ASCIIと等しいです。
atext = <See Section 3.2.4 of RFC 2822>
.4<Seeセクション3.2RFC2822atext=>。
uQuoted-string = DQUOTE *uqcontent DQUOTE
; Replace Quoted-string in RFC 2821, Section 4.1.2
uQuotedストリングはDQUOTE*uqcontent DQUOTEと等しいです。 RFC2821、セクション4.1.2における引用文字列を取り替えてください。
DQUOTE = <See appendix B.1 of RFC 5234>
DQUOTEはRFC5234>の<See付録B.1と等しいです。
uqcontent = qcontent / UTF8-non-ascii
uqcontentはqcontent / UTF8非ASCIIと等しいです。
qcontent = <See Section 3.2.5 of RFC 2822>
.5<Seeセクション3.2RFC2822qcontent=>。
uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal
; Replace Domain in RFC 2821, Section 4.1.2
uDomainが等しい、(サブudomain1*、(「. 」 サブudomain) /、アドレス文字通り。 RFC2821、セクション4.1.2におけるドメインを取り替えてください。
address-literal = <See Section 4.1.2 of RFC 2822>
アドレス文字通りの=<Seeセクション4.1 .2RFC2822>。
sub-udomain = uLet-dig [uLdh-str]
; Replace sub-domain in RFC 2821, Section 4.1.2
サブudomainはuLet-皮肉と等しいです[uLdh-str]。 RFC2821、セクション4.1.2におけるサブドメインを取り替えてください。
uLet-dig = Let-dig / UTF8-non-ascii
uLet-皮肉は皮肉をさせている/UTF8非ASCIIと等しいです。
Let-dig = <See Section 4.1.3 of RFC 2821>
皮肉をさせている=<は.3セクション4.1RFC2821>を見ます。
uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig
; Replace Ldh-str in RFC 2821, Section 4.1.3
uLdh-strは*(UTF8非アルファ/ケタ/「-」/ASCII)uLet-皮肉と等しいです。 RFC2821、セクション4.1.3でLdh-strを取り替えてください。
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8非ASCIIはUTF8-2/UTF8-3/UTF8-4と等しいです。
UTF8-2 = <See Section 4 of RFC 3629>
UTF8-2=<はRFC3629>のセクション4を見ます。
UTF8-3 = <See Section 4 of RFC 3629>
UTF8-3=<はRFC3629>のセクション4を見ます。
UTF8-4 = <See Section 4 of RFC 3629>
UTF8-4=<はRFC3629>のセクション4を見ます。
Yao & Mao Experimental [Page 8] RFC 5336 EAI SMTP Extension September 2008
[8ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
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"SHOULDでは、IDNA[RFC3490]の一部として指定されたテストを適用しながら、確かめられてください。 その検証が失敗するなら、そのuDomainがあるEメールアドレスを有効なEメールアドレスと見なしてはいけません。
3.4. The ALT-ADDRESS Parameter
3.4. ALT-アドレスパラメタ
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拡張子を提供するなら、「ALTアドレス」という任意のesmtp-キーワードを支持するためにSMTPメールとRCPTコマンドの構文を広げています。 そのキーワードは格下げするとき使用されるかもしれない交互のオールASCIIアドレスを指定します。 ALT-ADDRESS esmtp-キーワードが使用されているなら、それには、関連esmtp-値(以下で定義されるALT-ADDRESS-esmtp値)がなければなりません。
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が汎用第二の機会アドレスであるとみなすのに誘惑しているかもしれない間、そのような振舞いはここで定義されません。 関連第一のアドレスが非ASCIIであり、メッセージが格下げされるときだけ、代わりに、この仕様では、ALT-ADDRESSは意味を持っています。 どんなそのような拡大も現在、予期されませんが、この制限は仕様の今後の拡大を考慮します。
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パラメタ用法は以下の通り定義されます。 RFC2821で使用されるのと同じ形式で以下の定義を与えます。
"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.
「メールFROM:」 (uReverse「<>」/経路) [SPメールパラメタ] CRLF。 .2にRFC2821のメールコマンド、セクション4.1.1をアップデートしてください。 ; ABNF非端末によって定義された新しいパラメタ。 <ALT-ADDRESS-パラメタ>は加えられます。 それは応じます。 構文がRFC2821の<esmtp-param>に指定されている状態で。
"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.
「RCPT TO:」 (uForward「<郵便局長@」uDomain">"/「<郵便局長>」/経路) [SP Rcpt-パラメタ] CRLF。 .3にRFC2821のRCPTコマンド、セクション4.1.1をアップデートしてください。 ; ABNF非端末によって定義された新しいパラメタ。 <ALT-ADDRESS-パラメタ>は加えられます。 それは応じます。 構文が<esmtp-param>に指定されている状態で。 ; uDomainはこのドキュメントのセクション3.3で定義されます。
uReverse-path = uPath
; Replace Reverse-path in RFC 2821, Section 4.1.2.
uReverse-経路はuPathと等しいです。 RFC2821、セクション4.1.2における逆経路を取り替えてください。
uForward-path = uPath
; Replace Forward-path in RFC 2821, Section 4.1.2.
uForward-経路はuPathと等しいです。 RFC2821、セクション4.1.2におけるフォワードパスを取り替えてください。
Yao & Mao Experimental [Page 9] RFC 5336 EAI SMTP Extension September 2008
[9ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
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が等しい、「<、」 [d l」、:、」、]、uMailbox">"。 RFC2821、セクション4.1.2における経路を取り替えてください。 ; uMailboxはこのドキュメントのセクション3.3で定義されます。
A-d-l = <See Section 4.1.2 of RFC 2821>
d l=<は.2セクション4.1RFC2821>を見ます。
ALT-ADDRESS-parameter = "ALT-ADDRESS=" ALT-ADDRESS-value
ALTアドレスパラメタ=「ALTアドレス=」ALT-アドレス値
ALT-ADDRESS-value = xtext
; The value is a mailbox name encoded as xtext.
ALT-ADDRESS-値はxtextと等しいです。 値はxtextとしてコード化されたメールボックス名です。
xtext = <See Section 4.2 of RFC 3461>
xtextはRFC3461>の<Seeセクション4.2と等しいです。
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-パラメタはどんなメールやRCPTコマンドでも一度より多く見えてはいけません。 ALT-ADDRESS-esmtp-値はxtextコード化の前のオールASCII Eメールアドレスでなければなりません。
3.5. ALT-ADDRESS Parameter Usage and Response Codes
3.5. ALT-アドレスパラメタ用法と応答コード
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ケタの回答コードはRFC2821で定義されるようにそれらの意味と一致しています。
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を必要とするメールコマンドなどの他の理由で拒絶されるとき、意味が「メールボックス入手できません、な」状態で応答コード550は使用されます。 機能アップされたサーバサポートが「X.6.7"[RFC5248]は使用されています、「ALT-アドレスは、必要ですが、指定されません」と意味して」システムステータスコード[RFC3463]、応答コードに郵送するとき。
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」は「取引は失敗した」意味と共に使用されます。 機能アップされたサーバサポートが「X.6.9"[RFC5248]は使用されています、「UTF8SMTPダウングレードは失敗した」意味」をシステムステータスコード[RFC3463]、応答コードに郵送するとき。
Yao & Mao Experimental [Page 10] RFC 5336 EAI SMTP Extension September 2008
[10ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
3.6. Body Parts and SMTP Extensions
3.6. ボディ・パーツとSMTP拡張子
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パラメタは全くありません。 メッセージが国際的にされるかどうかに関する正確な知識を必要とするSMTPサーバーが、メッセージ本体ですべてのメッセージヘッダーフィールドとMIMEヘッダーフィールドを分析するのに必要です。
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ビットのデータ、多くの複雑なコード化問題を避ける適切な取り扱い能力があるのを保証するために、8BITMIME拡張子[RFC1652]をサポートするのを必要としている間、国際化しているアドレスの使用はMIMEメッセージで明らかに非ASCII身体の部分を必要としません。 ボディー内容を考えて、それが適切であるなら、UTF8SMTP拡張子がBODY=8BITMIMEパラメタと共に使用されるかもしれませんか、またはBODY=BINARYMIMEパラメタで、サーバがBINARYMIME[RFC3030]の広告を出すか、そして、それは適切です。
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:
'BODYパラメタがありません'の正確な解釈、サーバがALT-ADDRESSのあるなしにかかわらずUTF8SMTPと8BITMIMEの広告を出して、少なくとも1つの非ASCIIアドレスを受け取ると仮定して、「ボディー=8BITMIME」、およびメールコマンドにおける「ボディー=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. BODYパラメタが全くなければ、ヘッダーは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キャラクタを含んでいます、そして、いくつかかすべての身体の部分が行長かデリミタに関して制限なしで2進のデータを含んでいます。
3.7. Additional ESMTP Changes and Clarifications
3.7. 追加ESMTP変化と明確化
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コマンドに加えた様々な文脈とそれらへの拡張代替手段にアドレス(「メールボックス」)とドメイン名にかかわります。 一般に、規則はRFC2821がメールボックスを指定するとき、この仕様が、UTF-8が全体のストリングに使用されると予想するということです。 RFC2821がドメイン名を指定するとき、名前SHOULDは生のフォームが非ASCIIであるならACEラベルの形で指定します。
The following subsections list and discuss all of the relevant cases.
以下の小区分は、関連ケースのすべてを記載して、議論します。
Yao & Mao Experimental [Page 11] RFC 5336 EAI SMTP Extension September 2008
[11ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
3.7.1. The Initial SMTP Exchange
3.7.1. 初期のSMTP交換
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への応答に現れるドメイン名もホスト名フォームのそれがEHLOから応答を受ける後であるに違いないまでUTF8SMTPをサポートするかどうかを知ることができないので、すなわち、国際化しているACEラベルの形にあるに違いありません。
3.7.2. Mail eXchangers
3.7.2. 交換器を郵送してください。
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.
組織は、しばしば複数のサーバがそれらに扱われたメールを受け入れるのを認可します。 例えば、組織がそうするかもしれない、それ自体、1つ以上のサーバを操作してください、そして、バックアップとしてメールを認めるためにまたか代わりに他の組織と共に協定を持ってもよいです。 一般に、認可されたサーバはRFC2821で説明されるようにMX記録に記載されています。 1つ以上のサーバがメールボックスのドメイン部分のためのメールを受け入れるとき、それらのすべてかいずれのどちらかもUTF8SMTP拡張子をサポートしないと強く忠告されます。 さもなければ、驚異的なダウングレードは一時障害の間、起こることができます。(ユーザは重大な信頼性の問題として一時障害を知覚するかもしれません)。
3.7.3. Trace Information
3.7.3. トレース情報
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サーバーが配送かさらなる処理へのメッセージを受け取るとき、それはメールの文頭の内容で跡(「タイムスタンプ」の、または、「受け取られていている」)の情報を挿入しなければなりません。 「タイムスタンプ」か「受け取ったこと」が「受け取った」形に現れます。 系列。 Receivedの最も重要な使用: 系列がデバッグメール障害によってあります。 配送SMTPサーバがメッセージの「最終的な配送」を作ると、それはメールデータの始めにReturn-経路線を挿入します。 Return-経路のプライマリ目的は送られる非配送か他のメールシステム障害を示すメッセージがことであるアドレスを指定することです。 トレース情報に関しては、このメモは以下の通り正式に定義されたタイムスタンプ系列とリターンパス線[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
uReturn経路線=、「リターンパス:」 FWS uReverse-経路<CRLF>。 RFC2821のセクション4.4でリターン経路線を取り替えます。 uReverse-経路はこのドキュメントのセクション3.3で定義されます。
uTime-stamp-line = "Received:" FWS uStamp <CRLF>
; Replaces Time-stamp-line in Section 4.4 of RFC 2821
uTimeスタンプ系列=「受け取りました」。 FWS uStamp<CRLF>。 RFC2821のセクション4.4で時間スタンプ線を取り替えます。
uStamp = From-domain By-domain uOpt-info ";" FWS date-time
; Replaces Stamp in Section 4.4 of RFC 2821
「uStampはドメインからのドメインのそばのuOpt-インフォメーションと等しい」;、」 FWS日付-時間。 RFC2821のセクション4.4でスタンプを取り替えます。
Yao & Mao Experimental [Page 12] RFC 5336 EAI SMTP Extension September 2008
[12ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
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
を通してuOpt-インフォメーションが等しい、[]、[With][ID][uFor]。 RFCのセクション4.4でインフォメーションを選んでいる2821を取り替えます。 Withのためのプロトコル値はUTF8SMTP値を許容するでしょう。
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
uForは“FOR"(FWS(uPath / uMailbox))CFWSと等しいです。 コネのために、RFC2821のセクション4.4に取って代わります。 そして、uPathとuMailboxがセクション2.4で定義される、。 2.3と、それぞれ、このドキュメント
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.
以下に注意してください。 For節の1つのアドレスだけを可能にして、[RFC2821bis]との定義に合うようにFORパラメタを変えました。 そのドキュメントに取り組むグループは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-経路'値を除いて、ACEラベルの形でReceived分野の国際化ドメイン名を伝えなければなりません。 この拡大が使用されているとき、WITH節のプロトコル値はこのドキュメントの「IANA問題」セクションで指定されたUTF8SMTP値の1つです。
3.7.4. UTF-8 Strings in Replies
3.7.4. 回答におけるUTF-8ストリング
3.7.4.1. MAIL and RCPT Commands
3.7.4.1. メールとRCPTコマンド
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に関連しているEメールアドレスと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-8Eメールアドレスを含む251か551の応答を、受け入れて、処理できなければなりません。 与えられたRCPTコマンドが非ASCII封筒アドレスを含んでいないなら、サーバは非ASCIIメールボックスを含む251か551応答を返してはいけません。 代わりに、それはそのような応答をアドレスを含まない250か550の応答に変えなければなりません。
3.7.4.2. VRFY and EXPN Commands and the UTF8REPLY Parameter
3.7.4.2. VRFY、EXPNコマンド、およびUTF8REPLYパラメタ
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
VRFYとEXPNコマンドが"UTF8REPLY"という任意のパラメタで伝えられるなら、それは、クライアントがそれらのコマンドから回答でUTF-8ストリングを受け入れることができるのを示します。 これで、サーバはクライアントがそれらによって混乱するかもしれないという関心なしで回答で現れるメールボックス名とフルネームにUTF-8ストリングを使用できます。 この仕様に従うSMTPクライアントは、受け入れて、UTF-8ストリングを含むVRFYとEXPNコマンドから回答を正しく処理しなければなりません。 しかしながら、SMTPサーバーはUTF-8を使用してはいけません。
Yao & Mao Experimental [Page 13] RFC 5336 EAI SMTP Extension September 2008
[13ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
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.
SMTPクライアントが明確にないするなら、回答におけるストリングは、このパラメタを伝えることによって、そのような回答を許します。 ほとんどの回答は、メールボックス名が返されたテキストに含まれているのを必要としません、そして、したがって、UTF-8はそれらで必要ではありません。 いくつかの回答(著しくVRFYとEXPNコマンドのうまくいっている実行から生じるもの)がメールボックスを含んでいます、このセクションに関する条項を重要にして。
VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:
以下のことのためにVERIFY(VRFY)とEXPAND(EXPN)コマンド構文を変えます。
"VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF
; uLocal-part and uMailbox are defined in
; Section 3.3 of this document.
"VRFY"SP(uLocal-部分/uMailbox)[SP"UTF8REPLY"]CRLF。 uLocal-部分と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(uLocal-部分/uMailbox)[SP"UTF8REPLY"]CRLF。 uLocal-部分と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"パラメタは値を使用しません。 VERIFY(VRFY)かEXPAND(EXPN)コマンドに関する回答がUTF-8を必要としますが、SMTPクライアントが"UTF8REPLY"パラメタを使用しないなら、サーバは応答コード252か550を使用しなければなりません。 [RFC2821]で定義された応答コード252は「しかし、VRFYユーザ、意志は、メッセージを受け入れて、配送を試みることができないこと」を意味します。 また、[RFC2821]で定義された応答コード550が意味する、「取られなかった要求された行動:」 「メールボックス入手できません」。 サーバサポートがメールシステムステータスコード[RFC3463]を高めたとき、以下で指定されるとしての高められた応答コードは使用されています。 aがある"UTF8REPLY"パラメタが確かめるか(VRFY)、または広くする使用はそのコマンドだけのためのUTF-8回答を可能にします(EXPN)が、命令する。
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で定義されます。 ; ユーザNameは非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ストリングを必要としますが、UTF-8が回答で許容されていなくて、サーバサポートがメールシステムステータスコード[RFC3463]を高めて、高められた応答コードがどちらか、「X.6.8"か「「UTF-8ストリングを含む回答がメールボックス名を示しているのに必要ですが、その形式の応答はクライアントによって受入れられません」と意味するX.6.10"[RFC5248]。」
Yao & Mao Experimental [Page 14] RFC 5336 EAI SMTP Extension September 2008
[14ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
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がこのセクションで指定された規則の下で応答におけるEメールアドレスを表すのが必要ですが、この拡大はUTF-8のいかなる他の目的の使用も可能にしません。 このセクションで明確に受入れられた限られたケース以外に、SMTPサーバーは回答に非ASCII文字を含んではいけません。
4. IANA Considerations
4. IANA問題
IANA has added a new value "UTF8SMTP" to the SMTP Service Extension subregistry of the Mail Parameters registry, according to the following data:
IANAはメールパラメタ登録のSMTPサービス拡張子副登録に新しい値の"UTF8SMTP"を加えました、以下のデータによると:
+----------+---------------------------------+-----------+
| Keywords | Description | Reference |
+----------+---------------------------------+-----------+
| UTF8SMTP | Internationalized email address | [RFC5336] |
+----------+---------------------------------+-----------+
+----------+---------------------------------+-----------+ | キーワード| 記述| 参照| +----------+---------------------------------+-----------+ | UTF8SMTP| 国際化しているEメールアドレス| [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:
このドキュメントはメールParameters登録のSMTP Enhanced Status Code subregistryに新しい値を加えます、セクション3.5と3.7で指導に続いて。.4 このドキュメントと、[RFC5248]に.2基づくこと。 登録データは以下の通りです:
Yao & Mao Experimental [Page 15] RFC 5336 EAI SMTP Extension September 2008
[15ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
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が必要ですが、指定されたAssociated基本的なステータスコードは必要ではありません: 553、550記述: これがメールのレセプションを示すか、またはRCPTは、それがALT-ADDRESSパラメタを必要としましたが、そのようなパラメタが存在していなかったと命令します。 定義される: RFC5336(実験コース)Submitter: Jiankang YAO Changeコントローラ: 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ストリング回答は、クライアントのAssociatedの基本的なステータスコードによって必要ですが、受入れられません: 553、550記述: これは、UTF-8ストリングを含む回答がメールボックス名を示しているのに必要ですが、その形式の応答がクライアントによって受入れられないのを示します。 定義される: RFC5336。 (実験コース) Submitter: Jiankang YAO Changeコントローラ: 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は失敗したAssociated基本的なステータスコードを格下げします: 550記述: 「これは、トランザクションが決勝の後に失敗したのを示します」。. 」 データコマンドについて。 定義される: RFC5336。 (実験コース) Submitter: Jiankang YAO Changeコントローラ: 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ストリング回答は、クライアントのAssociatedの基本的なステータスコードによって必要ですが、受入れられません: 252記述: これは、UTF-8ストリングを含む回答がメールボックス名を示しているのに必要ですが、その形式の応答がクライアントによって受入れられないのを示します。 定義される: RFC5336。 (実験コース) Submitter: Jiankang YAO Changeコントローラ: IESG。
Yao & Mao Experimental [Page 16] RFC 5336 EAI SMTP Extension September 2008
[16ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
The "Mail Transmission Types" registry under the Mail Parameters registry is requested to be updated to include the following new entries:
メールParameters登録の下の「メールトランスミッションタイプ」登録が以下の新しいエントリーを含むようにアップデートするよう要求されています:
+---------------+----------------------------+----------------------+ | 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] | +---------------+----------------------------+----------------------+
+---------------+----------------------------+----------------------+ | WITHプロトコル| 記述| 参照| | タイプ| | | +---------------+----------------------------+----------------------+ | UTF8SMTP| サービスがあるUTF8SMTP| [RFC5336]| | | 拡大| | | UTF8SMTPA| SMTP AUTHとUTF8SMTP| [RFC4954][RFC5336]| | UTF8SMTPS| STARTTLSとUTF8SMTP| [RFC3207][RFC5336]| | UTF8SMTPSA| 両方があるUTF8SMTP| [RFC3207][RFC4954]| | | STARTTLSとSMTP AUTH| [RFC5336]| +---------------+----------------------------+----------------------+
5. Security Considerations
5. セキュリティ問題
See the extended security considerations discussion in the framework document [RFC4952].
フレームワークドキュメントにおける拡張セキュリティ問題議論[RFC4952]を見てください。
6. Acknowledgements
6. 承認
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]。 重要なコメントと提案は、JETチームのシャオドンLEE、Nai-Wenシュー、Yangwooノックアウト、Yoshiro YONEYAから受け取られていて、および他のメンバーであり、仕様に組み入れられました。 追加重要なコメント、提案、およびしばしば特定のテキストはWGとデザインチームの多くのメンバーによって寄付されました。 それらの貢献はジョンC Klensin、チャールズ・リンジー、デーヴ・クロッカー、ハラルドTveit Alvestrand、マルコス・サンス、クリス・ニューマン、マーチンDuerst、エドモン・チャン、トニーFinch、カリHurtta、ランドルGellens、フランクEllermann、Alexeyメリニコフ、ピートレズニック、S.Moonesamy、Soobokリー、ショーン・スティール、アルフレッドHoenes、ミゲル・ガルシア、マグヌスWesterlund、およびラース・エッゲルトからの材料を含んでいます。 もちろん、個人のだれでも必ずここに表された考えの組み合わせに責任があるというわけではありません。
Yao & Mao Experimental [Page 17] RFC 5336 EAI SMTP Extension September 2008
[17ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[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 Institut(以前アメリカ合衆国規格研究所)、「米国情報交換用符号」、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.、解放されています、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPは8ビット-MIMEtransportのために拡大を修理します」、RFC1652、1994年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status Notifications
(DSNs)", RFC 3461, January 2003.
[RFC3461]ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, January 2003.
[RFC3463] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC3463、2003年1月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications", RFC 3464,
January 2003.
[RFC3464] ムーアとK.とG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for
Mail", RFC 4409, April 2006.
[RFC4409] GellensとR.とJ.Klensin、「メールのためのメッセージ提案」、RFC4409、2006年4月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 4952, July 2007.
[RFC4952] Klensin、J.、Y.コー、および「国際化しているメールのための概要とフレームワーク」、RFC4952、7月2007日
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年1月。
Yao & Mao Experimental [Page 18] RFC 5336 EAI SMTP Extension September 2008
[18ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP
Enhanced Mail System Status Codes", BCP 138, RFC 5248,
June 2008.
[RFC5248] ハンセン、T.、およびJ.Klensin、「SMTPのための登録はメールシステムステータスコードを高めました」、BCP138、RFC5248、2008年6月。
[RFC5335] Abel, Y., Ed., "Internationalized Email Headers",
RFC 5335, September 2008.
[RFC5335] アベル、Y.、エド、「国際化しているメールヘッダー」、RFC5335、9月2008日
[RFC5337] Newman, C. and A. Melnikov, Ed., "Internationalized
Delivery Status and Disposition Notifications",
RFC 5337, September 2008.
[RFC5337] ニューマンとC.とA.メリニコフ、エド、「配送状態と気質通知を国際的にした」、RFC5337、9月2008日
7.2. Informative References
7.2. 有益な参照
[Downgrade] Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for
Email Address Internationalization", Work in Progress,
July 2008.
[格下げします] フジワラとK.とY.Yoneya、「メールAddress Internationalizationのためにメカニズムを格下げします」、Progress、2008年7月のWork。
[Emailaddr] Klensin, J., "Internationalization of Email Addresses",
Work in Progress, July 2005.
J.、「Eメールアドレスの国際化」という[Emailaddr]Klensinは進歩、2005年7月に働いています。
[RFC0974] Partridge, C., "Mail routing and the domain system",
RFC 974, January 1986.
[RFC0974] ヤマウズラ、C.が「ルーティングとドメインシステムを郵送する」、RFC974、1月1986日
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
October 1996.
[RFC2033] マイアーズ、J.、「ローカルのメール転送プロトコル」、RFC2033、1996年10月。
[RFC2821bis] Klensin, J., "Simple Mail Transfer Protocol", Work
in Progress, July 2008.
「簡単なメール転送プロトコル」という[RFC2821bis]Klensin、J.は進歩、2008年7月に働いています。
[RFC3030] Vaudreuil, G., "SMTP Service Extensions for
Transmission of Large and Binary MIME Messages",
RFC 3030, December 2000.
[RFC3030]ボードルイ、G.、「大きくて2進のMIMEメッセージの伝達のためのSMTPサービス拡張子」、RFC3030、2000年12月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP
over Transport Layer Security", RFC 3207,
February 2002.
[RFC3207]ホフマン、P.、「トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子」、RFC3207、2002年2月。
[RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
Extension for Authentication", RFC 4954, July 2007.
エド[RFC4954]Siemborski、R.、A.メリニコフ、エド、「認証のためのSMTPサービス拡張子」、RFC4954、7月2007日
Yao & Mao Experimental [Page 19] RFC 5336 EAI SMTP Extension September 2008
[19ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
Appendix A. Material Updating RFC 4952
RFC4952をアップデートする付録A.の材料
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.
RFC4952(国際化しているメールのためのこのセットの拡大をカバーする概要とフレームワークドキュメント)はこの仕様の前に完成しました。仕様はプロトコルセットの特定の部分を指定します。 この付録(規範的である)はこの仕様の残りで説明された仕事が終了するまで遅れる主張されたRFC4952に法人組織であった材料を含んでいます。 この材料はどんなアップデートでもRFC4952に含められるべきです。
A.1. Conventional Message and Internationalized Message
A.1。 従来のメッセージと国際化しているメッセージ
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]とどれが厳密にそうかにRFC2822[RFC2822]とconformantを定義したということです。
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つ以上を利用するメッセージです、それがもう2822年のメッセージのRFC仕様へのconformantでないように。
A.2. LMTP
A.2。 LMTP
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は、これらの状況に対処するためにアップデートする必要があります。
A.3. SMTP Service Extension for DSNs
A.3。 DSNsのためのSMTPサービス拡張子
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]に関する既存のDraft Standardはプロトコルのマシンの読み込み可能な部分のASCIIテキストに制限されます。 「国際Delivery StatusとDisposition Notifications」[RFC5337]は、格下げの後にさえ正しく非ASCII文字とのオリジナルの受取人アドレスを保存できるように国際的なEメールアドレスのための新しいアドレスタイプを加えます。 SMTPサーバーがUTF8SMTPとDSN拡張子の両方の広告を出すなら、ORCPTパラメタのサポートを含んでいて、そのサーバはEAI DSN[RFC5337]を実装しなければなりません。
A.4. Implementation Advice
A.4。 実装アドバイス
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
この拡大がないとき、SMTPクライアントとサーバはRFC2821によって可能にされたそれらのアドレスだけを使用するのに抑制されます。 それらのアドレスの地方の部分はどんなASCII文字でも作られるかもしれません、そこで指定されるとして彼らの何人かを引用しなければなりませんが。 それがoverstruck ASCII文字を使用するいくつかのシステムの上に長い歴史がある国際化文脈で注目に値する、(
Yao & Mao Experimental [Page 20] RFC 5336 EAI SMTP Extension September 2008
[20ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
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.
そして、キャラクタ、aがバックスペースキーである、別のキャラクタ) 非ASCII文字に近似する引用文字列の中で。 この拡大が広く配布されるようになるので国際化SHOULDのこのフォームが段階的に廃止されて、後方の互換性問題だけが、サポートされ続けているのを必要とします。
A.5. Applicability of SMTP Extension to Additional Uses
A.5。 追加用途へのSMTP拡張子の適用性
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キャラクタを含んでいて、メッセージが格下げされるときだけ、このセットの仕様の目的のために、この代替アドレスには意味があります。 プライマリアドレスが拒絶されるときはいつも、使用されるために代替アドレスが汎用第二の機会アドレスであるとみなすのに誘惑しているかもしれない間、そのような振舞いはここで定義されません。 この制限はそのような汎用第二の機会アドレスを作成する開発されるべき今後の拡大を考慮します、そのような拡大に対するどんな特定の仕事も現在、予期されませんが。 どんなそのような拡張子も、異なった可能なサーバが異なったESMTPオプション(この場合アドレス)をサポートすると[RFC0974]配列規則が意味することに関する質問を考える必要に注意してください。 また、この質問の答えは[RFC2821]にアップデートを含意するかもしれません。
Authors' Addresses
作者のアドレス
Jiankang YAO (editor) CNNIC No.4 South 4th Street, Zhongguancun Beijing
第4South通り、Jiankang YAO(エディタ)CNNIC No.4Zhongguancun北京
Phone: +86 10 58813007 EMail: yaojk@cnnic.cn
以下に電話をしてください。 +86 10 58813007はメールされます: yaojk@cnnic.cn
Wei MAO (editor) CNNIC No.4 South 4th Street, Zhongguancun Beijing
第4South通り、ウェイMAO(エディタ)CNNIC No.4Zhongguancun北京
Phone: +86 10 58812230 EMail: maowei_ietf@cnnic.cn
以下に電話をしてください。 +86 10 58812230はメールされます: maowei_ietf@cnnic.cn
Yao & Mao Experimental [Page 21] RFC 5336 EAI SMTP Extension September 2008
[21ページ]RFC5336EAI SMTP拡大2008年9月に実験的な八尾とマオ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Yao & Mao Experimental [Page 22]
八尾とマオExperimentalです。[22ページ]
一覧
スポンサーリンク
