Network Working Group K. Moore
Request for Comments: 3461 University of Tennessee
Obsoletes 1891 January 2003
Category: Standards Track
Simple Mail Transfer Protocol (SMTP) Service Extension
for Delivery Status Notifications (DSNs)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent.
このメモは、（b）は、このような通知は内容を返す必要があるかどうか、SMTPクライアントは、（a）はその配信状態通知（DSN）が一定の条件の下で生成されるように指定することを可能にする簡易メール転送プロトコル（SMTP）サービスへの拡張を定義しますメッセージ、及び（c）付加情報のうち、送信者がDSNが発行された受信者（複数可）、及び元のメッセージが送信されたトランザクションの両方を識別することを可能にするDSNで返されます。
Terminology
用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [7].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[7]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Framework for the Delivery Status Notification Extension . . . 4
3. The Delivery Status Notification service extension . . . . . . 5
4. Additional parameters for RCPT and MAIL commands . . . . . . . 6
4.1 The NOTIFY parameter of the ESMTP RCPT command. . . . . . . . 7
4.2 The ORCPT parameter to the ESMTP RCPT command . . . . . . . . 8
4.3 The RET parameter of the ESMTP MAIL command . . . . . . . . . 9
4.4 The ENVID parameter to the ESMTP MAIL command . . . . . . . . 9
4.5 Restrictions on the use of Delivery Status Notification
parameters. . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Conformance requirements . . . . . . . . . . . . . . . . . . . 10
5.1 SMTP protocol interactions. . . . . . . . . . . . . . . . . . 11
5.2 Handling of messages received via SMTP. . . . . . . . . . . . 11
5.2.1 Relay of messages to other conforming SMTP servers. . . . . 12
5.2.2 Relay of messages to non-conforming SMTP servers. . . . . . 13
5.2.3 Local delivery of messages. . . . . . . . . . . . . . . . . 14
5.2.4 Gatewaying a message into a foreign environment . . . . . . 14
5.2.5 Delays in delivery. . . . . . . . . . . . . . . . . . . . . 15
5.2.6 Failure of a conforming MTA to deliver a message. . . . . . 16
5.2.7 Forwarding, aliases, and mailing lists. . . . . . . . . . . 16
5.2.7.1 mailing lists . . . . . . . . . . . . . . . . . . . . . . 17
5.2.7.2 single-recipient aliases. . . . . . . . . . . . . . . . . 18
5.2.7.3 multiple-recipient aliases. . . . . . . . . . . . . . . . 18
5.2.7.4 confidential forwarding addresses . . . . . . . . . . . . 18
5.2.8 DSNs describing delivery to multiple recipients . . . . . . 19
5.3 Handling of messages from other sources . . . . . . . . . . . 19
5.4 Implementation limits . . . . . . . . . . . . . . . . . . . . 19
6. Format of delivery notifications . . . . . . . . . . . . . . . 20
6.1 SMTP Envelope to be used with delivery status
notifications . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 Contents of the DSN . . . . . . . . . . . . . . . . . . . . . 20
6.3 Message/delivery-status fields. . . . . . . . . . . . . . . . 21
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
9. Appendix - Type-Name Definitions . . . . . . . . . . . . . . . 24
9.1 "rfc822" address-type . . . . . . . . . . . . . . . . . . . . 24
9.2 "smtp" diagnostic-type. . . . . . . . . . . . . . . . . . . . 24
9.3 "dns" MTA-name-type . . . . . . . . . . . . . . . . . . . . . 25
10. Appendix - Example. . . . . . . . . . . . . . . . . . . . . . 26
10.1 Submission . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.2 Relay to Example.COM . . . . . . . . . . . . . . . . . . . . 28
10.3 Relay to Ivory.EDU . . . . . . . . . . . . . . . . . . . . . 29
10.4 Relay to Bombs.AF.MIL. . . . . . . . . . . . . . . . . . . . 30
10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV . . . . 31
10.6 "Delivered" DSN for Bob@Example.COM. . . . . . . . . . . . . 32
10.7 Failed DSN for Carol@Ivory.EDU . . . . . . . . . . . . . . . 33
10.8 Relayed DSN For Dana@Ivory.EDU . . . . . . . . . . . . . . . 34
10.9 Failure notification for Sam@Boondoggle.GOV. . . . . . . . . 35
11. Appendix - Changes since RFC 1891 . . . . . . . . . . . . . . 35
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 36
12.2 Informative References . . . . . . . . . . . . . . . . . . . 36
13. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 37
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 38
The SMTP protocol [1] requires that an SMTP server provide notification of delivery failure, if it determines that a message cannot be delivered to one or more recipients. Traditionally, such notification consists of an ordinary Internet mail message (format defined by [2]), sent to the envelope sender address (the argument of the SMTP MAIL command), containing an explanation of the error and at least the headers of the failed message.
SMTPプロトコル[1]は、メッセージが1つまたは複数の受信者に配信することができないと判断した場合、SMTPサーバは、配信失敗の通知を提供することを要求します。伝統的に、そのような通知は、通常のインターネットメールエンベロープ送信者アドレス（SMTPメール・コマンドの引数）に送信されたメッセージ（形式[2]によって定義される）、エラーの説明を含み、失敗の少なくともヘッダーから成りメッセージ。
Experience with large mail distribution lists [8] indicates that such messages are often insufficient to diagnose problems, or even to determine at which host or for which recipients a problem occurred. In addition, the lack of a standardized format for delivery notifications in Internet mail makes it difficult to exchange such notifications with other message handling systems.
大規模なメール配信リストの経験[8]、このようなメッセージは、多くの場合、問題を診断するには不十分であることを示している、あるいはどのホストで、または受信者が、問題が発生したかを決定します。また、インターネットメールで配信通知のための標準化された形式の欠如は、それが困難な他のメッセージ処理システムと、そのような通知を交換することができます。
Such experience has demonstrated a need for a delivery status notification service for Internet electronic mail, which:
このような経験は、インターネット、電子メール、の配信状態通知サービスの必要性を実証してきました：
(a) is reliable, in the sense that any DSN request will either be honored at the time of final delivery, or result in a response that indicates that the request cannot be honored,
（a）は、任意のDSN要求がいずれかの最終的な配信時に光栄、または要求が受け入れられないことを示す応答をもたらすであろうという意味で、信頼性が高いです
(b) when both success and failure notifications are requested, provides an unambiguous and nonconflicting indication of whether delivery of a message to a recipient succeeded or failed,
（b）の両方の成功と失敗通知が要求されたとき、受信者へのメッセージの配信が成功したか失敗したかを明確にし、競合しない指示を提供します、
(c) is stable, in that a failed attempt to deliver a DSN should never result in the transmission of another DSN over the network,
（c）は、その中で、ネットワーク上の別のDSNの伝送につながることはありませんDSNを提供するために失敗した安定しています
(d) preserves sufficient information to allow the sender to identify both the mail transaction and the recipient address which caused the notification, even when mail is forwarded or gatewayed to foreign environments, and
（d）は、送信者がメールトランザクションとメールが転送または外部環境にゲートウェイ処理された場合でも、通知の原因となった受信者アドレスの両方を識別することを可能にするのに十分な情報を保持し、そして
(e) interfaces acceptably with non-SMTP and non-822-based mail systems, both so that notifications returned from foreign mail systems may be useful to Internet users, and so that the notification requests from foreign environments may be honored. Among the requirements implied by this goal are the ability to request non-return-of-content, and the ability to specify whether positive delivery notifications, negative delivery notifications, both, or neither, should be issued.
（e）は、非SMTPおよび非-822ベースのメールシステムで許容できるインターフェース、の両方通知は、インターネットユーザに有用であり得る外部メールシステムから返されたように、そのため外国の環境からの通知要求が優先されてもよいこと。この目標によって暗示要件の中でノンリターン・オブ・コンテンツを要求する能力、および正の配信通知、負の配信通知は、両方、またはどちらも、発行されるべきではないかどうかを指定する機能です。
In an attempt to provide such a service, this memo uses the mechanism defined in [1] to define an extension to the SMTP protocol. Using this mechanism, an SMTP client may request that an SMTP server issue or not issue a Delivery Status Notification (DSN) under certain conditions. The format of a DSN is defined in [3].
そのようなサービスを提供しようとする試みでは、このメモはSMTPプロトコルの拡張機能を定義する、[1]で定義されたメカニズムを使用します。このメカニズムを使用して、SMTPクライアントは、SMTPサーバーの問題かどうかは、一定の条件の下で配信状態通知（DSN）を発行することを要求することができます。 DSNのフォーマットは、[3]で定義されています。
The following service extension is therefore defined:
以下のサービス拡張は、したがって、定義されています。
(1) The name of the SMTP service extension is "Delivery Status Notification";
（1）SMTPサービス拡張の名前は、「配信ステータス通知」です。
(2) the EHLO keyword value associated with this extension is "DSN", the meaning of which is defined in section 3 of this memo;
（2）この拡張子に関連付けられているEHLOキーワード値は「DSN」、このメモのセクション3で定義された意味です。
(3) no parameters are allowed with this EHLO keyword value;
（3）は、パラメータがこのEHLOキーワード値で許可されていません。
(4) two optional parameters are added to the RCPT command, and two optional parameters are added to the MAIL command:
（4）2つのオプションのパラメータは、RCPTコマンドに追加され、そして2つのオプションのパラメータは、MAILコマンドに追加されます。
An optional parameter for the RCPT command, using the
esmtp-keyword "NOTIFY", (to specify the conditions under which a
Delivery Status Notification should be generated), is defined in
section 5.1,
An optional parameter for the RCPT command, using the esmtp-keyword "ORCPT", (used to convey the "original" (sender-specified) recipient address), is defined in section 5.2, and
ESMTPキーワード「ORCPT」を用いRCPTコマンドのためのオプションのパラメータ、（「オリジナル」（送信者が指定した）受信者のアドレスを伝えるために使用される）、セクション5.2で定義され、そして
An optional parameter for the MAIL command, using the esmtp-keyword "RET", (to request that DSNs containing an indication of delivery failure either return the entire contents of a message or only the message headers), is defined in section 5.3,
MAILコマンドのためのオプションのパラメータは、ESMTPキーワード「RET」（配信障害の指標を含有するのDSNメッセージの内容全体またはメッセージヘッダーだけを返すのいずれかのことを要求する）を使用して、セクション5.3で定義されています
An optional parameter for the MAIL command, using the esmtp-keyword "ENVID", (used to propagate an identifier for this message transmission envelope, which is also known to the sender and will, if present, be returned in any DSNs issued for this transmission), is defined in section 4.4;
ESMTPキーワード「ENVID」を使用してMAILコマンドのオプションパラメータは、（また、送信者に知られており、存在する場合、このために発行されたのDSNで返されます。このメッセージ送信封筒、の識別子を伝播するために使用されますトランスミッション）が、セクション4.4で定義されています。
(5) no additional SMTP verbs are defined by this extension.
（5）追加のSMTP動詞はこの拡張によって定義されていません。
The remainder of this memo specifies how support for the extension affects the behavior of a message transfer agent.
このメモの残りの部分は、拡張のためのサポートは、メッセージ転送エージェントの行動にどのように影響するかを指定します。
An SMTP client wishing to request a DSN for a message may issue the EHLO command to start an SMTP session, to determine if the server supports any of several service extensions. If the server responds with code 250 to the EHLO command, and the response includes the EHLO keyword DSN, then the Delivery Status Notification extension (as described in this memo) is supported.
メッセージのDSNを要求したいSMTPクライアントは、サーバが複数のサービス拡張のいずれかをサポートしているかどうかを判断するために、SMTPセッションを開始するためにEHLOコマンドを発行することができます。サーバは、EHLOコマンドにコード250で応答し、応答がEHLOキーワードDSNは、配信状態通知の拡張（このメモに記載されているように）サポートされているが含まれている場合。
Ordinarily, when an SMTP server returns a positive (2xx) reply code in response to a RCPT command, it agrees to accept responsibility for either delivering the message to the named recipient, or sending a notification to the sender of the message indicating that delivery has failed. However, an extended SMTP ("ESMTP") server which implements this service extension will accept an optional NOTIFY parameter with the RCPT command. If present, the NOTIFY parameter alters the conditions for generation of Delivery Status Notifications from the default (issue notifications only on failure) specified in [1]. The ESMTP client may also request (via the RET parameter) whether the entire contents of the original message should be returned (as opposed to just the headers of that message), along with the DSN.
SMTPサーバがRCPTコマンドに応答して正（2XX）応答コードを返した場合、通常、それは、指定受信者にメッセージを配信する、または配信が持っていることを示すメッセージの送信者に通知を送信することのいずれかの責任を受け入れることに同意します失敗しました。しかし、このサービスの拡張機能を実装し、拡張SMTP（「ESMTP」）サーバーは、RCPTコマンドでオプションのNOTIFYパラメータを受け入れます。存在する場合、NOTIFYパラメータは、[1]で指定されたデフォルトの配信状態通知を生成するための条件（唯一の失敗の問題の通知を）変えます。 ESMTPクライアントは、DSNと一緒に、（そのメッセージのヘッダだけではなく）元のメッセージの内容全体が返されるべきかどうか（RETパラメータを介して）要求することができます。
In general, an ESMTP server which implements this service extension will propagate Delivery Status Notification requests when relaying mail to other SMTP-based MTAs which also support this extension, and make a "best effort" to ensure that such requests are honored when messages are passed into other environments.
一般的には、このサービス拡張を実装ESMTPサーバーもこの拡張機能をサポートする他のSMTPベースのMTAにメールを中継する際配信ステータス通知要求を伝播し、メッセージが渡されたときに、そのような要求が受け入れていることを保証するために、「最善の努力」を行います他の環境に。
In order for Delivery Status Notifications to be meaningful to the sender, ESMTP servers, which support this extension, should propagate the following information for use in generating DSNs to any other MTAs that are used to relay the message:
配信状態通知が送信者に意味のあるものにするためには、この拡張をサポートするESMTPサーバーは、メッセージを中継するために使用されている任意の他のMTAへのDSNを生成する際に使用するために、以下の情報を伝播する必要があります。
(a) for each recipient, a copy of the original recipient address, as used by the sender of the message.
（a）は、受信者ごとに、元の受信者のアドレスのコピー、メッセージの送信者によって使用されます。
This address need not be the same as the mailbox specified in
the RCPT command. For example, if a message was originally
addressed to A@B.C and later forwarded to A@D.E, after such
forwarding has taken place, the RCPT command will specify a
mailbox of A@D.E. However, the original recipient address
remains A@B.C.
Also, if the message originated from an environment which does not use Internet-style user@domain addresses, and was gatewayed into SMTP, the original recipient address will preserve the original form of the recipient address.
メッセージはインターネット形式のユーザー@ドメインのアドレスを使用しない環境に由来し、SMTPにゲートウェイされた場合も、元の受信者のアドレスが受信者アドレスの元の形式を保持します。
(b) for the entire SMTP transaction, an envelope identification string, which may be used by the sender to associate any delivery status notifications with the transaction used to send the original message.
（B）全体SMTPトランザクションのために、送信者によって使用されてもよいエンベロープ識別文字列は、元のメッセージを送信するために使用されるトランザクションに任意の配信状態通知を関連付けます。
The extended RCPT and MAIL commands are issued by a client when it wishes to request a DSN from the server, under certain conditions, for a particular recipient. The extended RCPT and MAIL commands are identical to the RCPT and MAIL commands defined in [1], except that one or more of the following parameters appear after the sender or recipient address, respectively. The general syntax for extended SMTP commands is defined in [1].
それは、特定の受信者に対して、一定の条件の下で、サーバーからのDSNを要求したい場合に拡張RCPTとMAILコマンドがクライアントによって発行されています。拡張RCPTとMAILコマンドは、以下のパラメータの1つ以上を除いて、[1]で定義されたRCPTとMAILコマンドと同一である、それぞれ、送信者または受信者のアドレスの後に現れます。拡張SMTPコマンドの一般的な構文は、[1]で定義されています。
NOTE: Although RFC 822 ABNF is used to describe the syntax of these parameters, they are not, in the language of that document, "structured field bodies". Therefore, while parentheses MAY appear within an emstp-value, they are not recognized as comment delimiters.
注：RFC 822 ABNFは、これらのパラメータの構文を記述するために使用されているが、彼らはそのドキュメント、「構造化フィールドボディ」の言葉で、ではありません。括弧はemstp値内に現れるかもしれないがそのため、彼らはコメント区切り文字として認識されません。
The syntax for "esmtp-value" in [1] does not allow SP, "=", control characters, or characters outside the traditional ASCII range of 1-127 decimal to be transmitted in an esmtp-value. Because the ENVID and ORCPT parameters may need to convey values outside this range, the esmtp-values for these parameters are encoded as "xtext". "xtext" is formally defined as follows:
「ESMTP値」の構文は、[1] SPを許可しない、「=」、1-127小数点の伝統的なASCIIの範囲外の制御文字、または文字がESMTP値で送信されます。 ENVIDとORCPTパラメータがこの範囲外の値を伝達する必要があるかもしれないので、これらのパラメータのESMTP値を「XTEXT」として符号化されます。以下のように「XTEXTは」正式に定義されています。
xtext = *( xchar / hexchar )
XTEXT = *（XCHAR / hexchar）
xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, except for "+" and "=".
間XCHAR =任意のASCII CHAR "！" "+" と "=" を除く包括（33）と "〜"（126）。
; "hexchar"s are intended to encode octets that cannot appear ; as ASCII characters within an esmtp-value.
; 「hexchar」sが表示されないことができオクテットをエンコードすることを意図しています。 ESMTP値内のASCII文字として。
hexchar = ASCII "+" immediately followed by two upper case hexadecimal digits
すぐ上の2つのケースの16進数字が続くhexchar = ASCII「+」
When encoding an octet sequence as xtext:
XTEXTとしてオクテット配列をコードする場合：
+ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", MAY be encoded as itself. (A CHAR in this range MAY instead be encoded as a "hexchar", at the implementor's discretion.)
+ "！" の間で任意のASCII CHARそして「〜」を含め、「+」や「=」を除いて、それ自体として符号化することができます。 （この範囲のCHARではなく、実装の裁量で、「hexchar」として符号化されてもよいです。）
+ ASCII CHARs that fall outside the range above must be encoded as "hexchar".
上記範囲外+ ASCIIチャー「はhexchar」として符号化されなければなりません。
A RCPT command issued by a client may contain the optional esmtp-keyword "NOTIFY", to specify the conditions under which the SMTP server should generate DSNs for that recipient. If the NOTIFY esmtp-keyword is used, it MUST have an associated esmtp-value, formatted according to the following rules, using the ABNF of RFC 822:
クライアントによって発行されたRCPTコマンドは、SMTPサーバーは、その受信者のDSNを生成する条件を指定するには、「NOTIFY」オプションのESMTPキーワードが含まれていてもよいです。 NOTIFY ESMTPキーワードが使用される場合、それはRFC 822のABNFを使用して、次の規則に従ってフォーマット関連ESMTP値を持つ必要があります。
notify-esmtp-value = "NEVER" / 1#notify-list-element
通知-ESMTP値= "NEVER" / 1＃通知リスト要素
notify-list-element = "SUCCESS" / "FAILURE" / "DELAY"
通知リスト要素=「成功」/「失敗」/「遅れ」
Notes:
ノート：
a. Multiple notify-list-elements, separated by commas, MAY appear in a NOTIFY parameter; however, the NEVER keyword MUST appear by itself.
A。複数の通知リスト要素は、カンマで区切って、NOTIFYパラメータに表示されるかもしれません。しかし、NEVERキーワードは、それ自体で現れなければなりません。
b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled in any combination of upper and lower case letters.
B。キーワードのいずれかが、成功、失敗、またはDELAYは、大文字と小文字の任意の組み合わせで綴らなくてもよい絶対。
The meaning of the NOTIFY parameter values is generally as follows:
次のようにNOTIFYパラメータ値の意味は、一般的に次のとおりです。
+ A NOTIFY parameter value of "NEVER" requests that a DSN not be returned to the sender under any conditions.
+ Aは、DSNは、任意の条件の下で、送信者に返されない「NEVER」リクエストのパラメータ値を通知します。
+ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE" keywords requests that a DSN be issued on successful delivery or delivery failure, respectively.
+ Aは、「成功」または「失敗」のキーワードを含むパラメータ値はDSNは、それぞれ、正常に配信または配信失敗で発行することを要求しNOTIFY。
+ A NOTIFY parameter value containing the keyword "DELAY" indicates the sender's willingness to receive "delayed" DSNs. Delayed DSNs may be issued if delivery of a message has been delayed for an unusual amount of time (as determined by the MTA at which the message is delayed), but the final delivery status (whether successful or failure) cannot be determined. The absence of the DELAY keyword in a NOTIFY parameter requests that a "delayed" DSN NOT be issued under any conditions.
+ Aは、キーワード「DELAY」を含むパラメータ値が「遅延」のDSNを受信するために、送信者の意欲を示しNOTIFY。メッセージの配信は、（メッセージが遅延されたMTAによって決定される）時間の異常な量だけ遅延されているが、最終的な配信ステータス（成功か失敗か）を判断できない場合、遅延DSNは発行されてもよいです。 「遅れた」DSNは、任意の条件の下で発行されないNOTIFYパラメータ要求でDELAYキーワードの不在。
The actual rules governing interpretation of the NOTIFY parameter are given in section 6.
NOTIFYパラメータの解釈を支配する実際のルールはセクション6に記載されています。
For compatibility with SMTP clients that do not use the NOTIFY facility, the absence of a NOTIFY parameter in a RCPT command may be interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY.
NOTIFY機能を使用しないSMTPクライアントとの互換性のために、RCPTコマンドでNOTIFYパラメータが存在しないことは、=失敗を通知したり= FAILURE、DELAYをNOTIFYのいずれかとして解釈することができます。
The ORCPT esmtp-keyword of the RCPT command is used to specify an "original" recipient address that corresponds to the actual recipient to which the message is to be delivered. If the ORCPT esmtp-keyword is used, it MUST have an associated esmtp-value, which consists of the original recipient address, encoded according to the rules below. The ABNF for the ORCPT parameter is:
RCPTコマンドのORCPTのESMTPキーワードは、メッセージが配信されるため、実際の受信者に対応する「元の」受信者のアドレスを指定するために使用されます。 ORCPTのESMTPキーワードが使用される場合、それは以下の規則に従って符号化された元の受信者のアドレス、から構成関連ESMTP値を有していなければなりません。 ORCPTパラメータのABNFは、次のとおりです。
orcpt-parameter = "ORCPT=" original-recipient-address
ORCPTパラメータ=「ORCPT =」オリジナルの受信者アドレス
original-recipient-address = addr-type ";" xtext
オリジナルの受信者アドレス= addrの型「;」 XTEXT
addr-type = atom
ADDR型=原子
The "addr-type" portion MUST be an IANA-registered electronic mail address-type (as defined in [3]), while the "xtext" portion contains an encoded representation of the original recipient address using the rules in section 5 of this document. The entire ORCPT parameter MAY be up to 500 characters in length.
「XTEXT」部分は、このセクション5のルールを使用して、元の受信者のアドレスの符号化表現を含むが、（[3]で定義されるように）「ADDR型」部分は、IANAに登録電子メールアドレス型でなければなりません資料。全体ORCPTパラメータの長さは、最大500文字です。
When initially submitting a message via SMTP, if the ORCPT parameter is used, it MUST contain the same address as the RCPT TO address (unlike the RCPT TO address, the ORCPT parameter will be encoded as xtext). Likewise, when a mailing list submits a message via SMTP to be distributed to the list subscribers, if ORCPT is used, the ORCPT parameter MUST match the new RCPT TO address of each recipient, not the address specified by the original sender of the message.)
最初にSMTPを介してメッセージを送信するときにORCPTパラメータが使用される場合、それはアドレスにRCPTと同じアドレスを含まなければならない（アドレスへのRCPT異なり、ORCPTパラメータはXTEXTとしてエンコードされます）。メーリングリストは、リストの購読者に配布するSMTP経由でメッセージを送信したときにORCPTが使用されている場合は同様に、、ORCPTパラメータは、各受信者ではなく、メッセージの元の送信者によって指定されたアドレスのアドレスを新しいRCPTと一致しなければなりません。 ）
The "addr-type" portion of the original-recipient-address is used to indicate the "type" of the address which appears in the ORCPT parameter value. However, the address associated with the ORCPT keyword is NOT constrained to conform to the syntax rules for that "addr-type".
元の受信者アドレスの「ADDR型」部分は、ORCPTパラメータの値に表示されるアドレスの「タイプ」を示すために使用されます。しかし、ORCPTキーワードに関連したアドレスは、「ADDRタイプ」の構文規則に準拠するように制約されません。
Ideally, the "xtext" portion of the original-recipient-address should contain, in encoded form, the same sequence of characters that the sender used to specify the recipient. However, for a message gatewayed from an environment (such as X.400) in which a recipient address is not a simple string of printable characters, the representation of recipient address must be defined by a specification for gatewaying between DSNs and that environment.
理想的には、元の受信者アドレスの「XTEXT」部分は、符号化された形式で、送信者が受信者を指定するために使用される文字の同じ配列を含むべきです。しかし、受信者のアドレスは、印刷可能文字の単純な文字列ではないである（例えば、X.400など）環境からゲートウェイ処理メッセージを、受信者のアドレスの表現のDSNとその環境との間にゲートウェイの仕様によって定義されなければなりません。
Due to limitations in the Delivery Status Notification format, the value of the original recipient address prior to encoding as "xtext" MUST consist entirely of printable (graphic and white space) characters from the US-ASCII [4] repertoire. If an addr-type is defined for addresses which use characters outside of this repertoire, the specification for that addr-type MUST define the means of encoding those addresses in printable US-ASCII characters when are then encoded as xtext.
配信状態通知の形式の制限により、「XTEXT」として符号化前の元の受信者のアドレスの値は、印刷可能（グラフィック及びホワイトスペース）の全体構成されなければなりませんUS-ASCII [4]レパートリーから文字。 ADDR型がこのレパートリーの外の文字を使用するアドレスのために定義されている場合、そのADDR型の仕様は次にXTEXTとして符号化された場合の印刷可能なUS-ASCII文字にこれらのアドレスを符号化する手段を定義しなければなりません。
The RET esmtp-keyword on the extended MAIL command specifies whether or not the message should be included in any failed DSN issued for this message transmission. If the RET esmtp-keyword is used, it MUST have an associated esmtp-value, which is one of the following keywords:
拡張されたMAILコマンドのRETのESMTPキーワードは、メッセージがこのメッセージを送信するために発行された失敗したDSNに含まれるべきかどうかを指定します。 RETのESMTPキーワードが使用されている場合は、次のキーワードのいずれかである関連したESMTP値を、持っている必要があります。
FULL requests that the entire message be returned in any "failed" Delivery Status Notification issued for this recipient.
メッセージ全体がこの受信者のために発行された「失敗」配信ステータス通知に返されるFULL要求します。
HDRS requests that only the headers of the message be returned.
HDRSは、メッセージのヘッダだけが返されることを要求します。
The FULL and HDRS keywords may be spelled in any combination of upper and lower case letters.
FULLとHDRSキーワードは、大文字と小文字の任意の組み合わせで綴られてもよいです。
If no RET parameter is supplied, the MTA MAY return either the headers of the message or the entire message for any DSN containing indication of failed deliveries.
いかなるRETパラメータが供給されない場合、MTAは、失敗の配達の指示を含む任意のDSNのためのメッセージのヘッダまたはメッセージ全体のいずれかを返すことができます。
Note that the RET parameter only applies to DSNs that indicate delivery failure for at least one recipient. If a DSN contains no indications of delivery failure, only the headers of the message should be returned.
RETパラメータのみ少なくとも一つの受信者の配信失敗を示すのDSNに適用されることに注意してください。 DSNが配信障害の兆候が含まれていない場合は、メッセージのヘッダーだけが返されます。
The ENVID esmtp-keyword of the SMTP MAIL command is used to specify an "envelope identifier" to be transmitted along with the message and included in any DSNs issued for any of the recipients named in this SMTP transaction. The purpose of the envelope identifier is to allow the sender of a message to identify the transaction for which the DSN was issued.
SMTPのMAILコマンドのENVIDのESMTPキーワードは、メッセージとともに送信され、このSMTPトランザクションで名前の受信者のいずれかのために発行されたのDSNに含まれる「エンベロープ識別子」を指定するために使用されます。封筒識別子の目的は、DSNが発行されたトランザクションを識別するために、メッセージの送信者を可能にすることです。
The ABNF for the ENVID parameter is:
ENVIDパラメータのABNFは、次のとおりです。
envid-parameter = "ENVID=" xtext
ENVIDパラメータ= "ENVID =" XTEXT
The ENVID esmtp-keyword MUST have an associated esmtp-value. No meaning is assigned by the mail system to the presence or absence of this parameter or to any esmtp-value associated with this parameter; the information is used only by the sender or his user agent. The ENVID parameter MAY be up to 100 characters in length.
ENVIDのESMTPキーワードは、関連するESMTP値を持たなければなりません。何の意味は、このパラメータの有無又はこのパラメータに関連する任意のESMTP値にメールシステムによって割り当てられていません。情報のみを送信者または自分のユーザエージェントによって使用されます。 ENVIDパラメータの長さは、最大100文字です。
Due to limitations in the Delivery Status Notification format, the value of the ENVID parameter prior to encoding as "xtext" MUST consist entirely of printable (graphic and white space) characters from the US-ASCII [4] repertoire.
配信状態通知の形式の制限のために、「XTEXT」として符号化する前ENVIDパラメータの値は、US-ASCII [4]レパートリーから印刷可能（グラフィック及び空白）文字全体構成する必要があります。
The RET and ENVID parameters MUST NOT appear more than once each in any single MAIL command. If more than one of either of these parameters appears in a MAIL command, the ESMTP server SHOULD respond with "501 syntax error in parameters or arguments".
RETとENVIDパラメータは、任意の単一のMAILコマンドに一度、各より多く見えてはいけません。これらのパラメータのいずれかの2つ以上がMAILコマンドで表示された場合は、ESMTPサーバーは、「パラメータまたは引数で501構文エラー」と応答する必要があります。
The NOTIFY and ORCPT parameters MUST NOT appear more than once in any RCPT command. If more than one of either of these parameters appears in a RCPT command, the ESMTP server SHOULD respond with "501 syntax error in parameters or arguments".
NOTIFYとORCPTパラメータは任意のRCPTコマンドで複数回出現することはできません。これらのパラメータのいずれかの2つ以上がRCPTコマンドで表示された場合は、ESMTPサーバーは、「パラメータまたは引数で501構文エラー」と応答する必要があります。
The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer Agents (MTAs) when accepting, relaying, or gatewaying mail, as well as User Agents (UAs) when submitting mail to the mail transport system. The DSN extension to SMTP may be used to allow UAs to convey the sender's requests as to when DSNs should be issued. A UA which claims to conform to this specification must meet certain requirements as described below.
簡易メール転送プロトコル（SMTP）は、受け入れ中継、またはメール転送システムにメールを送信する際、メール、ならびにユーザエージェント（UAS）をゲートウェイ処理するとき、メッセージ転送エージェント（MTA）によって使用されます。 SMTPのDSN拡張は、UAがのDSNを発行しなければならないときにとして、送信者の要望を伝えることを可能にするために使用することができます。以下に説明するように、この仕様に準拠するように主張するUAは、特定の要件を満たさなければなりません。
Typically, a message transfer agent (MTA) which supports SMTP will assume, at different times, both the role of a SMTP client and an SMTP server, and may also provide local delivery, gatewaying to foreign environments, forwarding, and mailing list expansion. An MTA which, when acting as an SMTP server, issues the DSN keyword in response to the EHLO command, MUST obey the rules below for a "conforming SMTP client" when acting as a client, and a "conforming SMTP server" when acting as a server. The term "conforming MTA" refers to an MTA which conforms to this specification, independent of its role of client or server.
典型的には、SMTPをサポートするメッセージ転送エージェント（MTA）は、異なる時点で、SMTPクライアントの役割とSMTPサーバーの両方を想定し、また外国の環境、転送、およびメーリングリストの拡大にゲートウェイ、局所送達を提供することができます。動作する際にSMTPサーバとして動作する場合、EHLOコマンドに応答してDSNキーワードを発行し、MTAは、クライアントとして動作する場合、「準拠SMTPクライアント」については、以下の規則に従わなければならない、と「適合するSMTPサーバ」サーバー。 「MTAの準拠」という用語は、クライアントまたはサーバーの役割とは無関係に、この仕様に準拠MTAを指します。
The following rules apply to SMTP transactions in which any of the ENVID, NOTIFY, RET, or ORCPT keywords are used:
次の規則はRET、NOTIFY、ENVIDのもので任意のSMTP取引に適用する、またはORCPTキーワードが使用されます。
(a) If an SMTP client issues a MAIL command containing a valid ENVID parameter and associated esmtp-value and/or a valid RET parameter and associated esmtp-value, a conforming SMTP server MUST return the same reply-code as it would to the same MAIL command without the ENVID and/or RET parameters. A conforming SMTP server MUST NOT refuse a MAIL command based on the absence or presence of valid ENVID or RET parameters, or on their associated esmtp-values.
SMTPクライアントが有効なENVIDパラメータと関連したESMTP値および/または有効なRETパラメータと関連したESMTP値を含むMAILコマンドを発行した場合、それが同じように（a）は、適合するSMTPサーバーは同じ応答コードを返さなければなりませんENVIDおよび/またはRETパラメータなしで同じMAILコマンド。準拠したSMTPサーバは、有効なENVIDまたはRETパラメータの有無に、またはそれらに関連するESMTP値に基づいMAILコマンドを拒否してはなりません。
However, if the associated esmtp-value is not valid (i.e.,
contains illegal characters), or if there is more than one ENVID
or RET parameter in a particular MAIL command, the server MUST
issue the reply-code 501 with an appropriate message (e.g.,
"syntax error in parameter").
(b) If an SMTP client issues a RCPT command containing any valid NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST return the same response as it would to the same RCPT command without those NOTIFY and/or ORCPT parameters. A conforming SMTP server MUST NOT refuse a RCPT command based on the presence or absence of any of these parameters.
SMTPクライアントは、任意の有効なNOTIFYおよび/またはORCPTパラメータを含むRCPTコマンドを発行した場合、それはそれらなしで同じRCPTコマンドの場合と同じように（b）は、適合するSMTPサーバーは同じ応答を返さなければなりませんNOTIFYおよび/またはORCPTパラメータ。準拠したSMTPサーバは、これらのパラメータのいずれかの有無に基づいて、RCPTコマンドを拒否してはなりません。
However, if any of the associated esmtp-values are not valid, or
if there is more than one of any of these parameters in a
particular RCPT command, the server SHOULD issue the response
"501 syntax error in parameter".
This section describes how a conforming MTA should handle any messages received via SMTP.
このセクションでは、準拠するMTAは、SMTPを介して受信されたすべてのメッセージを処理する方法について説明します。
NOTE: A DSN MUST NOT be returned to the sender for any message for which the return address from the SMTP MAIL command was NULL ("<>"), even if the sender's address is available from other sources (e.g., the message header). However, the MTA which would otherwise issue a DSN SHOULD inform the local postmaster of delivery failures through some appropriate mechanism that will not itself result in the generation of DSNs.
注：DSNは、送信者のアドレスは、他のソース（例えば、メッセージヘッダ）から提供された場合でも、SMTPのMAILコマンドからのリターンアドレスがNULL（「<>」）であったために任意のメッセージを送信者に返されてはなりません。しかし、それ以外のDSNを発行するMTAは、それ自体がなDSNの世代にはなりませんいくつかの適切なメカニズムを介して配信の失敗のローカルのpostmasterに通知する必要があります。
DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to be sent with a NULL return address ("reverse-path"). This creates an interesting situation when a message arrives with one or more nonfunctional recipient addresses in addition to a nonfunctional return address. When delivery to one of the recipient addresses fails, the MTA will attempt to send a nondelivery notification to the return address, setting the return address on the notification to NULL. When the delivery of this notification fails, the MTA attempting delivery of that notification sees a NULL return address. If that MTA were not to inform anyone of the situation, the original message would be silently lost. Furthermore, a nonfunctional return address is often indicative of a configuration problem in the sender's MTA. Reporting the condition to the local postmaster may help to speed correction of such errors.
議論：RFC 1123、セクション2.3.3は、NULLの戻りアドレス（「パスを逆」）で送信されるエラー通知が必要です。メッセージは、非機能的なリターンアドレスに加えて、1つのまたは複数の非機能的な受信者のアドレスに到着したとき、これは興味深い状況を作成します。受信者のアドレスのいずれかへの配信が失敗した場合、MTAはNULLへの通知にリターンアドレスを設定し、リターンアドレスに不達通知を送信しようとします。この通知の配信が失敗すると、その通知のMTA試みる配信がNULLの戻りアドレスを見ています。そのMTAは、状況の誰にも知らせないようにした場合は、元のメッセージは静かに失われてしまいます。さらに、非機能的なリターンアドレスは、多くの場合、送信者のMTAで構成の問題を示しています。ローカルポストマスターに状態を報告するようなエラーの訂正を加速するのを助けることができます。
The following rules govern the behavior of a conforming MTA, when relaying a message which was received via the SMTP protocol, to an SMTP server that supports the Delivery Status Notification service extension:
配信ステータス通知サービス拡張をサポートしているSMTPサーバーに、SMTPプロトコルを介して受信されたメッセージを中継する場合には、次の規則が、準拠するMTAの動作を管理します：
(a) Any ENVID parameter included in the MAIL command when a message was received, MUST also appear on the MAIL command with which the message is relayed, with the same associated esmtp-value. If no ENVID parameter was included in the MAIL command when the message was received, the ENVID parameter MUST NOT be supplied when the message is relayed.
メッセージを受信した場合（A）どれENVIDパラメータはMAILコマンドに含まれ、また、同じ関連ESMTP値と、メッセージが中継されるMAILコマンドに現れなければなりません。何ENVIDパラメータがメッセージを受信したMAILコマンドに含まれなかった場合は、メッセージが中継されたときに、ENVIDパラメータを供給してはなりません。
(b) Any RET parameter included in the MAIL command when a message was received, MUST also appear on the MAIL command with which the message is relayed, with the same associated esmtp-value. If no RET parameter was included in the MAIL command when the message was received, the RET parameter MUST NOT supplied when the message is relayed.
メッセージを受信した場合（B）MAILコマンドに含まれる任意のRETパラメータは、また、同じ関連ESMTP値と、メッセージが中継されるMAILコマンドに現れなければなりません。何RETパラメータがメッセージを受信したMAILコマンドに含まれなかった場合は、メッセージが中継されたときに、RETパラメータが与えてはなりません。
(c) If the NOTIFY parameter was supplied for a recipient when the message was received, the RCPT command issued when the message is relayed MUST also contain the NOTIFY parameter along with its associated esmtp-value. If the NOTIFY parameter was not supplied for a recipient when the message was received, the NOTIFY parameter MUST NOT be supplied for that recipient when the message is relayed.
メッセージを受信した場合（C）NOTIFYパラメータが受取人のために供給された場合、メッセージが中継されるときに発行されたRCPTコマンドは、その関連するESMTP値と共にNOTIFYパラメータを含まなければなりません。 NOTIFYパラメータがメッセージを受信した受信者のために提供されていなかった場合は、メッセージが中継されたときに、NOTIFYパラメータがその受取人のために供給してはなりません。
(d) If any ORCPT parameter was present in the RCPT command for a recipient when the message was received, an ORCPT parameter with the identical original-recipient-address MUST appear in the RCPT command issued for that recipient when relaying the message. (For example, the MTA therefore MUST NOT change the case of any alphabetic characters in an ORCPT parameter.)
（D）任意ORCPTパラメータは、メッセージが受信された受信者のRCPTコマンドで存在していた場合は、同じ元の受信者アドレスを持つORCPTパラメータは、メッセージを中継するときに受信者に対して発行RCPTコマンドで現れなければなりません。 （たとえば、MTAは、したがってORCPTパラメータの任意のアルファベット文字のケースを変更しないでください。）
If no ORCPT parameter was present in the RCPT command when the
message was received, an ORCPT parameter MAY be added to the RCPT
command when the message is relayed. If an ORCPT parameter is
added by the relaying MTA, it MUST contain the recipient address
from the RCPT command used when the message was received by that
MTA.
The following rules govern the behavior of a conforming MTA (in the role of client), when relaying a message which was received via the SMTP protocol, to an SMTP server that does not support the Delivery Status Notification service extension:
配信ステータス通知サービス拡張をサポートしていないSMTPサーバーに、SMTPプロトコルを介して受信されたメッセージを中継する場合には、次の規則が、準拠するMTA（クライアントの役割）の動作を管理します：
(a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when relaying the message.
（A）ENVID、NOTIFY、RET、またはORCPTパラメータは、メッセージを中継する際に発行してはいけません。
(b) If the NOTIFY parameter was supplied for a recipient, with an esmtp-value containing the keyword SUCCESS, and the SMTP server returns a success (2xx) reply-code in response to the RCPT command, the client MUST issue a "relayed" DSN for that recipient.
（b）はNOTIFYパラメータがSUCCESSキーワードを含むESMTP値と、受信者のために供給し、SMTPサーバーがRCPTコマンドに応答して、成功（2xxの）応答コードを返し、クライアントは「中継を発行しなければならない場合その受取人のための「DSN。
(c) If the NOTIFY parameter was supplied for a recipient with an esmtp-value containing the keyword FAILURE, and the SMTP server returns a permanent failure (5xx) reply-code in response to the RCPT command, the client MUST issue a "failed" DSN for that recipient.
（C）NOTIFYパラメータがキーワードFAILUREを含むESMTP値を持つ受信者に対して供給し、SMTPサーバがRCPTコマンドに応答して永久的な障害（5xxの）応答コードを返し、クライアントは「失敗を発行する必要がある場合その受取人のための「DSN。
(d) If the NOTIFY parameter was supplied for a recipient with an esmtp-value of NEVER, the client MUST NOT issue a DSN for that recipient, regardless of the reply-code returned by the SMTP server. However, if the server returned a failure (5xx) reply-code, the client MAY inform the local postmaster of the delivery failure via an appropriate mechanism that will not itself result in the generation of DSNs.
NOTIFYパラメータがNEVERのESMTP値を持つ受信者のために供給された場合（d）に、クライアントは関係なく、SMTPサーバから返された応答コードの、その受取人のためにDSNを発行してはいけません。サーバが故障（5xxの）応答コードを返した場合は、クライアントは、それ自体がのDSNの生成をもたらさないであろう適切な機構を介して配信障害のローカルポストマスターに通知することができます。
When attempting to relay a message to an SMTP server that does
not support this extension, and if NOTIFY=NEVER was specified for
some recipients of that message, a conforming SMTP client MAY
relay the message for those recipients in a separate SMTP
transaction, using an empty reverse-path in the MAIL command.
This will prevent DSNs from being issued for those recipients by
MTAs that conform to [1].
(e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP server returns a success (2xx) reply-code in response to a RCPT command, the client MUST NOT issue any DSN for that recipient.
NOTIFYパラメータが受取人のために供給され、SMTPサーバーがRCPTコマンドに応答して、成功（2xxの）応答コードを返していなかった場合（e）は、クライアントがその受取人のための任意のDSNを発行してはいけません。
(f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP server returns a permanent failure (5xx) reply-code in response to a RCPT command, the client MUST issue a "failed" DSN for that recipient.
NOTIFYパラメータが受取人のために供給され、SMTPサーバーがRCPTコマンドに応答して恒久的な失敗（5xxの）応答コードを返していなかった場合（f）は、クライアントがその受取人のためにDSNを「失敗」発行しなければなりません。
The following rules govern the behavior of a conforming MTA upon successful delivery of a message that was received via the SMTP protocol, to a local recipient's mailbox:
次の規則は、ローカル受信者のメールボックスに、SMTPプロトコルを介して受信されたメッセージの配信成功時に準拠したMTAの動作を管理します：
"Delivery" means that the message has been placed in the recipient's mailbox. For messages which are transmitted to a mailbox for later retrieval via IMAP [9], POP [10] or a similar message access protocol, "delivery" occurs when the message is made available to the IMAP (POP, etc.) service, rather than when the message is retrieved by the recipient's user agent.
「送達」のメッセージが受信者のメールボックスに置かれていることを意味します。メッセージは、IMAP（POPなど）サービスが利用できるようにされたときにIMAP [9]、POP [10]または類似のメッセージアクセスプロトコルを介して、後の検索のためのメールボックスに送信されるメッセージについては、「送達」むしろ、発生しますメッセージは受信者のユーザエージェントによって取得されたときよりも。
Similarly, for a recipient address which corresponds to a mailing list exploder, "delivery" occurs when the message is made available to that list exploder, even though the list exploder might refuse to deliver that message to the list recipients.
メッセージは、リストエクスプローダは、リストの受信者にそのメッセージを配信することを拒否する場合でも、そのリストエクスプローダに利用できるようになる場合も同様に、メーリングリストエクスプローダに対応した受信者のアドレスに対して、「配達」が発生します。
(a) If the NOTIFY parameter was supplied for that recipient, with an esmtp-value containing the SUCCESS keyword, the MTA MUST issue a "delivered" DSN for that recipient.
NOTIFYパラメータがSUCCESSキーワードを含むESMTP値と、その受信者のために供給された場合（A）、MTAはその受取人のための「配信」DSNを発行しなければなりません。
(b) If the NOTIFY parameter was supplied for that recipient which did not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for that recipient.
NOTIFYパラメータがSUCCESSキーワードが含まれていなかったその受信者のために供給された場合（b）は、MTAはその受取人のためにDSNを発行してはいけません。
(c) If the NOTIFY parameter was not supplied for that recipient, the MTA MUST NOT issue a DSN.
NOTIFYパラメータがその受取人のために提供されていなかった場合（c）は、MTAは、DSNを発行してはいけません。
The following rules govern the behavior of a conforming MTA, when gatewaying a message that was received via the SMTP protocol, into a foreign (non-SMTP) environment:
外来（非SMTP）環境に、SMTPプロトコルを介して受信されたメッセージをゲートウェイ処理する場合、次の規則は、適合するMTAの挙動を支配します。
(a) If the the foreign environment is capable of issuing appropriate notifications under the conditions requested by the NOTIFY parameter, and the conforming MTA can ensure that any notification thus issued will be translated into a DSN and delivered to the original sender, then the MTA SHOULD gateway the message into the foreign environment, requesting notification under the desired conditions, without itself issuing a DSN.
（a）は外国環境がNOTIFYパラメータによって要求された条件の下で、適切な通知を発行することが可能であり、適合するMTAはMTAそして、このようにして発行された通知がDSNに翻訳され、元の送信者に配信されることを保証することができた場合それ自体がDSNを発行することなく、所望の条件下で通知を要求し、外来環境にメッセージをゲートウェイべきです。
(b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the destination environment cannot return an appropriate notification on successful delivery, the MTA SHOULD issue a "relayed" DSN for that recipient.
NOTIFYパラメータがSUCCESSキーワードで供給したが、先の環境が成功の配信に適切な通知を返すことができない場合は（b）に、MTAはその受取人のための「中継」DSNを発行する必要があります。
(c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a DSN MUST NOT be issued. If possible, the MTA SHOULD direct the destination environment to not issue delivery notifications for that recipient.
NOTIFYパラメータがNEVERのESMTPキーワード付属している場合（c）は、DSNが発行されてはなりません。可能ならば、MTAはその受取人の配信通知を発行しないために先環境を指示すべきです。
(d) If the NOTIFY parameter was not supplied for a particular recipient, a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD attempt to ensure that appropriate notification will be provided by the foreign mail environment if eventual delivery failure occurs, and that no notification will be issued on successful delivery.
NOTIFYパラメータが特定の受信者のために供給されなかった場合（D）、DSNは、ゲートウェイによって発行されるべきではありません。ゲートウェイは、最終的な配信障害が発生した場合に適切な通知が外部メール環境によって提供されることを保証するためにしようと、何の通知が成功した配信に発行されないことをすべきです。
(e) When gatewaying a message into a foreign environment, the return-of-content conditions specified by any RET parameter are nonbinding; however, the MTA SHOULD attempt to honor the request using whatever mechanisms exist in the foreign environment.
（e）は、外来環境にメッセージをゲートウェイする場合、任意のRETパラメータで指定された戻りのコンテンツ条件は非結合です。しかし、MTAは外国環境に存在するどんなメカニズム使用して要求を尊重しようとすべきです。
If a conforming MTA receives a message via the SMTP protocol, and is unable to deliver or relay the message to one or more recipients for an extended length of time (to be determined by the MTA), it MAY issue a "delayed" DSN for those recipients, subject to the following conditions:
適合するMTAは、SMTPプロトコルを介してメッセージを受信し、（MTAにより決定される）時間の延長された長さのために1人以上の受信者にメッセージを配信又は中継することができない場合、それはのための「遅延」DSNを発行してもよいです以下の条件に従うそれらの受信者：
(a) If the NOTIFY parameter was supplied for a recipient and its value included the DELAY keyword, a "delayed" DSN MAY be issued.
（a）の場合はNOTIFYパラメータは「遅れた」DSNを発行することができ、受信者のために供給し、その値は、DELAYキーワードが含まれていました。
(b) If the NOTIFY parameter was not supplied for a recipient, a "delayed" DSN MAY be issued.
NOTIFYパラメータが受取人のために提供されていなかった場合（b）は、「遅れた」DSNを発行することができます。
(c) If the NOTIFY parameter was supplied which did not contain the DELAY keyword, a "delayed" DSN MUST NOT be issued.
DELAYキーワードが含まれていなかった（C）NOTIFYパラメータが供給された場合は、「遅延」DSNを発行してはなりません。
NOTE: Although delay notifications are common in present-day electronic mail, a conforming MTA is never required to issue "delayed" DSNs. The DELAY keyword of the NOTIFY parameter is provided to allow the SMTP client to specifically request (by omitting the DELAY parameter) that "delayed" DSNs NOT be issued.
注：遅延通知が現代の電子メールでは一般的ですが、適合するMTAは「遅れた」DSNを発行するために必要とされることはありません。 NOTIFYパラメータのDELAYキーワードは、SMTPクライアントは、特に「遅延」のDSNが発行されないこと（DELAYパラメータを省略して）要求することを可能にするために提供されます。
The following rules govern the behavior of a conforming MTA which received a message via the SMTP protocol, and is unable to deliver a message to a recipient specified in the SMTP transaction:
以下の規則は、SMTPプロトコルを介してメッセージを受信した適合MTAの動作を管理し、SMTPトランザクションで指定された受信者にメッセージを配信することができません。
(a) If a NOTIFY parameter was supplied for the recipient with an esmtp-keyword containing the value FAILURE, a "failed" DSN MUST be issued by the MTA.
NOTIFYパラメータが値FAILUREを含むESMTPキーワードと受信者のために供給された場合（A）、DSNは、MTAによって発行されなければならない「失敗しました」。
(b) If a NOTIFY parameter was supplied for the recipient which did not contain the value FAILURE, a DSN MUST NOT be issued for that recipient. However, the MTA MAY inform the local postmaster of the delivery failure via some appropriate mechanism which does not itself result in the generation of DSNs.
NOTIFYパラメータが値FAILUREが含まれていませんでした受信者のために供給された場合（b）は、DSNはその受取人のために発行してはなりません。しかし、MTAは、DSNの世代の中で自分自身を得られないいくつかの適切な機構を介して配信障害の局所的なポストマスターに通知することができます。
(c) If no NOTIFY parameter was supplied for the recipient, a "failed" DSN MUST be issued.
何のNOTIFYパラメータが受取人のために供給されなかった場合（c）は、「失敗した」DSNを発行しなければなりません。
NOTE: Some MTAs are known to forward undeliverable messages to the local postmaster or "dead letter" mailbox. This is still considered delivery failure, and does not diminish the requirement to issue a "failed" DSN under the conditions defined elsewhere in this memo. If a DSN is issued for such a recipient, the Action value MUST be "failed".
注：一部のMTAは、ローカルのpostmasterまたは「デッドレター」メールボックスに配信不能メッセージを転送することが知られています。これはまだ配信の失敗とみなされ、そして、このメモの他の場所で定義された条件の下で、「失敗した」DSNを発行する必要性を減少させません。 DSNは、このような受信者のために発行されている場合は、アクションの値が「失敗」しなければなりません。
Delivery of a message to a local email address usually causes the message to be stored in the recipient's mailbox. However, MTAs commonly provide a facility where a local email address can be designated as an "alias" or "mailing list"; delivery to that address then causes the message to be forwarded to each of the (local or remote) recipient addresses associated with the alias or list. It is also common to allow a user to optionally "forward" her mail to one or more alternate addresses. If this feature is enabled, her mail is redistributed to those addresses instead of being deposited in her mailbox.
ローカルのメールアドレスへのメッセージの配信は通常、メッセージが受信者のメールボックスに記憶させます。ただし、MTAが、一般的にローカル電子メールアドレスは「エイリアス」または「メーリングリスト」として指定することができる機能を提供します。そのアドレスへの配信は、メッセージがエイリアスまたはリストに関連付けられた（ローカルまたはリモート）受信者アドレスのそれぞれに転送させます。ユーザーが1つまたは複数の代替アドレスに「前方」彼女のメールを任意にできるようにすることも一般的です。この機能が有効になっている場合は、彼女のメールがそれらのアドレスに再配分される代わりに、彼女のメールボックスに堆積されます。
Following the example of [11] (section 5.3.6), this document defines the difference between an "alias" and "mailing list" as follows: When forwarding a message to the addresses associated with an "alias", the envelope return address (e.g., SMTP MAIL FROM) remains intact. However, when forwarding a message to the addresses associated with a "mailing list", the envelope return address is changed to that of the administrator of the mailing list. This causes DSNs and other nondelivery reports resulting from delivery to the list members to be sent to the list administrator rather than the sender of the original message.
次のように[11]（セクション5.3.6）の例以下、本文書では、「エイリアス」と「メーリングリスト」との間の差を定義：「エイリアス」に関連付けられたアドレスにメッセージを転送するとき、エンベロープリターンアドレス（例えば、FROM SMTPのMAIL）はそのまま残ります。 「メーリングリスト」に関連したアドレスにメッセージを転送するときしかし、エンベロープのリターンアドレスは、メーリングリストの管理者のものに変更されます。これは、DSNは、リストのメンバーへの配信に起因する他の配信不能レポートはリスト管理者ではなく、元のメッセージの送信者に送信されます。
The DSN processing for aliases and mailing lists is as follows:
次のようにエイリアスやメーリングリストのためのDSNの処理は次のとおりです。
When a message is delivered to a list submission address (i.e., placed in the list's mailbox for incoming mail, or accepted by the process that redistributes the message to the list subscribers), this is considered final delivery for the original message. If the NOTIFY parameter for the list submission address contained the SUCCESS keyword, a "delivered" DSN MUST be returned to the sender of the original message.
メッセージがリストの送信アドレス（すなわち、受信メールのリストのメールボックスに入れ、またはリスト加入者にメッセージを再配布プロセスによって受け入れられる）に送達される場合、これは、元のメッセージのための最終的な配信と考えられます。リストの提出アドレスのNOTIFYパラメータがSUCCESSキーワードが含まれていた場合、「配信」DSNは、元のメッセージの送信者に返さなければなりません。
NOTE: Some mailing lists are able to reject message submissions, based on the content of the message, the sender's address, or some other criteria. While the interface between such a mailing list and its MTA is not well-defined, it is important that DSNs NOT be issued by both the MTA (to report successful delivery to the list), and the list (to report message rejection using a "failure" DSN.)
注：一部のメーリングリストは、メッセージ、送信者のアドレス、またはいくつかの他の基準の内容に基づいて、メッセージの送信を拒否することができます。そのようなメーリングリストとそのMTA間のインタフェースが明確に定義されていないが、MTA（リストへの配信の成功を報告するために）、およびリストの両方によって発行されないのDSNは、（使用して、メッセージの拒否を報告することが重要です」失敗」DSN。）
However, even if a "delivered" DSN was issued by the MTA, a mailing list which rejects a message submission MAY notify the sender that the message was rejected using an ordinary message instead of a DSN.
ただし、「配信」DSNは、MTA、メッセージがDSNの代わりに通常のメッセージを使用して拒否されたことを送信者に通知することができるメッセージの提出を拒否し、メーリングリストによって発行された場合でも。
Whenever a message is redistributed to an mailing list,
メッセージがメーリングリストに再配布されるたびに、
(a) The envelope return address is rewritten to point to the list maintainer. This address MAY be that of a process that recognizes DSNs and processes them automatically, but it MUST forward unrecognized messages to the human responsible for the list.
（a）は封筒リターンアドレスは、リストのメンテナを指すように書き換えられています。このアドレスは、DSNを認識し、自動的にそれらを処理プロセスのものかもしれないが、それはリストを担当する人間に認識されていないメッセージを転送しなければなりません。
(b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the redistributed message MUST NOT be derived from those of the original message.
（B）再配布メッセージは元のメッセージのものに由来してはいけません伴うENVID、NOTIFY、RET、およびORCPTパラメータ。
(c) The NOTIFY and RET parameters MAY be specified by the local postmaster or the list administrator. If ORCPT parameters are supplied during redistribution to the list subscribers, they SHOULD contain the addresses of the list subscribers in the format used by the mailing list.
（c）に通知し、RETパラメータは、ローカルポストマスターまたはリスト管理者によって指定されてもよいです。 ORCPTパラメータがリストの購読者に再配分中に供給されている場合は、メーリング・リストで使用される形式でリスト加入者のアドレスを含むべきです。
Under normal circumstances, when a message arrives for an "alias" which has a single forwarding address, a DSN SHOULD NOT be issued. Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with the message as it is redistributed to the forwarding address.
通常の状況下では、メッセージは単一の転送アドレスを持っている「エイリアス」のために到着したときに、DSNが発行されるべきではありません。任意ENVID、NOTIFY、RET、またはORCPTパラメータは、それが転送先アドレスに再分配されるメッセージで伝播されるべきです。
An "alias" with multiple recipient addresses may be handled in any of the following ways:
複数の受信者アドレスを持つ「エイリアス」は、以下のいずれかの方法で処理することができます。
(a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated when relaying the message to any of the forwarding addresses. If the NOTIFY parameter for the alias contained the SUCCESS keyword, the MTA issues a "relayed" DSN. (In effect, the MTA treats the message as if it were being relayed into an environment that does not support DSNs.)
（a）は、任意のENVIDを、NOTIFY、RET、または転送アドレスのいずれかにメッセージを中継する際ORCPTパラメータが伝播されません。エイリアスのNOTIFYパラメータがSUCCESSキーワードが含まれていた場合、MTAは「中継」DSNを発行します。 （それがDSNをサポートしていない環境に中継されたかのような効果では、MTAは、メッセージを扱います。）
(b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent requests if the message is gatewayed) are propagated to EXACTLY one of the forwarding addresses. No DSN is issued. (This is appropriate when aliasing is used to forward a message to a "vacation" auto-responder program in addition to the local mailbox.)
（B）任意ENVID、NOTIFY、RET、またはORCPTパラメータ（または同等のリクエストメッセージがゲートウェイ処理されている場合）は、転送アドレスのうちの正確に1つに伝播されます。何DSNは発行されません。 （エイリアシングがローカルメールボックスに加えて、「休暇」自動応答プログラムにメッセージを転送するために使用されたとき、これは適切です。）
(c) Any ENVID, RET, or ORCPT parameters are propagated to all forwarding addresses associated with that alias. The NOTIFY parameter is propagated to the forwarding addresses, except that it any SUCCESS keyword is removed. If the original NOTIFY parameter for the alias contained the SUCCESS keyword, an "expanded" DSN is issued for the alias. If the NOTIFY parameter for the alias did not contain the SUCCESS keyword, no DSN is issued for the alias.
（C）任意ENVID、RET、またはORCPTパラメータは、その別名に関連付けられたすべての転送アドレスに伝播されます。 NOTIFYパラメータは、それいかなるSUCCESSキーワードが削除されることを除いて、転送アドレスに伝播されます。エイリアスのオリジナルのNOTIFYパラメータがSUCCESSキーワードが含まれていた場合は、「拡大」DSNは、エイリアスのために発行されます。エイリアスのNOTIFYパラメータがSUCCESSキーワードが含まれていなかった場合、DSNは別名に発行されません。
If it is desired to maintain the confidentiality of a recipient's forwarding address, the forwarding may be treated as if it were a mailing list. A DSN will be issued, if appropriate, upon "delivery" to the recipient address specified by the sender. When the message is forwarded it will have a new envelope return address. Any DSNs which result from delivery failure of the forwarded message will not be returned to the original sender of the message and thus not expose the recipient's forwarding address.
受信者の転送アドレスの機密性を維持することが望まれるならば、それはメーリングリストであるかのように、転送が処理することができます。 DSNは、送信者によって指定された受信者アドレスに「配信」すると、適切な場合、発行されます。メッセージが転送されるとき、それは新しい封筒のリターンアドレスを持つことになります。転送されたメッセージの配信失敗から生じる任意のDSNは、メッセージの元の送信者に返されないため、受信者の転送先アドレスを公開しません。
A single DSN may describe attempts to deliver a message to multiple recipients of that message. If a DSN is issued for some recipients in an SMTP transaction and not for others according to the rules above, the DSN SHOULD NOT contain information for recipients for whom DSNs would not otherwise have been issued.
単一DSNは、そのメッセージの複数の受信者にメッセージを配信する試みを記述することができます。 DSNは、上記のルールに従って他の人のためのSMTPトランザクションで一部の受信者に対して発行されたとされていない場合、DSNは、DSNには、そうでない場合に発行されなかったであろう誰のための受信者のための情報を含むべきではありません。
For messages which originated from "local" users (whatever that means), the specifications under which DSNs should be generated can be communicated to the MTA via any protocol agreed on between the sender's mail composer (user agent) and the MTA. The local MTA can then either relay the message, or issue appropriate delivery status notifications. However, if such requests are transmitted within the message itself (for example in the message headers), the requests MUST be removed from the message before it is transmitted via SMTP.
「ローカル」ユーザー（どんなことを意味します）から発信メッセージの場合、DSNには、生成されるべき下の仕様は、任意のプロトコルを介してMTAに伝えることができ、送信者のメール作曲（ユーザエージェント）とMTAの間で合意しました。ローカルMTAは、いずれかのメッセージを中継し、または適切な配信状態通知を発行することができます。このような要求は、（メッセージヘッダーで例えば）メッセージ自体の中で送信される場合には、SMTPを介して送信される前に、しかし、要求がメッセージから除去されなければなりません。
For messages gatewayed from non-SMTP sources and further relayed by SMTP, the gateway SHOULD, using the SMTP extensions described here, attempt to provide the delivery reporting conditions expected by the source mail environment. If appropriate, any DSNs returned to the source environment SHOULD be translated into the format expected in that environment.
SMTPにより中継、さらに非SMTP源からゲートウェイメッセージの場合、ゲートウェイは、ここで説明したSMTP拡張機能を使用して、元のメール環境により予想配信レポーティング条件を提供しようとすべきです。適切であれば、ソース環境に戻されたDSNはその環境で期待されるフォーマットに翻訳する必要があります。
A conforming MTA MUST accept ESMTP parameters of at least the following sizes:
適合するMTAは、少なくとも以下のサイズのESMTPパラメータを受け入れなければなりません：
(a) ENVID parameter: 100 characters.
（a）はENVIDパラメータ：100の文字。
(b) NOTIFY parameter: 28 characters.
28の文字：（b）のパラメータを通知します。
(c) ORCPT parameter: 500 characters.
（C）ORCPTパラメータ：500の文字。
(d) RET parameter: 8 characters.
（d）のRETパラメータ：8つの文字。
The maximum sizes for the ENVID and ORCPT parameters are intended to be adequate for the transmission of "foreign" envelope identifier and original recipient addresses. However, user agents which use SMTP as a message submission protocol SHOULD NOT generate ENVID parameters which are longer than 38 characters in length.
ENVIDとORCPTパラメータの最大サイズは「外来」エンベロープ識別子と元の受信者アドレスの送信のために適切であることが意図されます。しかし、メッセージの送信プロトコルとしてSMTPを使用するユーザエージェントは、長さが38文字より長いENVIDパラメータを生成すべきではありません。
A conforming MTA MUST be able to accept SMTP command-lines which are at least 1036 characters long (530 characters for the ORCPT and NOTIFY parameters of the RCPT command, in addition to the 512 characters required by [1]). If other SMTP extensions are supported by the MTA, the MTA MUST be able to accept a command-line large enough for each SMTP command and any combination of ESMTP parameters which may be used with that command.
適合するMTAは少なくとも1036個の文字であるSMTPコマンドライン受け入れる（ORCPT 530の文字と[1]によって必要とされる512個の文字に加えて、RCPTコマンドのパラメータをNOTIFY）ことができなければなりません。他のSMTP拡張がMTAによってサポートされている場合、MTAは、コマンドライン各SMTPコマンドとそのコマンドと共に使用することができるESMTPパラメータの任意の組み合わせのために十分な大きさを受け入れることができなければなりません。
The format of Delivery Status Notifications is defined in [3], which uses the framework defined in [5]. Delivery Status Notifications are to be returned to the sender of the original message as outlined below.
配信状態通知のフォーマットは、[5]で定義されたフレームワークを使用する、[3]で定義されています。配信状態通知は、下記のとおり、元のメッセージの送信者に返さなければなりません。
The DSN sender address (in the SMTP MAIL command) MUST be a null reverse-path ("<>"), as required by section 5.3.3 of [11]. The DSN recipient address (in the RCPT command) is copied from the MAIL command which accompanied the message for which the DSN is being issued. When transmitting a DSN via SMTP, the RET parameter MUST NOT be used. The NOTIFY parameter MAY be used, but its value MUST be NEVER. The ENVID parameter (with a newly generated envelope-id) and/or ORCPT parameter MAY be used.
[11]のセクション5.3.3によって必要とされる（SMTPメールコマンドで）DSNの送信元アドレスは、ヌル逆経路（「<>」）でなければなりません。 （RCPTコマンドで）DSNの受信者アドレスは、DSNが発行されているメッセージを伴うMAILコマンドからコピーされます。 SMTP経由でDSNを送信する場合、RETパラメータを使用してはいけません。 NOTIFYパラメータを使用することができるが、その値は決してあってはなりません。 （新たに生成されたエンベロープ-IDを持つ）ENVIDパラメータおよび/またはORCPTパラメータを使用することができます。
A DSN is transmitted as a MIME message with a top-level content-type of multipart/report (as defined in [3]).
DSNは、（[3]で定義されるように）マルチパート/レポートのトップレベルのコンテンツタイプとMIMEメッセージとして送信されます。
The multipart/report content-type may be used for any of several kinds of reports generated by the mail system. When multipart/report is used to convey a DSN, the report-type parameter of the multipart/report content-type is "delivery-status".
マルチパート/レポートのコンテンツタイプは、メールシステムによって生成されたレポートのいくつかの種類のいずれかのために使用することができます。マルチパート/レポートはDSNを伝えるために使用された場合は、マルチパート/レポートのコンテンツタイプのレポート型パラメータは「配送状況」です。
As described in [5], the first component of a multipart/report content-type is a human readable explanation of the report. For a DSN, the second component of the multipart/report is of content-type message/delivery-status (defined in [3]). The third component of the multipart/report consists of the original message or some portion thereof. When the value of the RET parameter is FULL, the full message SHOULD be returned for any DSN which conveys notification of delivery failure. (However, if the length of the message is greater than some implementation-specified length, the MTA MAY return only the headers even if the RET parameter specified FULL.) If a DSN contains no notifications of delivery failure, the MTA SHOULD return only the headers.
[5]で説明したように、マルチパート/レポートのコンテンツタイプの第一の成分は、レポートの人間が読み取り可能な説明です。 DSNのために、マルチパート/レポートの第二成分は、（[3]で定義された）コンテンツタイプメッセージ/配送状況です。マルチパート/レポートの第三成分は、元のメッセージまたはその一部から成ります。 RETパラメータの値が満杯になると、完全なメッセージは、配信失敗の通知を伝える任意のDSNのために返されるべきです。 （メッセージの長さは、いくつかの実装に指定された長さよりも大きい場合は、MTAは、RETパラメータがFULLを指定した場合でもヘッダーのみを返すことができる。）DSNが配達失敗のない通知が含まれていない場合、MTAは、返すべきヘッダ。
The third component must have an appropriate content-type label. Issues concerning selection of the content-type are discussed in [5].
第三成分は、適切なコンテンツタイプのラベルを有していなければなりません。コンテンツタイプの選択に関する問題は、[5]に記載されています。
The message/delivery-status content-type defines a number of fields, with general specifications for their contents. The following requirements for any DSNs generated in response to a message received by the SMTP protocol by a conforming SMTP server, are in addition to the requirements defined in [3] for the message/delivery-status type.
メッセージ/配送状況コンテンツタイプは、その内容のための一般的な仕様で、フィールドの数を定義します。適合するSMTPサーバでSMTPプロトコルによって受信されたメッセージに応答して生成された任意のDSNのために以下の要件は、メッセージ/配送状況タイプ[3]で定義された要件に加えています。
When generating a DSN for a message which was received via the SMTP protocol, a conforming MTA will generate the following fields of the message/delivery-status body part:
SMTPプロトコルを介して受信されたメッセージのDSNを生成する場合、適合するMTAは、メッセージ/配送状況身体部分の次のフィールドが生成されます。
(a) if an ENVID parameter was present on the MAIL command, an Original-Envelope-ID field MUST be supplied, and the value associated with the ENVID parameter must appear in that field. If the message was received via SMTP with no ENVID parameter, the Original-Envelope-ID field MUST NOT be supplied.
（A）ENVIDパラメータはMAILコマンドで存在していた場合は、元のエンベロープ-IDフィールドを指定する必要があり、そしてENVIDパラメータに関連付けられた値は、そのフィールドに表示されなければなりません。メッセージはありませんENVIDパラメータでSMTPを介して受信された場合は、オリジナル・封筒-IDフィールドを供給してはなりません。
Since the ENVID parameter is encoded as xtext, but the
Original-Envelope-ID header is NOT encoded as xtext, the MTA
must decode the xtext encoding when copying the ENVID value to
the Original-Envelope-ID field.
(b) The Reporting-MTA field MUST be supplied. If Reporting MTA can determine its fully-qualified Internet domain name, the MTA-name-type subfield MUST be "dns", and the field MUST contain the fully-qualified domain name of the Reporting MTA. If the fully-qualified Internet domain name of the Reporting MTA is not known (for example, for an SMTP server which is not directly connected to the Internet), the Reporting-MTA field may contain any string identifying the MTA, however, in this case the MTA-name-type subfield MUST NOT be "dns". A MTA-name-type subfield value of "x-local-hostname" is suggested.
（B）報告-MTAフィールドが供給されなければなりません。 MTAはその完全修飾インターネットドメイン名を決定することができます報告した場合、MTA名型サブフィールドは、「DNS」でなければならない、とフィールドが報告MTAの完全修飾ドメイン名を含まなければなりません。レポートMTAの完全修飾インターネットドメイン名が知られていない場合（例えば、インターネットに直接接続されていないSMTPサーバのため）、レポーティング-MTAフィールドは、この中で、しかし、MTAを識別する任意の文字列を含んでいてもよいですケースMTA名型サブフィールドは、「DNS」にすることはできません。 「X-ローカル・ホスト名」のMTA名型サブフィールドの値が推奨されます。
(c) Other per-message fields as defined in [3] MAY be supplied as appropriate.
（C）その他のメッセージごとのフィールドで定義されるように[3]を適切として供給され得ます。
(d) If the ORCPT parameter was provided for this recipient, the Original-Recipient field MUST be supplied, with its value taken from the ORCPT parameter. If no ORCPT parameter was provided for this recipient, the Original-Recipient field MUST NOT appear.
ORCPTパラメータは、この受信者のために提供された場合（d）は、元の受信者フィールドがORCPTパラメータから採取し、その値を用いて、供給されなければなりません。何ORCPTパラメータがこの受信者のために提供されなかった場合は、オリジナル・受信者フィールドが表示されてはなりません。
(e) The Final-Recipient field MUST be supplied. It MUST contain the recipient address from the message envelope. If the message was received via SMTP, the address-type will be "rfc822".
（e）の最終的な受信者フィールドが供給されなければなりません。これは、メッセージエンベロープから受信者アドレスを含まなければなりません。メッセージがSMTP経由で受信された場合、アドレス型は「RFC822」になります。
(f) The Action field MUST be supplied.
（F）アクションフィールドが供給されなければなりません。
(g) The Status field MUST be supplied, using a status-code from [6]. If there is no specific code which suitably describes a delivery failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent failure) MUST be used.
（G）、Statusフィールドは、[6]からステータスコードを使用して、供給されなければなりません。好適配信の失敗を説明しない特定のコードが存在しない場合、4.0.0（一時的な障害）、または5.0.0（永久故障）のいずれかを使用しなければなりません。
(h) For DSNs resulting from attempts to relay a message to one or more recipients via SMTP, the Remote-MTA field MUST be supplied for each of those recipients. The mta-name-type subfields of those Remote-MTA fields will be "dns".
（h）はSMTPを介して1つまたは複数の受信者にメッセージを中継する試みに起因DSNのために、リモートMTAフィールドは、それらの受信者のそれぞれに供給されなければなりません。これらのリモートMTAフィールドのMTA名型サブフィールドは、「DNS」になります。
(i) For DSNs resulting from attempts to relay a message to one or more recipients via SMTP, the Diagnostic-Code MUST be supplied for each of those recipients. The diagnostic-type subfield will be "smtp". See section 9.2 of this document for a description of the "smtp" diagnostic-code.
SMTPを介して1つまたは複数の受信者にメッセージを中継する試みに起因DSNのための式（I）は、診断コードがそれらの受信者のそれぞれに供給されなければなりません。診断型のサブフィールドは、「SMTP」になります。 「SMTP」診断コードの説明については、本書のセクション9.2を参照。
(j) For DSNs resulting from attempts to relay a message to one or more recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be supplied for each recipient, which contains the address of that recipient which was presented to the remote SMTP server.
（j）はSMTPを介して1つまたは複数の受信者にメッセージを中継する試みに起因DSNのために、SMTP-リモート受信者拡張フィールドは、リモートSMTPサーバに提示されたその受信者のアドレスを含む各受信者のために供給されるかもしれません。
(k) Other per-recipient fields defined in [3] MAY appear, as appropriate.
（K）で定義された他の受信者ごとのフィールドは、[3]、必要に応じて、表示されることがあります。
The author wishes to thank Eric Allman, Harald Alvestrand, Jim Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall Rose, Greg Vaudreuil, and Klaus Weide for their suggestions for improvement of this document.
著者はエリック・オールマン、ハラルドAlvestrand、ジム・コンクリン、ブライアンCostales、ピーター・コーウェン、デイブ・クロッカー、ロジャーFajman、ネッドフリード、マルコKaittola、スティーブKille、ジョン・クレンシン、アナスタシオスKotsikonas、ジョン・ガーディナーマイヤーズ、ジュリアン玉ねぎ、ヤコブパルメに感謝したいです、マーシャルローズ、グレッグボードルイ、そしてクラウス・ウェイド、この文書の改善のための彼らの提案のため。
The SMTP extension described in this document does not change the fundamental nature of the SMTP service and hence does not create any new security exposures in and of itself. It necessarily adds complexity to implementations, however, and with added complexity comes an increased risk of implementation errors.
この文書で説明したSMTP拡張は、SMTPサービスの基本的な性質を変えていないので、それ自体のいずれかの新しいセキュリティリスクを作成しません。それは必ずしもしかし、実装が複雑に、そして追加の複雑さと実装エラーのリスクの増加が来ます。
Previous ad-hoc delivery notification mechanisms sometimes produced a storm of receipts due to unanticipated interactions with mailing list expansion software. In this specification notification of successful delivery is carefully designed so, if properly implemented, it cannot interact with a list expander in this way.
前のアドホック配信通知メカニズムは時々メーリングリストの拡張ソフトウェアとの予期しない相互作用による領収書の嵐を生産しました。適切に実装する場合は、この明細書では成功した配達の通知は慎重ように設計されて、それがこのようにリストエキスパンダと対話することはできません。
The security considerations section in [5] describes security issues associated with multipart/report objects in general and the security considerations section in [3] describes security issues with DSNs in particular.
[3]特にDSNの持つセキュリティ問題について説明し[5]のセキュリティ問題部は、一般にマルチパート/レポートオブジェクトに関連付けられたセキュリティ問題やセキュリティ問題部を記述する。
The following type names are defined for use in DSN fields generated by conforming SMTP-based MTAs:
以下のタイプ名はSMTPベースのMTAを準拠によって生成されたDSNフィールドでの使用のために定義されています。
The "rfc822" address-type is to be used when reporting Internet electronic mail address in the Original-Recipient and Final-Recipient DSN fields.
「RFC822」アドレス型オリジナル・受信者と最終受信者のDSNフィールドに、インターネットの電子メールアドレスを通知する際に使用されるべきです。
(a) address-type name: rfc822
（a）のアドレス型名：RFC822
(b) syntax for mailbox addresses
（b）は、メールボックスアドレスの構文を
RFC822 mailbox addresses are generally expected to be of the
form
[route] addr-spec
[ルート] ADDRスペック
where "route" and "addr-spec" are defined in [2], and the "domain" portions of both "route" and "addr-spec" are fully-qualified domain names that are registered in the DNS. However, an MTA MUST NOT modify an address obtained from the message envelope to force it to conform to syntax rules.
「ルート」および「ADDR仕様は」[2]で定義される場合、および「ルート」と「ADDR仕様」の両方の「ドメイン」部分は、DNSに登録されている完全修飾ドメイン名です。しかし、MTAは、構文規則に準拠するためにそれを強制的にメッセージエンベロープから取得したアドレスを変更してはいけません。
(c) If addresses of this type are not composed entirely of graphic characters from the US-ASCII repertoire, a specification for how they are to be encoded as graphic US-ASCII characters in a DSN Original-Recipient or Final-Recipient DSN field.
（c）は、このタイプのアドレスは完全にUS-ASCIIレパートリーから図形文字の構成されていない場合、彼らはどのようにするための仕様は、DSNオリジナル・受信者または最終受信者のDSNフィールドのグラフィックUS-ASCII文字としてコード化されます。
RFC822 addresses consist entirely of graphic characters from the
US-ASCII repertoire, so no translation is necessary.
The "smtp" diagnostic-type is to be used when reporting SMTP reply-codes in Diagnostic-Code DSN fields.
「SMTP」診断型診断-コードDSNフィールドでSMTP返信コードを報告するときに使用されます。
(a) diagnostic-type name: SMTP
（a）は、診断型名：SMTP
(b) A description of the syntax to be used for expressing diagnostic codes of this type as graphic characters from the US-ASCII repertoire.
（b）は、構文の説明は、US-ASCIIレパートリーから図形文字としてのこのタイプの診断コードを発現させるために使用されます。
An SMTP diagnostic-code is of the form
SMTP診断コードの形式であります
*( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text
*（3 * DIGIT " - " *テキスト）3 * DIGITのSPACE *テキスト
For a single-line SMTP reply to an SMTP command, the diagnostic-code SHOULD be an exact transcription of the reply. For multi-line SMTP replies, it is necessary to insert a SPACE before each line after the first. For example, an SMTP reply of:
SMTPコマンドへ単一行のSMTP応答のために、診断コードは、応答の正確な転写であるべきです。マルチラインのSMTP応答を、最初の後の各ラインの前にスペースを挿入する必要があります。たとえば、SMTPの返信：
550-mailbox unavailable
550 user has moved with no forwarding address
could appear as follows in a Diagnostic-Code DSN field:
診断 - コードDSNフィールドに次のように表示される可能性：
Diagnostic-Code: smtp ; 550-mailbox unavailable
550 user has moved with no forwarding address
(c) A list of valid diagnostic codes of this type and the meaning of each code.
（c）は、このタイプと各コードの意味の有効な診断コードのリスト。
SMTP reply-codes are currently defined in [1] and [11].
Additional codes may be defined by other RFCs.
The "dns" MTA-name-type should be used in the Reporting-MTA field. An MTA-name of type "dns" is a fully-qualified domain name. The name must be registered in the DNS, and the address Postmaster@{mta-name} must be valid.
「DNS」MTA名型は、Reporting-MTA分野で使用されるべきです。タイプ「DNS」のMTA名は完全修飾ドメイン名です。名前がDNSに登録する必要があり、そのアドレスのpostmaster @ {MTA-name}は有効でなければなりません。
(a) MTA-name-type name: dns
（a）はMTA名型名：DNS
(b) A description of the syntax of MTA names of this type, using BNF, regular expressions, ASN.1, or other non-ambiguous language.
（b）は、このタイプのMTA名の構文の説明を、BNF、正規表現、ASN.1、または他の非あいまいな言語を使用して。
MTA names of type "dns" SHOULD be valid Internet domain names.
If such domain names are not available, a domain-literal
containing the internet protocol address is acceptable. Such
domain names generally conform to the following syntax:
domain = real-domain / domain-literal
ドメイン=実ドメイン/ドメインリテラル
real-domain = sub-domain *("." sub-domain)
実ドメイン=サブドメイン*（「」サブドメイン）
sub-domain = atom
サブドメイン=原子
domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]"
ドメインリテラル= "[" 1 * 3DIGIT 3（ "" 1 * 3DIGIT） "]"
where "atom" and "DIGIT" are defined in [2].
「原子」と「桁が」[2]で定義されます。
(c) If MTA names of this type do not consist entirely of graphic characters from the US-ASCII repertoire, a specification for how an MTA name of this type should be expressed as a sequence of graphic US-ASCII characters.
（c）は、このタイプのMTA名がUS-ASCIIレパートリーからグラフィック文字で完全に構成されていない場合は、このタイプのMTA名は、グラフィックUS-ASCII文字のシーケンスとして表現する方法の仕様を。
MTA names of type "dns" consist entirely of graphic US-ASCII
characters, so no translation is needed.
This example traces the flow of a single message addressed to multiple recipients. The message is sent by Alice@Example.ORG to Bob@Example.COM, Carol@Ivory.EDU, Dana@Ivory.EDU, Eric@Bombs.AF.MIL, Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a variety of per-recipient options. The message is successfully delivered to Bob, Dana (via a gateway), Eric, and Fred. Delivery fails for Carol and George.
この例では、複数の受信者宛の単一のメッセージの流れをトレース。メッセージはBob@Example.COM、Carol@Ivory.EDU、Dana@Ivory.EDU、Eric@Bombs.AF.MIL、Fred@Bombs.AF.MIL、ジョージ@ Tax-にAlice@Example.ORGによって送られますME.GOV、受信者ごとのさまざまなオプションを持ちます。メッセージが正常にボブ、ダナ（ゲートウェイを介して）、エリック、およびフレッドに送達されます。配信はキャロルとジョージのために失敗しました。
NOTE: Formatting rules for RFCs require that no line be longer than 72 characters. Therefore, in the following examples, some SMTP commands longer than 72 characters are printed on two lines, with the first line ending in "\". In an actual SMTP transaction, such a command would be sent as a single line (i.e., with no embedded CRLFs), and without the "\" character that appears in these examples.
注：RFCのフォーマットのルールは何の行が72文字を超えることがないことが必要です。したがって、以下の例では、いくつかのSMTPは長い72文字を超えるコマンド「\」で終わる最初の行で、2行に印刷されています。実際のSMTPトランザクションでは、そのようなコマンド（すなわち、無埋め込みのCRLFで）単一の行として送信され、これらの実施例に現れる「\」文字無しであろう。
Alice's user agent sends the message to the SMTP server at Example.ORG. Note that while this example uses SMTP as a mail submission protocol, other protocols could also be used.
AliceのユーザーエージェントはExample.ORGのSMTPサーバーにメッセージを送信します。この例では、メールの送信プロトコルとしてSMTPを使用しながら、他のプロトコルを使用することもできることに留意されたいです。
<<< 220 Example.ORG SMTP server here >>> EHLO Example.ORG <<< 250-Example.ORG <<< 250-DSN <<< 250-EXPN <<< 250 SIZE >>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159 <<< 250 <Alice@Example.ORG> sender ok >>> RCPT TO:<Bob@Example.COM> NOTIFY=SUCCESS \ ORCPT=rfc822;Bob@Example.COM <<< 250 <Bob@Example.COM> recipient ok >>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \ ORCPT=rfc822;Carol@Ivory.EDU <<< 250 <Carol@Ivory.EDU> recipient ok >>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \ ORCPT=rfc822;Dana@Ivory.EDU <<< 250 <Dana@Ivory.EDU> recipient ok >>> RCPT TO:<Eric@Bombs.AF.MIL> NOTIFY=FAILURE \ ORCPT=rfc822;Eric@Bombs.AF.MIL <<< 250 <Eric@Bombs.AF.MIL> recipient ok >>> RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER <<< 250 <Fred@Bombs.AF.MIL> recipient ok >>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \ ORCPT=rfc822;George@Tax-ME.GOV <<< 250 <George@Tax-ME.GOV> recipient ok >>> DATA <<< 354 okay, send message >>> (message goes here) >>> . <<< 250 message accepted >>> QUIT <<< 221 goodbye
<<<ここに220 Example.ORG SMTPサーバー>>> EHLO Example.ORG <<< 250-Example.ORG <<< 250-DSN <<< 250-EXPN <<< 250 SIZE >>> MAIL FROM：<アリス@ Example.ORG> RET = HDRS ENVID = QQ314159 <<< 250 <Alice@Example.ORG>送信者OK >>> RCPT TO：<Bob@Example.COM> NOTIFY = SUCCESS \ ORCPT = RFC822; Bob@Example.COM <<< 250 <Bob@Example.COM>受信者OK >>> RCPT TO：<Carol@Ivory.EDU> \ ORCPT = RFC822 = FAILUREをNOTIFY; Carol@Ivory.EDU <<< 250 <Carol@Ivory.EDU>受信者OK >>> RCPT TO：<Dana@Ivory.EDU> NOTIFY = SUCCESS、FAILURE \ ORCPT = RFC822; Dana@Ivory.EDU <<< 250 <Dana@Ivory.EDU>受信者OK >>> RCPT TO：< Eric@Bombs.AF.MIL> NOTIFY = FAILURE \ ORCPT = RFC822、RCPT TO >>> OK Eric@Bombs.AF.MIL <<< 250 <Eric@Bombs.AF.MIL>受信者：<Fred@Bombs.AF .MIL> NOTIFY = NEVER <<< 250 <Fred@Bombs.AF.MIL>受信者OK >>> RCPT TO：<George@Tax-ME.GOV> = FAILURE \ ORCPT = RFC822をNOTIFY、ジョージ@税-ME。 GOV <<< 250 <George@Tax-ME.GOV>受信者OK >>>データ<<< 354大丈夫、>>>（メッセージをここに）>>>メッセージを送信します。 >>> <<< 221別れを終了受け入れ<<< 250メッセージ
The SMTP at Example.ORG then relays the message to Example.COM. (For the purpose of this example, mail.Example.COM is the primary mail exchanger for Example.COM).
Example.ORGでSMTPはその後Example.COMにメッセージを中継します。 （この例の目的のために、mail.Example.COMはExample.COMのプライマリメール交換です）。
<<< 220 mail.Example.COM says hello >>> EHLO Example.ORG <<< 250-mail.Example.COM <<< 250 DSN >>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159 <<< 250 sender okay >>> RCPT TO:<Bob@Example.COM> NOTIFY=SUCCESS \ ORCPT=rfc822;Bob@Example.COM <<< 250 recipient okay >>> DATA <<< 354 send message >>> (message goes here) >>> . <<< 250 message received >>> QUIT <<< 221 bcnu
<<< 220 mail.Example.COMが挨拶>>> EHLO Example.ORG <<< 250-mail.Example.COM <<< 250 >>> DSN MAIL FROM：<Alice@Example.ORG> RET = HDRS ENVID = QQ314159 <<< 250差出人大丈夫>>> RCPT TO：<Bob@Example.COM> NOTIFY = SUCCESS \ ORCPT = RFC822; Bob@Example.COM <<< 250受け手大丈夫>>>データ<<< 354送信メッセージ>>> >>>（メッセージはここに）。 <<< 250メッセージ221 BCNUを<<< QUIT >>>受信しました
The SMTP at Example.ORG relays the message to Ivory.EDU, which (as it happens) is a gateway to a LAN-based mail system that accepts SMTP mail and supports the DSN extension.
Example.ORGでSMTPは、SMTPメールを受け付け、DSN拡張をサポートするLANベースのメールシステムへのゲートウェイである（それが起こるように）Ivory.EDU、メッセージを中継します。
<<< 220 Ivory.EDU gateway to FooMail(tm) here >>> EHLO Example.ORG <<< 250-Ivory.EDU <<< 250 DSN >>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159 <<< 250 ok >>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \ ORCPT=rfc822;Carol@Ivory.EDU <<< 550 error - no such recipient >>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \ ORCPT=rfc822;Dana@Ivory.EDU <<< 250 recipient ok >>> DATA <<< 354 send message, end with '.' >>> (message goes here) >>> . <<< 250 message received >>> QUIT <<< 221 bye
FooMailに<<< 220 Ivory.EDUゲートウェイ（商標）ここで>>> EHLO Example.ORG <<< 250-Ivory.EDU <<< 250 DSN >>> MAIL FROM：<Alice@Example.ORG> RET = HDRS ENVID = QQ314159 <<< 250 OK >>> RCPT TO：<Carol@Ivory.EDU> \ ORCPT = RFC822 = FAILUREをNOTIFY; Carol@Ivory.EDU <<< 550エラー - いいえ、そのような受信者>>> RCPT TO：< Dana@Ivory.EDU> NOTIFY = SUCCESS、FAILURE \ ORCPT = RFC822; '' Dana@Ivory.EDU <<< 250受信者OK >>>データ<<< 354送信メッセージ、で終わり>>> >>>（メッセージはここに）。 <<< 250メッセージ221 BYEを<<< QUIT >>>受信しました
Note that since the Ivory.EDU refused to accept mail for Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the sender-SMTP (in this case Example.ORG) must generate a DSN.
以来Ivory.EDUがCarol@Ivory.EDUのメールを受け入れることを拒否し、指定した送信者が= FAILUREをNOTIFY、送信側SMTPは、（この場合はExample.ORG）がDSNを生成しなければならないことに注意してください。
The SMTP at Example.ORG relays the message to Bombs.AF.MIL, which does not support the SMTP extension. Because the sender specified NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Example.ORG chooses to send the message for that recipient in a separate transaction with a reverse-path of <>.
Example.ORGのSMTPは、SMTP拡張をサポートしていませんBombs.AF.MILにメッセージを中継します。指定された送信者が受信者Fred@Bombs.AF.MILため= NEVER NOTIFYないので、Example.ORGでSMTPは、<>の逆パスで別のトランザクションでその受信者に対するメッセージを送信することを選択しました。
<<< 220-Bombs.AF.MIL reporting for duty. <<< 220 Electronic mail is to be used for official business only. >>> EHLO Example.ORG <<< 502 command not implemented >>> RSET <<< 250 reset >>> HELO Example.ORG <<< 250 Bombs.AF.MIL >>> MAIL FROM:<Alice@Example.ORG> <<< 250 ok >>> RCPT TO:<Eric@Bombs.AF.MIL> <<< 250 ok >>> DATA <<< 354 send message >>> (message goes here) >>> . <<< 250 message accepted >>> MAIL FROM:<> <<< 250 ok >>> RCPT TO:<Fred@Bombs.AF.MIL> <<< 250 ok >>> DATA <<< 354 send message >>> (message goes here) >>> . <<< 250 message accepted >>> QUIT <<< 221 Bombs.AF.MIL closing connection
義務のために報告<<< 220-Bombs.AF.MIL。 <<< 220電子メールは唯一の公式なビジネスのために使用されるべきです。 >>> EHLO Example.ORG <<< 502コマンドではない実施>>> RSET <<< 250リセット>>> HELO Example.ORG <<< 250 Bombs.AF.MIL >>>、MAIL FROM：<アリス@例。 ORG> <<< 250 OK >>> RCPT TO：<Eric@Bombs.AF.MIL> <<< 250のOK >>>データ<<< 354送信メッセージ>>>（メッセージをここに）>>>。 <<< 250メッセージ受け入れ>>> MAIL FROM：<> <<< 250 OK >>> RCPT TO：<Fred@Bombs.AF.MIL> <<< 250のOK >>>データ<<< 354送信メッセージ> >> >>>（メッセージはここに）。 <<< 250メッセージは<<< 221 Bombs.AF.MIL閉鎖接続を終了>>>受け付け
The SMTP at Example.ORG relays the message to Tax-ME.GOV. (this step is not shown). MTA Tax-ME.GOV then forwards the message to Sam@Boondoggle.GOV (shown below). Both Tax-ME.GOV and Example.ORG support the SMTP DSN extension. Note that RET, ENVID, and ORCPT all retain their original values.
Example.ORGでSMTPはTax-ME.GOVにメッセージを中継します。 （このステップは図示せず）。 MTA Tax-ME.GOVは次にSam@Boondoggle.GOV（下図）にメッセージを転送します。 Tax-ME.GOVとExample.ORGの両方がSMTP DSN拡張をサポートしています。 RET、ENVID、およびORCPTはすべて元の値を保持していることに注意してください。
<<< 220 BoonDoggle.GOV says hello >>> EHLO Example.ORG <<< 250-mail.Example.COM <<< 250 DSN >>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159 <<< 250 sender okay >>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCESS \ ORCPT=rfc822;George@Tax-ME.GOV <<< 250 recipient okay >>> DATA <<< 354 send message >>> (message goes here) >>> . <<< 250 message received >>> QUIT <<< 221 bcnu
<<< 220 BoonDoggle.GOVが挨拶>>> EHLO Example.ORG <<< 250-mail.Example.COM <<< 250 >>> DSN MAIL FROM：<Alice@Example.ORG> RET = HDRS ENVID = QQ314159 <<< 250差出人大丈夫>>> RCPT TO：<Sam@Boondoggle.GOV> = SUCCESS \ ORCPT = RFC822をNOTIFY; George@Tax-ME.GOV <<< 250受け手大丈夫>>>データ<<< 354送信メッセージ>>> >>>（メッセージはここに）。 <<< 250メッセージ221 BCNUを<<< QUIT >>>受信しました
MTA mail.Example.COM successfully delivers the message to Bob@Example.COM. Because the sender specified NOTIFY=SUCCESS, mail.Example.COM issues the following DSN, and sends it to Alice@Example.ORG.
MTA mail.Example.COMが正常Bob@Example.COMにメッセージを配信します。指定された送信者が= SUCCESSをNOTIFYので、mail.Example.COM以下のDSNを発行し、Alice@Example.ORGに送信します。
To: Alice@Example.ORG From: postmaster@mail.Example.COM Subject: Delivery Notification (success) for Bob@Example.COM Content-Type: multipart/report; report-type=delivery-status; boundary=abcde MIME-Version: 1.0
To：Alice@Example.ORGから：postmaster@mail.Example.COM件名：Bob@Example.COMのContent-Typeのための配信通知（成功）：マルチパート/レポート。レポートタイプ=配送状況。境界= ABCDE MIME-バージョン：1.0
--abcde Content-type: text/plain; charset=us-ascii
--abcdeコンテンツタイプ：テキスト/平野。文字セット= US-ASCII
Your message (id QQ314159) was successfully delivered to Bob@Example.COM.
あなたのメッセージ（のid QQ314159）は成功しBob@Example.COMに配信されました。
--abcde Content-type: message/delivery-status
--abcdeコンテンツタイプ：メッセージ/配送状況
Reporting-MTA: dns; mail.Example.COM Original-Envelope-ID: QQ314159
報告-MTA：DNSを。 mail.Example.COMオリジナル・封筒-ID：QQ314159
Original-Recipient: rfc822;Bob@Example.COM Final-Recipient: rfc822;Bob@Example.COM Action: delivered Status: 2.0.0
オリジナル・受信者：RFC822; Bob@Example.COM最終受信者：RFC822; Bob@Example.COMアクション：配信ステータス：2.0.0
--abcde Content-type: message/rfc822
--abcdeコンテンツタイプ：メッセージ/ RFC822
(headers of returned message go here)
（返されたメッセージのヘッダがここに入ります）
--abcde--
--abcde--
Because delivery to Carol failed and the sender specified NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Example.ORG (the SMTP client to which the failure was reported via SMTP) issues the following DSN.
キャロルへの配信が失敗し、指定した送信者がCarol@Ivory.EDU用= FAILUREをNOTIFYので、MTA Example.ORG（障害がSMTP経由で報告された先のSMTPクライアント）は、以下のDSNを発行します。
To: Alice@Example.ORG From: postmaster@Example.ORG Subject: Delivery Notification (failure) for Carol@Ivory.EDU Content-Type: multipart/report; report-type=delivery-status; boundary=bcdef MIME-Version: 1.0
To：Alice@Example.ORGから：postmaster@Example.ORG件名：Carol@Ivory.EDUのContent-Typeのための配信通知（失敗）：マルチパート/レポート。レポートタイプ=配送状況。境界= BCDEF MIME-バージョン：1.0
--bcdef Content-type: text/plain; charset=us-ascii
--bcdefコンテンツタイプ：テキスト/平野。文字セット= US-ASCII
Your message (id QQ314159) could not be delivered to Carol@Ivory.EDU.
あなたのメッセージ（のid QQ314159）はCarol@Ivory.EDUに配信することができませんでした。
A transcript of the session follows:
セッションのトランスクリプトは次のとおりです。
(while talking to Ivory.EDU) >>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE <<< 550 error - no such recipient
（一方Ivory.EDUに話し）>>> RCPT TO： - そのようなレシピエント<Carol@Ivory.EDU> = FAILURE <<< 550エラーをNOTIFY
--bcdef Content-type: message/delivery-status
--bcdefコンテンツタイプ：メッセージ/配送状況
Reporting-MTA: dns; Example.ORG Original-Envelope-ID: QQ314159
報告-MTA：DNSを。 Example.ORGオリジナル・封筒-ID：QQ314159
Original-Recipient: rfc822;Carol@Ivory.EDU Final-Recipient: rfc822;Carol@Ivory.EDU SMTP-Remote-Recipient: Carol@Ivory.EDU Diagnostic-Code: smtp; 550 error - no such recipient Action: failed Status: 5.0.0
オリジナル・受信者：RFC822; Carol@Ivory.EDU最終受信者：RFC822; Carol@Ivory.EDU SMTP-リモート受信者：Carol@Ivory.EDU診断-コード：SMTP; 550エラー - いいえ、そのような受信者の処置：失敗した状況：5.0.0
--bcdef Content-type: message/rfc822
--bcdefコンテンツタイプ：メッセージ/ RFC822
(headers of returned message go here)
（返されたメッセージのヘッダがここに入ります）
--bcdef--
--bcdef--
Although the mail gateway Ivory.EDU supports the DSN SMTP extension, the LAN mail system attached to its other side does not generate positive delivery confirmations. So Ivory.EDU issues a "relayed" DSN:
メールゲートウェイIvory.EDUがDSN SMTP拡張をサポートしていますが、その反対側に接続されたLANのメールシステムは、正の配信確認を生成しません。だから、Ivory.EDUは「中継」DSNが発行されます。
To: Alice@Example.ORG From: postmaster@Ivory.EDU Subject: mail relayed for Dana@Ivory.EDU Content-Type: multipart/report; report-type=delivery-status; boundary=cdefg MIME-Version: 1.0
To：Alice@Example.ORGから：postmaster@Ivory.EDU件名：Dana@Ivory.EDUのContent-Typeのために中継されるメール：マルチパート/レポート。レポートタイプ=配送状況。境界= CDEFG MIME-バージョン：1.0
--cdefg Content-type: text/plain; charset=us-ascii
--cdefgコンテンツタイプ：テキスト/平野。文字セット= US-ASCII
Your message (addressed to Dana@Ivory.EDU) was successfully relayed to:
（Dana@Ivory.EDU宛）あなたのメッセージが正常に中継されました：
ymail!Dana
ymail！オン
by the FooMail gateway at Ivory.EDU.
Ivory.EDUでFooMailゲートウェイによって。
Unfortunately, the remote mail system does not support confirmation of actual delivery. Unless delivery to ymail!Dana fails, this will be the only Delivery Status Notification sent.
残念ながら、リモートメールシステムは、実際の配達の確認をサポートしていません。配信がymailしない限り！ダナが失敗し、これが送られたのみ配信ステータス通知されます。
--cdefg Content-type: message/delivery-status
--cdefgコンテンツタイプ：メッセージ/配送状況
Reporting-MTA: dns; Ivory.EDU Original-Envelope-ID: QQ314159
報告-MTA：DNSを。 Ivory.EDUオリジナル・封筒-ID：QQ314159
Original-Recipient: rfc822;Dana@Ivory.EDU Final-Recipient: rfc822;Dana@Ivory.EDU Action: relayed Status: 2.0.0
オリジナル・受信者：RFC822; Dana@Ivory.EDU最終受信者：RFC822; Dana@Ivory.EDUアクション：中継状況：2.0.0
--cdefg Content-type: message/rfc822
--cdefgコンテンツタイプ：メッセージ/ RFC822
(headers of returned message go here)
（返されたメッセージのヘッダがここに入ります）
--cdefg--
--cdefg--
The message originally addressed to George@Tax-ME.GOV was forwarded to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to deliver the message due to a lack of disk space in Sam's mailbox. After trying for several days, Boondoggle.GOV returned the following DSN:
もともとはGeorge@Tax-ME.GOV宛のメッセージが原因サムのメールボックスでディスク容量の不足にSam@Boondoggle.GOVに転送さが、Boondoggle.GOVのためのMTAは、メッセージを配信することができませんでしたました。数日間試した後、Boondoggle.GOVは、以下のDSNを返しました：
To: Alice@Example.ORG From: Postmaster@Boondoggle.GOV Subject: Delivery failure for Sam@Boondoggle.GOV Content-Type: multipart/report; report-type=delivery-status; boundary=defgh MIME-Version: 1.0
To：Alice@Example.ORGから：Postmaster@Boondoggle.GOV件名：Sam@Boondoggle.GOVのContent-Typeの配信失敗：マルチパート/レポート。レポートタイプ=配送状況。境界= defgh MIME-バージョン：1.0
--defgh Your message, originally addressed to George@Tax-ME.GOV, and forwarded from there to Sam@Boondoggle.GOV could not be delivered, for the following reason:
もともとGeorge@Tax-ME.GOVに宛てて、以下の理由により、配信できなかったSam@Boondoggle.GOVにそこから転送され、あなたのメッセージを--defgh：
write error to mailbox, disk quota exceeded
メールボックスにエラーを書き込み、ディスククォータを超えました
--defgh Content-type: message/delivery-status
--defghコンテンツタイプ：メッセージ/配送状況
Reporting-MTA: Boondoggle.GOV Original-Envelope-ID: QQ314159
報告-MTAを：Boondoggle.GOVオリジナル-封筒-ID：QQ314159
Original-Recipient: rfc822;George@Tax-ME.GOV Final-Recipient: rfc822;Sam@Boondoggle.GOV Action: failed Status: 4.2.2 (disk quota exceeded)
オリジナル・受信者：RFC822; George@Tax-ME.GOV最終受信者：RFC822; Sam@Boondoggle.GOV処置：失敗ステータス：4.2.2（ディスククォータを超過）
--defgh Content-type: message/rfc822
--defghコンテンツタイプ：メッセージ/ RFC822
(headers of returned message go here)
（返されたメッセージのヘッダがここに入ります）
--defgh--
--defgh--
- updated author's address
- 更新著者のアドレス
- In examples, changed Pure-Heart.ORG and Big-Bucks.COM to Example.ORG and Example.COM, respectively. Since publication of RFC 1891, the former two domains have been registered.
- 実施例では、それぞれ、Example.ORGとExample.COMにPure-Heart.ORGとBig-Bucks.COMを変え。 RFC 1891の刊行ので、前者の2つのドメインが登録されています。
- Clarified that ENVID and ORCPT parameters must consist entirely of US-ASCII characters prior to encoding as xtext.
- ENVIDとORCPTパラメータがXTEXTとしてエンコードする前に、完全にUS-ASCII文字で構成しなければならないことを明らかにしました。
- A Security Considerations section was added.
- セキュリティの考慮セクションが追加されました。
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[2] Crocker, D., "Standard for the format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[2]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[3] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[3]ムーア、K.、およびG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、RFC 3464、2003年1月。
[4] Coded Character Set - 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986.
[4]コード化文字セット - 情報交換のための7ビットの米国標準コード、ANSI X3.4-1986。
[5] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[5]ヴォードルイユ、G.、RFC 3462「メールシステムの管理メッセージの報告のための複合/レポートのコンテンツタイプ」、2003年1月。
[6] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[6]ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、RFC 3463、2003年1月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[8] Westine, A. and J. Postel, "Problems with the Maintenance of Large Mailing Lists.", RFC 1211, March 1991.
[8] Westine、A.とJ.ポステル、 "大規模なメーリングリストのメンテナンスの問題。"、RFC 1211、1991年3月。
[9] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[9]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 2060、1996年12月。
[10] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[10]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[11] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[11]ブレーデン、R.、エド、 "インターネットホストのための要件 - 、アプリケーションとサポート"。、STD 3、RFC 1123、1989年10月。
Keith Moore University of Tennessee 1122 Volunteer Blvd, Suite 203 Knoxville, TN 37996-3450 USA
テネシー1122年のキース・ムーア大学ボランティアブルバード、スイート203ノックスビル、テネシー州37996から3450 USA
EMail: moore@cs.utk.edu
メールアドレス：moore@cs.utk.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。