[要約] RFC 3464は、配信状態通知のための拡張可能なメッセージ形式を定義しています。このRFCの目的は、電子メールの配信状態を通知するための標準化された形式を提供することです。

Network Working Group                                           K. Moore
Request for Comments: 3464                       University of Tennessee
Obsoletes: 1894                                             G. Vaudreuil
Category: Standards Track                            Lucent Technologies
                                                            January 2003
        

An Extensible Message Format for Delivery Status Notifications

配信ステータス通知の拡張可能なメッセージ形式

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 a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail.

このメモは、メッセージ転送エージェント(MTA)または電子メールゲートウェイが使用できる多目的インターネットメールエクステンション(MIME)コンテンツタイプを定義して、1人以上の受信者にメッセージを配信しようとする結果を報告します。このコンテンツタイプは、インターネット電子メールで現在使用されているさまざまな種類の配信ステータス通知の機械加工可能な交換として意図されています。

Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network (LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail.

インターネットと他のメッセージングシステム(X.400やいわゆる「ローカルエリアネットワーク(LAN)ベースの「システムなど)の間で多くのメッセージが送信されるため、配信ステータス通知(DSN)プロトコルは、有用であるように設計されています。マルチプロトコルメッセージング環境。この目的のために、このメモで説明されているプロトコルは、インターネットメールで通常使用されるものに加えて、「外国」アドレスとエラーコードのキャリッジを提供します。インターネットメールを介した外国通知の「トンネル」をサポートするために、追加の属性を定義することもできます。

Table of Contents

目次

   1. Introduction ....................................................3
     1.1 Purposes .....................................................3
     1.2 Requirements .................................................4
     1.3 Terminology ..................................................5
   2. Format of a Delivery Status Notification ........................7
     2.1 The message/delivery-status content-type .....................9
      2.1.1 General conventions for DSN fields ........................9
      2.1.2 "*-type" sub-fields .......................................9
      2.1.3 Lexical tokens imported from RFC 822 .....................10
     2.2 Per-Message DSN Fields ......................................11
      2.2.1 The Original-Envelope-Id field ...........................11
      2.2.2 The Reporting-MTA DSN field ..............................12
      2.2.3 The DSN-Gateway field ....................................13
      2.2.4 The Received-From-MTA DSN field ..........................14
      2.2.5 The Arrival-Date DSN field ...............................14
     2.3 Per-Recipient DSN fields ....................................14
      2.3.1 Original-Recipient field .................................15
      2.3.2 Final-Recipient field ....................................15
      2.3.3 Action field .............................................16
      2.3.4 Status field .............................................18
      2.3.5 Remote-MTA field .........................................19
      2.3.6 Diagnostic-Code field ....................................19
      2.3.7 Last-Attempt-Date field ..................................20
      2.3.8 final-log-id field .......................................20
      2.3.9 Will-Retry-Until field ...................................20
     2.4 Extension fields ............................................21
   3. Conformance and Usage Requirements .............................22
   4. Security Considerations ........................................23
     4.1 Forgery .....................................................23
     4.2 Confidentiality .............................................23
     4.3 Non-Repudiation .............................................25
   5. References .....................................................25
   6. Acknowledgments ................................................26
   Appendix A - Collected Grammar ....................................27
   Appendix B - Guidelines for Gatewaying DSNS .......................29
     Gatewaying from other mail systems to DSNs ......................29
     Gatewaying from DSNs to other mail systems ......................30
   Appendix C - Guidelines for Use of DSNS By Mailing List Exploders .30
   Appendix D - IANA Registration Forms for DSN Types ................31
     IANA registration form for address-type .........................32
     IANA registration form for diagnostic-type ......................32
     IANA registration form for MTA-name-type ........................32
   Appendix E - Examples .............................................33
     Simple DSN ......................................................34
     Multi-Recipient DSN .............................................35
     DSN from gateway to foreign system ..............................36
        Delayed DSN .....................................................37
   Appendix F - Changes from RFC 1894 ................................38
   Authors' Addresses ................................................39
   Full Copyright Statement ..........................................40
        
1. Introduction
1. はじめに

This memo defines a Multipurpose Internet Mail Extensions (MIME) [MIME1] content-type for Delivery Status Notifications (DSNs). A DSN can be used to notify the sender of a message of any of several conditions: failed delivery, delayed delivery, successful delivery, or the gatewaying of a message into an environment that may not support DSNs. The "message/delivery-status" content-type defined herein is intended for use within the framework of the "multipart/report" content type defined in [REPORT].

このメモは、配信ステータス通知(DSNS)の多目的インターネットメールエクステンション(MIME)[MIME1]コンテンツタイプを定義します。DSNを使用して、送信の失敗、配達の遅延、配信の成功、またはDSNSをサポートしない可能性のある環境へのメッセージのゲートウェイなど、いくつかの条件のいずれかのメッセージを送信者に通知することができます。本明細書で定義されている「メッセージ/配信ステータス」コンテンツタイプは、[レポート]で定義されている「マルチパート/レポート」コンテンツタイプのフレームワーク内で使用することを目的としています。

This memo defines only the format of the notifications. An extension to the Simple Message Transfer Protocol (SMTP) [SMTP] to fully support such notifications is the subject of a separate memo [DRPT].

このメモは、通知の形式のみを定義します。このような通知を完全にサポートするための単純なメッセージ転送プロトコル(SMTP)[SMTP]の拡張は、個別のメモ[DRPT]の対象です。

Document Conventions

文書規則

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 [RFC2119].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。

1.1 Purposes
1.1 目的

The DSNs defined in this memo are expected to serve several purposes:

このメモで定義されているDSNSは、いくつかの目的を果たすことが期待されています。

(a) Inform human beings of the status of message delivery processing, as well as the reasons for any delivery problems or outright failures, in a manner that is largely independent of human language and media;

(a) 人間の言語やメディアから大きく独立した方法で、メッセージ配信処理の状態と、配信の問題や完全な失敗の理由を人間に知らせます。

(b) Allow mail user agents to keep track of the delivery status of messages sent, by associating returned DSNs with earlier message transmissions;

(b) 返されたDSNSを以前のメッセージ送信に関連付けることにより、メールユーザーエージェントが送信されたメッセージの配信ステータスを追跡できるようにします。

(c) Allow mailing list exploders to automatically maintain their subscriber lists when delivery attempts repeatedly fail;

(c) 配達の試行が繰り返し失敗したときに、メーリングリストの爆発者がサブスクライバーリストを自動的に維持できるようにします。

(d) Convey delivery and non-delivery notifications resulting from attempts to deliver messages to "foreign" mail systems via a gateway;

(d) ゲートウェイを介して「外国」メールシステムにメッセージを配信しようとする試みに起因する配送と非配信通知を伝えます。

(e) Allow "foreign" notifications to be tunneled through a MIME-capable message system and back into the original messaging system that issued the original notification, or even to a third messaging system;

(e) 「外国の」通知をMIME対応のメッセージシステムからトンネル化し、元の通知を発行した元のメッセージングシステムに戻るか、3番目のメッセージングシステムに戻すことができます。

(f) Allow language-independent and medium-independent, yet reasonably precise, indications of the reason for the failure of a message to be delivered; and

(f) 言語に依存し、中依存性に依存しないが、合理的に正確に、メッセージが配信されない理由の兆候を許可します。そして

(g) Provide sufficient information to remote MTA maintainers (via "trouble tickets") so that they can understand the nature of reported errors. This feature is used in the case that failure to deliver a message is due to the malfunction of a remote MTA and the sender wants to report the problem to the remote MTA administrator.

(g) 報告されたエラーの性質を理解できるように、リモートMTAメンテナーに十分な情報を(「トラブルチケット」を介して)提供します。この機能は、メッセージの配信に失敗している場合がリモートMTAの誤動作によるものであり、送信者が問題をリモートMTA管理者に報告することを望んでいる場合に使用されます。

1.2 Requirements
1.2 要件

These purposes place the following constraints on the notification protocol:

これらの目的は、通知プロトコルに次の制約を課します。

(a) It must be readable by humans as well as being machine-parsable.

(a) それは人間が読むことができ、機械加工可能である必要があります。

(b) It must provide enough information to allow message senders (or the user agents) to unambiguously associate a DSN with the message that was sent and the original recipient address for which the DSN is issued (if such information is available), even if the message was forwarded to another recipient address.

(b) メッセージ送信者(またはユーザーエージェント)がDSNを送信されたメッセージと、DSNが発行された元の受信者アドレス(そのような情報が利用可能な場合)を明確に関連付けるのに十分な情報を提供する必要があります。別の受信者アドレスに転送されます。

(c) It must be able to preserve the reason for the success or failure of a delivery attempt in a remote messaging system, using the "language" (mailbox addresses and status codes) of that remote system.

(c) そのリモートシステムの「言語」(メールボックスアドレスとステータスコード)を使用して、リモートメッセージングシステムでの配信試行の成功または失敗の理由を維持できる必要があります。

(d) It must also be able to describe the reason for the success or failure of a delivery attempt, independent of any particular human language or of the "language" of any particular mail system.

(d) また、特定の人間の言語または特定のメールシステムの「言語」とは無関係に、配達の試みの成功または失敗の理由を説明できる必要があります。

(e) It must preserve enough information to allow the maintainer of a remote MTA to understand (and if possible, reproduce) the conditions that caused a delivery failure at that MTA.

(e) リモートMTAのメンテナーがそのMTAで送達障害を引き起こした条件を理解する(可能であれば再現する)ことができるように十分な情報を保存する必要があります。

(f) For any notifications issued by foreign mail systems, which are translated by a mail gateway to the DSN format, the DSN must preserve the "type" of the foreign addresses and error codes, so that these may be correctly interpreted by gateways.

(f) DSN形式へのメールゲートウェイによって翻訳される外国の郵便システムによって発行された通知の場合、DSNは外国の住所とエラーコードの「タイプ」を保持する必要があります。

A DSN contains a set of per-message fields that identify the message and the transaction during which the message was submitted, along with other fields that apply to all delivery attempts described by the DSN. The DSN also includes a set of per-recipient fields to convey the result of the attempt to deliver the message to each of one or more recipients.

DSNには、DSNによって記述されたすべての配信試行に適用される他のフィールドとともに、メッセージとメッセージが送信されたトランザクションを識別するメッセージごとのフィールドのセットが含まれています。DSNには、1人以上の受信者のそれぞれにメッセージを配信しようとする試みの結果を伝えるために、一連のレシピエントフィールドも含まれています。

1.3 Terminology
1.3 用語

A message may be transmitted through several message transfer agents (MTAs) on its way to a recipient. For a variety of reasons, recipient addresses may be rewritten during this process, so each MTA may potentially see a different recipient address. Depending on the purpose for which a DSN is used, different formats of a particular recipient address will be needed.

メッセージは、受信者への途中でいくつかのメッセージ転送エージェント(MTA)を介して送信される場合があります。さまざまな理由で、このプロセス中に受信者のアドレスが書き直される可能性があるため、各MTAは異なる受信者アドレスが表示される可能性があります。DSNを使用する目的に応じて、特定の受信者アドレスの異なる形式が必要になります。

Several DSN fields are defined in terms of the view from a particular MTA in the transmission. The MTAs are assigned the following names:

いくつかのDSNフィールドは、伝送内の特定のMTAからのビューの観点から定義されています。MTAには次の名前が割り当てられます。

(a) Original MTA

(a) オリジナルMTA

The Original MTA is the one to which the message is submitted for delivery by the sender of the message.

元のMTAは、メッセージの送信者から配信のためにメッセージが送信されるものです。

(b) Reporting MTA

(b) 報告MTA

For any DSN, the Reporting MTA is the one which is reporting the results of delivery attempts described in the DSN.

任意のDSNの場合、報告MTAは、DSNで説明されている配信試行の結果を報告しているものです。

If the delivery attempts described occurred in a "foreign" (non-Internet) mail system, and the DSN was produced by translating the foreign notice into DSN format, the Reporting MTA will still identify the "foreign" MTA where the delivery attempts occurred.

記述された配送の試みが「外国」(非インターネット)メールシステムで発生し、DSNが外国通知をDSN形式に翻訳することによって生成された場合、報告MTAは引き続き配信の試みが発生した「外国」MTAを特定します。

(c) Received-From MTA

(c) MTAから受信

The Received-From MTA is the MTA from which the Reporting MTA received the message, and accepted responsibility for delivery of the message.

受信したMTAは、報告MTAがメッセージを受け取ったMTAであり、メッセージの配信の責任を受け入れました。

(d) Remote MTA

(d) リモートMTA

If an MTA determines that it must relay a message to one or more recipients, but the message cannot be transferred to its "next hop" MTA, or if the "next hop" MTA refuses to accept responsibility for delivery of the message to one or more of its intended recipients, the relaying MTA may need to issue a DSN on behalf of the recipients for whom the message cannot be delivered. In this case the relaying MTA is the Reporting MTA, and the "next hop" MTA is known as the Remote MTA.

MTAがメッセージを1人以上の受信者に中継する必要があると判断したが、メッセージを「次のホップ」MTAに転送することはできません。意図された受信者の詳細は、メッセージを配信できない受信者に代わってDSNを発行する必要がある場合があります。この場合、中継MTAは報告MTAであり、「次のホップ」MTAはリモートMTAとして知られています。

Figure 1 illustrates the relationship between the various MTAs.

図1は、さまざまなMTA間の関係を示しています。

+-----+    +--------+           +---------+    +---------+      +------+
|     |    |        |           |Received-|    |         |      |      |
|     | => |Original| => ... => |  From   | => |Reporting| ===> |Remote|
| user|    |   MTA  |           |   MTA   |    |   MTA   | <No! |  MTA |
|agent|    +--------+           +---------+    +----v----+      +------+
|     |                                             |
|     | <-------------------------------------------+
+-----+      (DSN returned to sender by Reporting MTA)
        

Figure 1. Original, Received-From, Reporting and Remote MTAs

図1.オリジナル、受信、レポート、リモートMTA

Each of these MTAs may provide information that is useful in a DSN:

これらの各MTAは、DSNで役立つ情報を提供する場合があります。

+ Ideally, the DSN will contain the address of each recipient as originally specified to the Original MTA by the sender of the message.

+ 理想的には、DSNには、メッセージの送信者によって元のMTAに当初指定された各受信者のアドレスが含まれます。

This version of the address is needed (rather than a forwarding address or some modified version of the original address) so that the sender may compare the recipient address in the DSN with the address in the sender's records (e.g., an address book for an individual, the list of subscribers for a mailing list) and take appropriate action.

送信者がDSNの受信者アドレスを送信者の記録のアドレスと比較できるように、アドレスのこのバージョンが(転送アドレスまたは元のアドレスの変更されたバージョンではなく)必要です(例:個人のアドレス帳、メーリングリストの購読者のリスト)と適切なアクションを実行します。

Similarly, the DSN might contain an "envelope identifier" that was known to both the sender's user agent and the Original MTA at the time of message submission, and which, if included in the DSN, can be used by the sender to keep track of which messages were or were not delivered.

同様に、DSNには、メッセージの提出時に送信者のユーザーエージェントと元のMTAの両方に知られている「エンベロープ識別子」が含まれている場合があり、DSNに含まれる場合は、送信者が使用するために使用できます。どのメッセージが配信された、または配信されなかったか。

+ If a message was (a) forwarded to a different address than that specified by the sender, (b) gatewayed to a different mail system than that used by the sender, or (c) subjected to address rewriting during transmission, the "final" form of the recipient address (i.e., the one seen by the Reporting MTA) will be different than the original (sender-specified) recipient address. Just as the sender's user agent (or the sender) prefers the original recipient address, so the "final" address is needed when reporting a problem to the postmaster of the site where message delivery failed, because only the final recipient address will allow her to reproduce the conditions that caused the failure.

+ メッセージが(a)送信者が指定したアドレスとは異なるアドレスに転送された場合、(b)送信者が使用したものとは異なるメールシステムにゲートウェイされた場合、または(c)送信中に書き換えを行うのにさらされた場合、「最終」は「最終」です。受信者アドレスの形式(つまり、報告MTAで見られるもの)は、元の(送信者指定)受信者アドレスとは異なります。送信者のユーザーエージェント(または送信者)が元の受信者アドレスを好むように、最終的な受信者アドレスのみが彼女を許可するため、メッセージ配信が失敗したサイトのポストマスターに問題を報告するときに「最終」アドレスが必要です障害を引き起こした条件を再現します。

+ A "failed" DSN should contain the most accurate explanation for the delivery failure that is available. For ease of interpretation, this information should be a format that is independent of the mail transport system that issued the DSN. However, if a foreign error code is translated into some transport-independent format, some information may be lost. It is therefore desirable to provide both a transport-independent status code and a mechanism for reporting transport-specific codes. Depending on the circumstances that produced delivery failure, the transport-specific code might be obtained from either the Reporting MTA or the Remote MTA.

+ 「失敗した」DSNには、利用可能な配信障害の最も正確な説明が含まれている必要があります。解釈を容易にするために、この情報は、DSNを発行したメール輸送システムに依存しない形式である必要があります。ただし、外交エラーコードが輸送に依存しない形式に変換された場合、一部の情報が失われる場合があります。したがって、輸送に依存しないステータスコードと、輸送固有のコードを報告するためのメカニズムの両方を提供することが望ましいです。配信の障害を生成した状況に応じて、輸送固有のコードは、レポートMTAまたはリモートMTAから取得される場合があります。

Since different values for "recipient address" and "delivery status code" are needed according to the circumstance in which a DSN will be used, and since the MTA that issues the DSN cannot anticipate those circumstances, the DSN format described here may contain both the original and final forms of a recipient address, and both a transport-independent and a transport-specific indication of delivery status.

「受信者アドレス」と「配信ステータスコード」の異なる値がDSNを使用する状況に応じて必要であるため、DSNを発行するMTAはそれらの状況を予測できないため、ここで説明するDSN形式には両方が含まれる場合があります。受信者アドレスの元の形式と最終フォーム、および配信ステータスの輸送に依存しない、および輸送固有の兆候の両方。

Extension fields may also be added by the Reporting MTA as needed to provide additional information for use in a trouble ticket or to preserve information for tunneling of foreign delivery reports through Internet DSNs.

拡張フィールドは、必要に応じて報告MTAによって追加され、トラブルチケットで使用するための追加情報を提供したり、インターネットDSNを介した外交レポートのトンネリングのための情報を保存することもできます。

The Original, Reporting, and Remote MTAs may exist in very different environments and use dissimilar transport protocols, MTA names, address formats, and delivery status codes. DSNs therefore do not assume any particular format for mailbox addresses, MTA names, or transport-specific status codes. Instead, the various DSN fields that carry such quantities consist of a "type" sub-field followed by a sub-field whose contents are ordinary text characters, and the format of which is indicated by the "type" sub-field. This allows a DSN to convey these quantities regardless of format.

オリジナル、レポート、およびリモートMTAは、非常に異なる環境に存在し、異なる輸送プロトコル、MTA名、アドレス形式、および配信ステータスコードを使用する場合があります。したがって、DSNSは、メールボックスアドレス、MTA名、または輸送固有のステータスコードの特定の形式を想定していません。代わりに、このような数量を運ぶさまざまなDSNフィールドは、「タイプ」サブフィールドで構成され、その後の内容が通常のテキスト文字であり、その形式は「タイプ」サブフィールドで示されます。これにより、DSNは形式に関係なくこれらの数量を伝えることができます。

2. Format of a Delivery Status Notification
2. 配信ステータス通知の形式

A DSN is a MIME message with a top-level content-type of multipart/report (defined in [REPORT]). When a multipart/report content is used to transmit a DSN:

DSNは、マルチパート/レポートのトップレベルのコンテンツタイプ([レポート]で定義)を備えたMIMEメッセージです。MultiPart/レポートコンテンツを使用してDSNを送信する場合:

(a) The report-type parameter of the multipart/report content is "delivery-status".

(a) マルチパート/レポートコンテンツのレポートタイプのパラメーターは「配信ステータス」です。

(b) The first component of the multipart/report contains a human-readable explanation of the DSN, as described in [REPORT].

(b) [レポート]に記載されているように、MultiPart/レポートの最初のコンポーネントには、DSNの人間が読みやすい説明が含まれています。

(c) The second component of the multipart/report is of content-type message/delivery-status, described in section 2.1 of this document.

(c) MultiPart/レポートの2番目のコンポーネントは、このドキュメントのセクション2.1で説明されているコンテンツタイプのメッセージ/配信ステータスのものです。

(d) If the original message or a portion of the message is to be returned to the sender, it appears as the third component of the multipart/report.

(d) 元のメッセージまたはメッセージの一部が送信者に返される場合、MultiPart/レポートの3番目のコンポーネントとして表示されます。

NOTE: For delivery status notifications gatewayed from foreign systems, the headers of the original message may not be available. In this case the third component of the DSN may be omitted, or it may contain "simulated" RFC 822 headers that contain equivalent information. In particular, it is very desirable to preserve the subject, date, and message-id (or equivalent) fields from the original message.

注:外部システムからゲートウェイされた配信ステータス通知の場合、元のメッセージのヘッダーが利用できない場合があります。この場合、DSNの3番目のコンポーネントが省略されるか、同等の情報を含む「シミュレートされた」RFC 822ヘッダーを含める場合があります。特に、元のメッセージから主題、日付、メッセージ(または同等の)フィールドを保存することが非常に望ましいです。

The DSN MUST be addressed (in both the message header and the transport envelope) to the return address from the transport envelope which accompanied the original message for which the DSN was generated. (For a message that arrived via SMTP, the envelope return address appears in the MAIL FROM command.)

DSNは(メッセージヘッダーとトランスポートエンベロープの両方で)、DSNが生成された元のメッセージに伴うトランスポートエンベロープからの返信アドレスに対処する必要があります。(SMTPを介して到着したメッセージの場合、Envelope Returnアドレスがコマンドからメールに表示されます。)

The From field of the message header of the DSN SHOULD contain the address of a human who is responsible for maintaining the mail system at the Reporting MTA site (e.g., Postmaster), so that a reply to the DSN will reach that person. Exception: if a DSN is translated from a foreign delivery report, and the gateway performing the translation cannot determine the appropriate address, the From field of the DSN MAY be the address of a human who is responsible for maintaining the gateway.

DSNのメッセージヘッダーのFROMフィールドには、レポートMTAサイト(ポストマスターなど)でメールシステムを維持する責任がある人間の住所を含める必要があります。これにより、DSNへの返信がその人に届きます。例外:DSNが外交レポートから翻訳され、翻訳を実行するゲートウェイが適切なアドレスを決定できない場合、DSNのフィールドは、ゲートウェイの維持を担当する人間のアドレスである可能性があります。

The envelope sender address of the DSN SHOULD be chosen to ensure that no delivery status reports will be issued in response to the DSN itself, and MUST be chosen so that DSNs will not generate mail loops. Whenever an SMTP transaction is used to send a DSN, the MAIL FROM command MUST use a NULL return address, i.e., "MAIL FROM:<>".

DSNのエンベロープ送信者アドレスを選択して、DSN自体に応じて配信ステータスレポートが発行されないようにし、DSNSがメールループを生成しないように選択する必要があります。SMTPトランザクションを使用してDSNを送信する場合はいつでも、コマンドからのメールは、null返信アドレス、つまり「from:<>」を使用する必要があります。

A particular DSN describes the delivery status for exactly one message. However, an MTA MAY report on the delivery status for several recipients of the same message in a single DSN. Due to the nature of the mail transport system (where responsibility for delivery of a message to its recipients may be split among several MTAs, and delivery to any particular recipient may be delayed), multiple DSNs may still be issued in response to a single message submission.

特定のDSNは、正確に1つのメッセージの配信ステータスを説明します。ただし、MTAは、単一のDSNで同じメッセージの複数の受信者の配信ステータスについて報告する場合があります。メール輸送システムの性質上(受信者へのメッセージの配信の責任がいくつかのMTAに分割される場合があり、特定の受信者への配信が遅れる可能性があります)。提出。

2.1 The message/delivery-status content-type
2.1 メッセージ/配信ステータスコンテンツタイプ

The message/delivery-status content-type is defined as follows:

メッセージ/配信ステータスコンテンツタイプは、次のように定義されています。

MIME type name: message MIME subtype name: delivery-status Optional parameters: none Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers. Security considerations: discussed in section 4 of this memo.

MIMEタイプ名:メッセージMIMEサブタイプ名:配信ステータスオプションパラメーター:なしエンコード考慮事項:「7ビット」エンコードで十分であり、非MIMEメールリーダーが表示するときに読みやすさを維持するために使用する必要があります。セキュリティ上の考慮事項:このメモのセクション4で説明します。

The message/delivery-status report type for use in the multipart/report is "delivery-status".

マルチパート/レポートで使用するメッセージ/配信ステータスレポートタイプは「配信ステータス」です。

The body of a message/delivery-status consists of one or more "fields" formatted according to the ABNF of RFC 822 header "fields" (see [RFC822]). The per-message fields appear first, followed by a blank line. Following the per-message fields are one or more groups of per-recipient fields. Each group of per-recipient fields is preceded by a blank line. Using the ABNF of RFC 822, the syntax of the message/delivery-status content is as follows:

メッセージ/配信ステータスの本文は、RFC 822ヘッダー「フィールド」のABNFに従ってフォーマットされた1つ以上の「フィールド」で構成されています([RFC822]を参照)。メッセージごとのフィールドが最初に表示され、その後に空白が続きます。メッセージあたりのフィールドに従うことは、レシピエントごとのフィールドの1つ以上のグループです。レシピエントごとのフィールドの各グループの前には、ブランクラインがあります。RFC 822のABNFを使用して、メッセージ/配信ステータスコンテンツの構文は次のとおりです。

delivery-status-content = per-message-fields 1* ( CRLF per-recipient-fields )

DERVILY-STATUS-CONTENT = MESSAGE-FIELDS 1*(CRLF RECIPIENT-FIELDS)

The per-message fields are described in section 2.2. The per-recipient fields are described in section 2.3.

メッセージごとのフィールドについては、セクション2.2で説明しています。レシピエントごとのフィールドについては、セクション2.3で説明します。

2.1.1 General conventions for DSN fields
2.1.1 DSNフィールドの一般規則

Since these fields are defined according to the rules of RFC 822, the same conventions for continuation lines and comments apply. Notification fields may be continued onto multiple lines by beginning each additional line with a SPACE or HTAB. Text that appears in parentheses is considered a comment and not part of the contents of that notification field. Field names are case-insensitive, so the names of notification fields may be spelled in any combination of upper and lower case letters. Comments in DSN fields may use the "encoded-word" construct defined in [MIME3].

これらのフィールドはRFC 822のルールに従って定義されているため、継続ラインとコメントの同じ規則が適用されます。通知フィールドは、スペースまたはHTABを使用して各追加ラインを開始することにより、複数の行に継続できます。括弧内に表示されるテキストはコメントと見なされ、その通知フィールドの内容の一部ではありません。フィールド名はケースに依存しないため、通知フィールドの名前は、上品および小文字の任意の組み合わせで綴られる場合があります。DSNフィールドでのコメントは、[MIME3]で定義された「エンコードされた単語」コンストラクトを使用する場合があります。

2.1.2 "*-type" sub-fields
2.1.2 「*-Type」サブフィールド

Several DSN fields consist of a "-type" sub-field, followed by a semicolon, followed by "*text". For these fields, the keyword used in the address-type, diagnostic-type, or MTA-name-type sub-field indicates the expected format of the address, status-code, or MTA-name which follows.

いくつかのDSNフィールドは、「-type」サブフィールドで構成され、その後にセミコロンが続き、その後に「*テキスト」が続きます。これらのフィールドの場合、アドレス型、診断タイプ、またはMTA-NAMEタイプのサブフィールドで使用されるキーワードは、次のアドレス、ステータスコード、またはMTA-NAMEの予想形式を示します。

The "-type" sub-fields are defined as follows:

「-type」サブフィールドは、次のように定義されます。

(a) An "address-type" specifies the format of a mailbox address. For example, Internet mail addresses use the "rfc822" address-type.

(a) 「アドレスタイプ」は、メールボックスアドレスの形式を指定します。たとえば、インターネットメールアドレスは「RFC822」アドレスタイプを使用します。

               address-type = atom
        

(b) A "diagnostic-type" specifies the format of a status code. For example, when a DSN field contains a reply code reported via the Simple Mail Transfer Protocol [SMTP], the "smtp" diagnostic-type is used.

(b) 「診断タイプ」は、ステータスコードの形式を指定します。たとえば、DSNフィールドにSimple Mail転送プロトコル[SMTP]を介して報告された返信コードが含まれている場合、「SMTP」診断タイプが使用されます。

               diagnostic-type = atom
        

(c) An "MTA-name-type" specifies the format of an MTA name. For example, for an SMTP server on an Internet host, the MTA name is the domain name of that host, and the "dns" MTA-name-type is used.

(c) 「MTA-Name-Type」は、MTA名の形式を指定します。たとえば、インターネットホストのSMTPサーバーの場合、MTA名はそのホストのドメイン名であり、「DNS」MTA-Nameタイプが使用されます。

               mta-name-type = atom
        

Values for address-type, diagnostic-type, and MTA-name-type are case-insensitive. Thus address-type values of "RFC822" and "rfc822" are equivalent.

アドレスタイプ、診断タイプ、およびMTA-NAMEタイプの値は症例感受性です。したがって、「RFC822」と「RFC822」のアドレス型値は同等です。

The Internet Assigned Numbers Authority (IANA) will maintain a registry of address-types, diagnostic-types, and MTA-name-types, along with descriptions of the meanings and acceptable values of each, or a reference to one or more specifications that provide such descriptions. (The "rfc822" address-type, "smtp" diagnostic-type, and "dns" MTA-name-type are defined in [DRPT].) Registration forms for address-type, diagnostic-type, and MTA-name-type appear in Appendix D.

インターネットに割り当てられた数字当局(IANA)は、それぞれの意味と許容値の説明、または提供する1つまたは複数の仕様への参照とともに、アドレスタイプ、診断タイプ、およびMTA-NAMEタイプのレジストリを維持します。そのような説明。(「RFC822」アドレスタイプ、「SMTP」診断タイプ、および「DNS」MTA-NAMEタイプは[DRPT]で定義されています。)アドレスタイプ、診断タイプ、およびMTA-NAMEタイプの登録フォーム付録Dに表示されます

IANA will not accept registrations for any address-type, diagnostic-type, or MTA-name-type name that begins with "X-". These type names are reserved for experimental use.

IANAは、「X-」で始まるアドレスタイプ、診断タイプ、またはMTA-NAMEタイプの名前の登録を受け入れません。これらのタイプ名は、実験用に予約されています。

2.1.3 Lexical tokens imported from RFC 822
2.1.3 RFC 822からインポートされた語彙トークン

The following lexical tokens, defined in [RFC822], are used in the ABNF grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. The date-time lexical token is defined in [HOSTREQ].

[RFC822]で定義されている次の語彙トークンは、DSNSのABNF文法で使用されています:Atom、Char、Comment、Crlf、Crlf、Digit、LF、Linear-White-Space、Space、Text。日付の語彙トークンは[Hostreq]で定義されています。

2.2 Per-Message DSN Fields
2.2 メッセージパーセージDSNフィールド

Some fields of a DSN apply to all of the delivery attempts described by that DSN. At most, these fields may appear once in any DSN. These fields are used to correlate the DSN with the original message transaction and to provide additional information which may be useful to gateways.

DSNの一部のフィールドは、そのDSNによって説明されているすべての配信試行に適用されます。せいぜい、これらのフィールドはDSNに一度表示される場合があります。これらのフィールドは、DSNを元のメッセージトランザクションと相関させ、ゲートウェイに役立つ追加情報を提供するために使用されます。

          per-message-fields =
                [ original-envelope-id-field CRLF ]
                reporting-mta-field CRLF
                [ dsn-gateway-field CRLF ]
                [ received-from-mta-field CRLF ]
                [ arrival-date-field CRLF ]
                *( extension-field CRLF )
        
2.2.1 The Original-Envelope-Id field
2.2.1 オリジナルエンベロープIDフィールド

The optional Original-Envelope-Id field contains an "envelope identifier" that uniquely identifies the transaction during which the message was submitted, and was either (a) specified by the sender and supplied to the sender's MTA, or (b) generated by the sender's MTA and made available to the sender when the message was submitted. Its purpose is to allow the sender (or her user agent) to associate the returned DSN with the specific transaction in which the message was sent.

オプションのOriginal-Envelope-IDフィールドには、メッセージが送信されたトランザクションを一意に識別する「エンベロープ識別子」が含まれており、(a)送信者によって指定され、送信者のMTAに供給されるか、(b)送信者のMTAは、メッセージが送信されたときに送信者が利用できるようにしました。その目的は、送信者(または彼女のユーザーエージェント)が返されたDSNをメッセージが送信された特定のトランザクションに関連付けることを許可することです。

If such an envelope identifier was present in the envelope that accompanied the message when it arrived at the Reporting MTA, it SHOULD be supplied in the Original-Envelope-Id field of any DSNs issued as a result of an attempt to deliver the message. Except when a DSN is issued by the sender's MTA, an MTA MUST NOT supply this field unless there is an envelope-identifier field in the envelope that accompanied this message on its arrival at the Reporting MTA.

そのような封筒識別子が、レポートMTAに到達したときにメッセージに付随するエンベロープに存在する場合、メッセージを配信しようとした結果として発行されたDSNSの元のエンベロープIDフィールドに提供する必要があります。送信者のMTAによってDSNが発行された場合を除き、MTAは、報告MTAに到着したときにこのメッセージに伴うエンベロープ識別子フィールドがエンベロープにある場合を除き、このフィールドを供給してはなりません。

The Original-Envelope-Id field is defined as follows:

元のエンベロープIDフィールドは、次のように定義されています。

           original-envelope-id-field =
                  "Original-Envelope-Id" ":" envelope-id
        
            envelope-id = *text
        

There may be at most one Original-Envelope-Id field per DSN.

DSNごとに最大で1つのオリジナルエンベロープIDフィールドがある場合があります。

The envelope-id is CASE-SENSITIVE. The DSN MUST preserve the original case and spelling of the envelope-id.

Envelope-IDはケースに敏感です。DSNは、元のケースとEnvelope-IDのスペルを保存する必要があります。

NOTE: The Original-Envelope-Id is NOT the same as the Message-Id from the message header. The Message-Id identifies the content of the message, while the Original-Envelope-Id identifies the transaction in which the message is sent.

注:Original-Envelope-IDは、メッセージヘッダーからのメッセージIDと同じではありません。Message-IDはメッセージの内容を識別し、Original-Envelope-IDはメッセージが送信されるトランザクションを識別します。

2.2.2 The Reporting-MTA DSN field
2.2.2 Reporting-MTA DSNフィールド
         reporting-mta-field =
               "Reporting-MTA" ":" mta-name-type ";" mta-name
        
          mta-name = *text
        

The Reporting-MTA field is defined as follows:

報告MTAフィールドは次のように定義されています。

A DSN describes the results of attempts to deliver, relay, or gateway a message to one or more recipients. In all cases, the Reporting-MTA is the MTA that attempted to perform the delivery, relay, or gateway operation described in the DSN. This field is required.

DSNは、1人以上の受信者にメッセージを配信、リレー、またはゲートウェイの試みの結果を説明します。すべての場合において、Reporting-MTAは、DSNで説明されている配信、リレー、またはゲートウェイ操作を実行しようとしたMTAです。この項目は必須です。

Note that if an SMTP client attempts to relay a message to an SMTP server and receives an error reply to a RCPT command, the client is responsible for generating the DSN, and the client's domain name will appear in the Reporting-MTA field. (The server's domain name will appear in the Remote-MTA field.)

