[要約] RFC 3461は、SMTPのサービス拡張であるDSNのための仕様書であり、メールの配信状況の通知を提供することを目的としています。
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)
配信ステータス通知（DSNS）のSimple Mail転送プロトコル（SMTP）サービス拡張
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.
Copyright（c）The Internet Society（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.
このメモは、SMTPクライアントが（a）特定の条件下で生成する必要があることをSMTPクライアントが（a）提供する必要があることをSMTPクライアントが指定できるようにするため、SMTPクライアントが（b）そのような通知がコンテンツを返すべきかどうかを指定できるようにするため、SMTPクライアントが指定できるようにするため、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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].
このようなサービスを提供するために、このメモは[1]で定義されたメカニズムを使用して、SMTPプロトコルの拡張を定義します。このメカニズムを使用して、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つのオプションパラメーターがメールコマンドに追加されます。
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,
RCPTコマンドのオプションパラメーターは、ESMTP-KEYWORD「NOTIFY」を使用して（配信ステータス通知を生成する条件を指定するため）、セクション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-KEYWORD「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,
esmtp-keyword "ret"を使用して、メールコマンドのオプションパラメーター（配信障害の表示を含むDSNSがメッセージの全体の内容を返すか、メッセージヘッダーのみを返すように要求するために）は、セクション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-keyword "envid"を使用したメールコマンドのオプションパラメーター（このメッセージ伝送エンベロープの識別子を伝播するために使用されます。送信）、セクション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クライアントは、Ehloコマンドを発行してSMTPセッションを開始し、サーバーがいくつかのサービス拡張機能のいずれかをサポートするかどうかを判断する場合があります。サーバーがコード250でEhloコマンドに応答し、応答に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.
このアドレスは、RCPTコマンドで指定されたメールボックスと同じである必要はありません。たとえば、メッセージが元々a@b.cに宛てられ、後にa@d.eに転送された場合、そのような転送が行われた後、RCPTコマンドはa@d.eのメールボックスを指定します。ただし、元の受信者アドレスは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およびメールコマンドは発行されます。拡張されたRCPTおよびメールコマンドは、[1]で定義されているRCPTおよびメールコマンドと同一ですが、次のパラメーターの1つ以上が、それぞれ送信者または受信者のアドレスの後に表示されます。拡張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は、これらのパラメーターの構文を記述するために使用されますが、その文書の言語では「構造化されたフィールドボディ」ではありません。したがって、括弧内に括弧内に表示される場合がありますが、コメントデリミターとして認識されていません。
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:
[1]の「ESMTP値」の構文は、SP、「=」、コントロール文字、または1〜127小数の従来のASCII範囲外の文字を許可しません。EnvidおよびORCPTパラメーターは、この範囲外の値を伝える必要がある場合があるため、これらのパラメーターのESMTP値は「XTExt」としてエンコードされます。「Xtext」は次のように正式に定義されています。
xtext = *( xchar / hexchar )
xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, except for "+" and "=".
XChar =「！」の間のASCII char（33）および「〜」（126）は、 "" and "="を除きます。
; "hexchar"s are intended to encode octets that cannot appear ; as ASCII characters within an esmtp-value.
;「ヘキシャー」は、表示できないオクテットをエンコードすることを目的としています。ESMTP値内のASCII文字として。
hexchar = ASCII "+" immediately followed by two upper case hexadecimal digits
hexchar = ascii ""続いて2つの高級数字が続きます
When encoding an octet sequence as xtext:
Octetシーケンスを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は、実装者の裁量で「ヘキシャー」としてエンコードされる場合があります。）
+ ASCII CHARs that fall outside the range above must be encoded as "hexchar".
+ 上記の範囲の外側にあるASCII charは、「ヘキシャー」としてエンコードする必要があります。
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を生成する条件を指定するために、オプションのESMTPキーワード「Notify」を含めることができます。Notify ESMTP-KeyWordを使用する場合、RFC 822のABNFを使用して、次のルールに従ってフォーマットされた関連するESMTP値が必要です。
notify-esmtp-value = "NEVER" / 1#notify-list-element
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-List-Elementsは、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. キーワードのいずれも、成功、失敗、または遅延のいずれかが、上記の文字と小文字の任意の組み合わせで綴られることはありません。
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.
+ 「Never」の通知パラメーター値は、DSNがいかなる条件下でも送信者に返されないことを要求します。
+ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE" keywords requests that a DSN be issued on successful delivery or delivery failure, respectively.
+ 「成功」または「失敗」キーワードを含む通知パラメーター値は、それぞれ成功した配送または配信の故障時にDSNを発行することを要求します。
+ 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.
+ キーワード「遅延」を含む通知パラメーター値は、送信者が「遅延した」DSNを受け取る意欲を示します。メッセージの配信が異常な時間（メッセージが遅れているMTAによって決定される）が遅延している場合、遅延DSNSが発行される場合がありますが、最終配信ステータス（成功または失敗のかどうか）を決定できません。Notifyパラメーターに遅延キーワードがないため、「遅延」DSNはいかなる条件下でも発行されないことを要求します。
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 Facilityを使用しないSMTPクライアントとの互換性の場合、RCPTコマンドにNotifyパラメーターがないことは、notify = failsまたはnotify = fails、delayのいずれかと解釈できます。
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-KeyWordは、メッセージを配信する実際の受信者に対応する「元の」受信者アドレスを指定するために使用されます。ORCPT ESMTP-KeyWordを使用する場合、以下のルールに従ってエンコードされた元の受信者アドレスで構成される関連するESMTP値が必要です。ORCPTパラメーターのABNFは次のとおりです。
orcpt-parameter = "ORCPT=" original-recipient-address
orcpt-parameter = "orcpt =" original-recipient-address
original-recipient-address = addr-type ";" xtext
Original-Recipient-Address = addr-type ";"Xtext
addr-type = atom
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.
「addr-type」部分は、ianaが登録した電子メールアドレス型（[3]で定義）でなければなりません。一方書類。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".
Original-Recipient-Addressの「addr-type」部分は、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など）からゲートウェイされたメッセージの場合、受信者アドレスの表現は、DSNSとその環境間のゲートウェイウェイ用の仕様によって定義する必要があります。
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:
拡張メールコマンドのRet esmtp-Keywordは、このメッセージ送信のために発行された失敗したDSNにメッセージを含めるべきかどうかを指定します。ret esmtp-keywordを使用する場合、関連するESMTP値が必要です。これは次のキーワードの1つです。
FULL requests that the entire message be returned in any "failed" Delivery Status Notification issued for this recipient.
この受信者に対して発行された「失敗した」配信ステータス通知でメッセージ全体が返されることを完全にリクエストします。
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.
フルおよび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パラメーターは、少なくとも1人の受信者の配信障害を示すDSNSのみに適用されることに注意してください。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-KeyWordは、メッセージとともに送信される「エンベロープ識別子」を指定し、このSMTPトランザクションで指定された受信者のいずれかに発行されたDSNSに含まれる「エンベロープ識別子」を指定するために使用されます。エンベロープ識別子の目的は、メッセージの送信者がDSNが発行されたトランザクションを識別できるようにすることです。
The ABNF for the ENVID parameter is:
EvidパラメーターのABNFは次のとおりです。
envid-parameter = "ENVID=" xtext
envid-parameter = "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-KeyWordには、関連する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」としてエンコードする前のEvidパラメーターの値は、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パラメーターは、単一のメールコマンドにそれぞれ1回以上表示されてはなりません。これらのパラメーターのいずれかがメールコマンドに表示される場合、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コマンドに複数回表示してはなりません。これらのパラメーターのいずれかが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.
Simple Mail転送プロトコル（SMTP）は、メールトランスポートシステムにメールを送信する際に、メールを受け入れ、中継、またはゲートウェイの郵便物を受け入れ、中継、またはゲートウェイする際にメッセージ転送エージェント（MTA）によって使用されます。SMTPへのDSN拡張機能を使用して、UASがDSNSを発行する時期に関する送信者の要求を伝えることができます。この仕様に準拠すると主張する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キーワードを発行する場合、クライアントとして行動するときに「適合したSMTPクライアント」、および「適合SMTPサーバー」の場合は以下のルールに従う必要があります。サーバー。「適合MTA」という用語は、クライアントまたはサーバーの役割とは無関係に、この仕様に準拠するMTAを指します。
The following rules apply to SMTP transactions in which any of the ENVID, NOTIFY, RET, or ORCPT keywords are used:
以下のルールは、Evid、Notify、Ret、またはORCPTキーワードのいずれかが使用されるSMTPトランザクションに適用されます。
(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.
(a) SMTPクライアントが有効なEnvidパラメーターと関連するESMTP値および/または有効なRETパラメーターおよび関連するESMTP値を含むメールコマンドを発行する場合、適合するSMTPサーバーは同じメールコマンドと同じ返信コードを返す必要がありますEvidおよび/またはRETパラメーターなし。適合SMTPサーバーは、有効なEvidまたはRETパラメーターの不在または存在、または関連するESMTP値に基づいてメールコマンドを拒否してはなりません。
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").
ただし、関連するESMTP値が有効でない場合（つまり、違法な文字が含まれている場合）、または特定のメールコマンドに複数のenvidまたはRETパラメーターがある場合、サーバーは適切なメッセージでReply-Code 501を発行する必要があります（たとえば、「パラメーターの構文エラー」）。
(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.
(b) SMTPクライアントが有効なNotifyおよび/またはORCPTパラメーターを含むRCPTコマンドを発行する場合、適合したSMTPサーバーは、それらの通知および/またはORCPTパラメーターなしで同じRCPTコマンドに同じ応答を返す必要があります。適合した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".
ただし、関連するESMTP値のいずれかが有効でない場合、または特定のRCPTコマンドにこれらのパラメーターのいずれか以上がある場合、サーバーは「パラメーターの501構文エラー」という応答を発行する必要があります。
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メールコマンドからの返信アドレスがnull（ "<>"）であったメッセージに対して送信者に返送してはなりません。。ただし、そうでなければDSNを発行するMTAは、DSNの生成をもたらさない適切なメカニズムを介して、地元の郵便局長に配信障害を通知する必要があります。
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パラメーターは、同じ関連するESMTP値を使用して、メッセージが中継されるメールコマンドにも表示される必要があります。メッセージが受信されたときにevidパラメーターがメールコマンドに含まれていない場合、メッセージが中継されたときに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) メッセージが受信されたときにメールコマンドに含まれるRETパラメーターは、同じ関連するESMTP値を使用して、メッセージが中継されるメールコマンドにも表示される必要があります。メッセージが受信されたときにRETパラメーターがメールコマンドに含まれていない場合、メッセージが中継されたときに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.) 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.
(d) メッセージが受信されたときに受信者のRCPTコマンドにORCPTパラメーターが存在する場合、メッセージを中継するときにその受信者に対して発行されたRCPTコマンドに同一の元のrecipient-Addressを持つORCPTパラメーターが表示されなければなりません。（たとえば、MTAは、ORCPTパラメーターのアルファベット文字のケースを変更してはなりません。）メッセージが受信されたときにRCPTコマンドにORCPTパラメーターが存在しなかった場合、ORCPTパラメーターをRCPTコマンドに追加できます。メッセージが中継されます。MTAの中継によってORCPTパラメーターが追加されている場合、そのMTAがメッセージを受信したときに使用されるRCPTコマンドの受信者アドレスを含める必要があります。
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パラメーターがレシピエントに提供され、キーワードの成功を含む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) キーワード障害を含むESMTP値を持つ受信者にNotifyパラメーターが提供され、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.
(d) NeverのESMTP値を持つ受信者にNotifyパラメーターが提供された場合、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].
この拡張子をサポートしないSMTPサーバーにメッセージを中継しようとすると、そのメッセージの受信者にnotify =が指定されていない場合、適合しているSMTPクライアントは、別のSMTPトランザクションでそれらの受信者にメッセージを中継する場合があります。メールコマンドの空のリバースパス。これにより、[1]に準拠したMTAによってそれらの受信者に対してDSNが発行されるのを防ぎます。
(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.
(e) 受信者に通知パラメーターが提供されず、SMTPサーバーがRCPTコマンドに応じて成功（2xx）返信コードを返した場合、クライアントはその受信者に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.
(f) 受信者に通知パラメーターが提供されず、SMTPサーバーがRCPTコマンドに応じて永続的な障害（5xx）返信コードを返す場合、クライアントはその受信者に「失敗した」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 [9]、POP [10]、または同様のメッセージアクセスプロトコルを介して後で取得するためにメールボックスに送信されるメッセージの場合、メッセージがIMAP（POPなど）サービスで利用可能になったときに「配信」が発生します。メッセージが受信者のユーザーエージェントによって取得された場合よりも。
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.
(a) Successキーワードを含むESMTP値を使用して、その受信者にNotifyパラメーターが提供された場合、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.
(b) 成功キーワードが含まれていない受信者にNotifyパラメーターが提供された場合、MTAはその受信者にDSNを発行してはなりません。
(c) If the NOTIFY parameter was not supplied for that recipient, the MTA MUST NOT issue a DSN.
(c) その受信者にNotifyパラメーターが提供されていない場合、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パラメーターによって要求された条件の下で適切な通知を発行できる場合、およびこのように発行された通知がDSNに翻訳され、元の送信者に配信されることを保証できれば、MTAはゲートウェイする必要があります。外国環境へのメッセージは、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.
(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.
(c) NeverのESMTPキーワードが通知パラメーターに提供された場合、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.
(d) Notifyパラメーターが特定の受信者に提供されていない場合、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プロトコルを介してメッセージを受信し、1つ以上の受信者に長時間（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が発行される場合があります。
(b) If the NOTIFY parameter was not supplied for a recipient, a "delayed" DSN MAY be issued.
(b) 受信者にNotifyパラメーターが提供されていない場合、「遅延」DSNが発行される場合があります。
(c) If the NOTIFY parameter was supplied which did not contain the DELAY keyword, a "delayed" DSN MUST NOT be issued.
(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.
注：遅延通知は現在の電子メールでは一般的ですが、「遅延」DSNを発行するために適合MTAは決して必要ありません。Notifyパラメーターの遅延キーワードが提供され、SMTPクライアントが「遅延パラメーターを省略することにより）DSNが発行されないことを（遅延パラメーターを省略して）要求することができます。
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プロトコルを介してメッセージを受信し、SMTPトランザクションで指定された受信者にメッセージを配信できない適合MTAの動作を管理します。
(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.
(a) 値の障害を含むESMTPキーワードを受信者に通知パラメーターが提供された場合、MTAが「故障した」DSNを発行する必要があります。
(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.
(b) 値の障害が含まれていない受信者に通知パラメーターが提供された場合、その受信者にDSNを発行してはなりません。ただし、MTAは、DSNSの生成をもたらさない適切なメカニズムを介して、現地の郵便局長に配信障害を通知する場合があります。
(c) If no NOTIFY parameter was supplied for the recipient, a "failed" DSN MUST be issued.
(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は、地元の郵便局長または「デッドレター」メールボックスに配信不可能なメッセージを転送することが知られています。これは依然として配信の失敗と見なされており、このメモの他の場所で定義されている条件で「失敗した」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）の例に従って、このドキュメントは次のように「エイリアス」と「メーリングリスト」の違いを定義します。（例えば、SMTPメールからのメール）はそのままです。ただし、「メーリングリスト」に関連付けられたアドレスにメッセージを転送すると、エンベロープの返品アドレスがメーリングリストの管理者のアドレスに変更されます。これにより、リストメンバーへの配信が元のメッセージの送信者ではなく、リスト管理者に送信されるDSNSやその他の非派生レポートが発生します。
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パラメーターに成功キーワードが含まれている場合、「配信された」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の間のインターフェイスは明確に定義されていませんが、DSNはMTA（リストへの配信の成功を報告するため）とリスト（メッセージの拒否を報告するために、」の両方によって発行されないことが重要です。失敗 "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) エンベロープの返品アドレスは、リストメンテナーを指すように書き直されます。このアドレスは、DSNSを認識して自動的に処理するプロセスのアドレスである可能性がありますが、リストの責任者の人間に認識されていないメッセージを転送する必要があります。
(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) Notifyおよび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パラメーターに成功キーワードが含まれている場合、MTAは「リレーした」DSNを発行します。（実際には、MTAはメッセージをDSNSをサポートしていない環境に中継されているかのように扱います。）
(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パラメーターは、成功キーワードが削除されることを除いて、転送アドレスに伝播されます。エイリアスの元のNotifyパラメーターに成功キーワードが含まれている場合、エイリアスに対して「拡張された」DSNが発行されます。エイリアスのNotifyパラメーターに成功キーワードが含まれていない場合、エイリアスに対して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は、そのメッセージの複数の受信者にメッセージを配信する試みを説明する場合があります。上記のルールによると、SMTPトランザクションの一部の受信者に対してDSNが発行されていない場合、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.
「ローカル」ユーザー（それが意味するものは何でも）に由来するメッセージの場合、DSNSを生成する必要がある仕様は、送信者のメールコンポーザー（ユーザーエージェント）と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拡張機能を使用して、ソースメール環境で予想される配信報告条件を提供しようとする必要があります。必要に応じて、ソース環境に戻されたDSNSは、その環境で予想される形式に変換する必要があります。
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.
(b) 通知パラメーター：28文字。
(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文字より長い環境パラメーターを生成してはなりません。
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は、[1]で必要な512文字に加えて、少なくとも1036文字の長さのSMTPコマンドライン（ORCPTの530文字とRCPTコマンドのパラメーターに通知する）を受け入れることができなければなりません。他の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.
配信ステータス通知の形式は[3]で定義されており、[5]で定義されているフレームワークを使用します。配信ステータス通知は、以下に概説するように、元のメッセージの送信者に返送されます。
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.
DSN送信者アドレス（SMTPメールコマンド内）は、[11]のセクション5.3.3で要求されているように、ヌルリバースパス（ "<>"）でなければなりません。DSNレシピエントアドレス（RCPTコマンド）は、DSNが発行されているメッセージに付随するメールコマンドからコピーされます。SMTPを介してDSNを送信する場合、RETパラメーターを使用してはなりません。Notifyパラメーターは使用できますが、その値は決して必要ありません。Envidパラメーター（新しく生成されたEnvelope-IDを使用）および/または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".
マルチパート/レポートコンテンツタイプは、メールシステムによって生成されたいくつかの種類のレポートのいずれかに使用できます。MultiPart/レポートを使用してDSNを伝える場合、MultiPart/レポートコンテンツタイプのレポート型パラメーターは「配信ステータス」です。
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の場合、MultiPart/レポートの2番目のコンポーネントは、コンテンツタイプのメッセージ/配信ステータス（[3]で定義）です。MultiPart/レポートの3番目のコンポーネントは、元のメッセージまたはその一部で構成されています。RETパラメーターの値がいっぱいの場合、配信の障害の通知を伝えるDSNに対して完全なメッセージを返す必要があります。（ただし、メッセージの長さが実装指定の長さよりも大きい場合、MTAはRETパラメーターが完全に指定されている場合でもヘッダーのみを返すことができます。）DSNに配信障害の通知が含まれていない場合、MTAはMTAのみを返す必要があります。ヘッダー。
The third component must have an appropriate content-type label. Issues concerning selection of the content-type are discussed in [5].
3番目のコンポーネントには、適切なコンテンツタイプのラベルが必要です。コンテンツタイプの選択に関する問題は、[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プロトコルによって受信されたメッセージに応じて生成されたDSNSの次の要件は、メッセージ/配信ステータスタイプの[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パラメーターが存在する場合、元のエンベロープ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.
EnvidパラメーターはXtextとしてエンコードされているが、元のエンベロープIDヘッダーはXTExtとしてエンコードされていないため、MTAはenvid値を元のエンベロープIDフィールドにコピーするときにXTEXTエンコードをデコードする必要があります。
(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) Reporting-MTAフィールドを提供する必要があります。報告MTAが完全に資格のあるインターネットドメイン名を決定できる場合、MTA-Nameタイプのサブフィールドは「DNS」でなければならず、フィールドには報告MTAの完全に資格のあるドメイン名が含まれている必要があります。報告MTAの完全に資格のあるインターネットドメイン名が不明な場合（たとえば、インターネットに直接接続されていないSMTPサーバーの場合）、レポートMTAフィールドには、MTAを識別する文字列が含まれている場合があります。ケースMTA-Nameタイプのサブフィールドは「DNS」であってはなりません。「X-Local-HostName」のMTA-Nameタイプのサブフィールド値が提案されています。
(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.
(d) この受信者にORCPTパラメーターが提供された場合、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) [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人以上の受信者にメッセージを中継しようとする試みに起因するDSNSの場合、それらの各受信者にリモートMTAフィールドを提供する必要があります。これらのリモートMTAフィールドのMTA-Nameタイプのサブフィールドは「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.
(i) SMTPを介して1人以上の受信者にメッセージを中継しようとする試みに起因するDSNSの場合、それらの各受信者に診断コードを提供する必要があります。診断タイプのサブフィールドは「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人以上の受信者にメッセージを中継する試みに起因するDSNSの場合、各受信者にSMTP-Remote-Recipient拡張フィールドに提供される場合があります。
(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.
著者は、エリック・オールマン、ハラルド・アルベスランド、ジム・コンクリン、ブライアン・コスタレス、ピーター・カウエン、デイブ・クロッカー、ロジャー・ファイマン、ネッド・フリード、マルコ・カイトラ、スティーブ・キル、ジョン・クレンシン、アナスタシオス・コッツコナス、ジョン・ガーディナー・マイヤーズ、ジョン・ガーディナー・オニオン、ジャコブ・パーマーの感謝に感謝します。、Marshall Rose、Greg Vaudreuil、およびKlaus Weideは、この文書の改善のための提案について。
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.
[5]のセキュリティに関する考慮事項セクションでは、マルチパート/レポートオブジェクトに関連するセキュリティ問題について説明し、[3]のセキュリティに関する考慮事項セクションでは、特にDSNSのセキュリティ問題について説明します。
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」アドレスタイプは、元のレシピエントおよび最終的なRECIPIENT 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
RFC822メールボックスアドレスは一般にフォームになると予想されます
[route] addr-spec
[ルート] addr-spec
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-spec」が[2]で定義され、「ルート」と「addr-spec」の両方の「ドメイン」部分は、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 Repertoireのグラフィック文字で完全に構成されていない場合、DSN Original-RecipientまたはFinal-Recipient DSNフィールドのグラフィックUS-ASCII文字としてエンコードされる方法の仕様。
RFC822 addresses consist entirely of graphic characters from the US-ASCII repertoire, so no translation is necessary.
RFC822アドレスは、完全にUS-ASCIIレパートリーのグラフィック文字で構成されているため、翻訳は必要ありません。
The "smtp" diagnostic-type is to be used when reporting SMTP reply-codes in Diagnostic-Code DSN fields.
「SMTP」診断タイプは、診断コードDSNフィールドでSMTP Reply-Codeを報告するときに使用します。
(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
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
550-mailboxは利用できません550ユーザーが転送アドレスなしで移動しました
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
診断コード：SMTP;550-mailboxは利用できません550ユーザーが転送アドレスなしで移動しました
(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.
SMTP応答コードは現在、[1]および[11]で定義されています。追加のコードは、他のRFCによって定義される場合があります。
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-Name-Typeは、Reporting-MTAフィールドで使用する必要があります。タイプ「DNS」のMTA-Nameは、完全に資格のあるドメイン名です。名前はDNSに登録する必要があり、アドレスpostmaster@{mta-name}が有効でなければなりません。
(a) MTA-name-type name: dns
(a) mta-name-type名：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:
タイプ「DNS」のMTA名は、有効なインターネットドメイン名である必要があります。このようなドメイン名が利用できない場合、インターネットプロトコルアドレスを含むドメインリテラルは受け入れられます。このようなドメイン名は、一般に次の構文に準拠しています。
domain = real-domain / domain-literal
real-domain = sub-domain *("." sub-domain)
sub-domain = atom
domain-literal = "[" 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.
タイプ「DNS」のMTA名は完全にグラフィックUS-ASCII文字で構成されているため、翻訳は必要ありません。
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.
この例では、複数の受信者にアドレス指定された単一のメッセージのフローを追跡します。メッセージは、alice@example.orgからbob@example.com、carol@vory.edu、dana@vory.edu、eric@bombs.af.mil、fred@bombs.af.mil、およびgeorge@tax-に送信されます。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文字を超えるラインが長くないことが必要です。したがって、次の例では、72文字を超える長いSMTPコマンドが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
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は、たとえば.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
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は、メッセージをivory.eduにリレーします。これは（たまたま）SMTPメールを受け入れ、DSN拡張機能をサポートするLANベースのメールシステムへのゲートウェイです。
<<< 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
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のメールを受け入れることを拒否し、送信者が指定した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へのメッセージをリレーします。送信者はnotify = reciseient fred@bombs.af.milに対してNeverを指定したため、smtp at embler.orgは、<>の逆パスで別のトランザクションでその受信者のメッセージを送信することを選択します。
<<< 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
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
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にメッセージを正常に配信します。送信者がnotify = successを指定したため、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
--abcde
Content-type: text/plain; charset=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
Reporting-MTA：DNS;mail.example.com Original-Envelope-ID：QQ314159
Original-Recipient: rfc822;Bob@Example.COM
Final-Recipient: rfc822;Bob@Example.COM
Action: delivered
Status: 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の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
--bcdef
Content-type: text/plain; charset=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
--bcdef Content-type: message/delivery-status
-BCDEFコンテンツタイプ：メッセージ/配信ステータス
Reporting-MTA: dns; Example.ORG Original-Envelope-ID: QQ314159
Reporting-MTA：DNS;example.org Original-Envelope-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
--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:
Mail Gateway 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
--cdefg
Content-type: text/plain; charset=us-ascii
Your message (addressed to Dana@Ivory.EDU) was successfully relayed to:
あなたのメッセージ（dana@ivory.eduに宛てられた）は、次のことに成功しました。
ymail!Dana
ymail！dana
by the FooMail gateway at Ivory.EDU.
Ivory.eduのFoomail Gatewayによって。
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への配達がない限り、Danaが失敗しない限り、これは送信された唯一の配信ステータス通知になります。
--cdefg Content-type: message/delivery-status
-CDEFGコンテンツタイプ：メッセージ/配信ステータス
Reporting-MTA: dns; Ivory.EDU Original-Envelope-ID: QQ314159
Reporting-MTA：DNS;Ivory.edu original-envelope-id：qq314159
Original-Recipient: rfc822;Dana@Ivory.EDU
Final-Recipient: rfc822;Dana@Ivory.EDU
Action: relayed
Status: 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に転送されましたが、boodoggle.govのMTAは、SAMのメールボックスにディスクスペースがないためにメッセージを配信できませんでした。数日間試した後、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
--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:
-defghあなたのメッセージは、もともとgeorge@tax-me.govに宛てられ、そこからsam@boondoggle.govに転送されました。
write error to mailbox, disk quota exceeded
メールボックスにエラーを書き込み、ディスククォータを超えました
--defgh Content-type: message/delivery-status
-DEFGHコンテンツタイプ：メッセージ/配信ステータス
Reporting-MTA: Boondoggle.GOV Original-Envelope-ID: QQ314159
Reporting-Mta：BOONDOGGLE.GOV ORIGINAL-ENVELOPE-ID：QQ314159
Original-Recipient: rfc822;George@Tax-ME.GOV
Final-Recipient: rfc822;Sam@Boondoggle.GOV
Action: failed
Status: 4.2.2 (disk quota exceeded)
--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.
- たとえば、Pure-heart.orgとBig-bucks.comをそれぞれexample.orgとExample.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としてエンコードする前に、完全に米国ASCII文字で構成されなければならないことを明らかにしました。
- A Security Considerations section was added.
- セキュリティ上の考慮事項セクションが追加されました。
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1] Postel、J。、「Simple Mail Transfer Protocol」、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] Crocker、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] Moore、K。、およびG. Vaudreuil、「配信ステータス通知のための拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[4] Coded Character Set - 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986.
[4] コード化された文字セット-ANSI X3.4-1986の情報インターチェンジのための7ビットアメリカ標準コード。
[5] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[5] Vaudreuil、G。、「メールシステム管理メッセージのレポートのマルチパート/レポートコンテンツタイプ」、RFC 3462、2003年1月。
[6] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[6] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、2003年1月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[8] Westine, A. and J. Postel, "Problems with the Maintenance of Large Mailing Lists.", RFC 1211, March 1991.
[8] Westine、A。およびJ. Postel、「大規模なメーリングリストのメンテナンスに関する問題」、RFC 1211、1991年3月。
[9] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[9] Crispin、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 2060、1996年12月。
[10] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[10] Myers、J。およびM. Rose、「郵便局プロトコル - バージョン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] Braden、R.、ed。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
Keith Moore University of Tennessee 1122 Volunteer Blvd, Suite 203 Knoxville, TN 37996-3450 USA
キースムーア大学テネシー大学1122ボランティアBlvd、スイート203ノックスビル、テネシー州37996-3450 USA
EMail: moore@cs.utk.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。