RFC3464 日本語訳
3464 An Extensible Message Format for Delivery Status Notifications.K. Moore, G. Vaudreuil. January 2003. (Format: TXT=83060 bytes) (Obsoletes RFC1894) (Updated by RFC4865, RFC5337) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Moore
Request for Comments: 3464 University of Tennessee
Obsoletes: 1894 G. Vaudreuil
Category: Standards Track Lucent Technologies
January 2003
コメントを求めるワーキンググループK.ムーア要求をネットワークでつないでください: 3464年のテネシー大学は以下を時代遅れにします。 1894年のG.ボードルイカテゴリ: 標準化過程ルーセントテクノロジーズ2003年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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail.
このメモはメッセージ転送エージェント(MTA)か電子メールゲートウェイによって使用される、1人以上の受取人に伝言をもたらす試みの結果を報告するかもしれないマルチパーパスインターネットメールエクステンション(MIME)の満足しているタイプを定義します。 この満足しているタイプは現在インターネット電子メールで使用されている様々なタイプに関する配送状態通知とのマシン-処理可能交換として意図します。
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network (LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail.
インターネットと他のメッセージシステム(X.400かいわゆる「ローカル・エリア・ネットワーク(LAN)ベース」のシステムなどの)の間に多くのメッセージを送るので、Delivery Status Notification(DSN)プロトコルは環境を通信させながらマルチプロトコルで役に立つように設計されています。 このために、このメモで説明されたプロトコルは「外国」のアドレスとエラーコードのキャリッジに備えます、通常、インターネット・メールで使用されるものに加えて。 また、追加属性は、インターネット・メールによる外国通知が「トンネルを堀ること」を支持するために定義されるかもしれません。
Moore & Vaudreuil Standards Track [Page 1] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
1.1 Purposes .....................................................3
1.2 Requirements .................................................4
1.3 Terminology ..................................................5
2. Format of a Delivery Status Notification ........................7
2.1 The message/delivery-status content-type .....................9
2.1.1 General conventions for DSN fields ........................9
2.1.2 "*-type" sub-fields .......................................9
2.1.3 Lexical tokens imported from RFC 822 .....................10
2.2 Per-Message DSN Fields ......................................11
2.2.1 The Original-Envelope-Id field ...........................11
2.2.2 The Reporting-MTA DSN field ..............................12
2.2.3 The DSN-Gateway field ....................................13
2.2.4 The Received-From-MTA DSN field ..........................14
2.2.5 The Arrival-Date DSN field ...............................14
2.3 Per-Recipient DSN fields ....................................14
2.3.1 Original-Recipient field .................................15
2.3.2 Final-Recipient field ....................................15
2.3.3 Action field .............................................16
2.3.4 Status field .............................................18
2.3.5 Remote-MTA field .........................................19
2.3.6 Diagnostic-Code field ....................................19
2.3.7 Last-Attempt-Date field ..................................20
2.3.8 final-log-id field .......................................20
2.3.9 Will-Retry-Until field ...................................20
2.4 Extension fields ............................................21
3. Conformance and Usage Requirements .............................22
4. Security Considerations ........................................23
4.1 Forgery .....................................................23
4.2 Confidentiality .............................................23
4.3 Non-Repudiation .............................................25
5. References .....................................................25
6. Acknowledgments ................................................26
Appendix A - Collected Grammar ....................................27
Appendix B - Guidelines for Gatewaying DSNS .......................29
Gatewaying from other mail systems to DSNs ......................29
Gatewaying from DSNs to other mail systems ......................30
Appendix C - Guidelines for Use of DSNS By Mailing List Exploders .30
Appendix D - IANA Registration Forms for DSN Types ................31
IANA registration form for address-type .........................32
IANA registration form for diagnostic-type ......................32
IANA registration form for MTA-name-type ........................32
Appendix E - Examples .............................................33
Simple DSN ......................................................34
Multi-Recipient DSN .............................................35
DSN from gateway to foreign system ..............................36
1. 序論…3 1.1の目的…3 1.2の要件…4 1.3用語…5 2. 配送状態通知の形式…7 2.1 配送メッセージ/状態の満足しているタイプ…9 2.1 .1 DSN分野への一般コンベンション…9 「2.1に、.2はインチ*でタイプする」というサブ分野…9 2.1 RFC822から輸入された.3個の字句…10 2.2 1メッセージあたりのDSN分野…11 2.2 .1 Original封筒イド分野…11 2.2 .2 Reporting-MTA DSN分野…12 2.2 .3 DSN-ゲートウェイ分野…13 2.2 .4 MTA DSNからのReceived分野…14 2.2 .5 Arrival-日付のDSN分野…14 2.3 1受取人あたりのDSN分野…14 2.3 .1オリジナルの受取人分野…15 2.3 .2最終的な受取人分野…15 2.3 .3動作分野…16 2.3 .4状態分野…18 2.3 .5リモートMTA分野…19 2.3 .6診断コード分野…19 2.3 .7 最後に年月日欄を試みてください…20 2.3 .8最終的なログイド分野…20 2.3 .9、ウィルRetry、分野…20 2.4 拡大分野…21 3. 順応と用法要件…22 4. セキュリティ問題…23 4.1偽造…23 4.2秘密性…23 4.3 非拒否…25 5. 参照…25 6. 承認…26 付録A--文法を集めます…27付録B--、Gatewaying DSNSのためのガイドライン…29 他のメールシステムからDSNsまでGatewayingします…29 DSNsから他のメールシステムまでGatewayingします…30 付録C--メーリングリスト発破器.30付録DによるDSNSの使用のためのガイドライン--IANA登録はDSNタイプのために形成されます…31 アドレスタイプのためのIANA登録用紙…32 診断タイプのためのIANA登録用紙…32 MTA名前タイプのためのIANA登録用紙…32付録E--、例…33 簡単なDSN…34 マルチ受取人DSN…外国システムへのゲートウェイからの35DSN…36
Moore & Vaudreuil Standards Track [Page 2] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[2ページ]。
Delayed DSN .....................................................37
Appendix F - Changes from RFC 1894 ................................38
Authors' Addresses ................................................39
Full Copyright Statement ..........................................40
DSNを遅らせます…37 付録F--RFC1894からの変化…38人の作者のアドレス…39 完全な著作権宣言文…40
1. Introduction
1. 序論
This memo defines a Multipurpose Internet Mail Extensions (MIME) [MIME1] content-type for Delivery Status Notifications (DSNs). A DSN can be used to notify the sender of a message of any of several conditions: failed delivery, delayed delivery, successful delivery, or the gatewaying of a message into an environment that may not support DSNs. The "message/delivery-status" content-type defined herein is intended for use within the framework of the "multipart/report" content type defined in [REPORT].
このメモはDelivery Status Notifications(DSNs)のための満足しているタイプのマルチパーパスインターネットメールエクステンション(MIME)[MIME1]を定義します。 いくつかの状態のどれかに関するメッセージについて送付者に通知するのにDSNを使用できます: DSNsを支持しないかもしれない環境へのメッセージの失敗した配送、遅延分娩、うまくいっている配送、またはgatewaying。 ここに定義された「配送メッセージ/状態」満足しているタイプは使用のために[REPORT]で定義された「複合/レポート」満足しているタイプの枠組みの中で意図します。
This memo defines only the format of the notifications. An extension to the Simple Message Transfer Protocol (SMTP) [SMTP] to fully support such notifications is the subject of a separate memo [DRPT].
このメモは通知の書式だけを定義します。 そのような通知を完全に支持するSimple Message Transferプロトコル(SMTP)[SMTP]への拡大は別々のメモ[DRPT]の対象です。
Document Conventions
ドキュメントコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
1.1 Purposes
1.1 目的
The DSNs defined in this memo are expected to serve several purposes:
このメモで定義されたDSNsがいくつかの目的に役立つと予想されます:
(a) Inform human beings of the status of message delivery processing,
as well as the reasons for any delivery problems or outright
failures, in a manner that is largely independent of human
language and media;
(a) メッセージ配送処理の状態について人間に知らせてください、どんな配送問題や完全な失敗の理由と同様に、人間の言語とメディアから主に独立している方法で。
(b) Allow mail user agents to keep track of the delivery status of
messages sent, by associating returned DSNs with earlier message
transmissions;
(b) メールユーザエージェントにメッセージの状態が送った配送に動向をおさえさせてください、以前のメッセージ送信に返されたDSNsを関連づけることによって。
(c) Allow mailing list exploders to automatically maintain their
subscriber lists when delivery attempts repeatedly fail;
(c) 配送試みが繰り返して失敗するときにはメーリングリスト発破器にそれらの加入者名簿を自動的に維持させてください。
(d) Convey delivery and non-delivery notifications resulting from
attempts to deliver messages to "foreign" mail systems via a
gateway;
(d) ゲートウェイを通して「外国」のメールシステムにメッセージを渡す試みから生じる配送と非配送通知を伝えてください。
Moore & Vaudreuil Standards Track [Page 3] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[3ページ]。
(e) Allow "foreign" notifications to be tunneled through a MIME-
capable message system and back into the original messaging
system that issued the original notification, or even to a third
messaging system;
(e) 「外国」の通知にMIMEのできるメッセージシステムを通してオリジナルの通知を発行したオリジナルのメッセージシステムか、3番目のメッセージシステムにさえ行き帰りトンネルを堀らされてください。
(f) Allow language-independent and medium-independent, yet reasonably
precise, indications of the reason for the failure of a message
to be delivered; and
(f) 渡されるべきメッセージの失敗の理由の言語から独立していて、媒体から独立していますが、合理的に正確なしるしを許容してください。 そして
(g) Provide sufficient information to remote MTA maintainers (via
"trouble tickets") so that they can understand the nature of
reported errors. This feature is used in the case that failure
to deliver a message is due to the malfunction of a remote MTA
and the sender wants to report the problem to the remote MTA
administrator.
(g) 彼らが報告された誤りの本質を理解できるように、リモートMTA維持装置(「問題チケット」を通した)に十分な情報を供給してください。 伝言をもたらさない場合リモートMTAの不調のためにあって、この特徴は使用されています、そして、送付者はリモートMTA管理者に問題を報告したがっています。
1.2 Requirements
1.2 要件
These purposes place the following constraints on the notification protocol:
これらの目的は通知プロトコルに以下の規制を置きます:
(a) It must be readable by humans as well as being machine-parsable.
(a) それはマシン「パー-可能」であることと同様に人間で読み込み可能であるに違いありません。
(b) It must provide enough information to allow message senders (or
the user agents) to unambiguously associate a DSN with the
message that was sent and the original recipient address for
which the DSN is issued (if such information is available), even
if the message was forwarded to another recipient address.
(b) メッセージ送付者(または、ユーザエージェント)が明白に送られたメッセージとDSNが発行されるオリジナルの受取人アドレスにDSNを関連づけるのを許容できるくらいの情報を提供しなければなりません(そのような情報が利用可能であるなら)、別の受取人アドレスにメッセージを転送したとしても。
(c) It must be able to preserve the reason for the success or failure
of a delivery attempt in a remote messaging system, using the
"language" (mailbox addresses and status codes) of that remote
system.
(c) リモートメッセージシステムにおける、配送試みの成否の理由を保存できなければなりません、そのリモートシステムの「言語」(メールボックスアドレスとステータスコード)を使用して。
(d) It must also be able to describe the reason for the success or
failure of a delivery attempt, independent of any particular
human language or of the "language" of any particular mail
system.
(d) また、配送試みの成否の理由について説明できなければなりません、どんな特定の人間の言語かどんな特定のメールシステムの「言語」からも、独立しています。
(e) It must preserve enough information to allow the maintainer of a
remote MTA to understand (and if possible, reproduce) the
conditions that caused a delivery failure at that MTA.
(e) それはリモートMTAの維持装置がそのMTAで配信障害を引き起こした状態を理解しているのを(できれば、再生してください)許容できるくらいの情報を保存しなければなりません。
(f) For any notifications issued by foreign mail systems, which are
translated by a mail gateway to the DSN format, the DSN must
preserve the "type" of the foreign addresses and error codes, so
that these may be correctly interpreted by gateways.
(f) DSN形式へのメール・ゲートウェイによって翻訳される外国メールシステムによって発行されたどんな通知のためにもDSNは外国アドレスとエラーコードの「タイプ」を保存しなければなりません、ゲートウェイで正しくこれらを解釈できるように。
Moore & Vaudreuil Standards Track [Page 4] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[4ページ]。
A DSN contains a set of per-message fields that identify the message and the transaction during which the message was submitted, along with other fields that apply to all delivery attempts described by the DSN. The DSN also includes a set of per-recipient fields to convey the result of the attempt to deliver the message to each of one or more recipients.
DSNはメッセージを特定する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が特定の受取人アドレスの中古の、そして、異なった形式である目的によるのが必要でしょう。
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
MTAが、それが1人以上の受取人に伝言を伝えなければならないことを決定しますが、「次のホップ」MTAにメッセージを移すことができないで、「次のホップ」MTAが、メッセージがそうであるはずがない受取人を代表してDSNを発行するために意図している受取人のより多くのひとり、MTAが必要とするかもしれないリレーにメッセージの配送への責任を引き受けるのを拒否するかどうか決定するなら
Moore & Vaudreuil Standards Track [Page 5] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[5ページ]。
delivered. In this case the relaying MTA is the Reporting MTA,
and the "next hop" MTA is known as the Remote MTA.
渡す。 この場合、リレーしているMTAはReporting MTAです、そして、「次のホップ」MTAはRemote MTAとして知られています。
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 that 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.
元々メッセージ送信者によってOriginal MTAに指定されて、理想的に、DSNがそれぞれの受取人のアドレスを含む+。
This version of the address is needed (rather than a forwarding
address or some modified version of the original address) so that
the sender may compare the recipient address in the DSN with the
address in the sender's records (e.g., an address book for an
individual, the list of subscribers for a mailing list) and take
appropriate action.
アドレスのこのバージョンが、送付者が送付者の記録(例えば、個人のためのアドレス帳、メーリングリストのための応募者名簿)のアドレスとDSNの受取人アドレスを比べて、適切な行動を取ることができるくらい必要です(フォーワーディング・アドレスかオリジナルのアドレスの何らかの変更されたバージョンよりむしろ)。
Similarly, the DSN might contain an "envelope identifier" that was
known to both the sender's user agent and the Original MTA at the
time of message submission, and which, if included in the DSN, can
be used by the sender to keep track of which messages were or were
not delivered.
同様に、DSNはメッセージ提案時点で、送付者のユーザエージェントと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によって見られたもの)の「最終的な」フォームはオリジナル(送付者によって指定された)の受取人アドレスと異なるでしょう。 メッセージ配送が失敗したサイトの郵便局長に問題を報告するとき、「最終的な」アドレスが必要です、彼女が最終的な受取人アドレスだけで失敗を引き起こした状態を再生させることができるのでちょうど送付者のユーザエージェント(または、送付者)がオリジナルの受取人アドレスを好むように。
Moore & Vaudreuil Standards Track [Page 6] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[6ページ]。
+ A "failed" DSN should contain the most accurate explanation for the
delivery failure that is available. For ease of interpretation,
this information should be a format that is independent of the mail
transport system that issued the DSN. However, if a foreign error
code is translated into some transport-independent format, some
information may be lost. It is therefore desirable to provide both
a transport-independent status code and a mechanism for reporting
transport-specific codes. Depending on the circumstances that
produced delivery failure, the transport-specific code might be
obtained from either the Reporting MTA or the Remote MTA.
+ 「失敗した」DSNは利用可能な配信障害のための最も正確な説明を含むはずです。 解釈の容易さのために、この情報はDSNを発行したメール輸送システムから独立している形式であるべきです。 しかしながら、外国エラーコードが何らかの輸送から独立している形式に翻訳されるなら、何らかの情報が失われるかもしれません。 したがって、輸送から独立しているステータスコードとメカニズムの両方を輸送特有のコードを報告するのに提供するのは望ましいです。 配信障害を生産した事情によって、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" sub-field followed by a sub-field whose contents are ordinary text characters, and the format of which is indicated by the "type" sub-field. This allows a DSN to convey these quantities regardless of format.
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 [REPORT]). When a multipart/report content is used to transmit a DSN:
DSNはトップレベルの満足しているタイプの複合/レポート([REPORT]では、定義される)があるMIMEメッセージです。 複合/レポート内容がDSNを伝えるのに使用されるとき:
(a) The report-type parameter of the multipart/report content is
"delivery-status".
(a) 複合/レポート内容に関するレポート型引数は「配送状態」です。
(b) The first component of the multipart/report contains a human-
readable explanation of the DSN, as described in [REPORT].
(b) 複合/レポートの最初の成分は[REPORT]で説明されるようにDSNの人間の読み込み可能な説明を含んでいます。
Moore & Vaudreuil Standards Track [Page 7] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[7ページ]。
(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番目の成分として現れます。
NOTE: For delivery status notifications gatewayed from foreign systems, the headers of the original message may not be available. In this case the third component of the DSN may be omitted, or it may contain "simulated" RFC 822 headers that contain equivalent information. In particular, it is very desirable to preserve the subject, date, and message-id (or equivalent) fields from the original message.
以下に注意してください。 外国システムから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 still be issued in response to a single message submission.
特定のDSNはまさに1つのメッセージのために配送状態について説明します。 しかしながら、MTA MAYは同じメッセージの数人の受取人のために独身のDSNで配送状態に関して報告します。 メール輸送システム(受取人へのメッセージの配送への責任が数個のMTAsの中で分けられるかもしれなくて、どんな特定の受取人への配送も遅れるかもしれないところ)の本質のため、複数のDSNsがまだただ一つのメッセージ提案に対応して発行されているかもしれません。
Moore & Vaudreuil Standards Track [Page 8] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[8ページ]。
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 [RFC822]). The per-message fields appear first, followed by a blank line. Following the per-message fields are one or more groups of per-recipient fields. Each group of per-recipient fields is preceded by a blank line. Using the ABNF of RFC 822, the syntax of the message/delivery-status content is as follows:
配送メッセージ/状態のボディーはRFC822ヘッダー「分野」のABNFによると、フォーマットされた1「分野」から成ります([RFC822]を見てください)。 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で説明されます。 1受取人あたりの分野はセクション2.3で説明されます。
2.1.1 General conventions for DSN fields
2.1.1 DSN分野への総会
Since these fields are defined according to the rules of RFC 822, the same conventions for continuation lines and comments apply. Notification fields may be continued onto multiple lines by beginning each additional line with a SPACE or HTAB. Text that appears in parentheses is considered a comment and not part of the contents of that notification field. Field names are case-insensitive, so the names of notification fields may be spelled in any combination of upper and lower case letters. Comments in DSN fields may use the "encoded-word" construct defined in [MIME3].
RFC822の規則に従ってこれらの分野が定義されるので、継続行とコメントのための同じコンベンションは適用されます。 通知分野は、SPACEかHTABと共にそれぞれの追加線を始めることによって、複数の線に続けられるかもしれません。 括弧に現れるテキストは部分ではなく、その通知分野のコンテンツのコメントであると考えられます。 フィールド名が大文字と小文字を区別しないので、通知分野の名前は大文字と小文字手紙のどんな組み合わせでもつづられるかもしれません。 DSN分野でのコメントは[MIME3]で定義された「コード化された単語」構造物を使用するかもしれません。
2.1.2 "*-type" sub-fields
「2.1.2」 」 サブ分野を*でタイプしてください。
Several DSN fields consist of a "-type" sub-field, followed by a semicolon, followed by "*text". For these fields, the keyword used in the address-type, diagnostic-type, or MTA-name-type sub-field indicates the expected format of the address, status-code, or MTA-name which follows.
「いくつかのDSN分野がセミコロンがあとに続いたサブ分野が」 *テキストを続けた「タイプ」から成ります。」 これらの分野に、アドレスタイプ、診断タイプ、またはMTA名前タイプサブ分野で使用されるキーワードは従うアドレス、ステータスコード、またはMTA-名前の予想された書式を示します。
Moore & Vaudreuil Standards Track [Page 9] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[9ページ]。
The "-type" sub-fields 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 [SMTP], the "smtp" diagnostic-type
is used.
(b) 「診断タイプ」はステータスコードの形式を指定します。 DSN分野がシンプルメールトランスファプロトコル[SMTP]で報告された回答コードを含むとき、例えば、"smtp"診断タイプは使用されています。
diagnostic-type = atom
診断タイプは原子と等しいです。
(c) An "MTA-name-type" specifies the format of an MTA name. For
example, for an SMTP server on an Internet host, the MTA name is
the domain name of that host, and the "dns" MTA-name-type is
used.
(c) 「MTA名前タイプ」は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 one or more specifications that provide such descriptions. (The "rfc822" address-type, "smtp" diagnostic-type, and "dns" MTA-name-type are defined in [DRPT].) Registration forms for address-type, diagnostic-type, and MTA-name-type appear in Appendix D.
インターネットAssigned民数記Authority(IANA)はアドレスタイプ、診断タイプ、およびMTA名前タイプの登録を維持するでしょう、意味の記述とそれぞれの許容値、またはそのような記述を提供する1つ以上の仕様の参照と共に。 ("rfc822"アドレスタイプ、"smtp"診断タイプ、および"dns"MTA名前タイプは[DRPT]で定義されます。) アドレスタイプ、診断タイプ、およびMTA名前タイプのための登録用紙はAppendix Dに現れます。
IANA will not accept registrations for any address-type, diagnostic-type, or MTA-name-type name that begins with "X-". These type names are reserved for experimental use.
IANAは「X」と共に始まるどんなアドレスタイプ、診断タイプ、またはMTA名前タイプ名のための登録証明書も受け入れないでしょう。 これらの型名は実験用のために予約されます。
2.1.3 Lexical tokens imported from RFC 822
2.1.3 RFC822から輸入された字句
The following lexical tokens, defined in [RFC822], are used in the ABNF grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. The date-time lexical token is defined in [HOSTREQ].
[RFC822]で定義された以下の字句はDSNsにABNF文法に使用されます: 原子、CHAR、コメント、CR、CRLF、DIGIT、LF、直線的な余白、SPACE、テキスト。 日付-時間字句は[HOSTREQ]で定義されます。
Moore & Vaudreuil Standards Track [Page 10] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[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. At most, these fields may appear once in any DSN. These fields are used to correlate the DSN with the original message transaction and to provide additional information which may be useful to gateways.
DSNのいくつかの分野がそのDSNによって説明された配送試みのすべてに適用されます。 高々、これらの野原はどんなDSNにも一度現れるかもしれません。 これらの分野は、オリジナルのメッセージ取引でDSNを関連させて、ゲートウェイの役に立つかもしれない追加情報を提供するのに使用されます。
per-message-fields =
[ original-envelope-id-field CRLF ]
reporting-mta-field CRLF
[ dsn-gateway-field CRLF ]
[ received-from-mta-field CRLF ]
[ arrival-date-field CRLF ]
*( extension-field CRLF )
メッセージ分野単位で報告している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" that uniquely identifies the transaction during which the message was submitted, and was either (a) specified by the sender and supplied to the sender's MTA, or (b) generated by the sender's MTA and made available to the sender when the message was submitted. Its purpose is to allow the sender (or her user agent) to associate the returned DSN with the specific transaction in which the message was sent.
任意のOriginal封筒イド分野は、唯一、メッセージが提出された取引を特定する「封筒識別子」を含んでいて、送付者によって指定されて、送付者のMTAに供給された(a)か送付者のMTAを発生させて、メッセージを提出したとき送付者にとって利用可能にする(b)のどちらかでした。 目的は送付者(または、彼女のユーザエージェント)がメッセージが送られた特定の取引に返されたDSNを関連づけるのを許容することです。
If such an envelope identifier was present in the envelope that accompanied the message when it arrived at the Reporting MTA, it SHOULD be supplied in the Original-Envelope-Id field of any DSNs issued as a result of an attempt to deliver the message. Except when a DSN is issued by the sender's MTA, an MTA MUST NOT supply this field unless there is an envelope-identifier field in the envelope that accompanied this message on its arrival at the Reporting MTA.
そのような封筒識別子が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 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[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 that attempted to perform the delivery, relay, or gateway operation described in the DSN. This field is required.
DSNが提供する試み、リレーの結果について説明するか、またはゲートウェイは1人以上の受取人へのメッセージについて説明します。 すべての場合では、Reporting-MTAはDSNで説明された配送、リレー、またはゲートウェイ操作を実行するのを試みたMTAです。 この分野が必要です。
Note that if an SMTP client attempts to relay a message to an SMTP server and receives an error reply to a RCPT command, the client is responsible for generating the DSN, and the client's domain name will appear in the Reporting-MTA field. (The server's domain name will appear in the Remote-MTA field.)
SMTPクライアントがSMTPサーバーに伝言を伝えるのを試みて、RCPTコマンドにエラー応答を受けるなら、クライアントはDSNを発生させるのに責任があって、クライアントのドメイン名がReporting-MTA分野に現れることに注意してください。 (サーバのドメイン名は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 non-delivery notification which was gatewayed back into Internet mail, the Reporting-MTA field of the resulting DSN would be that of the MTA that originally reported the delivery failure, not that of the gateway which converted the foreign notification into a DSN. See Figure 2.
Reporting-MTAが必ず実際にDSNを発行したMTAであるというわけではないことに注意してください。 例えば、インターネットの外にメッセージを送る試みがインターネット・メールにgatewayedして戻された非配送通知をもたらすなら、結果として起こるDSNのReporting-MTA分野は外国通知をDSNに変換したゲートウェイのものではなく、元々配信障害を報告したMTAのものでしょうに。 図2を参照してください。
Moore & Vaudreuil Standards Track [Page 12] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[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 non-delivery
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 sub-field. If an MTA functions as a gateway between dissimilar mail environments and thus is known by multiple names depending on the environment, the mta-name sub-field SHOULD contain the name used by the environment from which the message was accepted by the Reporting-MTA.
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 that translated a foreign (non-Internet) delivery status notification into this DSN. This field MUST appear in any DSN that was translated by a gateway from a foreign system into DSN format, and MUST NOT appear otherwise.
DSN-ゲートウェイ分野は外国(非インターネットの)の配送状態通知をこのDSNに翻訳したゲートウェイかMTAという名前を示します。 ゲートウェイによって外国システムからDSN形式に翻訳されたどんなDSNにも現れなければなりません。そうでなければ、この野原は、現れてはいけません。
dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
「dsnゲートウェイ分野=「DSN-ゲートウェイ」」:、」 「mta名前タイプ」;、」 mta-名前
For gateways into Internet mail, the MTA-name-type will normally be "dns", and the mta-name will be the Internet domain name of the gateway.
通常、MTA名前タイプはインターネット・メールへのゲートウェイに関しては、"になるでしょう、そして、"dns mta-名前はゲートウェイのインターネットドメイン名になるでしょう。
Moore & Vaudreuil Standards Track [Page 13] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[13ページ]。
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 sub-field SHOULD be the Internet domain name supplied in the HELO or EHLO command, and the network address used by the SMTP client SHOULD be included as a comment enclosed in parentheses. (In this case, the MTA-name-type will be "dns".)
メッセージはHELOかEHLOで供給されたインターネットドメイン名がコマンドであったならインターネット・ホストからmta-名前サブ分野SHOULDでSMTP、コンテンツで受信されていたかどうか、そして、含まれていて、括弧に同封されたコメントとしてSMTPクライアントSHOULDによって使用されたネットワーク・アドレス。 (この場合、MTA名前タイプは"dns"でしょう。)
The mta-name portion of the Received-From-MTA field is formatted according to the conventions indicated by the MTA-name-type sub- field.
MTA名前タイプサブ分野によって示されたコンベンションによると、MTAからの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 [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be used.
[HOSTREQ]によって変更されるように日付と時間は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 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[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 ]
[ final-log-id-field CRLF ]
[ will-retry-until-field CRLF ]
*( extension-field CRLF )
受取人分野単位で最終受理者分野CRLF動作分野CRLF状態分野CRLF[遠く離れたmta分野CRLF][診断コード分野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 will normally be "rfc822", and the address will be according to the syntax specified in [RFC822]. The value "unknown" should be used if the Reporting MTA cannot determine the type of the original recipient address from the message envelope.
アドレスタイプ分野はオリジナルの受取人アドレスのタイプを示します。 メッセージがインターネットの中で由来したなら、通常、アドレスタイプ分野は"rfc822"でしょう、そして、[RFC822]で指定された構文によると、アドレスがあるでしょう。 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 [DRPT]. This address is the same as that provided by the sender and can be used to automatically correlate DSN reports and message transactions.
この分野は任意です。 送付者の指定された受取人アドレスがメッセージ封筒に存在している場合にだけ、それは含まれているでしょうに、[DRPT]で定義されたSMTP拡張子などのように。 このアドレスは、DSNレポートとメッセージ取引を自動的に関連させるようにそれを送付者が提供して、使用できるのと同じです。
2.3.2 Final-Recipient field
2.3.2 最終的な受取人分野
The Final-Recipient field indicates the recipient for which this set of per-recipient fields applies. This field MUST be present in each set of per-recipient data.
Final-受取人分野はこのセットの1受取人あたりの分野が適用される受取人を示します。 この分野はそれぞれのセットの1受取人あたりのデータに存在していなければなりません。
Moore & Vaudreuil Standards Track [Page 15] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[15ページ]。
The syntax of the field is as follows:
分野の構文は以下の通りです:
final-recipient-field =
"Final-Recipient" ":" address-type ";" generic-address
「最終受理者分野=「最終受理者」」:、」 「アドレスタイプ」;、」 一般的なアドレス
The generic-address sub-field of the Final-Recipient field MUST contain the mailbox address of the recipient (from the transport envelope), as it was when the Reporting MTA accepted the message for delivery.
Final-受取人分野の一般的なアドレスサブ分野は受取人(輸送封筒からの)のメールボックスアドレスを含まなければなりません、Reporting MTAが配送へのメッセージを受け入れた時であるときに。
The Final-Recipient address may differ from the address originally provided by the sender, because it may have been transformed during forwarding and gatewaying into a totally unrecognizable mess. However, in the absence of the optional Original-Recipient field, the Final-Recipient field and any returned content may be the only information available with which to correlate the DSN with a particular message submission.
Final-受取人アドレスは元々送付者によって提供されたアドレスと異なるかもしれません、推進の間、変えられて、完全に認知できない混乱にgatewayingしていたかもしれないので。 しかしながら、任意のOriginal-受取人分野がないとき、Final-受取人分野とどんな返された内容も特定のメッセージ提案があるDSNを関連させる利用可能な唯一の情報であるかもしれません。
The address-type sub-field indicates the type of address expected by the reporting MTA in that context. Recipient addresses obtained via SMTP will normally be of address-type "rfc822".
アドレスタイプサブ分野はその文脈で報告しているMTAによって予想されたアドレスのタイプを示します。 通常、SMTPを通して得られた受取人アドレスはアドレスタイプ"rfc822"のものになるでしょう。
NOTE: The Reporting MTA is not expected to ensure that the address actually conforms to the syntax conventions of the address-type. Instead, it MUST report exactly the address received in the envelope, unless that address contains characters such as CR or LF which are not allowed in a DSN field.
以下に注意してください。 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"
=が「失敗する」か、「遅らせる」、「渡す」か、「リレーする」、または「広げた」動作値
The action-value may be spelled in any combination of upper and lower case characters.
動作値は大文字と小文字キャラクタのどんな組み合わせでもつづられるかもしれません。
Moore & Vaudreuil Standards Track [Page 16] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[16ページ]。
"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 [DRPT], section 7.2.7: An action-value of "expanded" is only to be used when the message is delivered to a multiple-recipient "alias". An action-value of "expanded" SHOULD NOT be used with a DSN issued on delivery of a message to a "mailing list".
「メーリングリスト」という用語を使用して、[DRPT]、セクション7.2.7で定義される「別名」: 「広げられること」の動作値は複数の受取人「別名」にメッセージを送るとき、単に使用することです。 動作値、「広げられた」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 name server timed out.
動作の注意 ステータスコード: '動作'分野は'状態'分野で余分であるように思えるかもしれませんが、これはそうではありません。 特にa、「一時障害、」 (「4インチ) ステータスコードに「遅らせられた」どちらかの動作値と共に使用するか、または「失敗」であることができた」。 例えば、ドメイン名サーバへの質問が外で調節されたので、SMTPクライアントが受取人のために繰り返してメール交換器に伝言を伝えようとしますが、失敗すると仮定してください。
Moore & Vaudreuil Standards Track [Page 17] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[17ページ]。
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 that indicates the delivery status of the message to that recipient. This field MUST be present for each delivery attempt which is described by a DSN.
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 sub-field of the status-code.
; Each numeric sub-field within the status-code MUST be
; expressed without leading zero digits.
; 空白類文字とコメントは中に許容されていません。 括弧の同封のコメントですが、ステータスコード ステータスコードの最後の数値サブ野原に続くかもしれません。 ; ステータスコードの中のそれぞれの数値サブ分野はそうであるに違いありません。 先行ゼロケタなしで言い表されます。
Status codes thus consist of three numerical fields separated by ".". The first sub-field indicates whether the delivery attempt was successful (2= success, 4 = persistent temporary failure, 5 = permanent failure). The second sub-field indicates the probable source of any delivery anomalies, and the third sub-field denotes a precise error condition, if known.
「その結果、ステータスコードは3から数字の分野が分離した成る」、」 最初のサブ分野は、配送試みがうまくいったかどうかを(2は成功と等しいです、しつこい4=一時障害、永久的な5=失敗)示します。 2番目のサブ分野はどんな配送例外のありえそうな源も示します、そして、3番目のサブ分野は正確なエラー条件を指示します、知られているなら。
The initial set of status-codes is defined in [STATUS].
ステータスコードの始発は[STATUS]で定義されます。
Moore & Vaudreuil Standards Track [Page 18] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[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 sub-field 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 non-delivery 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 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[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 [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be used.
[HOSTREQ]によって変更されるように日付と時間はRFC822'日付-時間'形式で言い表されます。 数値タイムゾーン([+/-]HHMM形式)を使用しなければなりません。
2.3.8 final-log-id field
2.3.8 最終的なログイド分野
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.9 Will-Retry-Until field
2.3.9、ウィル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、」、」、:、」 日付-時間
Moore & Vaudreuil Standards Track [Page 20] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[20ページ]。
The date and time are expressed in RFC 822 'date-time' format, as modified by [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be used.
[HOSTREQ]によって変更されるように日付と時間はRFC822'日付-時間'形式で言い表されます。 数値タイムゾーン([+/-]HHMM形式)を使用しなければなりません。
2.4 Extension fields
2.4 拡大分野
Additional per-message or per-recipient DSN fields may be defined in the future by later revisions or extensions to this specification. Extension-field names beginning with "X-" will never be defined as standard fields; such names are reserved for experimental use. DSN field names NOT beginning with "X-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and published in an RFC.
メッセージか受取人あたりの追加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 that produced the DSN. (e.g., Foomail-Queue-ID).
特定のメッセージ転送エージェント(MTA)に特定の診断情報の伝達を許す(c)。 そのようなDSN分野の名前はDSNを生産したMTA実現のしるしで始まるべきです。 (例えば、Foomail Queue ID。)
MTA implementers are encouraged to provide adequate information, via extension fields if necessary, to allow an MTA maintainer to understand the nature of correctable delivery failures and how to fix them. For example, if message delivery attempts are logged, the DSN might include information that allows the MTA maintainer to easily find the log entry for a failed delivery attempt.
MTA implementersは必要なら、拡大分野を通って適切な情報を前提として、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」)に続くべきです。
Moore & Vaudreuil Standards Track [Page 21] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[21ページ]。
3. Conformance and Usage Requirements
3. 順応と用法要件
An MTA or gateway conforms to this specification if it generates DSNs according to the protocol defined in this memo. For MTAs and gateways that do not support requests for positive delivery notification (such as in [DRPT]), it is sufficient that delivery failure reports use this protocol.
このメモで定義されたプロトコルに応じてDSNsを発生させるなら、MTAかゲートウェイがこの仕様に一致しています。 積極的な配送通知([DRPT]などの)に関する要求を支持しないMTAsとゲートウェイでは、配送異常報告書がこのプロトコルを使用するのは、十分です。
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 [DRPT] permits such information to be carried in the envelope if it is available.)
メール転送プロトコルが服従時点で元々送付者によって指定されたアドレスを提供しない場合、MTAsとゲートウェイはDSNのOriginal-受取人分野を発生させてはいけません。 (普通のSMTPはその保証をしませんが、それが利用可能であるなら、[DRPT]で定義されたSMTP拡張子は、そのような情報が封筒で運ばれることを許可します。)
Each sender-specified recipient address SHOULD result in at most one "delivered" or "failed" DSN for that recipient. If a positive DSN is requested (e.g., one using NOTIFY=SUCCESS in SMTP) for a recipient that is forwarded to multiple recipients of an "alias" (as defined in [DRPT], section 7.2.7), the forwarding MTA SHOULD normally issue a "expanded" DSN for the originally-specified recipient and not propagate the request for a DSN to the forwarding addresses. Alternatively, the forwarding MTA MAY relay the request for a DSN to exactly one of the forwarding addresses and not propagate the request to the others.
アドレスSHOULDが最も1つでもたらすそれぞれの送付者によって指定された受取人は、その受取人のためにDSNに「渡す」か、または「失敗しました」。 積極的なDSNが「別名」の複数の受取人に送られる受取人のために要求されるなら(例えば、SMTPでNOTIFY=SUCCESSを使用する1つ)([DRPT]、セクション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を見てください。)
Moore & Vaudreuil Standards Track [Page 22] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[22ページ]。
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を使用するとき、以下のセキュリティ問題は適用されます:
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,
(a) メッセージであるときに、改竄された配送通知は示された受取人に提供されません。
(b) A falsified non-delivery notification when the message was in
fact delivered to the indicated recipient,
(b) メッセージであるときに、事実上、改竄された非配送通知を示された受取人に提供しました。
(c) A falsified Final-Recipient address,
(c) 改竄されたFinal-受取人アドレス
(d) A falsified Remote-MTA identification,
(d) 改竄されたRemote-MTA識別
(e) A falsified relay notification when the message is "dead ended".
(e) メッセージであるときに、改竄されたリレー通知は「終わった死者」です。
(f) Unsolicited DSNs
(f) 求められていないDSNs
4.2 Confidentiality
4.2 秘密性
Another dimension of security is confidentiality. There may be cases in which a message recipient is autoforwarding messages but does not wish to divulge the address to which the messages are autoforwarded. The desire for such confidentiality will probably be heightened as "wireless mailboxes", such as pagers, become more widely used as autoforward addresses.
セキュリティの別次元は秘密性です。 メッセージ受取人がメッセージを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つか、より多くで達成されるかもしれません:
Moore & Vaudreuil Standards Track [Page 23] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[23ページ]。
(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 reverse-path ("<>") (so that no DSNs would be sent from a
downstream MTA to the original sender),
NULL逆経路(「<>」)に封筒返送先(例えば、SMTPメールFROMアドレス)を設定して(川下のMTAから元の送り主にDSNsを全く送らないように)、秘密のアドレスに転送されたメッセージのための(d)
(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
または転送されたメッセージのための配送通知を無効にして(例えば、「次のホップ」MTAが決してRCPTコマンドへのどんなNOTIFYを使用する=パラメタでもESMTPを使用して、DSN拡張子をサポートしないなら)、秘密のアドレスに転送されたメッセージのための(e)。
(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に関するユーティリティに対してバランスをとらなければなりません。
Implementers are cautioned that many existing MTAs will send non- delivery notifications to a return address in the message header (rather than to the one in the envelope), in violation of SMTP and other protocols. If a message is forwarded through such an MTA, no reasonable action on the part of the forwarding MTA will prevent the downstream MTA from compromising the forwarding address. Likewise, if the recipient's MTA automatically responds to messages based on a request in the message header (such as the nonstandard, but widely used, Return-Receipt-To extension header), it will also compromise the forwarding address.
Implementersは多くの既存のMTAsがメッセージヘッダー(1つのコネへの封筒よりむしろ)の返送先に非配送している通知を送ると警告されます、SMTPと他のプロトコルを違反して。 そのようなMTAを通してメッセージを転送すると、推進MTA側のどんな合理的な動作も、川下のMTAがフォーワーディング・アドレスで妥協するのを防がないでしょう。 受取人のMTAが同様に自動的にメッセージヘッダーで要求に基づくメッセージに応じる、(標準的でないのですが、広く使用されているのなどようにReturnが領収書を出す、拡張ヘッダー)、また、それはフォーワーディング・アドレスで妥協するでしょう。
Moore & Vaudreuil Standards Track [Page 24] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[24ページ]。
4.3 Non-Repudiation
4.3 非拒否
Within the framework of today's internet mail, the DSNs defined in this memo provide valuable information to the mail user; however, even a "failed" DSN can not be relied upon as a guarantee that a message was not received by the recipient. Even if DSNs are not actively forged, conditions exist under which a message can be delivered despite the fact that a failure DSN was issued.
今日のインターネットメールの枠組みの中では、このメモで定義されたDSNsはメールユーザに貴重な情報を提供します。 しかしながら、メッセージが受取人によって受け取られなかったという保証として「失敗した」DSNさえ当てにすることができません。 DSNsが活発に鍛造されないでも、失敗DSNが発行されたという事実にもかかわらず、メッセージを送ることができる状態は存在しています。
For example, a race condition in the SMTP protocol allows for the duplication of messages if the connection is dropped following a completed DATA command, but before a response is seen by the SMTP client.
例えば、完成したDATAコマンドに続いて、接続が落とされますが、応答がSMTPクライアントによって見られる前を除いて、SMTPプロトコルの競合条件はメッセージの複製を考慮します。
This will cause the SMTP client to retransmit the message, even though the SMTP server has already accepted it [SMTPDUP]. If one of those delivery attempts succeeds and the other one fails, a "failed" DSN could be issued even though the message actually reached the recipient.
これで、SMTPサーバーは既に、それ[SMTPDUP]を受け入れましたが、SMTPクライアントはメッセージを再送するでしょう。 それらの配送試みの1つが成功して、もう片方が失敗するなら、メッセージは実際に受取人に届きましたが、「失敗した」DSNは発行されるかもしれません。
5. Normative References
5. 引用規格
[DRPT] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC 3461, January 2003.
[DRPT] ムーア、K.、「配送状態通知のためのSMTPサービス拡張子」、RFC3461、2003年1月。
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 1894, January 1996.
[DSN] ムーアとK.とG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC1894、1996年1月。
[HOSTREQ] Braden, R. (ed.), "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October 1989.
[HOSTREQ]ブレーデン、R.編、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[MIME1]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[MIME3]ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC
3462, January 2003.
[報告します] ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポート満足しているタイプ」、RFC3462、2003年1月。
[RFC822] Crocker, D., "Standard for the format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[RFC822] クロッカー、D.、「ARPAインターネットText Messagesの形式の規格」、STD11、RFC822、1982年8月。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
[SMTP] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
Moore & Vaudreuil Standards Track [Page 25] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[25ページ]。
[SMTPDUP] Partridge, C., "Duplicate Messages and SMTP", RFC 1047,
February 1988.
[SMTPDUP] ヤマウズラ、C.が「メッセージとSMTPをコピーする」、RFC1047、2月1988日
[STATUS] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
3463, January 2003.
[状態] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC3463、2003年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
6. Acknowledgments
6. 承認
The authors wish to thank the following people for their reviews of early drafts of RFC 1894, of which this document is a revision, and their suggestions for improvement: Eric Allman, Harald Alvestrand, Allan Cargille, Jim Conklin, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko Kaittola, Steve Kille, John Klensin, John Gardiner Myers, Mark Nahabedian, Julian Onions, Jacob Palme, Jean Charles Roy, and Gregory Sheehan.
作者は彼らのこのドキュメントが改正と、彼らの改善提案であるRFC1894の早めの草稿のレビューについて以下の人々に感謝したがっています: エリック・オールマン、ハラルドAlvestrand、アランCargille、ジム・コンクリン、ピーター・カウエン、デーヴ・クロッカー、ロジャーFajman、解放されたネッド、マルコKaittola、スティーブKille、ジョンKlensin、ジョン・ガーディナー・マイアーズはNahabedian、ジュリアンOnions、ヤコブ・パルメ、ジーン・チャールズ・ロイ、およびグレゴリー・シーハンをマークします。
Moore & Vaudreuil Standards Track [Page 26] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[26ページ]。
Appendix A - collected grammar
付録A--集まっている文法
NOTE: The following lexical tokens are defined in RFC 822: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. The date-time lexical token is defined in [HOSTREQ].
以下に注意してください。 以下の字句はRFC822で定義されます: 原子、CHAR、コメント、CR、CRLF、DIGIT、LF、直線的な余白、SPACE、テキスト。 日付-時間字句は[HOSTREQ]で定義されます。
action-field = "Action" ":" action-value
「動作分野=「動作」」:、」 動作値
action-value = "failed" / "delayed" / "delivered"
/ "relayed" / "expanded"
=が「失敗する」か、「遅らせる」、「渡す」か、「リレーする」、または「広げた」動作値
address-type = atom
アドレスタイプは原子と等しいです。
arrival-date-field = "Arrival-Date" ":" date-time
「到着分野とデートしている=「到着日付」」:、」 日付-時間
delivery-status-content = per-message-fields
1*( CRLF per-recipient-fields )
配送状態内容がメッセージ分野単位で等しい、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
「最終受理者分野=「最終受理者」」:、」 「アドレスタイプ」;、」 一般的なアドレス
final-log-id-field = "Final-Log-ID" ":" *text
「最終的なログイド分野は「最終的なLog ID」と等しい」:、」 *テキスト
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
「元の封筒イド分野は「オリジナルの封筒イド」と等しい」:、」 封筒イド
Moore & Vaudreuil Standards Track [Page 27] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[27ページ]。
original-recipient-field =
"Original-Recipient" ":" address-type ";" generic-address
「元の受取人分野は「オリジナルの受取人」と等しい」:、」 「アドレスタイプ」;、」 一般的なアドレス
per-message-fields =
[ original-envelope-id-field CRLF ]
reporting-mta-field CRLF
[ dsn-gateway-field CRLF ]
[ received-from-mta-field CRLF ]
[ arrival-date-field CRLF ]
*( extension-field CRLF )
メッセージ分野単位で報告している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 ]
[ final-log-id-field CRLF ]
[ will-retry-until-field CRLF ]
*( extension-field CRLF )
受取人分野単位で最終受理者分野CRLF動作分野CRLF状態分野CRLF[遠く離れたmta分野CRLF][診断コード分野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
; a status-code, though a comment enclosed in parentheses
; MAY follow the last numeric sub-field of the status-code.
; Each numeric sub-field within the status-code MUST be
; expressed without leading zero digits.
; 空白類文字とコメントはaの中に許容されていません。 括弧の同封のコメントですが、ステータスコード ステータスコードの最後の数値サブ野原に続くかもしれません。 ; ステータスコードの中のそれぞれの数値サブ分野はそうであるに違いありません。 先行ゼロケタなしで言い表されます。
status-field = "Status" ":" status-code
「状態分野=「状態」」:、」 ステータスコード
will-retry-until-field = "Will-Retry-Until" ":" date-time
「分野まで再試行するために望んでいる=、「ウィルRetry、」、」、:、」 日付-時間
Moore & Vaudreuil Standards Track [Page 28] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[28ページ]。
Appendix B - Guidelines for gatewaying DSNs
付録B--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ゲートウェイ要件は他のドキュメントによって定義されるかもしれません。
Gatewaying from other mail systems to DSNs
他のメールシステムから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 29] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[29ページ]。
Gatewaying from DSNs to other mail systems
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 sub-field of the Diagnostic-Code field indicates that the original diagnostic code is understood by the destination environment, the information from the Diagnostic-Code field should be used. Failing that, the information in the Status field should be mapped into the closest available diagnostic code used in the destination environment.
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情報を保存する手段を定義するかもしれません。
Appendix C - Guidelines for use of DSNs by mailing list exploders
付録C--メーリングリスト発破器によるDSNsの使用のためのガイドライン
This section pertains only to the use of DSNs by "mailing lists" as defined in [4], section 7.2.7.
このセクションは[4]、セクション7.2.7で定義されるように「メーリングリスト」でDSNsの使用だけに関係します。
DSNs are designed to be used by mailing list exploders to allow them to detect and automatically delete recipients for whom mail delivery fails repeatedly.
DSNsは、検出するのを許容するメーリングリスト発破器によって使用されて、自動的に、郵便配達が繰り返し失敗する受取人を削除するように設計されています。
When forwarding a message to list subscribers, the mailing list exploder should always set the envelope return address (e.g., SMTP MAIL FROM address) to point to a special address which is set up to receive non-delivery reports. A "smart" mailing list exploder can therefore intercept such non-delivery reports, and if they are in the DSN format, automatically examine them to determine for which recipients a message delivery failed or was delayed.
加入者を記載するメッセージを転送するとき、メーリングリスト発破器は、いつも封筒返送先(例えば、SMTP MAIL FROMアドレス)に非配送レポートを受け取るためにセットアップされる特別なアドレスを示すように設定するはずです。 したがって、「賢い」メーリングリスト発破器はそのような非配送レポートを傍受できて、DSN形式にそれらがあるなら、自動的にそれらを調べて、メッセージ配送がどの受取人に関して失敗したか、または遅れたか決定してください。
Moore & Vaudreuil Standards Track [Page 30] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[30ページ]。
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 might depend on the type of error. On the other hand, a "user unknown" error that persisted for several days could be considered a reliable indication that address were no longer valid.
しかしながら、数種類の失敗は一時的な病態、および数種類の失敗によって引き起こされた他のものがすぐに気付かれていて、他のものより修正されそうなほどありそうではありません。 加入者を削除するかどうか決めるとき、もう一度、正確なステータスコードは定義されて、ステータスコードを区別するのは役に立つかもしれません。 例えば、高いメッセージボリュームがあるリストでは、一時単に受取人を削除するよりむしろ繰り返された「一時的な」失敗を引き起こす受取人アドレスに荷渡しを中絶するのは望ましいかもしれません。 サスペンションの持続時間は誤りのタイプに頼るかもしれません。 他方では、アドレスがあった信頼できる指示であるともう有効でなく数日間持続した「ユーザ未知」誤りを考えることができました。
Appendix D - IANA registration forms for DSN types
付録D--DSNタイプのためのIANA登録用紙
The forms below are for use when registering a new address-type, diagnostic-type, or MTA-name-type with the Internet Assigned Numbers Authority (IANA). Each piece of information requested by a registration form may be satisfied either by providing the information on the form itself, or by including a reference to a published, publicly available specification which includes the necessary information. IANA MAY reject DSN type registrations because of incomplete registration forms, imprecise specifications, or inappropriate type names.
新しいアドレスタイプ、診断タイプ、またはMTA名前タイプをインターネットAssigned民数記Authority(IANA)に示すとき、以下のフォームは使用のためのものです。 登録用紙によって要求されたそれぞれの情報は、フォーム自体の情報を提供するか、または必要事項を含んでいる発行されて、公的に利用可能な仕様の指示するものを含んでいることによって、満たされるかもしれません。 IANA MAYは不完全な登録用紙、不正確な仕様、または不適当な型名でDSNタイプ登録証明書を拒絶します。
Moore & Vaudreuil Standards Track [Page 31] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[31ページ]。
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。
IANA registration form for address-type
アドレスタイプのためのIANA登録用紙
A registration for a DSN address-type MUST include the following information:
DSNアドレスタイプのための登録は以下の情報を含まなければなりません:
(a) The proposed address-type name.
(a) 提案されたアドレス型名。
(b) The syntax for mailbox addresses of this type, specified using
BNF, regular expressions, ASN.1, or other non-ambiguous language.
(b) BNF、正規表現、ASN.1、または他の非あいまいな言語を使用することで指定されたこのタイプのメールボックスアドレスのための構文。
(c) If addresses of this type are not composed entirely of graphic
characters from the US-ASCII repertoire, a specification for how
they are to be encoded as graphic US-ASCII characters in a DSN
Original-Recipient or Final-Recipient DSN field.
このタイプのアドレスがDSN Original-受取人に米国-ASCIIレパートリーからの図形文字、それらがグラフィック米国-ASCII文字としてどうコード化されることになっているかためには仕様に基づき完全に落ち着いていないか、そして、Final-受取人DSNがさばく(c)。
(d) [optional] A specification for how addresses of this type are to
be translated to and from Internet electronic mail addresses.
(d) アドレスとインターネット電子メールアドレスからどう翻訳されるかためにはこのタイプのアドレスがことである[任意の]仕様。
IANA registration form for diagnostic-type
診断タイプのためのIANA登録用紙
A registration for a DSN address-type MUST include the following information:
DSNアドレスタイプのための登録は以下の情報を含まなければなりません:
(a) The proposed diagnostic-type name.
(a) 提案された診断型名。
(b) A description of the syntax to be used for expressing diagnostic
codes of this type as graphic characters from the US-ASCII
repertoire.
(b) 図形文字として米国-ASCIIレパートリーからこのタイプの診断コードを表すのに使用されるべき構文の記述。
(c) A list of valid diagnostic codes of this type and the meaning of
each code.
(c) このタイプの有効な診断コードのリストとそれぞれのコードの意味。
(d) [optional] A specification for mapping from diagnostic codes of
this type to DSN status codes (as defined in [5]).
(d) このタイプの診断コードからDSNまでステータスコードを写像するための[任意の]仕様、([5])で定義されるように。
IANA registration form for MTA-name-type
MTA名前タイプのための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名の構文の記述。
Moore & Vaudreuil Standards Track [Page 32] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[32ページ]。
(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文字の系列としてどう表されるべきであるか仕様)からの図形文字から完全に成らないでください。
Appendix E - Examples
付録E--例
These examples are provided as illustration only, and are not considered part of the DSN protocol specification. If an example conflicts with the protocol definition above, the example is wrong.
これらの例は、イラストだけとして前提とされて、DSNプロトコル仕様の一部であると考えられません。 プロトコル定義が上で例が闘争するなら、例は間違っています。
Likewise, the use of *-type sub-field names or extension fields in these examples is not to be construed as a definition for those type names or extension fields.
同様に、これらの例の*タイプサブフィールド名か拡大分野の使用はそれらの型名か拡大分野のための定義に理解されないことです。
These examples were manually translated from bounced messages using whatever information was available.
これらの例は、送り返されたメッセージからどんな利用可能であった情報も使用することで手動で翻訳されました。
Moore & Vaudreuil Standards Track [Page 33] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[33ページ]。
Simple DSN
簡単なDSN
This is a simple DSN issued after repeated attempts to deliver a message failed. In this case, the DSN is issued by the same MTA from which the message was originated.
これは伝言をもたらす繰り返された試みが失敗した後に発行された簡単なDSNです。 この場合、DSNはメッセージが溯源されたのと同じMTAによって発行されます。
Date: Thu, 7 Jul 1994 17:16:05 -0400 From: Mail Delivery Subsystem
<MAILER-DAEMON@CS.UTK.EDU> Message-Id:
<199407072116.RAA14128@CS.UTK.EDU> Subject: Returned mail: Cannot
send message for 5 days To: <owner-info-mime@cs.utk.edu> MIME-
Version: 1.0 Content-Type: multipart/report; report-type=delivery-
status;
boundary="RAA14128.773615765/CS.UTK.EDU"
日付: 木曜日、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>はバージョンをまねます: 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 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[34ページ]。
Multi-Recipient DSN
マルチ受取人DSN
This is another DSN issued by the sender's MTA, which contains details of multiple delivery attempts. Some of these were detected locally, and others by a remote MTA.
これは多重配信試みの詳細を含む送付者のMTAによって発行された別のDSNです。 これらの或るものが局所的に検出された、そして、リモートMTAによる他のもの。
Date: Fri, 8 Jul 1994 09:21:47 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
Subject: Returned mail: User unknown
To: <owner-ups-mib@CS.UTK.EDU>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="JAA13167.773673707/CS.UTK.EDU"
日付: 金曜日、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 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[35ページ]。
[original message goes here]
[オリジナルのメッセージはここに行きます]
--JAA13167.773673707/CS.UTK.EDU--
--JAA13167.773673707/CS.UTK.EDU--
DSN from gateway to foreign system
外国システムへのゲートウェイからのDSN
A delivery report generated by Message Router (MAILBUS) and gatewayed by PMDF_MR to a DSN. In this case the gateway did not have sufficient information to supply an original-recipient address.
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 Entry found
無効のアドレス--nair_s%ディルE- NODIRMTCH、Entry 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 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[36ページ]。
Delayed DSN
遅れたDSN
A delay report from a multiprotocol MTA. Note that there is no returned content, so no third body part appears in the DSN.
multiprotocol MTAからの遅れレポート。 身体の部分がDSNで見える3番目が全くそのように満足していた状態で返されないことに注意してください。
MIME-Version: 1.0
From: <postmaster@nsfnet-relay.ac.uk>
Message-Id: <199407092338.TAA23293@CS.UTK.EDU>
Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
Sun, 10 Jul 1994 00:36:51 +0100
To: owner-info-mime@cs.utk.edu
Date: Sun, 10 Jul 1994 00:36:51 +0100
Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
content-type: multipart/report; report-type=delivery-status;
boundary=foobar
MIMEバージョン: 1.0 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, i.e., 7 days.
配送は、すなわち、7日間168時間の総経過時間まで試みられ続けるでしょう。
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
最終受理者: rfc822;thomas@de-montfort.ac.uk
Moore & Vaudreuil Standards Track [Page 37] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[37ページ]。
Status: 4.0.0 (unknown temporary failure) Action: delayed
状態: 4.0.0 (未知の一時障害)動作: 延着します。
--foobar--
--foobar--
Appendix F - Changes from RFC 1894
付録F--RFC1894からの変化
Changed Authors contact information
変えられたAuthors問い合わせ先
Updated required standards boilerplate
アップデートされた必要な基準の決まり文句
Edited the text to make it spell-checker and grammar checker compliant
編集されて、それをスペルチェッカーにするテキストと文法は言いなりになった状態で数奇です。
Updated references to point to later, more mature documents, changed reference enumeration scheme.
後で示すアップデートされた参照(より熟しているドキュメント)は参照列挙計画を変えました。
Fixed paragraph numbering on page 20
20ページでの固定パラグラフ付番
Fixed Delayed DSN example
固定Delayed DSNの例
Added Table of Contents
加えられた目次
Moved Appendices to the end of the document
動くドキュメントの端までのAppendices
Changed the MTA-name-Type for gateways into Internet mail, the MTA-name-type from "SMTP" to "dns".
インターネット・メールへのゲートウェイへのMTA名前タイプ、MTA名前タイプを"SMTP"から"dns"に変えました。
Moore & Vaudreuil Standards Track [Page 38] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[38ページ]。
Authors' Addresses
作者のアドレス
Keith Moore University of Tennessee 1122 Volunteer Blvd, Suite 203 Knoxville TN 37996-3450 USA
1122ボランティアBlvd、テネシースイート203ノクスビルテネシー37996-3450米国のキースムーア大学
Phone: +1-865-974-3126 Fax: +1-865-974-8296 EMail: moore@cs.utk.edu
以下に電話をしてください。 +1-865-974-3126 Fax: +1-865-974-8296 メールしてください: moore@cs.utk.edu
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas, Tx. 75214 USA
グレゴリーM.ボードルイルーセントテクノロジーズ7291ウィリアムソン・第ダラス、Tx。 75214 米国
Phone: +1 214 823 9325 EMail: GregV@ieee.org
以下に電話をしてください。 +1 9325年の214 823メール: GregV@ieee.org
Moore & Vaudreuil Standards Track [Page 39] RFC 3464 Delivery Status Notifications January 2003
ムーアとボードルイ規格は配送状態通知2003年1月にRFC3464を追跡します[39ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Moore & Vaudreuil Standards Track [Page 40]
ムーアとボードルイ標準化過程[40ページ]
一覧
スポンサーリンク