SMTPクライアントがメッセージをSMTPサーバーにリレーし、RCPTコマンドへのエラー返信を受信しようとすると、クライアントはDSNの生成を担当し、クライアントのドメイン名がReporting-MTAフィールドに表示されることに注意してください。(サーバーのドメイン名は、リモートMTAフィールドに表示されます。)

Note that the Reporting-MTA is not necessarily the MTA which actually issued the DSN. For example, if an attempt to deliver a message outside of the Internet resulted in a non-delivery notification which was gatewayed back into Internet mail, the Reporting-MTA field of the resulting DSN would be that of the MTA that originally reported the delivery failure, not that of the gateway which converted the foreign notification into a DSN. See Figure 2.

Reporting-MTAは、必ずしもDSNを実際に発行したMTAではないことに注意してください。たとえば、インターネットの外部でメッセージを配信しようとすると、インターネットメールにゲートウェイされた配信のない通知が得られた場合、結果のDSNのレポートMTAフィールドは、元々送達障害を報告したMTAの報告フィールドになります。、外国の通知をDSNに変換したゲートウェイのものではありません。図2を参照してください。

 sender's environment                            recipient's environment
 ............................ ..........................................
                            : :
                        (1) : :                             (2)
   +-----+  +--------+  +--------+  +---------+  +---------+   +------+
   |     |  |        |  |        |  |Received-|  |         |   |      |
   |     |=>|Original|=>|        |->|  From   |->|Reporting|-->|Remote|
   | user|  |   MTA  |  |        |  |   MTA   |  |   MTA   |<No|  MTA |
   |agent|  +--------+  |Gateway |  +---------+  +----v----+   +------+
   |     |              |        |                    |
   |     | <============|        |<-------------------+
   +-----+              |        |(4)                (3)
                        +--------+
                            : :
 ...........................: :.........................................
        

