RFC1894 日本語訳
1894 An Extensible Message Format for Delivery Status Notifications.K. Moore, G. Vaudreuil. January 1996. (Format: TXT=77462 bytes) (Obsoleted by RFC3464) (Updated by RFC2852) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Moore
Request for Comments: 1894 University of Tennessee
Category: Standards Track G. Vaudreuil
Octel Network Services
January 1996
コメントを求めるワーキンググループK.ムーア要求をネットワークでつないでください: 1894年のテネシー大学カテゴリ: 標準化過程G.ボードルイOctelネットワーク・サービス1996年1月
An Extensible Message Format for Delivery Status Notifications
配送状態通知のための広げることができるメッセージ・フォーマット
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo defines a 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)か電子メールゲートウェイによって使用される、1人以上の受取人に伝言をもたらす試みの結果を報告するかもしれないMIMEの満足しているタイプを定義します。 この満足しているタイプは現在インターネット電子メールで使用されている様々なタイプに関する配送状態通知とのマシン-処理可能交換として意図します。
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "LAN-based" systems), the 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プロトコルは環境を通信させながらマルチプロトコルで役に立つように設計されています。 このために、このメモで説明されたプロトコルは「外国」のアドレスとエラーコードのキャリッジに備えます、通常、インターネット・メールで使用されるものに加えて。 また、追加属性は、インターネット・メールによる外国通知が「トンネルを堀ること」を支持するために定義されるかもしれません。
Any questions, comments, and reports of defects or ambiguities in this specification may be sent to the mailing list for the NOTARY working group of the IETF, using the address <notifications@cs.utk.edu>. Requests to subscribe to the mailing list should be addressed to <notifications-request@cs.utk.edu>. Implementors of this specification are encouraged to subscribe to the mailing list, so that they will quickly be informed of any problems which might hinder interoperability.
この仕様による欠陥かあいまいさのどんな質問、コメント、およびレポートもIETFのNOTARYワーキンググループのためのメーリングリストに送るかもしれません、 address <notifications@cs.utk.edu を使用してgt。 メーリングリストに加入するという要求が記述された to <notifications-request@cs.utk.edu であるべきである、gt。 この仕様の作成者がメーリングリストに加入するよう奨励されます、彼らは相互運用性を妨げるかもしれないどんな問題でもすぐに知識があるようになるでしょう。
NOTE: This document is a Proposed Standard. If and when this protocol is submitted for Draft Standard status, any normative text (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in this document will be re-evaluated in light of implementation
以下に注意してください。 このドキュメントはProposed Standardです。 Draft Standard状態、どんな標準のテキストのためにもこのプロトコルを提出する、(SHOULD、SHOULD NOTを含む句は望んでいなければなりません、と5月) NOT、またはこれが記録するコネが再評価されたコネが実現の光であったなら望んでいなければなりません。
Moore & Vaudreuil Standards Track [Page 1] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[1ページ]。
experience, and are thus subject to change.
変化を経験して、その結果、被りやすいです。
1. Introduction
1. 序論
This memo defines a MIME [1] 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 [2].
このメモは配送状態通知(DSNs)のための満足しているタイプのMIME[1]を定義します。 いくつかの状態のどれかに関するメッセージについて送付者に通知するのにDSNを使用できます: DSNsを支持しないかもしれない環境へのメッセージの失敗した配送、遅延分娩、うまくいっている配送、またはgatewaying。 ここに定義された「配送メッセージ/状態」満足しているタイプは使用のために[2]で定義された「複合/レポート」満足しているタイプの枠組みの中で意図します。
This memo defines only the format of the notifications. An extension to the Simple Message Transfer Protocol (SMTP) [3] to fully support such notifications is the subject of a separate memo [4].
このメモは通知の書式だけを定義します。 そのような通知を完全に支持するSimple Message Transferプロトコル(SMTP)[3]への拡大は別々のメモ[4]の対象です。
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 which is largely independent of human language;
(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, yet reasonably precise, indications of
the reason for the failure of a message to be delivered (once status
codes of sufficient precision are defined); 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
(g) 彼らが報告された誤りの本質を理解できるように、リモートMTA維持装置(「問題チケット」を通した)に十分な情報を供給してください。 そして伝言をもたらさない場合リモートMTAの不調のためにあって、この特徴が使用されている。
Moore & Vaudreuil Standards Track [Page 2] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[2ページ]。
sender wants to report the problem to the remote MTA administrator.
送付者はリモート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 which 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はメッセージを特定する1セットの1メッセージあたりの分野とメッセージが提出された取引を含んでいます、DSNによって説明されたすべての配送試みに適用される他の分野と共に。 また、DSNは、受取人1人以上の各人にメッセージを送る試みの結果を伝えるために1セットの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.
メッセージはいくつかのメッセージ転送エージェント(MTAs)を通して受取人への途中に送られるかもしれません。 さまざまな理由で、受取人アドレスがこの過程の間、書き直されるかもしれないので、各MTAは潜在的に異なった受取人アドレスを見るかもしれません。 DSNが特定の受取人アドレスの中古の、そして、異なった形式である目的によるのが必要でしょう。
Moore & Vaudreuil Standards Track [Page 3] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[3ページ]。
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からトランスミッションで視点で定義されます。 以下の名前はMTAsに割り当てられます:
(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.
Original 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に関してはも、Reporting 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形式に翻訳することによって生産されたなら、それでも、Reporting 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.
Received、-、MTAはReporting 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にメッセージを移すことができないことを決定するか、または「次のホップ」MTAが、メッセージを送ることができない受取人を代表してDSNを発行するために意図している受取人のより多くのひとり、MTAが必要とするかもしれないリレーにメッセージの配送への責任を引き受けるのを拒否するなら。 この場合、リレーしているMTAはReporting MTAです、そして、「次のホップ」MTAはRemote MTAとして知られています。
Moore & Vaudreuil Standards Track [Page 4] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[4ページ]。
Figure 1 illustrates the relationship between the various MTAs.
図1は様々なMTAsの間の関係を例証します。
+-----+ +--------+ +---------+ +---------+ +------+ | | | | |Received-| | | | | | | => |Original| => ... => | From | => |Reporting| ===> |Remote| | user| | MTA | | MTA | | MTA | <No! | MTA | |agent| +--------+ +---------+ +----v----+ +------+ | | | | | <-------------------------------------------+ +-----+ (DSN returned to sender by Reporting MTA)
+-----+ +--------+ +---------+ +---------+ +------+ | | | | |受信します。| | | | | | | =>| オリジナル| =>… =>|| =>| 報告| ===>|、リモート| | ユーザ| | MTA| | MTA| | MTA| <ノー! | MTA| |エージェント| +--------+ +---------+ +----v----+ +------+ | | | | | <-------------------------------------------+ +-----+ (Reporting MTAによって送付者に返されたDSN)
Figure 1. Original, Received-From, Reporting and Remote MTAs
図1。 オリジナルの、そして、受け取っている報告とリモートMTAs
Each of these MTAs may provide information which is useful in a DSN:
それぞれのこれらのMTAsはDSNで役に立つ情報を提供するかもしれません:
+ Ideally, the DSN will contain the address of each recipient as originally specified to the Original MTA by the sender of the message. 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.
元々メッセージ送信者によってOriginal MTAに指定されて、理想的に、DSNがそれぞれの受取人のアドレスを含む+。 アドレスのこのバージョンが、送付者が送付者の記録(例えば、個人のためのアドレス帳、メーリングリストのための応募者名簿)のアドレスと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はメッセージ提案時点で、送付者のユーザエージェントとOriginal 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.
+ メッセージが送付者によって使用されたそれ送付者、異なったメールシステムにgatewayedされた(b)によって指定されたそれより異なったアドレスに送られた(a)であったか、そして、(c)がトランスミッションの間の書き直しを記述するためにかけられて、受取人アドレス(すなわち、Reporting 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 which is independent of the mail transport system that issued the DSN. However, if a foreign error
+ 「失敗した」DSNは利用可能な配信障害のための最も正確な説明を含むはずです。 解釈の容易さのために、この情報はDSNを発行したメール輸送システムから独立している形式であるべきです。 しかしながら、外国誤りです。
Moore & Vaudreuil Standards Track [Page 5] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[5ページ]。
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.
コードは何らかの輸送から独立している形式に翻訳されて、何らかの情報が失われるかもしれません。 したがって、輸送から独立しているステータスコードとメカニズムの両方を輸送特有のコードを報告するのに提供するのは望ましいです。 配信障害を生産した事情によって、Reporting MTAかRemote 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を発行するMTAがそれらの事情を予期できないのでDSNが使用される状況に従って「受取人アドレス」と「配送ステータスコード」のための異価が必要であるので、ここで説明された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.
また、拡大分野は、問題チケットにおける使用のための追加情報を提供するか、またはインターネットDSNsを通して外国配送レポートのトンネリングのための情報を保存するために必要に応じてReporting MTAによって加えられるかもしれません。
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" subfield followed by a subfield whose contents are ordinary text characters, and the format of which is indicated by the "type" subfield. This allows a DSN to convey these quantities regardless of format.
Original、Reporting、およびRemote MTAsは非常に異なった環境で存在していて、異なったトランスポート・プロトコル、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 [2]). When a multipart/report content is used to transmit a DSN:
DSNはトップレベルの満足しているタイプの複合/レポートがあるMIMEメッセージです。([2])では、定義されます。 複合/レポート内容が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 [2].
(b) 複合/レポートの最初の成分は[2]で説明されるように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) 複合/レポートの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) オリジナルのメッセージかメッセージの部分が送付者に返すことであるなら、それは複合/レポートの3番目の成分として現れます。
Moore & Vaudreuil Standards Track [Page 6] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[6ページ]。
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 which contain equivalent
information. In particular, it is very desirable to preserve the
subject, date, and message-id (or equivalent) fields from the
original message.
以下に注意してください。 外国システムからgatewayedされた配送状態通知には、オリジナルのメッセージのヘッダーは手があいていないかもしれません。 この場合、DSNの3番目の部品が省略されるかもしれませんか、またはそれは同等な情報を含む「シミュレートされた」RFC822ヘッダーを含むかもしれません。 それは特に、オリジナルのメッセージからの対象、日付、およびメッセージイドを保持するのにおいて非常に望ましくて(同等)の分野です。
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 MUST、DSNが発生したオリジナルのメッセージに伴った輸送封筒から返送先に記述されてください(メッセージヘッダーと輸送封筒の両方で)。 (SMTPを通して到着したメッセージに関して、封筒返送先はMAIL FROMコマンドに現れます。)
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 SHOULDのメッセージヘッダーのFrom分野はReporting MTAサイト(例えば、Postmaster)でメールシステムを維持するのに責任がある人間のアドレスを含んでいます、DSNへの回答がその人に届くように。 例外: DSNが外国配送から翻訳されるなら、報告してください。そうすれば、翻訳を実行するゲートウェイは、適切なアドレス、DSN MAYのFrom分野がゲートウェイを維持するのに責任がある人間のアドレスであることを決定できません。
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 SHOULDの封筒送付者アドレスを配送現状報告が全くDSN自身に対応して発行されないのを保証するために選ばれていて、DSNsがメール輪を発生させないように、選ばなければなりません。 SMTP取引がDSNを送るのに使用されるときはいつも、メールFROMコマンドはすなわち、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 be still be issued in response to a single message submission.
特定のDSNはまさに1つのメッセージのために配送状態について説明します。 しかしながら、MTA MAYは同じメッセージの数人の受取人のために独身のDSNで配送状態に関して報告します。 複数のDSNsがメール輸送システム(受取人へのメッセージの配送への責任が数個のMTAsの中で分けられるかもしれなくて、どんな特定の受取人への配送も遅れるかもしれないところ)の本質のためにですそれでも、ただ一つのメッセージ提案に対応して、発行されてください。
Moore & Vaudreuil Standards Track [Page 7] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[7ページ]。
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「副-タイプ」は以下を命名します。 配送状態Optionalパラメタ: なにも、Encoding問題: 「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 [6]). 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:
配送メッセージ/状態のボディーはRFC822ヘッダー「分野」のABNFによると、フォーマットされた1「分野」から成ります。([6])を見てください。 1メッセージあたりの野原は空白行があとに続いた1番目に見えます。 メッセージに従って、分野は1受取人あたりの分野の1つ以上のグループです。 空白行は1受取人あたりの分野の各グループに先行します。 RFC822のABNFを使用して、配送メッセージ/状態内容の構文は以下の通りです:
delivery-status-content =
per-message-fields 1*( CRLF per-recipient-fields )
配送状態内容がメッセージ分野単位で等しい、1*(CRLF、受取人分野、)
The per-message fields are described in section 2.2. The per- recipient fields are described in section 2.3.
1メッセージあたりの分野はセクション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 which 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 [7].
RFC822の規則に従ってこれらの分野が定義されるので、継続行とコメントのための同じコンベンションは適用されます。 通知分野は、SPACEかHTABと共にそれぞれの追加線を始めることによって、複数の線に続けられるかもしれません。 括弧に現れるテキストは部分ではなく、その通知分野のコンテンツのコメントであると考えられます。 フィールド名が大文字と小文字を区別しないので、通知分野の名前は大文字と小文字手紙のどんな組み合わせでもつづられるかもしれません。 DSN分野でのコメントは[7]で定義された「コード化された単語」構造物を使用するかもしれません。
A number of DSN fields are defined to have a portion of a field body of "xtext". "xtext" is used to allow encoding sequences of octets which contain values outside the range [1-127 decimal] of traditional ASCII characters, and also to allow comments to be inserted in the data. Any octet may be encoded as "+" followed by two upper case
多くのDSN分野が、"xtext"の分野本体の一部を持つために定義されます。 "xtext"は、伝統的なASCII文字の範囲[1-127 10進の]の外に値を保管している八重奏の系列をコード化するのを許容して、また、コメントがデータに挿入されるのを許容するのに使用されます。 「+」が2大文字で続いて、どんな八重奏もコード化されるかもしれません。
Moore & Vaudreuil Standards Track [Page 8] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[8ページ]。
hexadecimal digits. (The "+" character MUST be encoded as "+2B".) With certain exceptions, octets that correspond to ASCII characters may be represented as themselves. SPACE and HTAB characters are ignored. Comments may be included by enclosing them in parenthesis. Except within comments, encoded-words such as defined in [7] may NOT be used in xtext.
16進数字。 「(「」 + 2Bとして+ 」 キャラクタをコード化しなければなりません」。) ある例外で、ASCII文字に文通される八重奏は自分たちとして表されるかもしれません。 SPACEとHTABキャラクタは無視されます。 コメントは、挿入句にそれらを同封することによって、含まれるかもしれません。 コメント以外に、[7]で定義されるようなコード化された単語はxtextで使用されないかもしれません。
"xtext" is formally defined as follows:
"xtext"は以下の通り正式に定義されます:
xtext = *( xchar / hexchar / linear-white-space / comment )
xtextは*と等しいです。(直線的なxchar/hexchar/余白/コメント)
xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
except for "+", "\" and "(".
xcharは“!"の間でどんなASCII CHARとも等しいです。 (33) そして、「+」、「\」を除いて、包括的な「~」(126)、「(「.」
"hexchar"s are intended to encode octets that cannot be represented as plain text, either because they are reserved, or because they are non-printable. However, any octet value may be represented by a "hexchar".
「「sがプレーンテキストとして表すことができない八重奏をコード化することを意図します、それらが予約されているか、またはそれらが非印刷可能であるので」hexchar。 しかしながら、どんな八重奏値も"hexchar"によって表されるかもしれません。
hexchar = ASCII "+" immediately followed by two upper case
hexadecimal digits
hexcharは2つの大文字16進数字がすぐにあとに続いたASCII「+」と等しいです。
When encoding an octet sequence as xtext:
xtextとして八重奏系列をコード化するとき:
+ Any ASCII CHAR between "!" and "~" inclusive, except for "+", "\",
and "(", MAY be encoded as itself. (Some CHARs in this range may
also be encoded as "hexchar"s, at the implementor's discretion.)
そして、+ “!"と「+」、「\」を除いて、包括的な「~」の間のどんなASCII CHAR、も「(「それ自体としてコード化されるかもしれない、」(また、この範囲のいくつかのCHARsがコード化されるかもしれない、「hexchar、「作成者の裁量におけるs、)、」
+ ASCII CHARs that fall outside the range above must be encoded as
"hexchar".
"hexchar"として+ 範囲の外に上に落ちるASCII CHARsをコード化しなければなりません。
+ Line breaks (CR LF SPACE) MAY be inserted as necessary to keep line
lengths from becoming excessive.
+ ラインブレイク(CR LF SPACE)は、行長が過度になるのを妨げるために必要に応じて挿入されるかもしれません。
+ Comments MAY be added to clarify the meaning for human readers.
+ コメントは、人間の読者のために意味をはっきりさせるために加えられるかもしれません。
2.1.2 "*-type" subfields
「2.1.2」 」 部分体を*でタイプしてください。
Several DSN fields consist of a "-type" subfield, followed by a semicolon, followed by "*text". For these fields, the keyword used in the address-type, diagnostic-type, or MTA-name-type subfield indicates the expected format of the address, status-code, or MTA- name which follows.
「いくつかのDSN分野が」 *テキストがあとに続いたセミコロンがあとに続いた「タイプ」部分体から成ります。」 これらの分野に、アドレスタイプ、診断タイプ、またはMTA名前タイプ部分体に使用されるキーワードは従うアドレス、ステータスコード、またはMTA名の予想された書式を示します。
Moore & Vaudreuil Standards Track [Page 9] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[9ページ]。
The "-type" subfields are defined as follows:
「タイプ」部分体は以下の通り定義されます:
(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 [3], the "smtp" diagnostic-type is
used.
(b) 「診断タイプ」はステータスコードの形式を指定します。 DSN分野がシンプルメールトランスファプロトコル[3]で報告された回答コードを含むとき、例えば、"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名前タイプ」はMTA名の形式を指定します。 例えば、MTA名はインターネット・ホストの上のSMTPサーバーのための、そのホストのドメイン名です、そして、"dns"MTA名前タイプは使用されています。
mta-name-type = atom
mta名前タイプは原子と等しいです。
Values for address-type, diagnostic-type, and MTA-name-type are case-insensitive. Thus address-type values of "RFC822" and "rfc822" are equivalent.
アドレスタイプ、診断タイプ、およびMTA名前タイプのための値は大文字と小文字を区別しないです。 したがって、"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 a one or more specifications that provide such descriptions. (The "rfc822" address-type, "smtp" diagnostic- type, and "dns" MTA-name-type are defined in [4].) Registration forms for address-type, diagnostic-type, and MTA-name-type appear in section 8 of this document.
インターネットAssigned民数記Authority(IANA)はアドレスタイプ(そのような記述を提供する意味の記述とそれぞれの許容値、または1つか以上の参照と共に診断タイプの、そして、MTAがタイプを命名している仕様)の登録を維持するでしょう。 ("rfc822"アドレスタイプ、"smtp"病気の特徴タイプ、および"dns"MTA名前タイプは[4]で定義されます。) アドレスタイプ、診断タイプ、およびMTA名前タイプのための登録用紙はこのドキュメントのセクション8に現れます。
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名前型名も受け入れないでしょう。 これらの型名は実験用のために予約されます。
2.1.3 Lexical tokens imported from RFC 822
2.1.3 RFC822から輸入された字句
The following lexical tokens, defined in [6], 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 [8].
[6]で定義された以下の字句はDSNsにABNF文法に使用されます: 原子、CHAR、コメント、CR、CRLF、DIGIT、LF、直線的な余白、SPACE、テキスト。 日付-時間字句は[8]で定義されます。
Moore & Vaudreuil Standards Track [Page 10] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[10ページ]。
2.2 Per-Message DSN Fields
2.2 1メッセージあたりのDSN分野
Some fields of a DSN apply to all of the delivery attempts described by that DSN. These fields may appear at most 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 )
メッセージ分野単位で報告しているmta分野CRLF[dsnゲートウェイ分野CRLF][mta分野から容認されたCRLF][到着年月日欄CRLF]*と等しいです[元の封筒イド分野CRLF]。(拡大分野CRLF)
2.2.1 The Original-Envelope-Id field
2.2.1 Original封筒イド分野
The optional Original-Envelope-Id field contains an "envelope identifier" which 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封筒イド分野は、唯一、メッセージが提出された取引を特定する「封筒識別子」を含んでいて、送付者によって指定されて、送付者のMTAに供給された(a)か送付者のMTAを発生させて、メッセージを提出したとき送付者にとって利用可能にする(b)のどちらかでした。 目的は送付者(または、彼女のユーザエージェント)がメッセージが送られた特定の取引に返されたDSNを関連づけるのを許容することです。
If such an envelope identifier was present in the envelope which 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 which accompanied this message on its arrival at the Reporting MTA.
そのような封筒識別子がReporting MTAに到着して、SHOULDであるメッセージに伴った封筒に存在していたなら、メッセージを送る試みの結果、発行されたどんなDSNsのOriginal封筒イド分野でも供給してください。 封筒識別子分野がこのメッセージに到着次第Reporting MTAに伴った封筒にない場合送付者のMTA、MTA MUST NOT供給によるこの分野がDSNに発行される時を除いて。
The Original-Envelope-Id field is defined as follows:
Original封筒イド分野は以下の通り定義されます:
original-envelope-id-field =
"Original-Envelope-Id" ":" envelope-id
「元の封筒イド分野は「オリジナルの封筒イド」と等しい」:、」 封筒イド
envelope-id = *text
封筒イド=*テキスト
There may be at most one Original-Envelope-Id field per DSN.
1DSNあたりのOriginal封筒イド分野が最も1つにあるかもしれません。
The envelope-id is CASE-SENSITIVE. The DSN MUST preserve the original case and spelling of the envelope-id.
封筒イドはCASE-SENSITIVEです。 DSN MUSTは封筒イドのオリジナルのケースとスペルを保存します。
Moore & Vaudreuil Standards Track [Page 11] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[11ページ]。
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封筒イドはメッセージヘッダーからのMessage-イドと同じではありません。 Message-イドはメッセージの内容を特定しますが、Original封筒イドはメッセージが送られる取引を特定します。
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分野=「報告-MTA」」:、」 「mta名前タイプ」;、」 mta-名前
mta-name = *text
mta-名前=*テキスト
The Reporting-MTA field is defined as follows:
Reporting-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 which 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分野に現れることに注意してください。 (サーバのドメイン名はRemote-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 nondelivery 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であるというわけではないことに注意してください。 例えば、インターネットの外にメッセージを送る試みがインターネット・メールにgatewayedして戻された不着損害通知をもたらすなら、結果として起こるDSNのReporting-MTA分野は外国通知をDSNに変換したゲートウェイのものではなく、元々配信障害を報告したMTAのものでしょうに。 図2を参照してください。
Moore & Vaudreuil Standards Track [Page 12] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[12ページ]。
sender's environment recipient's environment
............................ ..........................................
: :
(1) : : (2)
+-----+ +--------+ +--------+ +---------+ +---------+ +------+
| | | | | | |Received-| | | | |
| |=>|Original|=>| |->| From |->|Reporting|-->|Remote|
| user| | MTA | | | | MTA | | MTA |<No| MTA |
|agent| +--------+ |Gateway | +---------+ +----v----+ +------+
| | | | |
| | <============| |<-------------------+
+-----+ | |(4) (3)
+--------+
: :
...........................: :.........................................
送付者の環境受取人の環境… .......................................... : : (1) : : (2) +-----+ +--------+ +--------+ +---------+ +---------+ +------+ | | | | | | |受信します。| | | | | | |=>|オリジナル|=>| |、-、>| from|、-、>|報告します。| -->、|リモート| | ユーザ| | MTA| | | | MTA| | MTA|<ノー| MTA| |エージェント| +--------+ |ゲートウェイ| +---------+ +----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 nondelivery
notification
(4) gateway translates foreign notification into a DSN
(1) メッセージはリレーする受取人の環境(2)試みようにgatewayedされて、メッセージが報告-mta(受取人の環境における)が(4) ゲートウェイが外国通知をDSNに翻訳するという不着損害通知を返す(3)に失敗するということです。
The mta-name portion of the Reporting-MTA field is formatted according to the conventions indicated by the mta-name-type subfield. 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 subfield SHOULD contain the name used by the environment from which the message was accepted by the Reporting-MTA.
mta名前タイプ部分体によって示されたコンベンションによると、Reporting-MTA分野のmta-名前部分はフォーマットされます。 MTAは異なったメール環境の間のゲートウェイとして機能して、mta-名前部分体SHOULDはメッセージがReporting-MTAによって受け入れられた環境で使用という名前を含んで、その結果、環境に依存する複数の名前によって知られています。
Because the exact spelling of an MTA name may be significant in a particular environment, MTA names are CASE-SENSITIVE.
MTA名の正確なスペルが特定の環境で重要であるかもしれないので、MTA名はCASE-SENSITIVEです。
2.2.3 The DSN-Gateway field
2.2.3 DSN-ゲートウェイ分野
The DSN-Gateway field indicates the name of the gateway or MTA which translated a foreign (non-Internet) delivery status notification into this DSN. This field MUST appear in any DSN which was translated by a gateway from a foreign system into DSN format, and MUST NOT appear otherwise.
DSN-ゲートウェイ分野は外国(非インターネットの)の配送状態通知をこのDSNに翻訳したゲートウェイかMTAという名前を示します。 ゲートウェイによって外国システムからDSN形式に翻訳されたどんなDSNにも現れなければなりません。そうでなければ、この野原は、現れてはいけません。
dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
「dsnゲートウェイ分野=「DSN-ゲートウェイ」」:、」 「mta名前タイプ」;、」 mta-名前
Moore & Vaudreuil Standards Track [Page 13] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[13ページ]。
For gateways into Internet mail, the MTA-name-type will normally be "smtp", and the mta-name will be the Internet domain name of the gateway.
通常、MTA名前タイプはインターネット・メールへのゲートウェイに関しては、"になるでしょう、そして、"smtp mta-名前はゲートウェイのインターネットドメイン名になるでしょう。
2.2.4 The Received-From-MTA DSN field
2.2.4 MTA DSNからのReceived分野
The optional Received-From-MTA field indicates the name of the MTA from which the message was received.
任意のMTAからのReceived分野はメッセージが受け取られたMTAという名前を示します。
received-from-mta-field =
"Received-From-MTA" ":" mta-name-type ";" mta-name
「mta分野から容認された=は「MTAから、受信」だった」:、」 「mta名前タイプ」;、」 mta-名前
If the message was received from an Internet host via SMTP, the contents of the mta-name subfield 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 "smtp".)
メッセージはHELOかEHLOで供給されたインターネットドメイン名がコマンドであったならインターネット・ホストからmta-名前部分体SHOULDでSMTP、コンテンツで受信されていたかどうか、そして、含まれていて、括弧に同封されたコメントとしてSMTPクライアントSHOULDによって使用されたネットワーク・アドレス。 (この場合、MTA名前タイプは"smtp"でしょう。)
The mta-name portion of the Received-From-MTA field is formatted according to the conventions indicated by the MTA-name-type subfield.
MTA名前タイプ部分体によって示されたコンベンションによると、MTAからのReceived分野のmta-名前部分はフォーマットされます。
Since case is significant in some mail systems, the exact spelling, including case, of the MTA name SHOULD be preserved.
ケースが重要であるので、いくつかのメールシステム、ケースを含むSHOULDというMTA名の正確なスペルでは、保存されてください。
2.2.5 The Arrival-Date DSN field
2.2.5 Arrival-日付の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.
任意のArrival-年月日欄はメッセージがReporting MTAに到着した日時を示します。 また、1受取人あたり1つの分野にLast試み年月日欄を提供するなら、メッセージがReporting MTAに到着した時、その受取人のためにレポートを発行したときに時間隔を決定するのにこれを使用できます。
arrival-date-field = "Arrival-Date" ":" date-time
「到着分野とデートしている=「到着日付」」:、」 日付-時間
The date and time are expressed in RFC 822 'date-time' format, as modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used.
日付と時間は[8]によって変更されるようにRFC822'日付-時間'形式で言い表されます。 数値タイムゾーン([+/-]HHMM形式)を使用しなければなりません。
2.3 Per-Recipient DSN fields
2.3 1受取人あたりの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人以上の受取人に伝言をもたらす試みの情報を含んでいます。 どんな特定の受取人への配送情報も1受取人あたりの隣接の分野のグループに含まれています。 空白行は1受取人あたりの分野の各グループに先行します。
Moore & Vaudreuil Standards Track [Page 14] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[14ページ]。
The syntax for the group of per-recipient fields is as follows:
1受取人あたりの分野のグループのための構文は以下の通りです:
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 ]
[ will-retry-until-field CRLF ]
*( extension-field CRLF )
受取人分野単位で最終受理者分野CRLF動作分野CRLF状態分野CRLF[遠く離れたmta分野CRLF][診断コード分野CRLF][最後の試み年月日欄CRLF][分野まで再試行しているCRLF]*と等しいです[元の受取人分野CRLF]。(拡大分野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.
Original-受取人分野は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 field will normally be "rfc822", and the address will be according to the syntax specified in [6]. The value "unknown" should be used if the Reporting MTA cannot determine the type of the original recipient address from the message envelope.
アドレスタイプ分野はオリジナルの受取人アドレスのタイプを示します。 メッセージがインターネットの中で由来したなら、通常、アドレスタイプ分野分野は"rfc822"でしょう、そして、[6]で指定された構文によると、アドレスがあるでしょう。 Reporting 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 [4]. This address is the same as that provided by the sender and can be used to automatically correlate DSN reports and message transactions.
この分野は任意です。 送付者の指定された受取人アドレスがメッセージ封筒に存在している場合にだけ、それは含まれているでしょうに、[4]で定義された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.
Final-受取人分野はこのセットの1受取人あたりの分野が適用される受取人を示します。 この分野はそれぞれのセットの1受取人あたりのデータに存在していなければなりません。
Moore & Vaudreuil Standards Track [Page 15] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[15ページ]。
The syntax of the field is as follows:
分野の構文は以下の通りです:
final-recipient-field =
"Final-Recipient" ":" address-type ";" generic-address
「最終受理者分野=「最終受理者」」:、」 「アドレスタイプ」;、」 一般的なアドレス
The generic-address subfield of the Final-Recipient field MUST contain the mailbox address of the recipient (from the transport envelope) as it was when the message was accepted for delivery by the Reporting MTA.
メッセージが配送のためにReporting MTAによって受け入れられた時であるときに、Final-受取人分野の一般的なアドレス部分体は受取人(輸送封筒からの)のメールボックスアドレスを含まなければなりません。
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 an 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.
Final-受取人アドレスは元々送付者によって提供されたアドレスと異なるかもしれません、推進の間、変えられて、完全に認知できない混乱にgatewayingしていたかもしれないので。 しかしながら、任意のOriginal-受取人分野がないとき、Final-受取人分野とどんな返された内容も特定のメッセージ提案があるDSNを関連させる利用可能な唯一の情報であるかもしれません。
The address-type subfield 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 may not appear in a DSN field.
以下に注意してください。 Reporting 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.
Action分野は、動作がこの受取人アドレスにメッセージを送る試みの結果、Reporting-MTAで働いたのを示します。 この分野はDSNで指定された各受取人のために存在していなければなりません。
The syntax for the action-field is:
動作分野への構文は以下の通りです。
action-field = "Action" ":" action-value
「動作分野=「動作」」:、」 動作値
action-value =
"failed" / "delayed" / "delivered" / "relayed" / "expanded"
=が「失敗する」か、「遅らせる」、「渡す」か、「リレーする」、または「広げた」動作値
Moore & Vaudreuil Standards Track [Page 16] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[16ページ]。
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.
「失敗」は、メッセージを受取人に送ることができなかったのを示します。 Reporting 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.
「延着」は、Reporting 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を全く予想するべきではありません。
"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を発生させることへの責任を引き受けない環境にリレーされるか、またはgatewayedされたのを示します。 この動作はSHOULD NOTを評価します。送付者がこの受取人のためにうまくいっている配送の通知を要求していない場合、使用されてください。
"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
[4], 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".
「メーリングリスト」という用語を使用して、[4]、セクション7.2.7で定義される「別名」: 「広げられること」の動作値は複数の受取人「別名」にメッセージを送るとき、単に使用することです。 動作値、「広げられた」SHOULD NOTでは、メッセージの配送のときに「メーリングリスト」に発行される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
動作の注意 ステータスコード: '動作'分野は'状態'分野で余分であるように思えるかもしれませんが、これはそうではありません。 特にa、「一時障害、」 (「4インチ) ステータスコードに「遅らせられた」どちらかの動作値と共に使用するか、または「失敗」であることができた」。 例えば、aがaにドメインについて質問するので、SMTPクライアントが受取人のために繰り返してメール交換器に伝言を伝えようとしますが、失敗すると仮定してください。
Moore & Vaudreuil Standards Track [Page 17] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[17ページ]。
name server timed out. 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を返す試みを捨てるかもしれません。 どれがaで始まるだろうか。ステータスコード、(「「一時障害」を示す4インチ) 両方のDSNsにおいて、同じでしょう」。
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かメール・ゲートウェイが伝言をもたらすことができないなら、それが「失敗」の'動作'分野と'XXX'のステータスコードでDSNを発行するでしょう。 メッセージが代わりにリレーされましたが、情報のいくらかの損失で同じXXXステータスコードにもかかわらず、「リレーされること」の動作分野があるDSNを発生させるかもしれないなら。
2.3.4 Status field
2.3.4 状態分野
The per-recipient Status field contains a transport-independent status code which 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.
1受取人あたりのStatus分野はメッセージの配送状態をその受取人に示す輸送から独立しているステータスコードを含んでいます。 この分野はDSNによって説明されるそれぞれの配送試みのために存在していなければなりません。
The syntax of the status field is:
状態分野の構文は以下の通りです。
status-field = "Status" ":" status-code
「状態分野=「状態」」:、」 ステータスコード
status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
「ステータスコードは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 subfield of the status-code. Each numeric
; subfield within the status-code MUST be expressed without
; leading zero digits.
; 空白類文字とコメントはaの中に許容されていません。 括弧に同封されたコメントは続くかもしれませんが、状態でコード化します。 ステータスコードの最後の数値部分体。 各数値。 ステータスコードの中の部分体を言い表さなければならない、。 先行ゼロケタ。
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 [5].
ステータスコードの始発は[5]で定義されます。
Moore & Vaudreuil Standards Track [Page 18] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[18ページ]。
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.
Remote-MTA DSN分野に関連している値は「報告している」MTAに配送状態を報告した「リモートな」MTAという名前の印刷可能なASCII表現です。
remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name
「遠く離れたmta分野=「リモートMTA」」:、」 「mta名前タイプ」;、」 mta-名前
NOTE: The Remote-MTA field preserves the "while talking to" information that was provided in some pre-existing nondelivery reports.
以下に注意してください。 Remote-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 subfield is needed to specify which type of diagnostic code is represented.
「失敗した」か「遅らせられた」受取人に関しては、Diagnostic-コードDSN分野はメール輸送で発行された実際の診断コードを含んでいます。 そのようなコードが1つのメールの輸送から別のものに異なるので、診断タイプ部分体がどのタイプの診断コードが表されるかを指定するのに必要です。
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 nondelivery reports through DSNs.
以下に注意してください。 Diagnostic-コード分野の情報はそれでStatus分野からいくらか余分であるかもしれません。 Status分野が、起源にかかわらずDSNsを分析するどんなユーザエージェントやゲートウェイにもどんなDSNも解釈できるくらい必要です。 以来、時々Statusコードは実際の輸送病気の特徴ほど正確でないコード、後者の情報を保有するためにDiagnostic-コード野原を供給するということでしょう。 そのような情報はReporting 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.
メッセージをリレーする試みの間のRemote MTAからそのMTAまでDiagnostic Codeを入手するなら、Remote-MTA分野は存在しているでしょうに。 DSNを解釈するとき、Remote-MTA分野の存在は、Diagnostic CodeがRemote MTAによって発行されたのを示します。 Remote-MTAの不在は、Diagnostic CodeがReporting MTAによって発行されたのを示します。
In addition to the Diagnostic-Code itself, additional textual description of the diagnostic, MAY appear in a comment enclosed in parentheses.
Diagnostic-コード自体に加えて、病気の特徴の追加原文の記述、5月は括弧に同封されたコメントに現れます。
Moore & Vaudreuil Standards Track [Page 19] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[19ページ]。
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.
この分野は任意です、いくつかのメールシステムが'動作'と'状態'分野で返されるそれを超えて追加情報を全く提供しないので。 しかしながら、輸送特有の診断情報が利用可能であるなら含まれていて、これはSHOULDをさばきます。
2.3.7 Last-Attempt-Date field
2.3.7 最後に年月日欄を試みてください。
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.
Last試み年月日欄はリレーする最後の試みの日時を与えます、ゲートウェイ、または、Reporting MTAで、メッセージ(うまくいくか、または失敗していることにかかわらず)を送ってください。 これは必ずメッセージのヘッダーからのDate分野の値が以前はよくこの配送状態通知を伝えていたのと同じであるというわけではありません: DSNがゲートウェイで発生した場合では、メッセージヘッダーのDate分野はゲートウェイでDSNを送って、最後の配送試みが起こったときDSN Last試み年月日欄が含む時間を含んでいます。
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 [8]. Numeric timezones ([+/-]HHMM format) MUST be used.
日付と時間は[8]によって変更されるようにRFC822'日付-時間'形式で言い表されます。 数値タイムゾーン([+/-]HHMM形式)を使用しなければなりません。
3.2.1.5 final-log-id field
3.2.1.5 最終的なログイド分野
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.
「最終的なログイド」分野は最終的なmtaによって使用されたメッセージの最終的なログイドを与えます。 これはインデックスとしてその配送試みのための最終的なmtaログエントリーの役に立つ場合があります。
final-log-id-field = "Final-Log-ID" ":" *text
「最終的なログイド分野は「最終的なLog ID」と等しい」:、」 *テキスト
This field is optional.
この分野は任意です。
2.3.8 Will-Retry-Until field
2.3.8、ウィルRetry、分野
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.
タイプのDSNsが「延着した」のでウィルRetry、分野はReporting MTAがその受取人にメッセージを送るすべての試みを捨てると予想する日付を与えます。 ウィルRetry、野原は、「遅れ」DSNsに任意であり、他のDSNsに現れてはいけません。
will-retry-until-field = "Will-Retry-Until" ":" date-time
「分野まで再試行するために望んでいる=、「ウィルRetry、」、」、:、」 日付-時間
The date and time are expressed in RFC 822 'date-time' format, as modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used.
日付と時間は[8]によって変更されるようにRFC822'日付-時間'形式で言い表されます。 数値タイムゾーン([+/-]HHMM形式)を使用しなければなりません。
Moore & Vaudreuil Standards Track [Page 20] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[20ページ]。
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.
メッセージか受取人あたりの追加DSN分野は将来、この仕様への後の改正か拡大で定義されるかもしれません。 「X」と共に始まる拡大フィールド名は標準の分野と決して定義されないでしょう。 そのような名前は実験用のために予約されます。 「X」と共に始まらないDSNフィールド名を、インターネット規定番号権威(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の物理的な推進アドレス)のしるしで始まるべきです。
(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のリモート受取人アドレス)を始めるべきです。 そのような分野はユーザエージェントかメール・ゲートウェイに使用されるのではなく、診断目的だけに使用されるべきです。
(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 which produced the DSN. (e.g. Foomail-Queue-ID).
特定のメッセージ転送エージェント(MTA)に特定の診断情報の伝達を許す(c)。 そのようなDSN分野の名前はDSNを生産したMTA実現のしるしで始まるべきです。 (例えば、Foomail Queue ID。)
MTA implementors 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 which allows the MTA maintainer to easily find the log entry for a failed delivery attempt.
MTA作成者は、必要なら、拡大分野を通って適切な情報を前提として、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 [4]), it is sufficient that delivery failure reports use this protocol.
このメモで定義されたプロトコルに応じてDSNsを発生させるなら、MTAかゲートウェイがこの仕様に一致しています。 積極的な配送通知に関する要求を支持しないMTAsとゲートウェイ、([4]) あれほど同じくらい中では、配送異常報告書がこのプロトコルを使用するのは、十分です。
Moore & Vaudreuil Standards Track [Page 21] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[21ページ]。
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.
この仕様の最小限の器具はDSNによって説明された受取人に伝言をもたらす各試み単位で1メッセージあたりのReporting-MTA分野、Final-受取人、Action、およびStatus分野だけを発生させなければなりません。 適切であるときに、他の分野の世代は強く推薦されます。
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 [4] permits such information to be carried in the envelope if it is available.)
メール転送プロトコルが服従時点で元々送付者によって指定されたアドレスを提供しない場合、MTAsとゲートウェイはDSNのOriginal-受取人分野を発生させてはいけません。 (普通のSMTPはその保証をしませんが、それが利用可能であるなら、[4]で定義された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 [4], 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.
アドレスSHOULDが最も1つでもたらすそれぞれの送付者によって指定された受取人は、その受取人のためにDSNに「渡す」か、または「失敗しました」。 積極的なDSNが「別名」の複数の受取人に送られる受取人のために要求されるなら(例えば、SMTPでNOTIFY=SUCCESSを使用する1つ)([4]、セクション7.2.7で定義されるように)、推進MTA SHOULDは通常、元々指定された受取人のために「広げられた」DSNを発行して、DSNのために要求をフォーワーディング・アドレスに伝播しません。 あるいはまた、推進MTA MAYはちょうどフォーワーディング・アドレスの1つにDSNを求める要求をリレーして、要求を他のものに伝播しません。
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.
対照的に、メーリングリスト発破器へのメッセージのうまくいっている服従はメッセージの最終的な配送であると考えられます。 メーリングリスト発破器に対応する受取人アドレスへのメッセージの配送のときに、Reporting MTA SHOULDはまるでちょうど受取人アドレスが普通のメールボックスのものであるかのように適切な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.)
以下に注意してください。 実際に、DSNsがメーリングリスト自体で使用可能になることをこの意図します。 封筒返送先はメーリングリスト加入者に送られたどんなメッセージでもリスト維持装置を示すべきです。[RFC1123(セクション5.3.7(E)])を見てください。 封筒返送先にDSNsを送るので、メーリングリストの受取人に配送から生じるすべてのDSNsをリスト維持装置に送るでしょう。 リスト維持装置は、機械的に領収書にDSNsを処理して、その結果、リストから無効のアドレスを自動的に削除するのを選ぶかもしれません。 (このメモのセクション7を見てください。)
This specification places no restrictions on the processing of DSNs received by user agents or distribution lists.
この仕様はユーザエージェントか発送先リストによって受け取られたDSNsの処理に関して制限を全く課しません。
4. Security Considerations
4. セキュリティ問題
The following security considerations apply when using DSNs:
DSNsを使用するとき、以下のセキュリティ問題は適用されます:
Moore & Vaudreuil Standards Track [Page 22] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[22ページ]。
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は普通のインターネット電子メールと同じくらい容易に鍛造されるかもしれません。 施設(メール発送先リスト発破器などの)を扱うDSNsの自動使用をしたがっているユーザエージェントと自動郵便配達人は、サービス不能攻撃から可能性のあるダメージを最小にするために適切な注意を払うべきです。
Security threats related to forged DSNs include the sending of:
偽造DSNsに関連する軍事的脅威は以下の発信を含んでいます。
(a) A falsified delivery notification when the message is not delivered
to the indicated recipient,
(b) A falsified non-delivery notification when the message was in fact
delivered to the indicated recipient,
(c) A falsified Final-Recipient address,
(d) A falsified Remote-MTA identification,
(e) A falsified relay notification when the message is "dead ended".
(f) Unsolicited DSNs
(a) (b) (c) (d) (e) メッセージが示された受取人に送られないときの改竄された配送通知、事実上示された受取人にメッセージを送ったときの改竄された非配送通知、改竄されたFinal-受取人アドレス、改竄されたRemote-MTA識別、メッセージであるときに、改竄されたリレー通知は「終わった死者」です。 (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.
セキュリティの別次元は秘密性です。 メッセージ受取人がメッセージをautoforwardingしていますが、メッセージがautoforwardedされるアドレスを明かしたがっていない場合があるかもしれません。 ポケットベルなどの「無線のメールボックス」が広く同じくらいautoforwardにより使用されたアドレスになるのに応じて、そのような秘密性に関する願望はたぶん高められるでしょう。
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:
MTA作者がエンドユーザがフォーワーディング・アドレスの秘密性を保存するのを可能にするメカニズムを提供するよう奨励されます。 必要である秘密性の程度、およびメッセージが転送されていた環境の本質によって、これは1つか、より多くで達成されるかもしれません:
(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,
(a) メッセージが秘密のフォーワーディング・アドレスに転送されて、転送されたメッセージのために積極的なDSNsを求める要求を無効にしているとき、「リレーされた」DSN(積極的な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) 渡されるべきメッセージを宣言して、再送が通信するので、秘密のフォーワーディング・アドレスにメッセージを再送して、どんなDSNsのためにも発行されるように手配しないで、aを発行すると、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
(d) 封筒返送先(例えば、SMTP MAIL FROMアドレス)をNULLに設定して、秘密のアドレスに転送されたメッセージのために
Moore & Vaudreuil Standards Track [Page 23] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[23ページ]。
reverse-path ("<>") (so that no DSNs would be sent from a downstream
MTA to the original sender),
逆経路(「<>」)(川下のMTAから元の送り主にDSNsを全く送らないように)である
(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が決してRCPTコマンドへのどんなNOTIFYを使用する=パラメタでもESMTPを使用して、DSN拡張子をサポートしないなら)、秘密のアドレスに転送されたメッセージのために。
(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.
一般に、Reporting MTAサイトが、分野の包含がサイト秘密性の大き過ぎる妥協を課すことを決定するなら、どんな任意のDSN分野も省略されるかもしれません。 そのような秘密性の必要性は問題レポートの省略された情報と外国環境へのDSNs gatewayedに関するユーティリティに対してバランスをとらなければなりません。
Implementors are cautioned that many existing MTAs will send nondelivery 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.
作成者は多くの既存のMTAsがメッセージヘッダー(1つのコネへの封筒よりむしろ)の返送先に不着損害通知を送ると警告されます、SMTPと他のプロトコルを違反して。 そのようなMTAを通してメッセージを転送すると、推進MTA側のどんな合理的な動作も、川下のMTAがフォーワーディング・アドレスで妥協するのを防がないでしょう。 受取人のMTAが同様に自動的にメッセージヘッダーで要求に基づくメッセージに応じる、(標準的でないのですが、広く使用されているのなどようにReturnが領収書を出す、拡張ヘッダー)、また、それはフォーワーディング・アドレスで妥協するでしょう。
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が発行されたという事実にもかかわらず、メッセージを送ることができる状態は存在しています。
Moore & Vaudreuil Standards Track [Page 24] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[24ページ]。
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. This will cause the SMTP client to retransmit the message, even though the SMTP server has already accepted it.[9] 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.
例えば、完成したDATAコマンドに続いて、接続が落とされますが、応答がSMTPクライアントによって見られる前を除いて、SMTPプロトコルの競合条件はメッセージの複製を考慮します。 これで、SMTPクライアントはメッセージを再送するでしょう、そして、SMTPサーバーは既にそれを受け入れましたが、.[9]はそれらの配送試みの1つであるなら成功します、そして、もう片方が失敗します、そして、メッセージは実際に受取人に届きましたが、「失敗した」DSNは発行できました。
Moore & Vaudreuil Standards Track [Page 25] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[25ページ]。
5. Appendix - collected grammar
5. 付録--集まっている文法
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 [8].
以下に注意してください。 以下の字句はRFC822で定義されます: 原子、CHAR、コメント、CR、CRLF、DIGIT、LF、直線的な余白、SPACE、テキスト。 日付-時間字句は[8]で定義されます。
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 )
配送状態内容がメッセージ分野単位で等しい、1*(CRLF、受取人分野、)
diagnostic-code-field =
"Diagnostic-Code" ":" diagnostic-type ";" *text
「診断コード分野は「診断コード」と等しい」:、」 「診断タイプ」;、」 *テキスト
diagnostic-type = atom
診断タイプは原子と等しいです。
dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
「dsnゲートウェイ分野=「DSN-ゲートウェイ」」:、」 「mta名前タイプ」;、」 mta-名前
envelope-id = *text
封筒イド=*テキスト
extension-field = extension-field-name ":" *text
「拡大分野=拡大フィールド名」:、」 *テキスト
extension-field-name = atom
拡大フィールド名=原子
final-recipient-field =
"Final-Recipient" ":" address-type ";" generic-address
「最終受理者分野=「最終受理者」」:、」 「アドレスタイプ」;、」 一般的なアドレス
generic-address = *text
一般的なアドレスは*テキストと等しいです。
last-attempt-date-field = "Last-Attempt-Date" ":" date-time
「= 「最後の試み日付」という最後の試み年月日欄」:、」 日付-時間
mta-name = *text
mta-名前=*テキスト
mta-name-type = atom
mta名前タイプは原子と等しいです。
original-envelope-id-field =
"Original-Envelope-Id" ":" envelope-id
「元の封筒イド分野は「オリジナルの封筒イド」と等しい」:、」 封筒イド
original-recipient-field =
"Original-Recipient" ":" address-type ";" generic-address
「元の受取人分野は「オリジナルの受取人」と等しい」:、」 「アドレスタイプ」;、」 一般的なアドレス
Moore & Vaudreuil Standards Track [Page 26] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[26ページ]。
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 )
メッセージ分野単位で報告しているmta分野CRLF[dsnゲートウェイ分野CRLF][mta分野から容認されたCRLF][到着年月日欄CRLF]*と等しいです[元の封筒イド分野CRLF]。(拡大分野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 ]
[ will-retry-until-field CRLF ]
*( extension-field CRLF )
受取人分野単位で最終受理者分野CRLF動作分野CRLF状態分野CRLF[遠く離れたmta分野CRLF][診断コード分野CRLF][最後の試み年月日欄CRLF][分野まで再試行しているCRLF]*と等しいです[元の受取人分野CRLF]。(拡大分野CRLF)
received-from-mta-field =
"Received-From-MTA" ":" mta-name-type ";" mta-name
「mta分野から容認された=は「MTAから、受信」だった」:、」 「mta名前タイプ」;、」 mta-名前
remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name
「遠く離れたmta分野=「リモートMTA」」:、」 「mta名前タイプ」;、」 mta-名前
reporting-mta-field =
"Reporting-MTA" ":" mta-name-type ";" mta-name
「報告しているmta分野=「報告-MTA」」:、」 「mta名前タイプ」;、」 mta-名前
status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
「ステータスコードは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 subfield of the status-code. Each numeric
; subfield within the status-code MUST be expressed without
; leading zero digits.
; 空白類文字とコメントはaの中に許容されていません。 括弧に同封されたコメントは続くかもしれませんが、状態でコード化します。 ステータスコードの最後の数値部分体。 各数値。 ステータスコードの中の部分体を言い表さなければならない、。 先行ゼロケタ。
status-field = "Status" ":" status-code
「状態分野=「状態」」:、」 ステータスコード
will-retry-until-field = "Will-Retry-Until" ":" date-time
「分野まで再試行するために望んでいる=、「ウィルRetry、」、」、:、」 日付-時間
Moore & Vaudreuil Standards Track [Page 27] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[27ページ]。
6. Appendix - Guidelines for gatewaying DSNs
6. 付録--gatewaying 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ゲートウェイ要件は他のドキュメントによって定義されるかもしれません。
6.1 Gatewaying from other mail systems to DSNs
6.1 他のメールシステムからDSNsまでGatewayingします。
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プロトコル要素のためのX400-*)
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.
ゲートウェイは、Reporting-MTA、Final-受取人、Action、およびStatus分野に適正価値を提供するのを試みなければなりません。 通常、値をリモート配送か非配送通知からそれらのインターネットスタイル同等物に翻訳することによって、これらを得るでしょう。 しかしながら、情報のいくらかの損失が予想されることになっています。 例えば、DSNsのために定義されたステータスコードのセットは、外国システムから配送の診断コードを完全に伝えるために適切でないかもしれません。 そして、ゲートウェイが失敗状態について説明する最も正確なコードを割り当てるはずであり、「一般的に」退くのが2.0などのように.0(成功)、4.0をコード化する、.0 (一時障害)、5.0 .0 (永久的な失敗) 必要であるときに。 実際の外国診断コードは、問題チケットにおける使用のためのDiagnostic-コード分野(適切な診断タイプ値がある)で保有されるべきであるか、またはトンネルを堀るべきです。
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.
送付者によって指定された受取人アドレス、およびオリジナルの封筒イド、外国輸送封筒に存在しているなら、Original-受取人とOriginal Envelope 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-ゲートウェイ分野に現れなければなりません。
Moore & Vaudreuil Standards Track [Page 28] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[28ページ]。
6.2 Gatewaying from DSNs to other mail systems
6.2 DSNsから他のメールシステムまでGatewayingします。
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.
それは外国メールシステムへのインターネットからのゲートウェイDSNsに可能であるかもしれません。 そのようなgatewayingの第一の目的は目的地システムで使用可能なフォームで配送状態情報を伝えることです。 副次目的はDSNsが外国メールシステムを通して「トンネルを堀ること」を許容することです、DSNがインターネットにgatewayedして戻されるといけないかもしれないので。
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.
できれば、ゲートウェイは、Original受取人アドレスとOriginal Envelope IDを保持するのを試みるはずです(存在しているなら)、結果として起こる外国配送現状報告で。
When reporting delivery failures, if the diagnostic-type subfield 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.
Diagnostic-コード分野の診断タイプ部分体が、元の診断コードが目的地環境に解釈されるのを示すなら配信障害を報告するとき、Diagnostic-コード分野からの情報は使用されるべきです。 それに失敗して、Status分野の情報は目的地環境で使用される中で最も近い利用可能な診断コードに写像されるべきです。
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情報を保存する手段を定義するかもしれません。
Moore & Vaudreuil Standards Track [Page 29] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[29ページ]。
7. Appendix - Guidelines for use of DSNs by mailing list exploders
7. 付録--メーリングリスト発破器によるDSNsの使用のためのガイドライン
NOTE: 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 received nondelivery reports. A "smart" mailing list exploder can therefore intercept such nondelivery 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 MAIL FROMアドレス)に受け取られていている不着損害レポートまで設定される特別なアドレスを示すように設定するはずです。 したがって、「賢い」メーリングリスト発破器はそのような不着損害レポートを傍受できて、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.
中古ですが、まさにリストに知られている加入者アドレスを合わせるべきであるので、Original-受取人分野は利用可能であるべきです。 Original-受取人分野が利用可能でないなら、受取人分野はリスト加入者アドレスに類似するかもしれません。 しかしながら、しばしば、リスト加入者が彼のメールを異なったアドレスに転送してしまうだろうか、またはアドレスはいくつかの書き直しを受けることがあるかもしれないので、発見的教授法が首尾よく受取人分野からのアドレスを合わせるのに必要であるかもしれません。 注意が、この場合偽のマッチの可能性を最小にするのに必要です。
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.
StatusとAction分野と、Diagnostic-コード分野から配信障害の理由を得ることができます(状態タイプが見分けられるなら)。 一般に、「失敗されること」を除いた動作値をもっている受取人へのレポートを無視できます。 特に、「遅らせられた」レポートのためリストから加入者を外すべきではありません。
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
しかしながら、数種類の失敗は一時的な病態、および数種類の失敗によって引き起こされた他のものがすぐに気付かれていて、他のものより修正されそうなほどありそうではありません。 加入者を削除するかどうか決めるとき、もう一度、正確なステータスコードは定義されて、ステータスコードを区別するのは役に立つかもしれません。 例えば、高いメッセージボリュームがあるリストでは、一時単に受取人を削除するよりむしろ繰り返された「一時的な」失敗を引き起こす受取人アドレスに荷渡しを中絶するのは望ましいかもしれません。 サスペンションの持続時間
Moore & Vaudreuil Standards Track [Page 30] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[30ページ]。
might depend on the type of error. On the other hand, a "user unknown" error which persisted for several days could be considered a reliable indication that address were no longer valid.
誤りのタイプに頼るかもしれません。 他方では、アドレスがあった信頼できる指示であるともう有効でなく数日間持続した「ユーザ未知」誤りを考えることができました。
8. Appendix - IANA registration forms for DSN types
8. 付録--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.
新しいアドレスタイプ、診断タイプ、またはMTA名前タイプをインターネットAssigned民数記Authority(IANA)に示すとき、以下のフォームは使用のためのものです。 登録用紙によって要求されたそれぞれの情報は、フォーム自体の情報を提供するか、または必要事項を含んでいる発行されて、公的に利用可能な仕様の指示するものを含んでいることによって、満たされるかもしれません。 IANA MAYは不完全な登録用紙、不正確な仕様、または不適当な型名でDSNタイプ登録証明書を拒絶します。
To register a DSN type, complete the applicable form below and send it via Internet electronic mail to <IANA@IANA.ORG>.
DSNタイプを示して、以下の適切な用紙に記入して、インターネット電子メール to <IANA@IANA.ORG を通してそれを送る、gt。
8.1 IANA registration form for address-type
8.1 アドレスタイプのための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) このタイプのアドレスが米国-ASCIIレパートリーから完全な図形文字で構成されないなら、それらがグラフィック米国-ASCII文字としてDSN Original-受取人かFinal-受取人DSN分野でどうコード化されることになっているかために、仕様です。
(d) [optional] A specification for how addresses of this type are to be
translated to and from Internet electronic mail addresses.
(d) [任意の] アドレスとインターネット電子メールアドレスからどう翻訳されるかためにはこのタイプのアドレスがことである仕様。
8.2 IANA registration form for diagnostic-type
8.2 診断タイプのための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) 図形文字として米国-ASCIIレパートリーからこのタイプの診断コードを表すのに使用されるべき構文の記述。
Moore & Vaudreuil Standards Track [Page 31] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[31ページ]。
(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])で定義されるように。
8.3 IANA registration form for MTA-name-type
8.3 MTA名前タイプのためのIANA登録用紙
A registration for a DSN MTA-name-type must include the following information:
DSN MTA名前タイプのための登録は以下の情報を含まなければなりません:
(a) The proposed MTA-name-type name.
(a) 提案されたMTA名前型名。
(b) A description of the syntax of MTA names of this type, using BNF,
regular expressions, ASN.1, or other non-ambiguous language.
(b) このタイプ、BNFを使用するか、正規表現、ASN.1、または他の非あいまいな言語のMTA名の構文の記述。
(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名が米国-ASCIIレパートリーからの図形文字から完全に成らないなら、このタイプのMTA名がグラフィック米国-ASCII文字の系列としてどう表されるべきであるかために、仕様です。
Moore & Vaudreuil Standards Track [Page 32] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[32ページ]。
9. Appendix - Examples
9. 付録--例
NOTE: 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 subfield 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.
これらの例は、送り返されたメッセージからどんな利用可能であった情報も使用することで手動で翻訳されました。
Moore & Vaudreuil Standards Track [Page 33] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[33ページ]。
9.1 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.
9.1 これは伝言をもたらす繰り返された試みが失敗した後に発行された簡単な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"
日付: 木曜日、1994年7月7日の17:16:05 -0400From: 配送 Subsystem <MAILER-DAEMON@CS.UTK.EDU に郵送してください、gt;、メッセージイド: <199407072116.RAA14128@CS.UTK.EDU>Subject: 返されたメール: 5日間To:へのメッセージを送ることができません。 <の、より自己のインフォメーションのパントマイム@cs.utk.eduの>MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは配送状態と等しいです。 境界="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
root@localhost からの土曜日、1994年7月2日17:10:28 -0400にオリジナルのメッセージを受け取りました。
----- The following addresses had delivery problems -----
<louisl@larry.slip.umd.edu> (unrecoverable error)
----- 以下のアドレスには、配送問題がありました。----- <louisl@larry.slip.umd.edu>。(回復不能エラー)
----- 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
----- セッションの転写は続きます。----- <louisl@larry.slip.umd.edu>… 延期される: 接続はlarry.slip.umd.eduによる外で調節しました。 メッセージは5日間渡して、Messageが待ち行列から削除されるということであることができませんでした。
--RAA14128.773615765/CS.UTK.EDU content-type: message/delivery-status
--RAA14128.773615765/CS.UTK.EDUの満足しているタイプ: 配送メッセージ/状態
Reporting-MTA: dns; cs.utk.edu
報告している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
オリジナルの受取人: rfc822;louisl@larry.slip.umd.edu 最終受理者: rfc822;louisl@larry.slip.umd.edu 動作: 失敗したStatus: 4.0.0 診断コード: smtp。 426 接続は出ているLast試み日付:を調節しました。 木曜日、1994年7月7日17:15:49 -0400
--RAA14128.773615765/CS.UTK.EDU content-type: message/rfc822
--RAA14128.773615765/CS.UTK.EDUの満足しているタイプ: メッセージ/rfc822
[original message goes here] --RAA14128.773615765/CS.UTK.EDU--
[オリジナルのメッセージはここに行きます] --RAA14128.773615765/CS.UTK.EDU--
Moore & Vaudreuil Standards Track [Page 34] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[34ページ]。
9.2 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.
9.2 これは多重配信試みの詳細を含む送付者の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"
日付: 金曜日、1994年7月8日の09:21:47 -0400From: 配送 Subsystem <MAILER-DAEMON@CS.UTK.EDU に郵送してください、gt;、Subject: 返されたメール: ユーザ未知To: <所有者mib@CS.UTK.EDU>を上げているMIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは配送状態と等しいです。 境界="JAA13167.773673707/CS.UTK.EDU"
--JAA13167.773673707/CS.UTK.EDU content-type: text/plain; charset=us-ascii
--JAA13167.773673707/CS.UTK.EDUの満足しているタイプ: テキスト/平野。 charsetが私たちと等しい、-、ASCII
----- The following addresses had delivery problems -----
<arathib@vnet.ibm.com> (unrecoverable error)
<wsnell@sdcc13.ucsd.edu> (unrecoverable error)
----- 以下のアドレスには、配送問題がありました。----- <arathib@vnet.ibm.com>(回復不能エラー) <wsnell@sdcc13.ucsd.edu 、gt。(回復不能エラー)
--JAA13167.773673707/CS.UTK.EDU content-type: message/delivery-status
--JAA13167.773673707/CS.UTK.EDUの満足しているタイプ: 配送メッセージ/状態
Reporting-MTA: dns; cs.utk.edu
報告している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
オリジナルの受取人: rfc822;arathib@vnet.ibm.com 最終受理者: rfc822;arathib@vnet.ibm.com 動作: 失敗したStatus: 5.0.0 (永久的な失敗)診断コード: smtp。 550 ' arathib@vnet.IBM.COM 'は登録されたゲートウェイユーザ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)
オリジナルの受取人: rfc822;johnh@hpnjld.njd.hp.com 最終受理者: rfc822;johnh@hpnjld.njd.hp.com 動作: 遅れたStatus: 4.0.0 (hpnjld.njd.jp.com: ホスト名ルックアップ失敗)
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
オリジナルの受取人: rfc822;wsnell@sdcc13.ucsd.edu 最終受理者: rfc822;wsnell@sdcc13.ucsd.edu 動作: 失敗したStatus: 5.0.0 診断コード: smtp。 550 ユーザの未知のRemote-MTA: dns。 sdcc13.ucsd.edu
--JAA13167.773673707/CS.UTK.EDU content-type: message/rfc822
--JAA13167.773673707/CS.UTK.EDUの満足しているタイプ: メッセージ/rfc822
Moore & Vaudreuil Standards Track [Page 35] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[35ページ]。
[original message goes here] --JAA13167.773673707/CS.UTK.EDU--
[オリジナルのメッセージはここに行きます] --JAA13167.773673707/CS.UTK.EDU--
9.3 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.
9.3 DSNにMessage Router(MAILBUS)によって発生して、PMDF_MRによってgatewayedされた配送レポート。 この場合、ゲートウェイには、オリジナルの受取人アドレスを供給できるくらいの情報がありませんでした。
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"
受取人を明らかにします: 日付:を禁止します。 金曜日、1994年7月8日09:21:25 -0400(東部夏時間の)のFrom: メッセージルータ提案 Agent <AMMGR@corp.timeplex.com 、gt;、Subject: 以下の状態 Re: バッテリーの現在の感覚To: owner-ups-mib@CS.UTK.EDU メッセージイド: <01HEGJ0WNBY28Y95LN@mr.timeplex.com>MIMEバージョン: 1.0 満足しているタイプ: 複合/レポート。 レポートタイプは配送状態と等しいです。 境界="84229080704991.122306.SYS30""
--84229080704991.122306.SYS30 content-type: text/plain
--84229080704991.122306.SYS30の満足しているタイプ: テキスト/平野
Invalid address - nair_s %DIR-E-NODIRMTCH, No matching Directory Entry found
無効のアドレス--nair_s%ディルE- NODIRMTCH、Entryが見つけなかった合っているディレクトリ全く
--84229080704991.122306.SYS30 content-type: message/delivery-status
--84229080704991.122306.SYS30の満足しているタイプ: 配送メッセージ/状態
Reporting-MTA: mailbus; SYS30
報告しているMTA: mailbus。 SYS30
Final-Recipient: unknown; nair_s Status: 5.0.0 (unknown permanent failure) Action: failed
最終受理者: 未知。 nair_s Status: 5.0.0 (未知の永久的な失敗)動作: 失敗されます。
--84229080704991.122306.SYS30--
--84229080704991.122306.SYS30--
Moore & Vaudreuil Standards Track [Page 36] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[36ページ]。
9.4 A delay report from a multiprotocol MTA. Note that there is no
returned content, so no third body part appears in the DSN.
9.4 multiprotocol MTAからの遅れレポート。 身体の部分がDSNで見える3番目が全くそのように満足していた状態で返されないことに注意してください。
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
From: <郵便局長@nsfnet、-、relay.ac.uk>メッセージイド: <199407092338.TAA23293@CS.UTK.EDU>は受信されました: sun2.nsfnet-relay.ac.uk id <g.12954-0@sun2.nsfnet-relay.ac.uk によるnsfnet-relay.ac.uk、gt;、。 Sun、1994年7月10日の00:36:51+0100To: owner-info-mime@cs.utk.edu 日付: Sun、1994年7月10日の00:36:51+0100Subject: 警告: メッセージは"nsfnet-relay.ac.uk"満足しているタイプで延着しました: 複合/レポート。 レポートタイプは配送状態と等しいです。 境界=foobar
--foobar content-type: text/plain
--foobarの満足しているタイプ: テキスト/平野
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, ie 7 days.
配送は、7日間168時間、ieの総経過時間まで試みられ続けるでしょう。
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の満足しているタイプ: 配送メッセージ/状態
Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk
報告しているMTA: dns。 sun2.nsfnet-relay.ac.uk
Final-Recipient: rfc822;thomas@de-montfort.ac.uk Status: 4.0.0 (unknown temporary failure) Action: delayed
最終受理者: rfc822;thomas@de-montfort.ac.uk 状態: 4.0.0 (未知の一時障害)動作: 延着します。
Moore & Vaudreuil Standards Track [Page 37] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[37ページ]。
--foobar--
--foobar--
10. Acknowledgments
10. 承認
The authors wish to thank the following people for their reviews of earlier drafts of this document 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.
作者は彼らのこのドキュメントと彼らの改善提案の以前の草稿のレビューについて以下の人々に感謝したがっています: エリック・オールマン、ハラルドAlvestrand、アランCargille、ジム・コンクリン、ピーター・カウエン、デーヴ・クロッカー、ロジャーFajman、解放されたネッド、マルコKaittola、スティーブKille、ジョンKlensin、ジョン・ガーディナー・マイアーズはNahabedian、ジュリアンOnions、ヤコブ・パルメ、ジーン・チャールズ・ロイ、およびグレゴリー・シーハンをマークします。
11. References
11. 参照
[1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions",
RFC 1521, Bellcore, Innosoft, September 1993.
Borenstein(N.)が解放した[1]、N.「マルチパーパスインターネットメールエクステンション」、RFC1521、Bellcore、Innosoft、1993年9月。
[2] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting
of Mail System Administrative Messages", RFC 1892, Octal Network
Services, January 1996.
[2] ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポート満足しているタイプ」、RFC1892、8進ネットワーク・サービス(1996年1月)。
[3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[3] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。
[4] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC 1891, University of Tennessee, January 1996.
[4] ムーア、K.、「配送状態通知のためのSMTPサービス拡張子」、RFC1891、テネシー大学、1996年1月。
[5] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, Octal
Network Services, January 1996.
[5] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC1893、8進ネットワーク・サービス、1996年1月。
[6] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[6] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
[7] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Two:
Message Header Extensions for Non-Ascii Text", RFC 1522, University
of Tennessee, September 1993.
[7] ムーア、K. 「パートTwoをまねてください(マルチパーパスインターネットメールエクステンション)」 「非アスキーテキストのためのメッセージヘッダー拡張子」、RFC1522、テネシー大学、1993年9月。
[8] Braden, R. (ed.) "Requirements for Internet Hosts - Application and
Support", STD 3, RFC 1123, USC/Information Sciences Institute,
October 1989.
[8] ブレーデン、R.編 「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、科学が設けるUSC/情報、10月1989日
[9] Partridge, C., "Duplicate Messages and SMTP", RFC 1047, BBN,
February 1988.
[9] ヤマウズラ、C.が「メッセージとSMTPをコピーする」、RFC1047、BBN、2月1988日
Moore & Vaudreuil Standards Track [Page 38] RFC 1894 Delivery Status Notifications January 1996
ムーアとボードルイ規格は配送状態通知1996年1月にRFC1894を追跡します[38ページ]。
11. Authors' Addresses
11. 作者のアドレス
Keith Moore University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 USA
キースムーアテネシー大学107歌曲Hallノクスビル、テネシー37996-1301米国
EMail: moore@cs.utk.edu Phone: +1 615 974 3126 Fax: +1 615 974 8296
メール: moore@cs.utk.edu 電話: +1 615 974、3126Fax: +1 615 974 8296
Gregory M. Vaudreuil Octel Network Services 17080 Dallas Parkway Dallas, TX 75248-1905 USA
グレゴリーM.ボードルイのOctelネットワーク・サービス17080ダラスParkwayテキサス75248-1905ダラス(米国)
EMail: Greg.Vaudreuil@Octel.Com
メール: Greg.Vaudreuil@Octel.Com
Moore & Vaudreuil Standards Track [Page 39]
ムーアとボードルイ標準化過程[39ページ]
一覧
スポンサーリンク