Figure 2. DSNs in the presence of gateways

図2.ゲートウェイの存在下でのDSNS

(1) message is gatewayed into recipient's environment (2) attempt to relay message fails (3) reporting-mta (in recipient's environment) returns non-delivery notification (4) gateway translates foreign notification into a DSN

(1) メッセージは受信者の環境にゲートウェイされます(2)メッセージが失敗する(3)レポート-MTA(受信者の環境で)非配信通知を返す(4)ゲートウェイは、外国の通知をDSNに変換します

The mta-name portion of the Reporting-MTA field is formatted according to the conventions indicated by the mta-name-type sub-field. If an MTA functions as a gateway between dissimilar mail environments and thus is known by multiple names depending on the environment, the mta-name sub-field SHOULD contain the name used by the environment from which the message was accepted by the Reporting-MTA.

Reporting-MTAフィールドのMTA-Name部分は、MTA-Nameタイプのサブフィールドで示されている規則に従ってフォーマットされています。MTAが異なるメール環境間のゲートウェイとして機能し、したがって環境に応じて複数の名前で知られている場合、MTA-Nameサブフィールドには、メッセージがReporting-MTAによって受け入れられた環境で使用される名前を含める必要があります。

Because the exact spelling of an MTA name may be significant in a particular environment, MTA names are CASE-SENSITIVE.

MTA名の正確なスペルは特定の環境で重要である可能性があるため、MTA名はケースに敏感です。

2.2.3 The DSN-Gateway field
2.2.3 DSN-Gatewayフィールド

The DSN-Gateway field indicates the name of the gateway or MTA that translated a foreign (non-Internet) delivery status notification into this DSN. This field MUST appear in any DSN that was translated by a gateway from a foreign system into DSN format, and MUST NOT appear otherwise.

DSN-Gatewayフィールドは、このDSNに外国(非インターネット)配信ステータス通知を翻訳したゲートウェイまたはMTAの名前を示します。このフィールドは、外部システムからゲートウェイによってDSN形式に翻訳された任意のDSNに表示され、別の方法で表示されてはなりません。

      dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
        

For gateways into Internet mail, the MTA-name-type will normally be "dns", and the mta-name will be the Internet domain name of the gateway.

インターネットメールへのゲートウェイの場合、MTA-Nameタイプは通常「DNS」となり、MTA-Nameはゲートウェイのインターネットドメイン名になります。

2.2.4 The Received-From-MTA DSN field
2.2.4 受信したMTA DSNフィールド

The optional Received-From-MTA field indicates the name of the MTA from which the message was received.

オプションの受信-MTAフィールドは、メッセージが受信されたMTAの名前を示します。

        received-from-mta-field =
             "Received-From-MTA" ":" mta-name-type ";" mta-name
        

If the message was received from an Internet host via SMTP, the contents of the mta-name sub-field SHOULD be the Internet domain name supplied in the HELO or EHLO command, and the network address used by the SMTP client SHOULD be included as a comment enclosed in parentheses. (In this case, the MTA-name-type will be "dns".)

メッセージがSMTPを介してインターネットホストから受信された場合、MTA-Nameサブフィールドの内容は、HELOまたはEHLOコマンドで供給されるインターネットドメイン名であり、SMTPクライアントが使用するネットワークアドレスを含める必要があります。括弧で囲まれたコメント。(この場合、MTA-Nameタイプは「DNS」になります。)

The mta-name portion of the Received-From-MTA field is formatted according to the conventions indicated by the MTA-name-type sub-field.

受信したMTAフィールドのMTA-NAME部分は、MTA-Nameタイプのサブフィールドで示される規則に従ってフォーマットされます。

Since case is significant in some mail systems, the exact spelling, including case, of the MTA name SHOULD be preserved.

一部のメールシステムではケースが重要であるため、MTA名のケースを含む正確なスペルを保存する必要があります。

2.2.5 The Arrival-Date DSN field
2.2.5 到着日DSNフィールド

The optional Arrival-Date field indicates the date and time at which the message arrived at the Reporting MTA. If the Last-Attempt-Date field is also provided in a per-recipient field, this can be used to determine the interval between when the message arrived at the Reporting MTA and when the report was issued for that recipient.

オプションの到着日フィールドは、メッセージが報告MTAに到着した日付と時刻を示します。最後のアタトメントデートフィールドがレシピエントごとのフィールドにも提供されている場合、これを使用して、メッセージがレポートMTAに到着したときとその受信者に対してレポートが発行されたときの間隔を決定できます。

        arrival-date-field = "Arrival-Date" ":" date-time
        

The date and time are expressed in RFC 822 'date-time' format, as modified by [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be used.

日付と時刻は、[Hostreq]によって変更されたRFC 822「日付時刻」形式で表されます。数値タイムゾーン([ / - ] HHMM形式)を使用する必要があります。

2.3 Per-Recipient DSN fields
2.3 レシピエントDSNフィールドごと

A DSN contains information about attempts to deliver a message to one or more recipients. The delivery information for any particular recipient is contained in a group of contiguous per-recipient fields. Each group of per-recipient fields is preceded by a blank line.

DSNには、1人以上の受信者にメッセージを配信しようとする試みに関する情報が含まれています。特定の受信者の配信情報は、連続したレシピエントごとのフィールドのグループに含まれています。レシピエントごとのフィールドの各グループの前には、ブランクラインがあります。

The syntax for the group of per-recipient fields is as follows:

通気者ごとのフィールドのグループの構文は次のとおりです。

        per-recipient-fields =
              [ original-recipient-field CRLF ]
              final-recipient-field CRLF
              action-field CRLF
              status-field CRLF
              [ remote-mta-field CRLF ]
              [ diagnostic-code-field CRLF ]
              [ last-attempt-date-field CRLF ]
              [ final-log-id-field CRLF ]
              [ will-retry-until-field CRLF ]
              *( extension-field CRLF )
        
2.3.1 Original-Recipient field
2.3.1 元の相性フィールド

The Original-Recipient field indicates the original recipient address as specified by the sender of the message for which the DSN is being issued.

元のレシピエントフィールドは、DSNが発行されているメッセージの送信者によって指定された元の受信者アドレスを示します。

       original-recipient-field =
             "Original-Recipient" ":" address-type ";" generic-address
        
        generic-address = *text
        

The address-type field indicates the type of the original recipient address. If the message originated within the Internet, the address-type field will normally be "rfc822", and the address will be according to the syntax specified in [RFC822]. The value "unknown" should be used if the Reporting MTA cannot determine the type of the original recipient address from the message envelope.

アドレスタイプフィールドは、元の受信者アドレスのタイプを示します。メッセージがインターネット内で発生した場合、アドレス型フィールドは通常「RFC822」になり、アドレスは[RFC822]で指定された構文に従っています。レポートMTAがメッセージエンベロープから元の受信者アドレスのタイプを決定できない場合、値「不明」を使用する必要があります。

This field is optional. It should be included only if the sender-specified recipient address was present in the message envelope, such as by the SMTP extensions defined in [DRPT]. This address is the same as that provided by the sender and can be used to automatically correlate DSN reports and message transactions.

このフィールドはオプションです。[DRPT]で定義されているSMTP拡張機能など、送信者指定の受信者アドレスがメッセージエンベロープに存在する場合にのみ含める必要があります。このアドレスは、送信者が提供するものと同じであり、DSNレポートとメッセージトランザクションを自動的に相関させるために使用できます。

2.3.2 Final-Recipient field
2.3.2 最終的なレシピエントフィールド

The Final-Recipient field indicates the recipient for which this set of per-recipient fields applies. This field MUST be present in each set of per-recipient data.

最終的なレシピエントフィールドは、このレシピエントごとのフィールドのセットが適用される受信者を示します。このフィールドは、一人ごとのデータの各セットに存在する必要があります。

The syntax of the field is as follows:

フィールドの構文は次のとおりです。

         final-recipient-field =
             "Final-Recipient" ":" address-type ";" generic-address
        

The generic-address sub-field of the Final-Recipient field MUST contain the mailbox address of the recipient (from the transport envelope), as it was when the Reporting MTA accepted the message for delivery.

最終受信フィールドの一般的なアドレスサブフィールドには、レポートMTAが配信のメッセージを受け入れたときのように、受信者のメールボックスアドレス(輸送エンベロープから)を含める必要があります。

The Final-Recipient address may differ from the address originally provided by the sender, because it may have been transformed during forwarding and gatewaying into a totally unrecognizable mess. However, in the absence of the optional Original-Recipient field, the Final-Recipient field and any returned content may be the only information available with which to correlate the DSN with a particular message submission.

最終的なレシピエントアドレスは、送信者が元々提供されたアドレスとは異なる場合があります。これは、転送およびゲートウェイ中に完全に認識できない混乱に変換された可能性があるためです。ただし、オプションのオリジナルレシピエントフィールドがない場合、最終的なレシピエントフィールドと返されたコンテンツは、DSNを特定のメッセージ提出と相関させるための唯一の情報である場合があります。

The address-type sub-field indicates the type of address expected by the reporting MTA in that context. Recipient addresses obtained via SMTP will normally be of address-type "rfc822".

アドレスタイプのサブフィールドは、そのコンテキストで報告MTAで予想されるアドレスのタイプを示します。SMTPを介して取得されたレシピエントアドレスは、通常、アドレス型「RFC822」のものです。

NOTE: The Reporting MTA is not expected to ensure that the address actually conforms to the syntax conventions of the address-type. Instead, it MUST report exactly the address received in the envelope, unless that address contains characters such as CR or LF which are not allowed in a DSN field.

注:レポートMTAは、アドレスが実際にアドレスタイプの構文規則に適合することを保証することは期待されていません。代わりに、DSNフィールドで許可されていないCRやLFなどの文字が含まれていない限り、封筒で受信したアドレスを正確に報告する必要があります。

Since mailbox addresses (including those used in the Internet) may be case sensitive, the case of alphabetic characters in the address MUST be preserved.

メールボックスアドレス(インターネットで使用されるものを含む)はケースに敏感な場合があるため、アドレス内のアルファベット文字の場合は保存する必要があります。

2.3.3 Action field
2.3.3 アクションフィールド

The Action field indicates the action performed by the Reporting-MTA as a result of its attempt to deliver the message to this recipient address. This field MUST be present for each recipient named in the DSN.

アクションフィールドは、この受信者アドレスにメッセージを配信しようとする試みの結果として、Reporting-MTAによって実行されたアクションを示します。このフィールドは、DSNに名前が付けられた各受信者に存在する必要があります。

The syntax for the action-field is:

アクションフィールドの構文は次のとおりです。

      action-field = "Action" ":" action-value
        
      action-value =
            "failed" / "delayed" / "delivered" / "relayed" / "expanded"
        

The action-value may be spelled in any combination of upper and lower case characters.

アクション値は、上品な文字と小文字の任意の組み合わせで綴られます。

"failed" indicates that the message could not be delivered to the recipient. The Reporting MTA has abandoned any attempts to deliver the message to this recipient. No further notifications should be expected.

「失敗」は、メッセージを受信者に配信できなかったことを示します。報告MTAは、この受信者にメッセージを配信する試みを放棄しました。これ以上の通知は予想してはなりません。

"delayed" indicates that the Reporting MTA has so far been unable to deliver or relay the message, but it will continue to attempt to do so. Additional notification messages may be issued as the message is further delayed or successfully delivered, or if delivery attempts are later abandoned.

「遅延」は、報告MTAがこれまでメッセージを配信または中継することができなかったことを示していますが、それは引き続きそうしようとします。追加の通知メッセージは、メッセージがさらに遅延または正常に配信されるか、配信の試行が後で放棄された場合に発行される場合があります。

"delivered" indicates that the message was successfully delivered to the recipient address specified by the sender, which includes "delivery" to a mailing list exploder. It does not indicate that the message has been read. This is a terminal state and no further DSN for this recipient should be expected.

「配信」は、メッセージが送信者によって指定された受信者アドレスに正常に配信されたことを示しています。メッセージが読まれたことを示していません。これは末端状態であり、このレシピエントのDSNそれ以上のDSNは予想される必要はありません。

"relayed" indicates that the message has been relayed or gatewayed into an environment that does not accept responsibility for generating DSNs upon successful delivery. This action-value SHOULD NOT be used unless the sender has requested notification of successful delivery for this recipient.

「中継」は、メッセージがリレーされているか、配信が成功したときにDSNSを生成する責任を受け入れない環境にリレーまたはゲートウェイが付けられていることを示しています。このアクション値は、送信者がこの受信者の配信の成功の通知を要求しない限り、使用しないでください。

"expanded" indicates that the message has been successfully delivered to the recipient address as specified by the sender, and forwarded by the Reporting-MTA beyond that destination to multiple additional recipient addresses. An action-value of "expanded" differs from "delivered" in that "expanded" is not a terminal state. Further "failed" and/or "delayed" notifications may be provided.

「拡張」は、送信者が指定したようにメッセージが受信者アドレスに正常に配信され、その目的地を越えてReporting-MTAによって複数の追加の受信者アドレスに転送されたことを示しています。「拡張された」という「拡張」のアクション値は、「拡張された」という点で「配信」とは異なります。これは端子状態ではありません。さらに「失敗」および/または「遅延」通知が提供される場合があります。

Using the terms "mailing list" and "alias" as defined in [DRPT], section 7.2.7: An action-value of "expanded" is only to be used when the message is delivered to a multiple-recipient "alias". An action-value of "expanded" SHOULD NOT be used with a DSN issued on delivery of a message to a "mailing list".

[drpt]で定義されている「メーリングリスト」と「エイリアス」という用語を使用して、セクション7.2.7:「拡張」のアクション値は、メッセージが多級の「エイリアス」に配信される場合にのみ使用されます。「拡張」のアクション値は、「メーリングリスト」へのメッセージの配信時に発行されたDSNで使用しないでください。

NOTE ON ACTION VS. STATUS CODES: Although the 'action' field might seem to be redundant with the 'status' field, this is not the case. In particular, a "temporary failure" ("4") status code could be used with an action-value of either "delayed" or "failed". For example, assume that an SMTP client repeatedly tries to relay a message to the mail exchanger for a recipient, but fails because a query to a domain name server timed out.

アクションVsに関するメモステータスコード:「アクション」フィールドは「ステータス」フィールドで冗長であるように見えるかもしれませんが、そうではありません。特に、「一時的な障害」(「4」)ステータスコードは、「遅延」または「失敗」のいずれかのアクション値で使用できます。たとえば、SMTPクライアントが受信者のメール交換機にメッセージをリレーしようと繰り返し試みますが、ドメイン名サーバーへのクエリがタイミングを出したために失敗します。

After a few hours, it might issue a "delayed" DSN to inform the sender that the message had not yet been delivered. After a few days, the MTA might abandon its attempt to deliver the message and return a "failed" DSN. The status code (which would begin with a "4" to indicate "temporary failure") would be the same for both DSNs.

数時間後、「遅延」DSNを発行して、メッセージがまだ配信されていないことを送信者に通知する可能性があります。数日後、MTAはメッセージを配信しようとする試みを放棄し、「失敗した」DSNを返します。ステータスコード(「一時的な障害」を示すために「4」で始まります)は、両方のDSNで同じです。

Another example for which the action and status codes may appear contradictory: If an MTA or mail gateway cannot deliver a message because doing so would entail conversions resulting in an unacceptable loss of information, it would issue a DSN with the 'action' field of "failure" and a status code of 'XXX'. If the message had instead been relayed, but with some loss of information, it might generate a DSN with the same XXX status-code, but with an action field of "relayed".

アクションコードとステータスコードが矛盾していると思われる別の例:MTAまたはメールゲートウェイがメッセージを配信できない場合、それを行うと情報の容認できない損失が発生するため、「アクション」フィールドでDSNを発行します。失敗」および「xxx」のステータスコード。メッセージが代わりにリレーされていたが、情報がある程度の損失がある場合、同じXXXステータスコードでDSNが生成される可能性がありますが、「リレー」のアクションフィールドがあります。

2.3.4 Status field
2.3.4 ステータスフィールド

The per-recipient Status field contains a transport-independent status code that indicates the delivery status of the message to that recipient. This field MUST be present for each delivery attempt which is described by a DSN.

レシピエントごとのステータスフィールドには、その受信者へのメッセージの配信ステータスを示すトランスポートに依存しないステータスコードが含まれています。このフィールドは、DSNによって記述される各配信の試行に存在する必要があります。

The syntax of the status field is:

ステータスフィールドの構文は次のとおりです。

   status-field = "Status" ":" status-code
        
   status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
        
      ; White-space characters and comments are NOT allowed within
      ; a status-code, though a comment enclosed in parentheses
      ; MAY follow the last numeric sub-field of the status-code.
      ; Each numeric sub-field within the status-code MUST be
      ; expressed without leading zero digits.
        

Status codes thus consist of three numerical fields separated by ".". The first sub-field indicates whether the delivery attempt was successful (2= success, 4 = persistent temporary failure, 5 = permanent failure). The second sub-field indicates the probable source of any delivery anomalies, and the third sub-field denotes a precise error condition, if known.

したがって、ステータスコードは、「。」で区切られた3つの数値フィールドで構成されています。最初のサブフィールドは、配信の試みが成功したかどうかを示します(2 =成功、4 =永続的な一時的な障害、5 =永続的な障害)。2番目のサブフィールドは、送達異常の可能性のあるソースを示し、3番目のサブフィールドは、既知の場合、正確なエラー条件を示します。

The initial set of status-codes is defined in [STATUS].

ステータスコードの初期セットは[ステータス]で定義されます。

2.3.5 Remote-MTA field
2.3.5 リモートMTAフィールド

The value associated with the Remote-MTA DSN field is a printable ASCII representation of the name of the "remote" MTA that reported delivery status to the "reporting" MTA.

リモートMTA DSNフィールドに関連付けられた値は、「レポート」MTAに配信ステータスを報告した「リモート」MTAの名前の印刷可能なASCII表現です。

      remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name
        

NOTE: The Remote-MTA field preserves the "while talking to" information that was provided in some pre-existing nondelivery reports.

注:リモート-MTAフィールドは、既存の非出産レポートで提供された「話しかけながら」情報を保持します。

This field is optional. It MUST NOT be included if no remote MTA was involved in the attempted delivery of the message to that recipient.

このフィールドはオプションです。その受信者へのメッセージの配信の試みにリモートMTAが関与していない場合は、含めてはなりません。

2.3.6 Diagnostic-Code field
2.3.6 診断コードフィールド

For a "failed" or "delayed" recipient, the Diagnostic-Code DSN field contains the actual diagnostic code issued by the mail transport. Since such codes vary from one mail transport to another, the diagnostic-type sub-field is needed to specify which type of diagnostic code is represented.

「失敗した」または「遅延」受信者の場合、診断コードDSNフィールドには、メールトランスポートが発行した実際の診断コードが含まれています。このようなコードは、メールトランスポートから別のメールへの輸送に異なるため、どのタイプの診断コードを表すかを指定するには、診断タイプのサブフィールドが必要です。

    diagnostic-code-field =
          "Diagnostic-Code" ":" diagnostic-type ";" *text
        

NOTE: The information in the Diagnostic-Code field may be somewhat redundant with that from the Status field. The Status field is needed so that any DSN, regardless of origin, may be understood by any user agent or gateway that parses DSNs. Since the Status code will sometimes be less precise than the actual transport diagnostic code, the Diagnostic-Code field is provided to retain the latter information. Such information may be useful in a trouble ticket sent to the administrator of the Reporting MTA, or when tunneling foreign non-delivery reports through DSNs.

注:診断コードフィールドの情報は、ステータスフィールドからの情報と多少冗長性がある場合があります。ステータスフィールドは、原産地に関係なく、DSNがDSNを解析するユーザーエージェントまたはゲートウェイによって理解されるようにするために必要です。ステータスコードは実際の輸送診断コードよりも正確ではない場合があるため、後者の情報を保持するために診断コードフィールドが提供されます。このような情報は、報告MTAの管理者に送信されるトラブルチケット、またはDSNSを介して外国の非配信レポートをトンネリングするときに役立つ場合があります。

If the Diagnostic Code was obtained from a Remote MTA during an attempt to relay the message to that MTA, the Remote-MTA field should be present. When interpreting a DSN, the presence of a Remote-MTA field indicates that the Diagnostic Code was issued by the Remote MTA. The absence of a Remote-MTA indicates that the Diagnostic Code was issued by the Reporting MTA.

メッセージをそのMTAに中継する試み中に診断コードがリモートMTAから取得された場合、リモートMTAフィールドが存在するはずです。DSNを解釈するとき、リモートMTAフィールドの存在は、診断コードがリモートMTAによって発行されたことを示しています。リモート-MTAがないことは、診断コードが報告MTAによって発行されたことを示しています。

In addition to the Diagnostic-Code itself, additional textual description of the diagnostic, MAY appear in a comment enclosed in parentheses.

診断コード自体に加えて、診断の追加のテキストの説明は、括弧内に囲まれたコメントに表示される場合があります。

This field is optional, because some mail systems supply no additional information beyond that which is returned in the 'action' and 'status' fields. However, this field SHOULD be included if transport-specific diagnostic information is available.

一部のメールシステムは、「アクション」および「ステータス」フィールドで返されるものを超えて追加情報を提供していないため、このフィールドはオプションです。ただし、輸送固有の診断情報が利用可能な場合は、このフィールドを含める必要があります。

2.3.7 Last-Attempt-Date field
2.3.7 最後のattempd-dateフィールド

The Last-Attempt-Date field gives the date and time of the last attempt to relay, gateway, or deliver the message (whether successful or unsuccessful) by the Reporting MTA. This is not necessarily the same as the value of the Date field from the header of the message used to transmit this delivery status notification: In cases where the DSN was generated by a gateway, the Date field in the message header contains the time the DSN was sent by the gateway and the DSN Last-Attempt-Date field contains the time the last delivery attempt occurred.

最後のアトリクトデートフィールドは、報告MTAによってメッセージ(成功したか失敗したかにかかわらず)をリレー、ゲートウェイ、または配信する最後の試みの日付と時刻を与えます。これは、この配信ステータス通知を送信するために使用されるメッセージのヘッダーからの日付フィールドの値と必ずしも同じではありません。DSNがゲートウェイによって生成された場合、メッセージヘッダーの日付フィールドにはDSNの時間が含まれます。ゲートウェイによって送信され、DSNの最後のアティックデートフィールドには、最後の配信の試行が発生した時間が含まれています。

      last-attempt-date-field = "Last-Attempt-Date" ":" date-time
        

This field is optional. It MUST NOT be included if the actual date and time of the last delivery attempt are not available (which might be the case if the DSN were being issued by a gateway).

このフィールドはオプションです。最後の配達試行の実際の日付と時刻が利用できない場合は含めてはなりません(DSNがゲートウェイによって発行されている場合はそうかもしれません)。

The date and time are expressed in RFC 822 'date-time' format, as modified by [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be used.

日付と時刻は、[Hostreq]によって変更されたRFC 822「日付時刻」形式で表されます。数値タイムゾーン([ / - ] HHMM形式)を使用する必要があります。

2.3.8 final-log-id field
2.3.8 Final-Log-IDフィールド

The "final-log-id" field gives the final-log-id of the message that was used by the final-mta. This can be useful as an index to the final-mta's log entry for that delivery attempt.

「Final-Log-ID」フィールドは、Final-MTAが使用したメッセージの最終ログIDを提供します。これは、その配信試行のための最終MTAのログエントリのインデックスとして役立ちます。

      final-log-id-field = "Final-Log-ID" ":" *text
        

This field is optional.

このフィールドはオプションです。

2.3.9 Will-Retry-Until field
2.3.9 ウィル・レトリ・ティル・フィールド

For DSNs of type "delayed", the Will-Retry-Until field gives the date after which the Reporting MTA expects to abandon all attempts to deliver the message to that recipient. The Will-Retry-Until field is optional for "delay" DSNs, and MUST NOT appear in other DSNs.

「遅延」タイプのDSNの場合、Will-Retry-Nothil-Thilのフィールドは、報告MTAがその受信者にメッセージを配信するすべての試みを放棄することを期待する日付を与えます。Will-retry-nuthilフィールドは、「遅延」DSNにオプションであり、他のDSNSに表示されてはなりません。

      will-retry-until-field = "Will-Retry-Until" ":" date-time
        

The date and time are expressed in RFC 822 'date-time' format, as modified by [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be used.

日付と時刻は、[Hostreq]によって変更されたRFC 822「日付時刻」形式で表されます。数値タイムゾーン([ / - ] HHMM形式)を使用する必要があります。

2.4 Extension fields
2.4 拡張フィールド

Additional per-message or per-recipient DSN fields may be defined in the future by later revisions or extensions to this specification. Extension-field names beginning with "X-" will never be defined as standard fields; such names are reserved for experimental use. DSN field names NOT beginning with "X-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and published in an RFC.

追加の1つのレシピエントごとのDSNフィールドは、この仕様の後の改訂または拡張により、将来的に定義される場合があります。「x-」で始まる拡張フィールド名は、標準フィールドとして定義されることはありません。このような名前は、実験用に予約されています。DSNフィールド名は「X-」から始まっていないInternet Assigned Numbers Authority(IANA)に登録し、RFCで公開する必要があります。

Extension DSN fields may be defined for the following reasons:

拡張DSNフィールドは、次の理由で定義できます。

(a) To allow additional information from foreign delivery status reports to be tunneled through Internet DSNs. The names of such DSN fields should begin with an indication of the foreign environment name (e.g., X400-Physical-Forwarding-Address).

(a) インターネットDSNSを介してトンネルを取得するために、外交デリバリーステータスレポートからの追加情報を許可します。そのようなDSNフィールドの名前は、外国の環境名(例:X400-Physical-forwarding-Address)の兆候から始める必要があります。

(b) To allow the transmission of diagnostic information which is specific to a particular mail transport protocol. The names of such DSN fields should begin with an indication of the mail transport being used (e.g., SMTP-Remote-Recipient-Address). Such fields should be used for diagnostic purposes only and not by user agents or mail gateways.

(b) 特定のメール輸送プロトコルに固有の診断情報の送信を許可する。そのようなDSNフィールドの名前は、使用されているメールトランスポートの兆候から始める必要があります(例:SMTP-Remote-Recipient-Address)。このようなフィールドは、ユーザーエージェントやメールゲートウェイではなく、診断目的でのみ使用する必要があります。

(c) To allow transmission of diagnostic information which is specific to a particular message transfer agent (MTA). The names of such DSN fields should begin with an indication of the MTA implementation that produced the DSN. (e.g., Foomail-Queue-ID).

(c) 特定のメッセージ転送エージェント(MTA)に固有の診断情報の送信を許可します。そのようなDSNフィールドの名前は、DSNを生成したMTA実装の兆候から始める必要があります。(例えば、Foomail-Queue-id)。

MTA implementers are encouraged to provide adequate information, via extension fields if necessary, to allow an MTA maintainer to understand the nature of correctable delivery failures and how to fix them. For example, if message delivery attempts are logged, the DSN might include information that allows the MTA maintainer to easily find the log entry for a failed delivery attempt.

MTAの実装者は、必要に応じて拡張フィールドを介して適切な情報を提供することをお勧めします。たとえば、メッセージ配信の試行がログに記録されている場合、DSNには、MTAメンテナーが失敗した配信試行のログエントリを簡単に見つけることができる情報が含まれる場合があります。

If an MTA developer does not wish to register the meanings of such extension fields, "X-" fields may be used for this purpose. To avoid name collisions, the name of the MTA implementation should follow the "X-", (e.g., "X-Foomail-Log-ID").

MTA開発者がこのような拡張フィールドの意味を登録することを希望しない場合、この目的のために「X-」フィールドを使用できます。名前の衝突を避けるために、MTA実装の名前は「X-」(「X-Foomail-Log-ID」など)に従う必要があります。

3. Conformance and Usage Requirements
3. 適合と使用法の要件

An MTA or gateway conforms to this specification if it generates DSNs according to the protocol defined in this memo. For MTAs and gateways that do not support requests for positive delivery notification (such as in [DRPT]), it is sufficient that delivery failure reports use this protocol.

MTAまたはゲートウェイは、このメモで定義されているプロトコルに従ってDSNSを生成する場合、この仕様に準拠しています。肯定的な配信通知のリクエストをサポートしていないMTAおよびゲートウェイ([DRPT]など)の場合、配信障害レポートがこのプロトコルを使用するだけで十分です。

A minimal implementation of this specification need generate only the Reporting-MTA per-message field, and the Final-Recipient, Action, and Status fields for each attempt to deliver a message to a recipient described by the DSN. Generation of the other fields, when appropriate, is strongly recommended.

この仕様の最小限の実装では、レポート-MTAのメッセージごとのフィールドのみを生成し、DSNが説明した受信者にメッセージを配信する試みの各試行の最終的なレシピエント、アクション、およびステータスフィールドのみを生成します。必要に応じて、他のフィールドの生成を強くお勧めします。

MTAs and gateways MUST NOT generate the Original-Recipient field of a DSN unless the mail transfer protocol provides the address originally specified by the sender at the time of submission. (Ordinary SMTP does not make that guarantee, but the SMTP extension defined in [DRPT] permits such information to be carried in the envelope if it is available.)

MTAとゲートウェイは、メール転送プロトコルが提出時に元々送信者によって指定されたアドレスを提供しない限り、DSNの元のレシピエントフィールドを生成してはなりません。(通常のSMTPはその保証を行いませんが、[DRPT]で定義されているSMTP拡張により、そのような情報が利用可能な場合は封筒に掲載されます。)

Each sender-specified recipient address SHOULD result in at most one "delivered" or "failed" DSN for that recipient. If a positive DSN is requested (e.g., one using NOTIFY=SUCCESS in SMTP) for a recipient that is forwarded to multiple recipients of an "alias" (as defined in [DRPT], section 7.2.7), the forwarding MTA SHOULD normally issue a "expanded" DSN for the originally-specified recipient and not propagate the request for a DSN to the forwarding addresses. Alternatively, the forwarding MTA MAY relay the request for a DSN to exactly one of the forwarding addresses and not propagate the request to the others.

各送信者指定の受信者アドレスは、その受信者に対して最大1つの「配信」または「失敗した」DSNをもたらす必要があります。「エイリアス」の複数の受信者に転送されるレシピエント([DRPT]、セクション7.2.7で定義)に陽性DSNが要求された場合(smtpでnotify = successを使用する)元々指定された受信者に「拡張された」DSNを発行し、DSNの転送アドレスへの要求を伝播しません。あるいは、転送MTAは、DSNのリクエストをフォワーディングアドレスの1つに正確に伝え、リクエストを他のものに伝播しない場合があります。

By contrast, successful submission of a message to a mailing list exploder is considered final delivery of the message. Upon delivery of a message to a recipient address corresponding to a mailing list exploder, the Reporting MTA SHOULD issue an appropriate DSN exactly as if the recipient address were that of an ordinary mailbox.

対照的に、メーリングリスト爆発物へのメッセージの提出に成功したことは、メッセージの最終配信と見なされます。メーリングリストの爆発者に対応する受信者にメッセージを配信すると、レポートMTAは、受信者アドレスが通常のメールボックスのものであるかのように適切なDSNを発行する必要があります。

NOTE: This is actually intended to make DSNs usable by mailing lists themselves. Any message sent to a mailing list subscriber should have its envelope return address pointing to the list maintainer [see RFC 1123, section 5.3.7(E)]. Since DSNs are sent to the envelope return address, all DSNs resulting from delivery to the recipients of a mailing list will be sent to the list maintainer. The list maintainer may elect to mechanically process DSNs upon receipt, and thus automatically delete invalid addresses from the list. (See section 7 of this memo.)

注:これは、実際には、郵送リスト自体でDSNを使用できるようにすることを目的としています。メーリングリストのサブスクライバーに送信されたメッセージには、リストメンテナーを指すエンベロープ返信アドレスを持つ必要があります[RFC 1123、セクション5.3.7(e)を参照]。DSNSはエンベロープ返信アドレスに送信されるため、メーリングリストの受信者への配信に起因するすべてのDSNがリストメンテナーに送信されます。リストメンテナーは、受領時にDSNSを機械的に処理することを選択することができ、したがって、リストから無効なアドレスを自動的に削除することができます。(このメモのセクション7を参照してください。)

This specification places no restrictions on the processing of DSNs received by user agents or distribution lists.

この仕様は、ユーザーエージェントまたは配布リストが受け取ったDSNの処理に制限を設けません。

4. Security Considerations
4. セキュリティに関する考慮事項

The following security considerations apply when using DSNs:

DSNSを使用する場合、次のセキュリティに関する考慮事項が適用されます。

4.1 Forgery
4.1 偽造

DSNs may be forged as easily as ordinary Internet electronic mail. User agents and automatic mail handling facilities (such as mail distribution list exploders) that wish to make automatic use of DSNs should take appropriate precautions to minimize the potential damage from denial-of-service attacks.

DSNSは、通常のインターネット電子メールと同じくらい簡単に偽造される場合があります。DSNを自動的に使用したいユーザーエージェントと自動メール処理施設(メール配布リスト爆発物など)は、サービス拒否攻撃による潜在的な損害を最小限に抑えるために適切な予防策を講じる必要があります。

Security threats related to forged DSNs include the sending of:

偽造されたDSNに関連するセキュリティの脅威には、以下の送信が含まれます。

(a) A falsified delivery notification when the message is not delivered to the indicated recipient,

(a) メッセージが指定された受信者に配信されない場合の偽造配達通知、

(b) A falsified non-delivery notification when the message was in fact delivered to the indicated recipient,

(b) メッセージが実際に指定された受信者に配信されたときに、偽造された非配信通知

(c) A falsified Final-Recipient address,

(c) 偽造された最終的な通知アドレス、

(d) A falsified Remote-MTA identification,

(d) 偽造されたリモートMTA識別、

(e) A falsified relay notification when the message is "dead ended".

(e) メッセージが「行き止まり」の場合の偽造リレー通知。

(f) Unsolicited DSNs

(f) 未承諾DSNS

4.2 Confidentiality
4.2 機密性

Another dimension of security is confidentiality. There may be cases in which a message recipient is autoforwarding messages but does not wish to divulge the address to which the messages are autoforwarded. The desire for such confidentiality will probably be heightened as "wireless mailboxes", such as pagers, become more widely used as autoforward addresses.

セキュリティの別の次元は機密性です。メッセージ受信者がメッセージを自動配置しているが、メッセージが自動配置されているアドレスを明かすことを望まない場合があります。このような機密性への欲求は、ポケットベルなどの「ワイヤレスメールボックス」がオートフォワードアドレスとしてより広く使用されるようになると、おそらく高められるでしょう。

MTA authors are encouraged to provide a mechanism which enables the end user to preserve the confidentiality of a forwarding address. Depending on the degree of confidentiality required, and the nature of the environment to which a message were being forwarded, this might be accomplished by one or more of: (a) issuing a "relayed" DSN (if a positive DSN was requested) when a message is forwarded to a confidential forwarding address, and disabling requests for positive DSNs for the forwarded message,

MTAの著者は、エンドユーザーが転送アドレスの機密性を維持できるようにするメカニズムを提供することをお勧めします。必要な機密性の程度、およびメッセージが転送された環境の性質に応じて、これは次の1つ以上によって達成される可能性があります。メッセージは、機密転送アドレスに転送され、転送されたメッセージの肯定的なDSNのリクエストを無効にします。

(b) declaring the message to be delivered, issuing a "delivered" DSN, re-sending the message to the confidential forwarding address, and arranging for no DSNs to be issued for the re-sent message,

(b) メッセージを配信するメッセージを宣言し、「配信された」DSNを発行し、メッセージを機密転送アドレスに再配置し、再シェントメッセージのDSNが発行されないように手配します。

(c) omitting "Remote-*" or extension fields of a DSN whenever they would otherwise contain confidential information (such as a confidential forwarding address),

(c) DSNの「リモート*」または拡張フィールドを省略した場合はいつでも、機密情報(機密転送アドレスなど)が含まれている場合はいつでも、

(d) for messages forwarded to a confidential address, setting the envelope return address (e.g., SMTP MAIL FROM address) to the NULL reverse-path ("<>") (so that no DSNs would be sent from a downstream MTA to the original sender),

(d) 機密アドレスに転送されたメッセージの場合、エンベロープ返信アドレス(アドレスからのsmtpメール)をnull reverse-path( "<>")に設定します(そのため、DSNSが下流のMTAから元の送信者に送信されません)、

(e) for messages forwarded to a confidential address, disabling delivery notifications for the forwarded message (e.g., if the "next-hop" MTA uses ESMTP and supports the DSN extension, by using the NOTIFY=NEVER parameter to the RCPT command), or

(e) 機密アドレスに転送されたメッセージの場合、転送されたメッセージの配信通知を無効にします(たとえば、「次のホップ」MTAがESMTPを使用してDSN拡張機能をサポートする場合、notify = never parameter to the rcptコマンドを使用して)、または

(f) when forwarding mail to a confidential address, having the forwarding MTA rewrite the envelope return address for the forwarded message and attempt delivery of that message as if the forwarding MTA were the originator. On its receipt of final delivery status, the forwarding MTA would issue a DSN to the original sender.

(f) メールを機密アドレスに転送するとき、転送されたMTAのエンベロープ返信アドレスを転送し、転送MTAがオリジネーターであるかのようにそのメッセージの配信を試みることを転送します。最終配送ステータスを受け取ると、転送MTAは元の送信者にDSNを発行します。

In general, any optional DSN field may be omitted if the Reporting MTA site determines that inclusion of the field would impose too great a compromise of site confidentiality. The need for such confidentiality must be balanced against the utility of the omitted information in trouble reports and DSNs gatewayed to foreign environments.

一般に、レポートMTAサイトがフィールドを含めることでサイトの機密性の妥協が大きすぎると判断した場合、オプションのDSNフィールドは省略される場合があります。このような機密性の必要性は、Trouble ReportsおよびDSNSが外国環境にゲートウェイされた省略された情報の有用性とバランスをとる必要があります。

Implementers are cautioned that many existing MTAs will send non-delivery notifications to a return address in the message header (rather than to the one in the envelope), in violation of SMTP and other protocols. If a message is forwarded through such an MTA, no reasonable action on the part of the forwarding MTA will prevent the downstream MTA from compromising the forwarding address. Likewise, if the recipient's MTA automatically responds to messages based on a request in the message header (such as the nonstandard, but widely used, Return-Receipt-To extension header), it will also compromise the forwarding address.

実装者は、多くの既存のMTAが、SMTPおよびその他のプロトコルに違反して、メッセージヘッダーの返信アドレスに(エンベロープ内のものではなく)メッセージヘッダーに送信アドレスに送信することを警告しています。このようなMTAを通じてメッセージが転送された場合、転送MTAの側で合理的なアクションは、下流のMTAが転送アドレスを損なうことを妨げません。同様に、受信者のMTAがメッセージヘッダーのリクエストに基づいてメッセージに自動的に応答した場合(非標準的ですが、広く使用されている、Reture-Receipt-to Extensionヘッダーなど)、転送アドレスも妥協します。

4.3 Non-Repudiation
4.3 非繰り返し

Within the framework of today's internet mail, the DSNs defined in this memo provide valuable information to the mail user; however, even a "failed" DSN can not be relied upon as a guarantee that a message was not received by the recipient. Even if DSNs are not actively forged, conditions exist under which a message can be delivered despite the fact that a failure DSN was issued.

今日のインターネットメールのフレームワーク内で、このメモで定義されているDSNSは、メールユーザーに貴重な情報を提供します。ただし、「失敗した」DSNでさえ、受信者がメッセージを受信しなかったという保証として依存することはできません。DSNSが積極的に偽造されていなくても、障害DSNが発行されたという事実にもかかわらず、メッセージが配信できる条件が存在します。

For example, a race condition in the SMTP protocol allows for the duplication of messages if the connection is dropped following a completed DATA command, but before a response is seen by the SMTP client.

たとえば、SMTPプロトコルのレース条件により、完了したデータコマンドに続いて接続がドロップされた場合、SMTPクライアントが応答する前にメッセージを複製できます。

This will cause the SMTP client to retransmit the message, even though the SMTP server has already accepted it [SMTPDUP]. If one of those delivery attempts succeeds and the other one fails, a "failed" DSN could be issued even though the message actually reached the recipient.

これにより、SMTPサーバーがすでにそれを受け入れている場合でも、SMTPクライアントはメッセージを再送信します[SMTPDUP]。これらの配信の試行の1つが成功し、もう1つが失敗した場合、メッセージが実際に受信者に届いたとしても、「失敗した」DSNが発行される可能性があります。

5. Normative References
5. 引用文献

[DRPT] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 3461, January 2003.

[DRPT]ムーア、K。、「配信ステータス通知のSMTPサービス拡張」、RFC 3461、2003年1月。

[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.

[DSN] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 1894、1996年1月。

[HOSTREQ] Braden, R. (ed.), "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.

[Hostreq] Braden、R。(ed。)、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。

[MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[Mime1] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能(MIME)パート1:インターネットメッセージボディの形式」、RFC 2045、1996年11月。

[MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.

[Mime3] Moore、K。、「Mime(多目的インターネットメールエクステンション)パート3:非ASCIIテキスト用のメッセージヘッダー拡張機能」、RFC 2047、1996年11月。

[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.

[レポート] Vaudreuil、G。、「メールシステム管理メッセージのレポートのマルチパート/レポートコンテンツタイプ」、RFC 3462、2003年1月。

[RFC822] Crocker, D., "Standard for the format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.

[RFC822] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。

[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.

[SMTP] Postel、J。、「Simple Mail Transfer Protocol」、Std 10、RFC 821、1982年8月。

[SMTPDUP] Partridge, C., "Duplicate Messages and SMTP", RFC 1047, February 1988.

[SMTPDUP] Partridge、C。、「DuplicateメッセージとSMTP」、RFC 1047、1988年2月。

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

[ステータス] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、2003年1月。

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

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

6. Acknowledgments
6. 謝辞

The authors wish to thank the following people for their reviews of early drafts of RFC 1894, of which this document is a revision, and their suggestions for improvement: Eric Allman, Harald Alvestrand, Allan Cargille, Jim Conklin, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko Kaittola, Steve Kille, John Klensin, John Gardiner Myers, Mark Nahabedian, Julian Onions, Jacob Palme, Jean Charles Roy, and Gregory Sheehan.

著者は、RFC 1894の初期ドラフトのレビューについて次の人々に感謝したいと考えています。この文書は改訂版であり、改善のための提案:ロジャー・ファイマン、ネッド・フリード、マルコ・カイトラ、スティーブ・キル、ジョン・クレンシン、ジョン・ガーディナー・マイヤーズ、マーク・ナハベディアン、ジュリアン・オニオン、ジェイコブ・パルメ、ジャン・チャールズ・ロイ、グレゴリー・シーハン。

Appendix A - collected grammar

付録A-収集された文法

NOTE: The following lexical tokens are defined in RFC 822: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. The date-time lexical token is defined in [HOSTREQ].

注:次の語彙トークンは、RFC 822で定義されています:Atom、Char、Comment、Cr、Crlf、Digit、LF、Linear-White-Space、Space、Textで定義されています。日付の語彙トークンは[Hostreq]で定義されています。

      action-field = "Action" ":" action-value
        
      action-value =  "failed" / "delayed" / "delivered"
            / "relayed" / "expanded"
        
      address-type = atom
        
      arrival-date-field = "Arrival-Date" ":" date-time
        

delivery-status-content = per-message-fields 1*( CRLF per-recipient-fields )

DERVILY-STATUS-CONTENT = MESSAGE-FIELDS 1*(CRLF RECIPIENT-FIELDS)

      diagnostic-code-field =  "Diagnostic-Code" ":"
            diagnostic-type ";" *text
        
      diagnostic-type = atom
        
      dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
        
      envelope-id = *text
        
      extension-field = extension-field-name ":" *text
        
      extension-field-name = atom
        
      final-recipient-field =
            "Final-Recipient" ":" address-type ";" generic-address
        
      final-log-id-field = "Final-Log-ID" ":" *text
        
      generic-address = *text
        
      last-attempt-date-field = "Last-Attempt-Date" ":" date-time
        
      mta-name = *text
        
      mta-name-type = atom
        
      original-envelope-id-field =
            "Original-Envelope-Id" ":" envelope-id
        
      original-recipient-field =
            "Original-Recipient" ":" address-type ";" generic-address
        
      per-message-fields =
            [ original-envelope-id-field CRLF ]
            reporting-mta-field CRLF
            [ dsn-gateway-field CRLF ]
            [ received-from-mta-field CRLF ]
            [ arrival-date-field CRLF ]
            *( extension-field CRLF )
        
      per-recipient-fields =
           [ original-recipient-field CRLF ]
           final-recipient-field CRLF
           action-field CRLF
           status-field CRLF
           [ remote-mta-field CRLF ]
           [ diagnostic-code-field CRLF ]
           [ last-attempt-date-field CRLF ]
           [ final-log-id-field CRLF ]
           [ will-retry-until-field CRLF ]
            *( extension-field CRLF )
        
      received-from-mta-field =
           "Received-From-MTA" ":" mta-name-type ";" mta-name
        
      remote-mta-field =
           "Remote-MTA" ":" mta-name-type ";" mta-name
        
      reporting-mta-field =
            "Reporting-MTA" ":" mta-name-type ";" mta-name
        
      status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
        
        ; White-space characters and comments are NOT allowed within a
        ; a status-code, though a comment enclosed in parentheses
        ; MAY follow the last numeric sub-field of the status-code.
        ; Each numeric sub-field within the status-code MUST be
        ; expressed without leading zero digits.
        
      status-field = "Status" ":" status-code
        
      will-retry-until-field = "Will-Retry-Until" ":" date-time
        

Appendix B - Guidelines for gatewaying DSNs

付録B- DSNSゲートウェイのガイドライン

NOTE: This section provides non-binding recommendations for the construction of mail gateways that wish to provide semi-transparent delivery reports between the Internet and another electronic mail system. Specific DSN gateway requirements for a particular pair of mail systems may be defined by other documents.

注:このセクションでは、インターネットと別の電子メールシステム間で半透明の配信レポートを提供したいと考えているメールゲートウェイの構築に関する非拘束力のある推奨事項を提供します。特定のペアのメールシステムの特定のDSNゲートウェイ要件は、他のドキュメントで定義される場合があります。

Gatewaying from other mail systems to DSNs

他のメールシステムからDSNSへのゲートウェイ

A mail gateway may issue a DSN to convey the contents of a "foreign" delivery or non-delivery notification over Internet mail. When there are appropriate mappings from the foreign notification elements to DSN fields, the information may be transmitted in those DSN fields. Additional information (such as might be useful in a trouble ticket or needed to tunnel the foreign notification through the Internet) may be defined in extension DSN fields. (Such fields should be given names that identify the foreign mail protocol, e.g., X400-* for X.400 NDN or DN protocol elements)

郵便ゲートウェイは、「外国」配達の内容またはインターネットメールを介した非配信通知の内容を伝えるためにDSNを発行する場合があります。外国通知要素からDSNフィールドに適切なマッピングがある場合、情報はこれらのDSNフィールドに送信される場合があります。追加情報(トラブルチケットで役立つ場合や、インターネットを介して外国の通知をトンネルするのに必要な場合など)は、拡張DSNフィールドで定義される場合があります。(そのようなフィールドには、X.400 NDNまたはDNプロトコル要素の場合、外国のメールプロトコルを識別する名前を指定する必要があります)

The gateway must attempt to supply reasonable values for the Reporting-MTA, Final-Recipient, Action, and Status fields. These will normally be obtained by translating the values from the remote delivery or non-delivery notification into their Internet-style equivalents. However, some loss of information is to be expected. For example, the set of status-codes defined for DSNs may not be adequate to fully convey the delivery diagnostic code from the foreign system. The gateway should assign the most precise code which describes the failure condition, falling back on "generic" codes such as 2.0.0 (success), 4.0.0 (temporary failure), and 5.0.0 (permanent failure) when necessary. The actual foreign diagnostic code should be retained in the Diagnostic-Code field (with an appropriate diagnostic-type value) for use in trouble tickets or tunneling.

ゲートウェイは、報告MTA、最終受信、アクション、およびステータスフィールドに合理的な値を提供しようと試みなければなりません。これらは通常、リモート配信または非配信通知からの値をインターネットスタイルの同等物に変換することによって取得されます。ただし、情報の喪失が予想されます。たとえば、DSNSに対して定義されたステータスコードのセットは、外国システムから配信診断コードを完全に伝えるのに十分ではない場合があります。ゲートウェイは、2.0.0(成功)、4.0.0(一時障害)、必要に応じて5.0.0(永続的な障害)などの「汎用」コードに戻る障害条件を説明する最も正確なコードを割り当てる必要があります。実際の外国診断コードは、トラブルチケットやトンネリングで使用するために、診断コードフィールド(適切な診断タイプの値を持つ)で保持する必要があります。

The sender-specified recipient address, and the original envelope-id, if present in the foreign transport envelope, should be preserved in the Original-Recipient and Original-Envelope-ID fields.

送信者指定の受信者アドレス、および元のエンベロープIDは、外国の輸送エンベロープに存在する場合は、元のレシピエントおよびオリジナルエンベロープIDフィールドに保存する必要があります。

The gateway should also attempt to preserve the "final" recipient addresses and MTA names from the foreign system. Whenever possible, foreign protocol elements should be encoded as meaningful printable ASCII strings.

また、ゲートウェイは、外国システムからの「最終的な」受信者アドレスとMTA名を保持しようとする必要があります。可能な限り、外国のプロトコル要素は、意味のある印刷可能なASCII文字列としてエンコードする必要があります。

For DSNs produced from foreign delivery or nondelivery notifications, the name of the gateway MUST appear in the DSN-Gateway field of the DSN.

外国配達または非派生通知から生成されたDSNSの場合、ゲートウェイの名前はDSNのDSNゲートウェイフィールドに表示されなければなりません。

Gatewaying from DSNs to other mail systems

DSNSから他のメールシステムへのゲートウェイ

It may be possible to gateway DSNs from the Internet into a foreign mail system. The primary purpose of such gatewaying is to convey delivery status information in a form that is usable by the destination system. A secondary purpose is to allow "tunneling" of DSNs through foreign mail systems, in case the DSN may be gatewayed back into the Internet.

インターネットから外国の郵便システムにDSNをゲートウェイすることが可能かもしれません。このようなゲートウェイの主な目的は、宛先システムが使用できる形式で配信ステータス情報を伝えることです。二次的な目的は、DSNがインターネットに戻って戻ってくる可能性がある場合に備えて、外国の郵便システムを介してDSNの「トンネル」を許可することです。

In general, the recipient of the DSN (i.e., the sender of the original message) will want to know, for each recipient: the closest available approximation to the original recipient address, the delivery status (success, failure, or temporary failure), and for failed deliveries, a diagnostic code that describes the reason for the failure.

一般に、DSNの受信者(つまり、元のメッセージの送信者)は、各受信者について、元の受信者アドレスに最も近い近似、配信ステータス(成功、失敗、または一時的な失敗)を知りたいと思うでしょう。失敗した配信の場合、障害の理由を説明する診断コード。

If possible, the gateway should attempt to preserve the Original-Recipient address and Original-Envelope-ID (if present), in the resulting foreign delivery status report.

可能であれば、ゲートウェイは、結果の外国配達ステータスレポートで、元のレシピエントアドレスとオリジナルエンベロープID(存在する場合)を保持しようとする必要があります。

When reporting delivery failures, if the diagnostic-type sub-field of the Diagnostic-Code field indicates that the original diagnostic code is understood by the destination environment, the information from the Diagnostic-Code field should be used. Failing that, the information in the Status field should be mapped into the closest available diagnostic code used in the destination environment.

配信の障害を報告する場合、診断コードフィールドの診断タイプのサブフィールドが、元の診断コードが宛先環境によって理解されていることを示している場合、診断コードフィールドからの情報を使用する必要があります。それに失敗すると、ステータスフィールドの情報は、宛先環境で使用される最も近い利用可能な診断コードにマッピングする必要があります。

If it is possible to tunnel a DSN through the destination environment, the gateway specification may define a means of preserving the DSN information in the delivery status reports used by that environment.

宛先環境を介してDSNをトンネルすることができる場合、ゲートウェイの仕様は、その環境で使用される配信ステータスレポートでDSN情報を保存する手段を定義する場合があります。

Appendix C - Guidelines for use of DSNs by mailing list exploders

付録C-メーリングリスト爆発物によるDSNSの使用に関するガイドライン

This section pertains only to the use of DSNs by "mailing lists" as defined in [4], section 7.2.7.

このセクションでは、[4]、セクション7.2.7で定義されている「メーリングリスト」によるDSNSの使用のみに関係しています。

DSNs are designed to be used by mailing list exploders to allow them to detect and automatically delete recipients for whom mail delivery fails repeatedly.

DSNSは、メーリングリスト爆発者で使用されるように設計されており、メール配信が繰り返し失敗する受信者を検出して削除できるようにします。

When forwarding a message to list subscribers, the mailing list exploder should always set the envelope return address (e.g., SMTP MAIL FROM address) to point to a special address which is set up to receive non-delivery reports. A "smart" mailing list exploder can therefore intercept such non-delivery reports, and if they are in the DSN format, automatically examine them to determine for which recipients a message delivery failed or was delayed.

サブスクライバーをリストするためにメッセージを転送する場合、メーリングリストの爆発者は、常に配信のないレポートを受け取るように設定された特別なアドレスをポイントにポイントするために、常にエンベロープ返信アドレス(アドレスからSMTPメール)を設定する必要があります。したがって、「スマート」メーリングリスト爆発物は、このような配信のないレポートを傍受でき、DSN形式がある場合は、自動的に調べて、受信者がメッセージ配信が失敗するか遅延したかを判断します。

The Original-Recipient field should be used if available, since it should exactly match the subscriber address known to the list. If the Original-Recipient field is not available, the recipient field may resemble the list subscriber address. Often, however, the list subscriber will have forwarded his mail to a different address, or the address may be subject to some re-writing, so heuristics may be required to successfully match an address from the recipient field. Care is needed in this case to minimize the possibility of false matches.

リストに既知のサブスクライバーアドレスと正確に一致する必要があるため、利用可能な場合は元の相性フィールドを使用する必要があります。元の通信フィールドが利用できない場合、受信者フィールドはリストサブスクライバーアドレスに似ている場合があります。ただし、多くの場合、リストサブスクライバーはメールを別のアドレスに転送するか、アドレスが何らかの書き直しの対象となる場合があるため、ヒューリスティックは受信者フィールドのアドレスを正常に一致させる必要がある場合があります。この場合、誤った一致の可能性を最小限に抑えるために注意が必要です。

The reason for delivery failure can be obtained from the Status and Action fields, and from the Diagnostic-Code field (if the status-type is recognized). Reports for recipients with action values other than "failed" can generally be ignored; in particular, subscribers should not be removed from a list due to "delayed" reports.

配信の故障の理由は、ステータスおよびアクションフィールド、および診断コードフィールドから取得できます(ステータスタイプが認識されている場合)。「失敗」以外のアクション値を持つ受信者のレポートは、一般に無視できます。特に、「遅延」レポートのために、購読者をリストから削除しないでください。

In general, almost any failure status code (even a "permanent" one) can result from a temporary condition. It is therefore recommended that a list exploder not delete a subscriber based on any single failure DSN (regardless of the status code), but only on the persistence of delivery failure over a period of time.

一般に、ほとんどすべての障害ステータスコード(「永続的な」コードでさえ)は、一時的な状態から生じる可能性があります。したがって、リスト爆発者は、単一の障害DSN(ステータスコードに関係なく)に基づいてサブスクライバーを削除しないことをお勧めしますが、一定期間にわたる配信障害の持続性だけです。

However, some kinds of failures are less likely than others to have been caused by temporary conditions, and some kinds of failures are more likely to be noticed and corrected quickly than others. Once more precise status codes are defined, it may be useful to differentiate between the status codes when deciding whether to delete a subscriber. For example, on a list with a high message volume, it might be desirable to temporarily suspend delivery to a recipient address which causes repeated "temporary" failures, rather than simply deleting the recipient. The duration of the suspension might depend on the type of error. On the other hand, a "user unknown" error that persisted for several days could be considered a reliable indication that address were no longer valid.

ただし、一部の種類の障害は、一時的な条件によって引き起こされた他の種類の障害よりも低く、ある種の障害は他の条件よりも迅速に気づき、修正される可能性が高くなります。もう一度正確なステータスコードが定義されると、サブスクライバーを削除するかどうかを決定するときに、ステータスコードを区別することが役立つ場合があります。たとえば、メッセージボリュームが高いリストでは、受信者を単に削除するのではなく、繰り返し「一時的な」障害を引き起こす受信者アドレスへの配信を一時的に一時停止することが望ましい場合があります。サスペンションの期間は、エラーのタイプに依存する場合があります。一方、数日間持続する「ユーザー未知の」エラーは、アドレスがもはや有効ではないという信頼できる兆候と見なすことができます。

Appendix D - IANA registration forms for DSN types

付録D -DSNタイプのIANA登録フォーム

The forms below are for use when registering a new address-type, diagnostic-type, or MTA-name-type with the Internet Assigned Numbers Authority (IANA). Each piece of information requested by a registration form may be satisfied either by providing the information on the form itself, or by including a reference to a published, publicly available specification which includes the necessary information. IANA MAY reject DSN type registrations because of incomplete registration forms, imprecise specifications, or inappropriate type names.

以下のフォームは、インターネットが割り当てられた数字当局(IANA)を使用して、新しいアドレスタイプ、診断タイプ、またはMTA-NAMEタイプを登録するときに使用するためです。登録フォームによって要求された各情報は、フォーム自体に関する情報を提供するか、必要な情報を含む公開された公開されている公開されている仕様への参照を含めることによって満たされる場合があります。IANAは、不完全な登録フォーム、不正確な仕様、または不適切なタイプ名のために、DSNタイプの登録を拒否する場合があります。

To register a DSN type, complete the applicable form below and send it via Internet electronic mail to <IANA@IANA.ORG>.

DSNタイプを登録するには、以下の該当するフォームに記入し、インターネット電子メールで<iana@iana.org>に送信します。

IANA registration form for address-type

アドレスタイプのIANA登録フォーム

A registration for a DSN address-type MUST include the following information:

DSNアドレスタイプの登録には、次の情報を含める必要があります。

(a) The proposed address-type name.

(a) 提案されたアドレスタイプ名。

(b) The syntax for mailbox addresses of this type, specified using BNF, regular expressions, ASN.1, or other non-ambiguous language.

(b) このタイプのメールボックスアドレスの構文は、BNF、正規式、ASN.1、またはその他の非曖昧な言語を使用して指定されています。

(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文字としてエンコードされる方法の仕様。

(d) [optional] A specification for how addresses of this type are to be translated to and from Internet electronic mail addresses.

(d) [オプション]このタイプのアドレスがインターネット電子メールアドレスにどのように翻訳されるかの仕様。

IANA registration form for diagnostic-type

診断タイプのIANA登録フォーム

A registration for a DSN address-type MUST include the following information:

DSNアドレスタイプの登録には、次の情報を含める必要があります。

(a) The proposed diagnostic-type name.

(a) 提案された診断タイプ名。

(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レパートリーのグラフィック文字として表現するために使用される構文の説明。

(c) A list of valid diagnostic codes of this type and the meaning of each code.

(c) このタイプの有効な診断コードのリストと各コードの意味。

(d) [optional] A specification for mapping from diagnostic codes of this type to DSN status codes (as defined in [5]).

(d) [オプション]このタイプの診断コードからDSNステータスコードへのマッピングの仕様([5]で定義)。

IANA registration form for MTA-name-type

MTA-Name-TypeのIANA登録フォーム

A registration for a DSN MTA-name-type must include the following information:

DSN MTA-Name-Typeの登録には、次の情報を含める必要があります。

(a) The proposed MTA-name-type name.

(a) 提案されているMTA-Nameタイプ名。

(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、またはその他の非曖昧な言語を使用しています。

(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文字のシーケンスとして表現する方法の仕様。

Appendix E - Examples

付録E-例

These examples are provided as illustration only, and are not considered part of the DSN protocol specification. If an example conflicts with the protocol definition above, the example is wrong.

これらの例は、図のみとして提供されており、DSNプロトコル仕様の一部とは見なされません。例が上記のプロトコル定義と競合する場合、例は間違っています。

Likewise, the use of *-type sub-field names or extension fields in these examples is not to be construed as a definition for those type names or extension fields.

同様に、これらの例で *タイプのサブフィールド名または拡張フィールドの使用は、それらのタイプ名または拡張フィールドの定義として解釈されるべきではありません。

These examples were manually translated from bounced messages using whatever information was available.

これらの例は、利用可能な情報を使用して、バウンスされたメッセージから手動で翻訳されました。

Simple DSN

単純なDSN

This is a simple DSN issued after repeated attempts to deliver a message failed. In this case, the DSN is issued by the same MTA from which the message was originated.

これは、メッセージを配信しようとする繰り返しの試みが失敗した後に発行された簡単なDSNです。この場合、DSNは、メッセージが発信された同じMTAによって発行されます。

   Date: Thu, 7 Jul 1994 17:16:05 -0400 From: Mail Delivery Subsystem
   <MAILER-DAEMON@CS.UTK.EDU> Message-Id:
   <199407072116.RAA14128@CS.UTK.EDU> Subject: Returned mail: Cannot
   send message for 5 days To: <owner-info-mime@cs.utk.edu> MIME-
   Version: 1.0 Content-Type: multipart/report; report-type=delivery-
   status;
          boundary="RAA14128.773615765/CS.UTK.EDU"
        

--RAA14128.773615765/CS.UTK.EDU

-raa14128.773615765/cs.utk.edu

   The original message was received at Sat, 2 Jul 1994 17:10:28 -0400
   from root@localhost
        
       ----- The following addresses had delivery problems -----
   <louisl@larry.slip.umd.edu>  (unrecoverable error)
        
   ----- Transcript of session follows -----
   <louisl@larry.slip.umd.edu>... Deferred: Connection timed out
               with larry.slip.umd.edu.
   Message could not be delivered for 5 days
   Message will be deleted from queue
        

--RAA14128.773615765/CS.UTK.EDU content-type: message/delivery-status

-raa14128.773615765/cs.utk.edu content-type:メッセージ/配信-status

Reporting-MTA: dns; cs.utk.edu

Reporting-MTA:DNS;cs.utk.edu

   Original-Recipient: rfc822;louisl@larry.slip.umd.edu
   Final-Recipient: rfc822;louisl@larry.slip.umd.edu
   Action: failed
   Status: 4.0.0
   Diagnostic-Code: smtp; 426 connection timed out
   Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
        

--RAA14128.773615765/CS.UTK.EDU content-type: message/rfc822

-raa14128.773615765/cs.utk.edu content-type:message/rfc822

[original message goes here]

[元のメッセージはここにあります]

--RAA14128.773615765/CS.UTK.EDU--

-raa14128.773615765/cs.utk.edu--

Multi-Recipient DSN

多recipient DSN

This is another DSN issued by the sender's MTA, which contains details of multiple delivery attempts. Some of these were detected locally, and others by a remote MTA.

これは、送信者のMTAによって発行された別のDSNであり、複数の配信試行の詳細が含まれています。これらのいくつかはローカルで検出され、他のものはリモートMTAによって検出されました。

   Date: Fri, 8 Jul 1994 09:21:47 -0400
   From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
   Subject: Returned mail: User unknown
   To: <owner-ups-mib@CS.UTK.EDU>
   MIME-Version: 1.0
   Content-Type: multipart/report; report-type=delivery-status;
          boundary="JAA13167.773673707/CS.UTK.EDU"
        
   --JAA13167.773673707/CS.UTK.EDU
   content-type: text/plain; charset=us-ascii
        
          ----- The following addresses had delivery problems -----
   <arathib@vnet.ibm.com> (unrecoverable error)
   <wsnell@sdcc13.ucsd.edu> (unrecoverable error)
        

--JAA13167.773673707/CS.UTK.EDU content-type: message/delivery-status

-jaa13167.773673707/cs.utk.edu content-type:メッセージ/配信-status

Reporting-MTA: dns; cs.utk.edu

Reporting-MTA:DNS;cs.utk.edu

   Original-Recipient: rfc822;arathib@vnet.ibm.com
   Final-Recipient: rfc822;arathib@vnet.ibm.com
   Action: failed
   Status: 5.0.0 (permanent failure)
   Diagnostic-Code: smtp;  550 'arathib@vnet.IBM.COM' is not a
    registered gateway user
   Remote-MTA: dns; vnet.ibm.com
        
   Original-Recipient: rfc822;johnh@hpnjld.njd.hp.com
   Final-Recipient: rfc822;johnh@hpnjld.njd.hp.com
   Action: delayed
   Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure)
        
   Original-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
   Final-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
   Action: failed
   Status: 5.0.0
   Diagnostic-Code: smtp; 550 user unknown
   Remote-MTA: dns; sdcc13.ucsd.edu
        

--JAA13167.773673707/CS.UTK.EDU content-type: message/rfc822

-jaa13167.773673707/cs.utk.edu content-type:message/rfc822

[original message goes here]

[元のメッセージはここにあります]

--JAA13167.773673707/CS.UTK.EDU--

-jaa13167.773673707/cs.utk.edu--

DSN from gateway to foreign system

ゲートウェイから外国システムへのDSN

A delivery report generated by Message Router (MAILBUS) and gatewayed by PMDF_MR to a DSN. In this case the gateway did not have sufficient information to supply an original-recipient address.

メッセージルーター(Mailbus)によって生成され、PMDF_MRによってDSNにゲートウェイされた配信レポート。この場合、ゲートウェイには、元のレシピエントアドレスを提供するのに十分な情報がありませんでした。

   Disclose-recipients: prohibited
   Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT)
   From: Message Router Submission Agent <AMMGR@corp.timeplex.com>
   Subject: Status of: Re: Battery current sense
   To: owner-ups-mib@CS.UTK.EDU
   Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com>
   MIME-version: 1.0
   content-type: multipart/report;
       report-type=delivery-status;
       boundary="84229080704991.122306.SYS30"
        

--84229080704991.122306.SYS30 content-type: text/plain

-84229080704991.122306.SYS30 Content-Type:Text/Plain

Invalid address - nair_s %DIR-E-NODIRMTCH, No matching Directory Entry Entry found

無効なアドレス-Nair_s%dir-e-nodirmtch、一致するディレクトリエントリが見つかりません

--84229080704991.122306.SYS30 content-type: message/delivery-status

-84229080704991.122306.SYS30 Content-Type:Message/Delivery-Status

Reporting-MTA: mailbus; SYS30

Reporting-Mta:Mailbus;sys30

Final-Recipient: unknown; nair_s Status: 5.0.0 (unknown permanent failure) Action: failed

最終受信者:不明。NAIR_Sステータス:5.0.0(不明な永続的障害)アクション:失敗

--84229080704991.122306.SYS30--

-84229080704991.122306.SYS30---

Delayed DSN

DSNの遅延

A delay report from a multiprotocol MTA. Note that there is no returned content, so no third body part appears in the DSN.

マルチプロトコルMTAからの遅延レポート。返されたコンテンツはないため、DSNに3番目のボディパーツが表示されないことに注意してください。

   MIME-Version: 1.0
   From: <postmaster@nsfnet-relay.ac.uk>
   Message-Id: <199407092338.TAA23293@CS.UTK.EDU>
   Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
           id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
           Sun, 10 Jul 1994 00:36:51 +0100
   To: owner-info-mime@cs.utk.edu
   Date: Sun, 10 Jul 1994 00:36:51 +0100
   Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
   content-type: multipart/report; report-type=delivery-status;
          boundary=foobar
        

--foobar content-type: text/plain

- Foobar Content-Type:Text/Plain

The following message:

次のメッセージ:

UA-ID: Reliable PC (... Q-ID: sun2.nsf:77/msg.11820-0

UA-ID:信頼できるPC(... Q-ID:Sun2.NSF:77/MSG.11820-0

has not been delivered to the intended recipient:

意図された受信者に届けられていません。

thomas@de-montfort.ac.uk

thomas@de-montfort.ac.uk

despite repeated delivery attempts over the past 24 hours.

過去24時間にわたって繰り返し配達の試みにもかかわらず。

The usual cause of this problem is that the remote system is temporarily unavailable.

この問題の通常の原因は、リモートシステムが一時的に利用できないことです。

Delivery will continue to be attempted up to a total elapsed time of 168 hours, i.e., 7 days.

配達は、168時間、つまり7日間の合計経過時間まで引き続き試みられます。

You will be informed if delivery proves to be impossible within this time.

この時間内に配達が不可能であることが証明された場合、あなたは通知されます。

Please quote the Q-ID in any queries regarding this mail.

このメールに関するクエリでQ-IDを引用してください。

--foobar content-type: message/delivery-status

- Foobar Content-Type:メッセージ/配信ステータス

Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk

Reporting-MTA:DNS;sun2.nsfnet-relay.ac.uk

   Final-Recipient: rfc822;thomas@de-montfort.ac.uk
      Status: 4.0.0 (unknown temporary failure)
   Action: delayed
        

--foobar--

- フーバー -

Appendix F - Changes from RFC 1894

付録F- RFC 1894からの変更

Changed Authors contact information

著者の連絡先情報を変更しました

Updated required standards boilerplate

必要な標準ボイラープレートを更新しました

Edited the text to make it spell-checker and grammar checker compliant

テキストを編集して、それをスペルチェッカーと文法チェッカーに準拠させる

Updated references to point to later, more mature documents, changed reference enumeration scheme.

後で指摘するための更新された参照、より成熟したドキュメントは、参照列挙スキームを変更しました。

Fixed paragraph numbering on page 20

20ページの段落番号を修正しました

Fixed Delayed DSN example

遅延DSNの例を修正しました

Added Table of Contents

目次が追加されました

Moved Appendices to the end of the document

ドキュメントの最後に付録を移動しました

Changed the MTA-name-Type for gateways into Internet mail, the MTA-name-type from "SMTP" to "dns".

ゲートウェイのMTA-Name-Typeをインターネットメールに変更しました。MTA-NAMEタイプは「SMTP」から「DNS」になりました。

Authors' Addresses

著者のアドレス

Keith Moore University of Tennessee 1122 Volunteer Blvd, Suite 203 Knoxville TN 37996-3450 USA

キースムーア大学テネシー大学1122ボランティアBlvd、スイート203ノックスビルTN 37996-3450 USA

   Phone: +1-865-974-3126
   Fax:   +1-865-974-8296
   EMail: moore@cs.utk.edu
        

Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas, Tx. 75214 USA

Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas、テキサス75214 USA

   Phone: +1 214 823 9325
   EMail: GregV@ieee.org
        

Full Copyright Statement

完全な著作権声明

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エディター機能の資金は現在、インターネット協会によって提供されています。