RFC3798 日本語訳
3798 Message Disposition Notification. T. Hansen, Ed., G. Vaudreuil,Ed.. May 2004. (Format: TXT=64049 bytes) (Obsoletes RFC2298) (Updates RFC3461, RFC2046) (Updated by RFC5337) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Hansen, Ed. Request for Comments: 3798 AT&T Laboratories Obsoletes: 2298 G. Vaudreuil, Ed. Updates: 3461, 2046 Lucent Technologies Category: Standards Track May 2004
ワーキンググループのT.ハンセン、エドをネットワークでつないでください。コメントのために以下を要求してください。 3798のAT&T研究所が以下を時代遅れにします。 2298 エドG.ボードルイ、アップデート: 3461、2046ルーセントテクノロジーズカテゴリ: 標準化過程2004年5月
Message Disposition Notification
メッセージ気質通知
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 (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past.
このメモはメールユーザエージェント(MUA)か電子メールゲートウェイによって使用される、首尾よくそれを受取人に届けた後にメッセージの気質を報告するかもしれないMIMEの満足しているタイプを定義します。 この満足しているタイプがマシン処理可能であることを意図します。 また、追加メッセージヘッダーは、Message Disposition Notifications(MDNs)がメッセージの送付者によって要求されていることを許可するために定義されます。 目的はX.400や独占「LANベース」のシステムなどの他のメッセージシステムでしばしば見つけられて、しばしば「領収書を読んでください」、「承認」、または「領収書通知」と呼ばれた機能性を支持するためにインターネットメールを広げることです。 意志は過去にそのような機能について議論したときのプライバシー関心(しばしば述べられた)を尊敬している間、これをすることです。
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN 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, 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ベース」のシステムなどの)の間に多くのメッセージを送るので、MDNプロトコルは環境を通信させながらマルチプロトコルで役に立つように設計されています。 このために、このメモで説明されたプロトコルは「外国」のアドレスのキャリッジに備えます、通常、インターネットメールに使用されるものに加えて。 また、追加属性は、インターネットメールを通した外国通知が「トンネルを堀ること」を支持するために定義されるかもしれません。
Hansen & Vaudreuil Standards Track [Page 1] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
2. Requesting Message Disposition Notifications . . . . . . . . . 4
2.1. The Disposition-Notification-To Header . . . . . . . . . 4
2.2. The Disposition-Notification-Options Header. . . . . . . 6
2.3. The Original-Recipient Header. . . . . . . . . . . . . . 7
2.4. Use with the Message/Partial Content Type. . . . . . . . 8
3. FORMAT OF A MESSAGE DISPOSITION NOTIFICATION . . . . . . . . . 8
3.1. The message/disposition-notification content-type. . . . 9
3.2. Message/disposition-notification Fields. . . . . . . . . 11
3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 16
4. Timeline of Events . . . . . . . . . . . . . . . . . . . . . . 17
5. Conformance and Usage Requirements . . . . . . . . . . . . . . 18
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
6.1. Forgery. . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Non-Repudiation. . . . . . . . . . . . . . . . . . . . . 20
6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 20
7. Collected Grammar. . . . . . . . . . . . . . . . . . . . . . . 20
8. Guidelines for Gatewaying MDNS . . . . . . . . . . . . . . . . 22
8.1. Gatewaying from other mail systems to MDNs . . . . . . . 23
8.2. Gatewaying from MDNs to other mail systems . . . . . . . 23
8.3. Gatewaying of MDN-requests to other mail systems . . . . 24
9. Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 25
10.1. Disposition-Notification-Options header parameter names. 26
10.2. Disposition modifier names . . . . . . . . . . . . . . . 26
10.3. MDN extension field names. . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A - Changes from RFC 2298 . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 目的. . . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 要件. . . . . . . . . . . . . . . . . . . . . . 3 1.3。 用語。 . . . . . . . . . . . . . . . . . . . . . . 4 2. メッセージ気質通知. . . . . . . . . 4 2.1を要求します。 気質通知、ヘッダー. . . . . . . . . 4 2.2 気質通知オプションヘッダー。 . . . . . . 6 2.3. オリジナルの受取人ヘッダー。 . . . . . . . . . . . . . 7 2.4. メッセージ/部分的な満足しているタイプで、使用します。 . . . . . . . 8 3. メッセージ気質通知. . . . . . . . . 8 3.1の形式。 気質メッセージ/通知の満足しているタイプ。 . . . 9 3.2. 気質メッセージ/通知分野。 . . . . . . . . 11 3.3. 拡大分野.164。 出来事. . . . . . . . . . . . . . . . . . . . . . 17 5に関するスケジュール。 順応と用法要件. . . . . . . . . . . . . . 18 6。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 19 6.1. 偽造。 . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. プライバシー。 . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3. 非拒否します。 . . . . . . . . . . . . . . . . . . . . 20 6.4. 爆撃. . . . . . . . . . . . . . . . . . . . . . 20 7を郵送してください。 集まっている文法… 20 8。 Gatewaying MDNS. . . . . . . . . . . . . . . . 22 8.1のためのガイドライン。 他のメールシステムからMDNs. . . . . . . 23 8.2までGatewayingします。 MDNsから他のメールシステム. . . . . . . 23 8.3までGatewayingします。 他のメールシステム. . . . 24 9にMDN-要求をGatewayingします。 例。 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 25 10.1. 気質通知オプションヘッダーパラメタ名。 26 10.2. 気質修飾語は.26 10.3を命名します。 MDN拡大フィールド名。 . . . . . . . . . . . . . . . 26 11. 承認. . . . . . . . . . . . . . . . . . . . . . . 27 12。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 27 12.1。 引用規格. . . . . . . . . . . . . . . . . . 27 12.2。 有益な参照. . . . . . . . . . . . . . . . . 28付録A--RFC2298.29人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 29からの変化は著作権宣言文. . . . . . . . . . . . . . . . . . . . . 30を洗い張りします。
Hansen & Vaudreuil Standards Track [Page 2] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[2ページ]。
1. Introduction
1. 序論
This memo defines a [RFC-MIME-MEDIA] content-type for message disposition notifications (MDNs). An MDN can be used to notify the sender of a message of any of several conditions that may occur after successful delivery, such as display of the message contents, printing of the message, deletion (without display) of the message, or the recipient's refusal to provide MDNs. The "message/disposition-notification" content-type defined herein is intended for use within the framework of the "multipart/report" content type defined in [RFC-REPORT].
このメモはメッセージ気質通知(MDNs)のための[RFC MIMEメディア]満足しているタイプを定義します。 うまくいっている配送の後に現れるかもしれないいくつかの状態のどれかに関するメッセージについて送付者に通知するのにMDNを使用できます、メッセージ内容の表示、メッセージの印刷、メッセージの削除(表示のない)、またはMDNsを提供することへの受取人の拒否などのように。 ここに定義された「気質メッセージ/通知」満足しているタイプは使用のために[RFC-REPORT]で定義された「複合/レポート」満足しているタイプの枠組みの中で意図します。
This memo defines the format of the notifications and the [RFC- MSGFMT] headers used to request them.
このメモは通知の書式を定義します、そして、[RFC- MSGFMT]ヘッダーは以前はよく彼らを要求していました。
1.1. Purposes
1.1. 目的
The MDNs defined in this memo are expected to serve several purposes:
このメモで定義されたMDNsがいくつかの目的に役立つと予想されます:
(a) Inform human beings of the disposition of messages after
successful delivery, in a manner that is largely independent of
human language;
(a) うまくいっている配送の後にメッセージの気質について人間に知らせてください、人間の言語から主に独立している方法で。
(b) Allow mail user agents to keep track of the disposition of
messages sent, by associating returned MDNs with earlier message
transmissions;
(b) メールユーザエージェントに以前のメッセージ送信に返されたMDNsを関連づけることによって送られたメッセージの気質に動向をおさえさせてください。
(c) Convey disposition notification requests and disposition
notifications between Internet Mail and "foreign" mail systems
via a gateway;
(c) ゲートウェイを通してインターネットメールと「外国」のメールシステムの間に気質通知要求と気質通知を伝えてください。
(d) 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;
(d) 「外国」の通知にMIMEのできるメッセージシステムを通してオリジナルの通知を発行したオリジナルのメッセージシステムか、3番目のメッセージシステムにさえ行き帰りトンネルを堀らされてください。
(e) Allow language-independent, yet reasonably precise, indications
of the disposition of a message to be delivered.
(e) 渡されるべきメッセージの気質の言語から独立していて、しかし、合理的に正確なしるしを許容してください。
1.2. Requirements
1.2. 要件
These purposes place the following constraints on the notification protocol:
これらの目的は通知プロトコルに以下の規制を置きます:
(a) It must be readable by humans, and must be machine-parsable.
(a) それは、人間で読み込み可能でなければならなく、マシン「パー-可能」であるに違いありません。
Hansen & Vaudreuil Standards Track [Page 3] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[3ページ]。
(b) It must provide enough information to allow message senders (or
their user agents) to unambiguously associate an MDN with the
message that was sent and the original recipient address for
which the MDN was issued (if such information is available),
even if the message was forwarded to another recipient address.
(b) メッセージ送付者(または、彼らのユーザエージェント)が明白に送られたメッセージとMDNが発行されたオリジナルの受取人アドレスにMDNを関連づけるのを許容できるくらいの情報を提供しなければなりません(そのような情報が利用可能であるなら)、別の受取人アドレスにメッセージを転送したとしても。
(c) It must also be able to describe the disposition of a message
independent of any particular human language or of the
terminology of any particular mail system.
(c) また、それはどんな特定の人間の言語の如何にかかわらずメッセージかどんな特定のメールシステムの用語の気質についても説明できなければなりません。
(d) The specification must be extensible in order to accommodate
future requirements.
(d) 仕様は、将来の要件を収容するために広げることができなければなりません。
1.3. Terminology
1.3. 用語
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 [RFC-KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-キーワード]で説明されるように本書では解釈されることであるべきですか?
All syntax descriptions use the ABNF specified by [RFC-MSGFMT], in which the lexical tokens (used below) are defined: "atom", "CRLF", "mailbox", "msg-id", and "text". The following lexical tokens are defined in the definition of the Content-Type header in [RFC-MIME- BODY]: "attribute" and "value".
すべての構文記述が字句(以下では、使用される)が定義される[RFC-MSGFMT]によって指定されたABNFを使用します: 「原子」、"CRLF"、「メールボックス」、「msg-イド」、および「テキスト。」 以下の字句は[RFC-MIME BODY]とのコンテントタイプヘッダーの定義で定義されます: 「結果と考え」て、「評価します」。
2. Requesting Message Disposition Notifications
2. メッセージ気質通知を要求します。
Message disposition notifications are requested by including a Disposition-Notification-To header in the message. Further information to be used by the recipient's MUA in generating the MDN may be provided by also including Original-Recipient and/or Disposition-Notification-Options headers in the message.
メッセージ気質通知がaを含んでいることによって要求されている、Disposition通知、メッセージのヘッダー。 また、メッセージにOriginal-受取人、そして/または、Disposition通知オプションヘッダーを含んでいることによって、MDNを発生させる際に受取人のMUAによって使用されるべき詳細を提供するかもしれません。
2.1. The Disposition-Notification-To Header
2.1. 気質通知、ヘッダー
A request for the receiving user agent to issue message disposition notifications is made by placing a Disposition-Notification-To header into the message. The syntax of the header is
aを置くことによって受信ユーザエージェントがメッセージ気質通知を発行するという要求をする、Disposition通知、メッセージへのヘッダー。 ヘッダーの構文はそうです。
mdn-request-header = "Disposition-Notification-To" ":"
mailbox *("," mailbox)
「mdn要求ヘッダー=、「気質通知、」、」、:、」 メールボックス*(「」、メールボックス)
The presence of a Disposition-Notification-To header in a message is merely a request for an MDN. The recipients' user agents are always free to silently ignore such a request. Alternatively, an explicit denial of the request for information about the disposition of the message may be sent using the "denied" disposition in an MDN.
aの存在、Disposition通知、MDNを求めてメッセージのヘッダーは単に要求です。 受取人のユーザエージェントはいつも自由に静かにそのような要求を無視できます。 あるいはまた、メッセージの気質の情報に関する要求の明白な拒絶にMDNで「否定された」気質を使用させるかもしれません。
Hansen & Vaudreuil Standards Track [Page 4] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[4ページ]。
An MDN MUST NOT itself have a Disposition-Notification-To header. An MDN MUST NOT be generated in response to an MDN.
MDN MUST NOT自身にはaがある、Disposition通知、ヘッダー。 MDN MUST NOT、MDNに対応して、発生してください。
A user agent MUST NOT issue more than one MDN on behalf of each particular recipient. That is, once an MDN has been issued on behalf of a recipient, no further MDNs may be issued on behalf of that recipient, even if another disposition is performed on the message. However, if a message is forwarded, an MDN may have been issued for the recipient doing the forwarding and the recipient of the forwarded message may also cause an MDN to be generated.
ユーザエージェントはそれぞれの特定の受取人を代表して1MDNを発行してはいけません。 すなわち、MDNが受取人を代表していったん発行されると、一層のMDNsは全くその受取人を代表して発行されないかもしれません、別の気質がメッセージに実行されても。 しかしながら、メッセージを転送するなら、推進をしている受取人のためにMDNを発行したかもしれません、そして、また、転送されたメッセージの受取人はMDNを発生させるかもしれません。
While Internet standards normally do not specify the behavior of user interfaces, it is strongly recommended that the user agent obtain the user's consent before sending an MDN. This consent could be obtained for each message through some sort of prompt or dialog box, or globally through the user's setting of a preference. The user might also indicate globally that MDNs are to never be sent or that a "denied" MDN is always sent in response to a request for an MDN.
通常、インターネット標準がユーザインタフェースの振舞いを指定していない間、MDNを送る前にユーザエージェントがユーザの同意を得ることが強く勧められます。 ユーザの優先の設定を通してある種のプロンプトかダイアログボックスを通してこの同意を各メッセージにグローバルに得ることができました。 また、ユーザは、MDNsを決して送ってはいけないか、または「否定された」MDNがいつもMDNを求める要求に対応して送られるのをグローバルに示すかもしれません。
MDNs SHOULD NOT be sent automatically if the address in the Disposition-Notification-To header differs from the address in the Return-Path header (see [RFC-MSGFMT]). In this case, confirmation from the user SHOULD be obtained, if possible. If obtaining consent is not possible (e.g., because the user is not online at the time), then an MDN SHOULD NOT be sent.
MDNs SHOULD、中のアドレスであるなら自動的に送られないでください、Disposition通知、ヘッダーはReturn-経路ヘッダーでアドレスと異なっています([RFC-MSGFMT]を見てください)。 この場合確認、できれば、ユーザSHOULDから、得てください。 得るなら、同意は可能でなく(例えば、ユーザが当時、オンラインのででない)、その時はMDN SHOULD NOTです。送ります。
Confirmation from the user SHOULD be obtained (or no MDN sent) if there is no Return-Path header in the message, or if there is more than one distinct address in the Disposition-Notification-To header.
確認、メッセージでReturn-経路ヘッダーが全くないか、または中に1つ以上の異なったアドレスがあればユーザSHOULDから得てください、(どんなMDNも発信しませんでした)Disposition通知、ヘッダー。
The comparison of the addresses should be done using only the addr- spec (local-part "@" domain) portion, excluding any phrase and route. The comparison MUST be case-sensitive for the local-part and case- insensitive for the domain part.
アドレスの比較はaddr仕様(地方の部分"@"ドメイン)部分だけを使用し終わるべきです、どんな句とルートを除いて。 ドメイン部分に、神経の鈍い地方の部分とケースにおいて、比較は大文字と小文字を区別しているに違いありません。
If the message contains more than one Return-Path header, the implementation may pick one to use for the comparison, or treat the situation as a failure of the comparison.
メッセージが1個以上のReturn-経路ヘッダーを含んでいるなら、実現は、比較に使用する1つを選ぶか、または比較の失敗として状況を扱うかもしれません。
The reason for not automatically sending an MDN if the comparison fails or more than one address is specified is to reduce the possibility of mail loops and of MDNs being used for mail bombing.
比較が失敗するか、または1つ以上のアドレスが指定されるなら自動的にMDNを送らない理由はメール爆撃に使用されることでメール輪とMDNsの可能性を減少させることです。
A message that contains a Disposition-Notification-To header SHOULD also contain a Message-ID header as specified in [RFC-MSGFMT]. This will permit automatic correlation of MDNs with their original messages by user agents.
aを含むメッセージ、Disposition通知、また、ヘッダーSHOULDは[RFC-MSGFMT]の指定されるとしてのMessage-IDヘッダーを含んでいます。 これはユーザエージェントによる彼らのオリジナルのメッセージでMDNsの自動修正を可能にするでしょう。
Hansen & Vaudreuil Standards Track [Page 5] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[5ページ]。
If the request for message disposition notifications for some recipients and not others is desired, two copies of the message should be sent, one with a Disposition-Notification-To header and one without. Many of the other headers of the message (e.g., To, Cc) will be the same in both copies. The recipients in the respective message envelopes determine for whom message disposition notifications are requested and for whom they are not. If desired, the Message-ID header may be the same in both copies of the message. Note that there are other situations (e.g., Bcc) in which it is necessary to send multiple copies of a message with slightly different headers. The combination of such situations and the need to request MDNs for a subset of all recipients may result in more than two copies of a message being sent, some with a Disposition- Notification-To header and some without.
他のものではなく、何人かの受取人へのメッセージ気質通知に関する要求を望んでいるなら、メッセージのコピー2部を送るべきです、aがある1、Disposition通知、ヘッダーと1 メッセージ(例えば、To、Cc)の他のヘッダーの多くが両方のコピーで同じになるでしょう。 それぞれのメッセージ封筒の受取人はメッセージ気質通知がだれにとって要求されているか、そして、それらがだれにとってないかを決心しています。 望まれているなら、Message-IDヘッダーはメッセージの両方のコピーで同じであるかもしれません。 わずかに異なったヘッダーと共にメッセージの複本を送るのが必要である他の状況(例えば、Bcc)があることに注意してください。 そのような状況の組み合わせとすべての受取人の部分集合のためにMDNsを要求する必要性は送られるメッセージのコピー2部以上をもたらすかもしれません、Dispositionがあるいくつか、通知、-、ヘッダーといくつか
Messages posted to newsgroups SHOULD NOT have a Disposition- Notification-To header.
ニュースグループSHOULD NOTに掲示されたメッセージがDispositionを持っている、通知、-、ヘッダー。
2.2. The Disposition-Notification-Options Header
2.2. 気質通知オプションヘッダー
Future extensions to this specification may require that information be supplied to the recipient's MUA for additional control over how and what MDNs are generated. The Disposition-Notification-Options header provides an extensible mechanism for such information. The syntax of this header is as follows:
この仕様への将来の拡張子は、情報がどのように、MDNsが何であるかの上で発生する追加コントロールのために受取人のMUAに提供されるのを必要とするかもしれません。 Disposition通知オプションヘッダーは広げることができるメカニズムをそのような情報に提供します。 このヘッダーの構文は以下の通りです:
Disposition-Notification-Options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
「気質通知オプションは「気質通知オプション」と等しい」:、」 気質通知パラメタ
disposition-notification-parameters = parameter *(";" parameter)
気質通知パラメタはパラメタ*と等しいです。(「」、;、パラメタ)
parameter = attribute "=" importance "," value *("," value)
」 「パラメタ=属性「=」重要性」、値の*(「」、値)
importance = "required" / "optional"
重要性=「必要」/「任意です」。
An importance of "required" indicates that interpretation of the parameter is necessary for proper generation of an MDN in response to this request. If an MUA does not understand the meaning of the parameter, it MUST NOT generate an MDN with any disposition type other than "failed" in response to the request. An importance of "optional" indicates that an MUA that does not understand the meaning of this parameter MAY generate an MDN in response anyway, ignoring the value of the parameter.
「必要」の重要性は、パラメタの解釈がこの要求に対応してMDNの適切な世代に必要であることを示します。 MUAがパラメタの意味を理解していないなら、それは要求に対応して「失敗される」以外のどんな気質タイプでもMDNを発生させてはいけません。 「任意」の重要性は、このパラメタの意味を理解していないMUAが応答でMDNをとにかく発生させるかもしれないのを示します、パラメタの値を無視して。
No parameters are defined in this specification. Parameters may be defined in the future by later revisions or extensions to this specification. Parameter attribute names beginning with "X-" will
パラメタは全くこの仕様に基づき定義されません。 パラメタは将来、この仕様への後の改正か拡大で定義されるかもしれません。 「X」と共に始まるパラメタ属性名はそうするでしょう。
Hansen & Vaudreuil Standards Track [Page 6] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[6ページ]。
never be defined as standard names; such names are reserved for experimental use. MDN parameter names not beginning with "X-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and described in a standards-track RFC or an experimental RFC approved by the IESG. (See Section 10 for a registration form.)
標準の名前と決して定義されないでください。 そのような名前は実験用のために予約されます。 数の権威(IANA)が割り当てられて、標準化過程RFCで説明されるインターネットかIESGによって承認される実験的なRFCに「X」と共に始まらないMDNパラメタ名を登録しなければなりません。 (登録用紙に関してセクション10を見てください。)
If a required parameter is not understood or contains some sort of error, the receiving MUA SHOULD issue an MDN with a disposition type of "failed" (see Section 3.2.6), and include a Failure field (see Section 3.2.7) that further describes the problem. MDNs with the disposition type of "failed" and a "Failure" field MAY also be generated when other types of errors are detected in the parameters of the Disposition-Notification-Options header.
必要なパラメタが理解されていないか、またはある種の誤りを含んでいるなら、受信MUA SHOULDは「失敗(セクション3.2.6を見る)にされるの」の気質タイプでMDNを発行して、さらに問題について説明するFailure分野(セクション3.2.7を見る)を含んでいます。 また、他のタイプの誤りがDisposition通知オプションヘッダーのパラメタに検出されるとき、「失敗されること」の気質タイプと「失敗」分野があるMDNsは発生するかもしれません。
However, an MDN with a disposition type of "failed" MUST NOT be generated if the user has indicated a preference that MDNs are not to be sent. If user consent would be required for an MDN of some other disposition type to be sent, user consent SHOULD also be obtained before sending an MDN with a disposition type of "failed".
しかしながら、ユーザがMDNsを送ってはいけない優先を示したなら、「失敗されること」の気質タイプがあるMDNは発生してはいけません。 ユーザ同意SHOULD、ユーザ同意がある他の気質のMDNに必要であるなら、タイプして、送ってください、また、「失敗されること」の気質タイプでMDNを送る前に、得てください。
2.3. The Original-Recipient Header
2.3. オリジナルの受取人ヘッダー
Since electronic mail addresses may be rewritten while the message is in transit, it is useful for the original recipient address to be made available by the delivering MTA. The delivering MTA may be able to obtain this information from the ORCPT parameter of the SMTP RCPT TO command, as defined in [RFC-SMTP] and [RFC-DSN-SMTP].
メッセージがトランジット中である間、電子メールアドレスが書き直されるかもしれないので、オリジナルの受取人アドレスが配送しているMTAによって利用可能にされるのは、役に立ちます。 配送しているMTAはSMTP RCPT TOコマンドのORCPTパラメタからこの情報を得ることができるかもしれません、[RFC-SMTP]と[RFC-DSN-SMTP]で定義されるように。
[RFC-DSN-SMTP] is amended as follows: If the ORCPT information is available, the delivering MTA SHOULD insert an Original-Recipient header at the beginning of the message (along with the Return-Path header). The delivering MTA MAY delete any other Original-Recipient headers that occur in the message. The syntax of this header is as follows:
[RFC-DSN-SMTP]は以下の通り修正されます: ORCPT情報が利用可能であるなら、配送しているMTA SHOULDはメールの文頭(Return-経路ヘッダーに伴う)にOriginal-受取人ヘッダーを挿入します。 配送しているMTA MAYはメッセージに起こるいかなる他のOriginal-受取人ヘッダーも削除します。 このヘッダーの構文は以下の通りです:
original-recipient-header =
"Original-Recipient" ":" address-type ";" generic-address
「オリジナルの受取人ヘッダーは「オリジナルの受取人」と等しい」:、」 「アドレスタイプ」;、」 一般的なアドレス
The address-type and generic-address token are as specified in the description of the Original-Recipient field in section 3.2.3.
アドレスタイプと一般的なアドレス象徴がセクション3.2.3における、Original-受取人分野の記述で指定されるようにあります。
The purpose of carrying the original recipient information and returning it in the MDN is to permit automatic correlation of MDNs with the original message on a per-recipient basis.
オリジナルの受取人情報を運んで、MDNでそれを返す目的は1受取人あたり1個のベースに関するオリジナルのメッセージでMDNsの自動修正を可能にすることです。
Hansen & Vaudreuil Standards Track [Page 7] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[7ページ]。
2.4. Use with the Message/Partial Content Type
2.4. メッセージ/部分的な満足しているタイプとの使用
The use of the headers Disposition-Notification-To, Disposition- Notification-Options, and Original-Recipient with the MIME message/partial content type ([RFC-MIME-MEDIA]) requires further definition.
ヘッダーの使用、Disposition通知、Dispositionはさらなる定義を必要とします通知オプション、およびMIMEメッセージ/部分的な内容をもっているOriginal-受取人が、タイプする([RFC MIMEメディア])。
When a message is segmented into two or more message/partial fragments, the three headers mentioned in the above paragraph SHOULD be placed in the "inner" or "enclosed" message (using the terms of [RFC-MIME-MEDIA]). These headers SHOULD NOT be used in the headers of any of the fragments themselves.
メッセージがいつ、2に区分されるか、そして、より多くのメッセージ/部分的な断片、3個のヘッダーが「内側」の、または、「同封」のメッセージに置かれる([RFC MIMEメディア]の用語を使用して)ように上のパラグラフSHOULDで言及しました。 これらのヘッダーSHOULD NOT、断片のどれか自体のヘッダーで使用されてください。
When the multiple message/partial fragments are reassembled, the following applies. If these headers occur along with the other headers of a message/partial fragment message, they pertain to an MDN that will be generated for the fragment. If these headers occur in the headers of the "inner" or "enclosed" message (using the terms of [RFC-MIME-MEDIA]), they pertain to an MDN that will be generated for the reassembled message. Section 5.2.2.1 of [RFC-MIME-MEDIA]) is amended to specify that, in addition to the headers specified there, the three headers described in this specification are to be appended, in order, to the headers of the reassembled message. Any occurrences of the three headers defined here in the headers of the initial enclosing message must not be copied to the reassembled message.
複数のメッセージ/部分的な断片が組み立て直されるとき、以下は適用されます。 これらのヘッダーがメッセージ/部分的な断片メッセージの他のヘッダーと共に起こるなら、彼らは断片のために発生するMDNに関係します。 これらのヘッダーが「内側」の、または、「同封」のメッセージのヘッダーに起こるなら([RFC MIMEメディア]の用語を使用して)、それらは組み立て直されたメッセージのために発生するMDNに関係します。 セクション5.2 .2 .1[RFC MIMEメディア]) この仕様で説明された3個のヘッダーが追加されることになっています、オーダーで、そこで指定されたヘッダーに加えて組み立て直されたメッセージのヘッダーに指定するために、修正されます。 ここ、初期の同封メッセージのヘッダーで定義された3個のヘッダーのどんな発生も組み立て直されたメッセージにコピーしてはいけません。
3. Format of a Message Disposition Notification
3. メッセージ気質通知の形式
A message disposition notification is a MIME message with a top-level content-type of multipart/report (defined in [RFC-REPORT]). When multipart/report content is used to transmit an MDN:
メッセージ気質通知はトップレベルの満足しているタイプの複合/レポート([RFC-REPORT]では、定義される)があるMIMEメッセージです。 複合/レポート内容がMDNを伝えるのに使用されるとき:
(a) The report-type parameter of the multipart/report content is
"disposition-notification".
(a) 複合/レポート内容に関するレポート型引数は「気質通知」です。
(b) The first component of the multipart/report contains a human-
readable explanation of the MDN, as described in [RFC-REPORT].
(b) 複合/レポートの最初の成分は[RFC-REPORT]で説明されるようにMDNの人間の読み込み可能な説明を含んでいます。
(c) The second component of the multipart/report is of content-type
message/disposition-notification, described in section 3.1 of
this document.
(c) 複合/レポートの2番目の成分はこのドキュメントのセクション3.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. The decision of whether or not to return the
message or part of the message is up to the MUA generating the
(d) オリジナルのメッセージかメッセージの部分が送付者に返すことであるなら、それは複合/レポートの3番目の成分として現れます。 メッセージを返すかどうかに関する決定かメッセージの一部がMUA発生次第です。
Hansen & Vaudreuil Standards Track [Page 8] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[8ページ]。
MDN. However, in the case of encrypted messages requesting
MDNs, encrypted message text MUST be returned, if it is returned
at all, only in its original encrypted form.
MDN。 しかしながら、MDNsを要求する暗号化メッセージの場合では、暗号化メッセージテキストを返さなければなりません、それを少しでも返すなら、元のコード化されたフォームだけで。
NOTE: For message disposition notifications gatewayed from foreign
systems, the headers of the original message may not be available.
In this case, the third component of the MDN may be omitted, or it
may contain "simulated" [RFC-MSGFMT] headers that contain equivalent
information. In particular, it is very desirable to preserve the
subject and date fields from the original message.
以下に注意してください。 外国システムからgatewayedされたメッセージ気質通知には、オリジナルのメッセージのヘッダーは手があいていないかもしれません。 この場合、MDNの3番目の部品が省略されるかもしれませんか、またはそれは同等な情報を含む「シミュレートされた」[RFC-MSGFMT]ヘッダーを含むかもしれません。 特に、オリジナルのメッセージから対象と日付の分野を保持するのは非常に望ましいです。
The MDN MUST be addressed (in both the message header and the transport envelope) to the address(es) from the Disposition- Notification-To header from the original message for which the MDN is being generated.
MDN MUST、Dispositionからアドレスに記述されてください、(メッセージヘッダーと輸送封筒の両方で)(esします)通知、-、MDNが発生しているオリジナルのメッセージからのヘッダー。
The From field of the message header of the MDN MUST contain the address of the person for whom the message disposition notification is being issued.
MDN MUSTのメッセージヘッダーのFrom分野はメッセージ気質通知が発行されている人のアドレスを含んでいます。
The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be null (<>), specifying that no Delivery Status Notification messages or other messages indicating successful or unsuccessful delivery are to be sent in response to an MDN.
封筒送付者はヌルが(<>)であったならMDN MUSTの(すなわち、SMTP MAIL FROM)を記述します、うまくいっているか失敗の配送を示すDelivery Status Notificationメッセージか他のどんなメッセージもMDNに対応して送られないことであると指定して。
A message disposition notification MUST NOT itself request an MDN. That is, it MUST NOT contain a Disposition-Notification-To header.
それ自体ではなく、通知がそうしなければならないメッセージ気質がMDNを要求します。 aを含んではいけない、Disposition通知、ヘッダー。
The Message-ID header (if present) for an MDN MUST be different from the Message-ID of the message for which the MDN is being issued.
Message-IDヘッダー、(存在しているなら) MDN MUSTに関しては、MDNが発行されているメッセージのMessage-IDと、異なってください。
A particular MDN describes the disposition of exactly one message for exactly one recipient. Multiple MDNs may be generated as a result of one message submission, one per recipient. However, due to the circumstances described in Section 2.1, MDNs may not be generated for some recipients for which MDNs were requested.
特定のMDNはちょうど1人の受取人のためにまさに1つのメッセージの気質について説明します。 複数のMDNsが1つのメッセージの服従、1受取人あたり1つの結果、発生するかもしれません。 しかしながら、セクション2.1で説明された事情のため、MDNsはMDNsが要求された何人かの受取人のために発生しないかもしれません。
3.1. The message/disposition-notification content-type
3.1. 気質メッセージ/通知の満足しているタイプ
The message/disposition-notification content-type is defined as follows:
気質メッセージ/通知の満足しているタイプは以下の通り定義されます:
MIME type name: message
MIMEの種類名: メッセージ
MIME subtype name: disposition-notification
MIME「副-タイプ」は以下を命名します。 気質通知
Optional parameters: none
任意のパラメタ: なし
Hansen & Vaudreuil Standards Track [Page 9] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[9ページ]。
Encoding considerations: "7bit" encoding is sufficient and
MUST be used to maintain readability
when viewed by non-MIME mail readers.
問題をコード化します: 「7ビット」のコード化を十分であり、非MIMEメール読者によって見られると、読み易さを維持するのに使用しなければなりません。
Security considerations: discussed in section 6 of this memo.
セキュリティ問題: このメモのセクション6で、議論します。
The message/disposition-notification report type for use in the multipart/report is "disposition-notification".
複合/レポートにおける使用のための気質メッセージ/通知レポートタイプは「気質通知」です。
The body of a message/disposition-notification consists of one or more "fields" formatted according to the ABNF of [RFC-MSGFMT] header "fields". The syntax of the message/disposition-notification content is as follows:
気質メッセージ/通知のボディーは[RFC-MSGFMT]ヘッダー「分野」のABNFによると、フォーマットされた1「分野」から成ります。 気質メッセージ/通知内容の構文は以下の通りです:
disposition-notification-content = [ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
disposition-field CRLF
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
気質通知内容は最終受理者分野CRLF[元のメッセージイド分野CRLF]気質分野CRLF*(失敗分野CRLF)*(誤り分野CRLF)*(警告分野CRLF)*と等しいです[報告しているua分野CRLF][mdnゲートウェイ分野CRLF][元の受取人分野CRLF]。(拡大分野CRLF)
3.1.1. General conventions for fields
3.1.1. 分野への総会
Since these fields are defined according to the rules of [RFC- MSGFMT], 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 notification fields may use the "encoded-word" construct defined in [RFC-MIME-HEADER].
[RFC- MSGFMT]の規則に従ってこれらの分野が定義されるので、継続行とコメントのための同じコンベンションは適用されます。 通知分野は、SPACEかHTABと共にそれぞれの追加線を始めることによって、複数の線に続けられるかもしれません。 括弧に現れるテキストは部分ではなく、その通知分野のコンテンツのコメントであると考えられます。 フィールド名がケース神経が鈍いので、通知分野の名前は大文字と小文字手紙のどんな組み合わせでもつづられるかもしれません。 通知分野でのコメントは[RFC MIME HEADER]で定義された「コード化された単語」構造物を使用するかもしれません。
3.1.2. "*-type" subfields
3.1.2. 「*タイプ」部分体
Several fields consist of a "-type" subfield, followed by a semi- colon, followed by "*text". For these fields, the keyword used in the address-type or MTA-type subfield indicates the expected format of the address or MTA-name that follows.
「いくつかの分野が」 *テキストがあとに続いた準コロンがあとに続いた「タイプ」部分体から成ります。」 これらの分野に、アドレスタイプかMTA-タイプ部分体に使用されるキーワードは従うアドレスかMTA-名前の予想された書式を示します。
Hansen & Vaudreuil Standards Track [Page 10] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[10ページ]。
The "-type" subfields are defined as follows:
「タイプ」部分体は以下の通り定義されます:
(a) An "address-type" specifies the format of a mailbox address.
For example, Internet Mail addresses use the "rfc822" address-
type.
(a) 「アドレスタイプ」はメールボックスアドレスの形式を指定します。 例えば、インターネットメールアドレスは"rfc822"アドレスタイプを使用します。
address-type = atom
アドレスタイプは原子と等しいです。
(b) An "MTA-name-type" specifies the format of a mail transfer agent
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.
(b) 「MTA名前タイプ」はメール転送エージェント名の形式を指定します。 例えば、MTA名はインターネット・ホストの上のSMTPサーバーのための、そのホストのドメイン名です、そして、"dns"MTA名前タイプは使用されています。
mta-name-type = atom
mta名前タイプは原子と等しいです。
Values for address-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) maintains a registry of address-type and mta-name-type values, along with descriptions of the meanings of each, or a reference to one or more specifications that provide such descriptions. (The "rfc822" address-type is defined in [RFC-DSN-SMTP].) Registration forms for address-type and mta-name-type appear in [RFC-DSN-FORMAT].
インターネットAssigned民数記Authority(IANA)はアドレスタイプとmta名前タイプ値の登録を維持します、それぞれの意味の記述、またはそのような記述を提供する1つ以上の仕様の参照と共に。 ("rfc822"アドレスタイプは[RFC-DSN-SMTP]で定義されます。) アドレスタイプとmta名前タイプのための登録用紙は[RFC-DSN-FORMAT]に現れます。
3.2. Message/disposition-notification Fields
3.2. 気質メッセージ/通知分野
3.2.1. The Reporting-UA field
3.2.1. Reporting-UA分野
reporting-ua-field = "Reporting-UA" ":" ua-name
[ ";" ua-product ]
「報告しているua分野=「報告-UA」」:、」 ua-名前[「」、;、ua-製品]
ua-name = *text
ua-名前=*テキスト
ua-product = *text
ua-製品=*テキスト
The Reporting-UA field is defined as follows:
Reporting-UA分野は以下の通り定義されます:
An MDN describes the disposition of a message after it has been delivered to a recipient. In all cases, the Reporting-UA is the MUA that performed the disposition described in the MDN. This field is optional, but recommended. For Internet Mail user agents, it is recommended that this field contain both: the DNS name of the particular instance of the MUA that generated the MDN, and the name of the product. For example,
それを受取人に届けた後にMDNはメッセージの気質について説明します。 すべての場合では、Reporting-UAはMDNで説明された気質を実行したMUAです。 この分野は、任意ですが、お勧めです。 インターネットメールユーザエージェントにとって、この分野が両方を含むのは、お勧めです: MDNを発生させたMUAの特定の例のDNS名、および製品の名前。 例えば
Reporting-UA: pc.example.com; Foomail 97.1
報告しているUA: pc.example.com。 Foomail97.1
Hansen & Vaudreuil Standards Track [Page 11] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[11ページ]。
If the reporting MUA consists of more than one component (e.g., a base program and plug-ins), this may be indicated by including a list of product names.
報告しているMUAが1つ以上のコンポーネント(例えば、基本プログラムとプラグイン)から成るなら、これは、製品名のリストを含んでいることによって、示されるかもしれません。
3.2.2. The MDN-Gateway field
3.2.2. MDN-ゲートウェイ分野
The MDN-Gateway field indicates the name of the gateway or MTA that translated a foreign (non-Internet) message disposition notification into this MDN. This field MUST appear in any MDN that was translated by a gateway from a foreign system into MDN format, and MUST NOT appear otherwise.
MDN-ゲートウェイ分野は外国(非インターネットの)のメッセージ気質通知をこのMDNに翻訳したゲートウェイかMTAという名前を示します。 ゲートウェイによって外国システムからMDN形式に翻訳されたどんなMDNにも現れなければなりません。そうでなければ、この野原は、現れてはいけません。
mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
「mdnゲートウェイ分野=「MDN-ゲートウェイ」」:、」 「mta名前タイプ」;、」 mta-名前
mta-name = *text
mta-名前=*テキスト
For gateways into Internet Mail, the MTA-name-type will normally be "smtp", and the mta-name will be the Internet domain name of the gateway.
通常、MTA名前タイプはインターネットメールへのゲートウェイに関しては、"になるでしょう、そして、"smtp mta-名前はゲートウェイのインターネットドメイン名になるでしょう。
3.2.3. Original-Recipient field
3.2.3. オリジナルの受取人分野
The Original-Recipient field indicates the original recipient address as specified by the sender of the message for which the MDN is being issued. For Internet Mail messages, the value of the Original- Recipient field is obtained from the Original-Recipient header from the message for which the MDN is being generated. If there is no Original-Recipient header in the message, then the Original-Recipient field MUST be omitted, unless the same information is reliably available some other way. If there is an Original-Recipient header in the original message (or original recipient information is reliably available some other way), then the Original-Recipient field must be supplied. If there is more than one Original-Recipient header in the message, the MUA may choose the one to use, or act as if no Original-Recipient header is present.
Original-受取人分野はMDNが発行されているメッセージ送信者による指定されるとしてのオリジナルの受取人アドレスを示します。 インターネットメールメッセージにおいて、Original-受取人ヘッダーからMDNが発生しているメッセージからOriginal受取人分野の値を得ます。 メッセージにOriginal-受取人ヘッダーが全くなければ、Original-受取人分野を省略しなければなりません、同じ情報がある他の方法で確かに利用可能でない場合。 オリジナルのメッセージにOriginal-受取人ヘッダーがあれば(オリジナルの受取人情報はある他の方法で確かに利用可能です)、Original-受取人野原を供給しなければなりません。 メッセージに1個以上のOriginal-受取人ヘッダーがあれば、まるでどんなOriginal-受取人ヘッダーも出席していないかのようにMUAは使用するか、または活動させるものを選ぶかもしれません。
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 [RFC-MSGFMT]. The value "unknown" should be used if the Reporting MUA cannot determine the type of the original recipient address from the message envelope.
アドレスタイプ分野はオリジナルの受取人アドレスのタイプを示します。 メッセージがインターネットの中で由来したなら、通常、アドレスタイプ分野は"rfc822"でしょう、そして、[RFC-MSGFMT]で指定された構文によると、アドレスがあるでしょう。 Reporting MUAがメッセージ封筒からのオリジナルの受取人アドレスのタイプを決定できないなら、値の「未知」は使用されるべきです。
Hansen & Vaudreuil Standards Track [Page 12] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[12ページ]。
This address is the same as that provided by the sender and can be used to automatically correlate MDN reports with original messages on a per recipient basis.
このアドレスは、受取人基礎あたりのaに関するオリジナルのメッセージでMDNレポートを自動的に関連させるようにそれを送付者が提供して、使用できるのと同じです。
3.2.4. Final-Recipient field
3.2.4. 最終的な受取人分野
The Final-Recipient field indicates the recipient for which the MDN is being issued. This field MUST be present.
Final-受取人分野はMDNが発行されている受取人を示します。 この分野は存在していなければなりません。
The syntax of the field is as follows:
分野の構文は以下の通りです:
final-recipient-field =
"Final-Recipient" ":" address-type ";" generic-address
「最終受理者分野=「最終受理者」」:、」 「アドレスタイプ」;、」 一般的なアドレス
The generic-address subfield of the Final-Recipient field MUST contain the mailbox address of the recipient (from the From header of the MDN) as it was when the MDN was generated by the MUA.
MDNがMUAによって発生した時であるときに、Final-受取人分野の一般的なアドレス部分体は受取人(MDNのFromヘッダーからの)のメールボックスアドレスを含まなければなりません。
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 MDN with a particular message recipient.
Final-受取人アドレスは元々送付者によって提供されたアドレスと異なるかもしれません、推進の間、変えられて、完全に認知できない混乱にgatewayingしていたかもしれないので。 しかしながら、任意のOriginal-受取人分野がないとき、Final-受取人分野とどんな返された内容も特定のメッセージ受取人と共にMDNを関連させる利用可能な唯一の情報であるかもしれません。
The address-type subfield indicates the type of address expected by the reporting MTA in that context. Recipient addresses obtained via SMTP will normally be of address-type "rfc822".
アドレスタイプ部分体はその文脈で報告しているMTAによって予想されたアドレスのタイプを示します。 通常、SMTPを通して得られた受取人アドレスはアドレスタイプ"rfc822"のものになるでしょう。
Since mailbox addresses (including those used in the Internet) may be case sensitive, the case of alphabetic characters in the address MUST be preserved.
メールボックスアドレス(インターネットで使用されるものを含んでいる)が大文字と小文字を区別しているかもしれないので、アドレスにおける、英字に関するケースを保存しなければなりません。
3.2.5. Original-Message-ID field
3.2.5. 元のMessage ID分野
The Original-Message-ID field indicates the message-ID of the message for which the MDN is being issued. It is obtained from the Message- ID header of the message for which the MDN is issued. This field MUST be present if the original message contained a Message-ID header. The syntax of the field is as follows:
Original Message ID分野はMDNが発行されているメッセージのメッセージIDを示します。 MDNが発行されるメッセージのMessage IDヘッダーからそれを得ます。 オリジナルのメッセージがMessage-IDヘッダーを含んだなら、この分野は存在していなければなりません。 分野の構文は以下の通りです:
original-message-id-field =
"Original-Message-ID" ":" msg-id
「元のメッセージイド分野は「元のMessage ID」と等しい」:、」 msg-イド
The msg-id token is as specified in [RFC-MSGFMT].
msg-イド象徴が[RFC-MSGFMT]で指定されるようにあります。
Hansen & Vaudreuil Standards Track [Page 13] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[13ページ]。
3.2.6. Disposition field
3.2.6. 気質分野
The Disposition field indicates the action performed by the Reporting-MUA on behalf of the user. This field MUST be present.
Disposition分野は、動作がReporting-MUAでユーザを代表して働いたのを示します。 この分野は存在していなければなりません。
The syntax for the Disposition field is:
Disposition分野への構文は以下の通りです。
disposition-field =
"Disposition" ":" disposition-mode ";"
disposition-type
[ "/" disposition-modifier
*( "," disposition-modifier ) ]
「気質分野=「気質」」:、」 「気質モード」;、」 気質タイプ[「/」気質修飾語*、(「」、気質修飾語]
disposition-mode = action-mode "/" sending-mode
「気質モード=動作モード」/、」 発信モード
action-mode = "manual-action" / "automatic-action"
動作モードは「手動の動き」/「自動動作」と等しいです。
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
発信モードは「手動で送られたMDN」/「自動的に送られたMDN」と等しいです。
disposition-type = "displayed"
/ "deleted"
=が「表示する」か、または「削除した」気質タイプ
disposition-modifier = "error"
/ disposition-modifier-extension
気質修飾語気質修飾語=「誤り」/拡大
disposition-modifier-extension = atom
気質修飾語拡大は原子と等しいです。
The disposition-mode, disposition-type, and disposition-modifier may be spelled in any combination of upper and lower case characters.
気質モード、気質タイプ、および気質修飾語は大文字と小文字キャラクタのどんな組み合わせでもつづられるかもしれません。
3.2.6.1. Disposition modes
3.2.6.1. 気質モード
The following disposition modes are defined:
以下の気質モードは定義されます:
"manual-action" The disposition described by the disposition
type was a result of an explicit instruction
by the user rather than some sort of
automatically performed action.
気質が気質タイプで説明した「手動の動き」はある種の自動的に実行された動作よりむしろユーザによる明白な指示の結果でした。
"automatic-action" The disposition described by the disposition
type was a result of an automatic action,
rather than an explicit instruction by the
user for this message.
気質が気質タイプで説明した「自動動作」はこのメッセージのためのユーザによる明白な指示よりむしろ自動動作の結果でした。
"Manual-action" and "automatic-action" are mutually exclusive. One or the other MUST be specified.
「手動の動き」と「自動動作」は互いに排他的です。 1かもう片方を指定しなければなりません。
Hansen & Vaudreuil Standards Track [Page 14] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[14ページ]。
"MDN-sent-manually" The user explicitly gave permission for this
particular MDN to be sent.
ユーザの「手動で送られたMDN」は明らかにこの特定のMDNが送られる許可を与えました。
"MDN-sent-automatically"
The MDN was sent because the MUA had
previously been configured to do so
automatically.
「MDNは自動的に発信しました」。MUAが以前にそう自動的にするために構成されたので、MDNを送りました。
"MDN-sent-manually" and "MDN-sent-automatically" are mutually exclusive. One or the other MUST be specified.
「MDNは手動で発信し」て「MDNは自動的に発信したこと」が互いに排他的です。 1かもう片方を指定しなければなりません。
3.2.6.2. Disposition types
3.2.6.2. 気質タイプ
The following disposition-types are defined:
以下の気質タイプは定義されます:
"displayed" The message has been displayed by the MUA
to someone reading the recipient's mailbox.
There is no guarantee that the content has
been read or understood.
「表示され」て、メッセージは、受信者のメールボックスを読みながら、だれかへのMUAによって表示されました。 内容が読まれるか、または理解されているという保証が全くありません。
"deleted" The message has been deleted. The
recipient may or may not have seen the
message. The recipient might "undelete"
the message at a later time and read the
message.
「削除され」て、メッセージは削除されました。 受取人はメッセージを見たかもしれません。 受取人は、メッセージが後で"非削除"であり、メッセージを読むかもしれません。
3.2.6.3. Disposition modifiers
3.2.6.3. 気質修飾語
Only the extension disposition modifiers is defined:
拡大気質修飾語だけが定義されます:
disposition-modifier-extension
Disposition modifiers may be defined
in the future by later revisions
or extensions to this specification.
Disposition value names beginning with "X-"
will never be defined as standard values;
such names are reserved for experimental
use. MDN disposition value names NOT
beginning with "X-" MUST be registered with
the Internet Assigned Numbers Authority
(IANA) and described in a standards-track
RFC or an experimental RFC approved by the
IESG. (See Section 10 for a registration
form.) MDNs with disposition modifier
names not understood by the receiving MUA
MAY be silently ignored or placed in the
気質修飾語拡大Disposition修飾語は将来、この仕様への後の改正か拡大で定義されるかもしれません。 「X」と共に始まる気質値の名は基準値と決して定義されないでしょう。 そのような名前は実験用のために予約されます。 数の権威(IANA)が割り当てられて、標準化過程RFCで説明されるインターネットかIESGによって承認される実験的なRFCに「X」と共に始まらないMDN気質値の名を登録しなければなりません。 (登録用紙に関してセクション10を見てください。) 気質修飾語名があるMDNsは静かに無視されるように受信MUA MAYで理解もしていませんでしたし、中に入賞もしませんでした。
Hansen & Vaudreuil Standards Track [Page 15] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[15ページ]。
user's mailbox without special
interpretation. They MUST not cause any
error message to be sent to the sender of
the MDN.
特別な解釈のないユーザのメールボックス。 彼らはどんなエラーメッセージもMDNの送付者に送らせてはいけません。
If an MUA developer does not wish to register the meanings of such disposition modifier extensions, "X-" modifiers may be used for this purpose. To avoid name collisions, the name of the MUA implementation should follow the "X-", (e.g., "X-Foomail-").
MUA開発者がそのような気質修飾語拡大の意味を登録したくないなら、「X」修飾語はこのために使用されるかもしれません。 名前衝突を避けるために、MUA実現の名前は「X」、(例えば、"X-Foomail")に続くべきです。
It is not required that an MUA be able to generate all of the possible values of the Disposition field.
MUAがDisposition分野の可能な値のすべてを発生させることができるのが必要ではありません。
A user agent MUST NOT issue more than one MDN on behalf of each particular recipient. That is, once an MDN has been issued on behalf of a recipient, no further MDNs may be issued on behalf of that recipient, even if another disposition is performed on the message. However, if a message is forwarded, a "dispatched" MDN may be issued for the recipient doing the forwarding and the recipient of the forwarded message may also cause an MDN to be generated.
ユーザエージェントはそれぞれの特定の受取人を代表して1MDNを発行してはいけません。 すなわち、MDNが受取人を代表していったん発行されると、一層のMDNsは全くその受取人を代表して発行されないかもしれません、別の気質がメッセージに実行されても。 しかしながら、メッセージを転送するなら、推進をしている受取人のために「派遣された」MDNを発行するかもしれません、そして、また、転送されたメッセージの受取人はMDNを発生させるかもしれません。
3.2.7. Failure, Error, and Warning fields
3.2.7. 失敗、Error、およびWarning分野
The Failure, Error, and Warning fields are used to supply additional information in the form of text messages when the "failure" disposition type, "error" disposition modifier, and/or the "warning" disposition modifier appear. The syntax is as follows:
Failure、Error、およびWarning分野は、「失敗」気質タイプ、「誤り」気質修飾語、そして/または、「警告」気質修飾語が現れるとき、テキスト・メッセージの形で追加情報を提供するのに使用されます。 構文は以下の通りです:
failure-field = "Failure" ":" *text
「失敗分野=「失敗」」:、」 *テキスト
error-field = "Error" ":" *text
「誤り分野=「誤り」」:、」 *テキスト
warning-field = "Warning" ":" *text
「警告分野=「警告」」:、」 *テキスト
3.3. Extension-fields
3.3. 拡大分野
Additional MDN 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. MDN field names NOT beginning with "X-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and described in a standards-track RFC or an experimental RFC approved by the IESG. (See Section 10 for a registration form.)
追加MDN分野は将来、この仕様への後の改正か拡大で定義されるかもしれません。 「X」と共に始まる拡大フィールド名は標準の分野と決して定義されないでしょう。 そのような名前は実験用のために予約されます。 数の権威(IANA)が割り当てられて、標準化過程RFCで説明されるインターネットかIESGによって承認される実験的なRFCに「X」と共に始まらないMDNフィールド名を登録しなければなりません。 (登録用紙に関してセクション10を見てください。)
Hansen & Vaudreuil Standards Track [Page 16] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[16ページ]。
MDN Extension-fields may be defined for the following reasons:
MDN Extension-分野は以下の理由で定義されるかもしれません:
(a) To allow additional information from foreign disposition reports
to be tunneled through Internet MDNs. The names of such MDN
fields should begin with an indication of the foreign
environment name (e.g., X400-Physical-Forwarding-Address).
(a) 外国気質からの追加情報を許容するのはインターネットMDNsを通してトンネルを堀られると報告します。 そのようなMDN分野の名前は外国環境名(例えば、X400の物理的な推進アドレス)のしるしで始まるべきです。
(b) To allow transmission of diagnostic information that is specific
to a particular mail user agent (MUA). The names of such MDN
fields should begin with an indication of the MUA implementation
that produced the MDN (e.g., Foomail-information).
(b) 診断情報の伝達を許すために、特定のメールユーザエージェント(MUA)にとって、それは特定です。 そのようなMDN分野の名前はMDN(例えば、Foomail-情報)を生産したMUA実現のしるしで始まるべきです。
If an application 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 application implementation should follow the "X-", (e.g., "X-Foomail-Log-ID" or "X-Foomail-EDI- info").
アプリケーション開発者がそのような拡大分野の意味を登録したくないなら、「X」分野はこのために使用されるかもしれません。 または、名前衝突を避けるために、アプリケーション実現の名前が「X」に続くべきである、(例えば、「X-FoomailはIDを登録する」、「X-Foomail-エディインフォメーション、」、)
4. Timeline of events
4. 出来事に関するスケジュール
The following timeline shows when various events in the processing of a message and generation of MDNs take place:
以下のスケジュールは、MDNsのメッセージと世代の処理における様々な出来事がいつ起こるかを示します:
-- User composes message
-- ユーザはメッセージを構成します。
-- User tells MUA to send message
-- ユーザは、メッセージを送るようにMUAに言います。
-- MUA passes message to MTA (original recipient information passed
along)
-- MUAはメッセージをMTAに通過します。(伝えられたオリジナルの受取人情報)
-- MTA sends message to next MTA
-- MTAは次のMTAにメッセージを送ります。
-- Final MTA receives message
-- 最終的なMTAはメッセージを受け取ります。
-- Final MTA delivers message to MUA (possibly generating a DSN)
-- 最終的なMTAはメッセージをMUAに渡します。(ことによるとDSNを発生させます)
-- MUA performs automatic processing and generates corresponding MDNs
("dispatched", "processed", "deleted", "denied", or "failed"
disposition type with "automatic-action" and "MDN-sent-
automatically" disposition modes)
-- MUAは自動処理を実行して、対応するMDNsを発生させます。(「急い」で、「自動動作」で「否定された」か、「失敗した」気質タイプを「削除され」て、「処理し」て、気質モードを「-自動的にMDN送ります」)
-- MUA displays list of messages to user
-- 表示が記載するユーザへのメッセージのMUA
-- User selects a message and requests that some action be performed
on it.
-- ユーザはメッセージと何らかの動作がそれに実行されるという要求を選択します。
Hansen & Vaudreuil Standards Track [Page 17] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[17ページ]。
-- MUA performs requested action and, with user's permission, sends
an appropriate MDN ("displayed", "dispatched", "processed",
"deleted", "denied", or "failed" disposition type, with "manual-
action" and "MDN-sent-manually" or "MDN-sent-automatically"
disposition mode).
-- MUAは要求された動作を実行して、ユーザの許可と共に適切なMDN(「マニュアル動作」と「手動で送られたMDN」か「自動的に送られたMDN」気質モードがある「表示された」か、「派遣された」か、「処理された」か、「削除された」か、「否定された」か、「失敗した」気質タイプ)を送ります。
-- User possibly performs other actions on message, but no further
MDNs are generated.
-- ユーザはことによるとメッセージへの他の動作を実行しますが、一層のMDNsは全く発生しません。
5. Conformance and Usage Requirements
5. 順応と用法要件
An MUA or gateway conforms to this specification if it generates MDNs according to the protocol defined in this memo. It is not necessary to be able to generate all of the possible values of the Disposition field.
このメモで定義されたプロトコルに応じてMDNsを発生させるなら、MUAかゲートウェイがこの仕様に一致しています。 Disposition分野の可能な値のすべてを発生させることができるのは必要ではありません。
MUAs and gateways MUST NOT generate the Original-Recipient field of an MDN unless the mail protocols provide 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 [RFC-DSN-SMTP] permits such information to be carried in the envelope if it is available. The Original-Recipient header defined in this document provides a way for the MTA to pass the original recipient address to the MUA.
メールプロトコルが服従時点で元々送付者によって指定されたアドレスを提供しないなら、MUAsとゲートウェイはMDNのOriginal-受取人分野を発生させてはいけません。 普通のSMTPはその保証をしませんが、それが利用可能であるなら、[RFC-DSN-SMTP]で定義されたSMTP拡張子は、そのような情報が封筒で運ばれることを許可します。 本書では定義されたOriginal-受取人ヘッダーはMTAがオリジナルの受取人アドレスをMUAに通過する方法を提供します。
Each sender-specified recipient address may result in more than one MDN. If an MDN is requested for a recipient that is forwarded to multiple recipients of an "alias" (as defined in [RFC-DSN-SMTP], section 6.2.7.3), each of the recipients may issue an MDN.
それぞれの送付者によって指定された受取人アドレスは1MDNをもたらすかもしれません。 MDNが「別名」の複数の受取人に送られる受取人のために要求されるなら([RFC-DSN-SMTP]、セクション6.2.7で.3を定義するので)、受取人各人はMDNを発行するかもしれません。
Successful distribution of a message to a mailing list exploder SHOULD be considered the final disposition of the message. A mailing list exploder MAY issue an MDN with a disposition type of "processed" and disposition modes of "automatic-action" and "MDN-sent- automatically" indicating that the message has been forwarded to the list. In this case, the request for MDNs is not propagated to the members of the list.
aのうまくいっている分配は通信します。メッセージの最終的な気質であるとメーリングリスト発破器SHOULDと考えられます。 メーリングリスト発破器は、「自動動作」の「処理」と気質モードの気質タイプでMDNを発行するかもしれなくて、メッセージがリストに転送されたのを示しながら、「-自動的にMDN発信しました」。 この場合、MDNsを求める要求はリストのメンバーに伝播されません。
Alternatively, the mailing list exploder MAY issue no MDN and propagate the request for MDNs to all members of the list. The latter behavior is not recommended for any but small, closely knit lists, as it might cause large numbers of MDNs to be generated and may cause confidential subscribers to the list to be revealed. The mailing list exploder MAY also direct MDNs to itself, correlate them, and produce a report to the original sender of the message.
あるいはまた、メーリングリスト発破器は、リストのすべてのメンバーにMDNを全く発行しないで、MDNsを求める要求を伝播するかもしれません。 後者の振舞いはいずれにもかかわらず、小さくて、密接に編み物しているリストのために推薦されません、それで多くのMDNsが発生することを引き起こすかもしれなくて、リストへの秘密の加入者を明らかにするとき。 メーリングリスト発破器は、メッセージの元の送り主にまた、それ自体にMDNsを向けて、彼らを関連させて、報告書を作成するかもしれません。
This specification places no restrictions on the processing of MDNs received by user agents or mailing lists.
この仕様はユーザエージェントかメーリングリストによって受け取られたMDNsの処理に関して制限を全く課しません。
Hansen & Vaudreuil Standards Track [Page 18] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[18ページ]。
6. Security Considerations
6. セキュリティ問題
The following security considerations apply when using MDNs:
MDNsを使用するとき、以下のセキュリティ問題は適用されます:
6.1. Forgery
6.1. 偽造
MDNs 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 MDNs should take appropriate precautions to minimize the potential damage from denial-of-service attacks.
MDNsは普通のインターネット電子メールと同じくらい容易に鍛造されるかもしれません。 施設(メール発送先リスト発破器などの)を扱うMDNsの自動使用をしたがっているユーザエージェントと自動郵便配達人は、サービス不能攻撃から可能性のあるダメージを最小にするために適切な注意を払うべきです。
Security threats related to forged MDNs include the sending of:
偽造MDNsに関連する軍事的脅威は以下の発信を含んでいます。
(a) A falsified disposition notification when the indicated
disposition of the message has not actually occurred,
(a) メッセージの示された気質であるときに、改竄された気質通知は実際に現れていません。
(b) Unsolicited MDNs
(b) 求められていないMDNs
6.2. Privacy
6.2. プライバシー
Another dimension of security is privacy. There may be cases in which a message recipient does not wish the disposition of messages addressed to him to be known, or is concerned that the sending of MDNs may reveal other sensitive information (e.g., when the message was read). In this situation, it is acceptable for the MUA to issue "denied" MDNs or to silently ignore requests for MDNs.
セキュリティの別次元はプライバシーです。 そこでは、メッセージ受取人が彼に記述されたメッセージの気質が知られていることを願っていないか、またはMDNsの発信が他の機密情報を明らかにするかもしれないことを(例えば、メッセージがいつ読まれましたか)心配している場合がそうです。 この状況で、MUAが「否定された」MDNsを発行するか、または静かにMDNsを求める要求を無視するのが許容できます。
If the Disposition-Notification-To header is passed on unmodified when a message is distributed to the subscribers of a mailing list, the subscribers to the list may be revealed to the sender of the original message by the generation of MDNs.
Disposition通知、メッセージがメーリングリストの加入者に分配されるとき、ヘッダーは変更されていなく伝えられて、リストへの加入者はMDNsの世代によってオリジナルのメッセージの送付者に明らかにされるかもしれません。
Headers of the original message returned in part 3 of the multipart/report could reveal confidential information about host names and/or network topology inside a firewall.
一部返されたオリジナルのメッセージのヘッダーはファイアウォールの中にホスト名、そして/または、ネットワーク形態に関する秘密情報を明らかにすることができました3複合/が、報告する。
An unencrypted MDN could reveal confidential information about an encrypted message, especially if all or part of the original message is returned in part 3 of the multipart/report. Encrypted MDNs are not defined in this specification.
unencrypted MDNは暗号化メッセージに関する秘密情報を明らかにすることができて、特にオリジナルのメッセージのすべてか一部を一部返すなら、3複合/が報告します。 コード化されたMDNsはこの仕様に基づき定義されません。
In general, any optional MDN field may be omitted if the Reporting MUA site or user 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 MDNs.
一般に、Reporting MUAサイトかユーザが、分野の包含がサイト秘密性の大き過ぎる妥協を課すと決心しているなら、どんな任意のMDN分野も省略されるかもしれません。 そのような秘密性の必要性はMDNsの省略された情報に関するユーティリティに対してバランスをとらなければなりません。
Hansen & Vaudreuil Standards Track [Page 19] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[19ページ]。
In some cases, someone with access to the message stream may use the MDN request mechanism to monitor the mail reading habits of a target. If the target is known to generate MDN reports, they could add a disposition-notification-to field containing the envelope from address along with a source route. The source route is ignored in the comparison so the addresses will always match. But if the source route is honored when the notification is sent, it could direct the message to some other destination. This risk can be minimized by not sending MDN's automatically.
いくつかの場合、メッセージストリームへのアクセスのだれかが、目標の習慣を読みながらメールをモニターするのにMDN要求メカニズムを使用するかもしれません。 目標がMDNレポートを作るのが知られているなら、aを加えるかもしれない、気質通知、送信元経路に伴うアドレスからの封筒を含む分野。 送信元経路が比較で無視されるので、アドレスはいつも合うでしょう。 しかし、通知を送るとき、送信元経路が光栄に思うなら、それはある他の目的地にメッセージを向けるかもしれません。 自動的にMDNを送らないことによって、この危険を最小にすることができます。
6.3. Non-Repudiation
6.3. 非拒否
MDNs do not provide non-repudiation with proof of delivery. Within the framework of today's Internet Mail, the MDNs defined in this document provide valuable information to the mail user; however, MDNs cannot be relied upon as a guarantee that a message was or was not seen by the recipient. Even if MDNs are not actively forged, they may be lost in transit. The recipient may bypass the MDN issuing mechanism in some manner.
MDNsは非拒否に配達証明を提供しません。 今日のインターネットメールの枠組みの中では、本書では定義されたMDNsはメールユーザに貴重な情報を提供します。 しかしながら、MDNsはメッセージがそうであったという保証として当てにすることができませんでしたし、受取人によって見られもしませんでした。 MDNsが活発に鍛造されないでも、彼らはトランジットで失われるかもしれません。 受取人は何らかの方法でメカニズムを発行するMDNを迂回させるかもしれません。
One possible solution for this purpose can be found in RFC 2634 [SEC-SERVICES].
RFC2634[SEC-SERVICES]でこのために1つの可能な解決策を見つけることができます。
6.4. Mail Bombing
6.4. メール爆撃
The MDN request mechanism introduces an additional way of mailbombing a mailbox. The MDN request notification provides an address to which MDN's should be sent. It is possible for an attacking agent to send a potentially large set of messages to otherwise unsuspecting third party recipients with a false "disposition-notification-to:" address. Automatic, or simplistic processing of such requests would result in a flood of MDN notifications to the target of the attack. Such an attack could overrun the capacity of the targeted mailbox and deny service.
MDN要求メカニズムはメールボックスをmailbombingする追加方法を導入します。 MDNは、通知がMDNのものが送られるべきであるアドレスを提供するよう要求します。 攻撃しているエージェントが偽をもっているそうでなければ、疑わない第三者受取人に潜在的に大きいセットのメッセージを送るのが、可能である、「気質通知、:、」 アドレス。 そのような要求の自動であるか、安易な処理は攻撃の目標へのMDN通知の洪水をもたらすでしょう。 そのような攻撃は、狙っているメールボックスの容量をオーバランさせて、サービスを否定するかもしれません。
For that reason, MDN's SHOULD NOT be sent automatically where the "disposition-notification-to:" address is different from the envelope MAIL FROM address. See section 2.1 for further discussion.
その理由、MDNのSHOULD NOTに関しては、自動的に送ってください、どこ、「気質通知、:、」 アドレスは封筒MAIL FROMアドレスと異なっています。 さらなる議論に関してセクション2.1を見てください。
7. Collected Grammar
7. 集まっている文法
NOTE: The following lexical tokens are defined in [RFC-MSGFMT]: atom, CRLF, mailbox, msg-id, text. The definitions of attribute and value are as in the definition of the Content-Type header in [RFC- MIME-BODY].
以下に注意してください。 以下の字句は[RFC-MSGFMT]で定義されます: 原子、CRLF、メールボックス、msg-イド、テキスト。 属性と価値の定義はそうです。[RFC MIME-BODY]とのコンテントタイプヘッダーの定義のように。
Hansen & Vaudreuil Standards Track [Page 20] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[20ページ]。
Message headers:
メッセージヘッダー:
mdn-request-header =
"Disposition-Notification-To" ":"
mailbox *("," mailbox)
「mdn要求ヘッダー=、「気質通知、」、」、:、」 メールボックス*(「」、メールボックス)
Disposition-Notification-Options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
「気質通知オプションは「気質通知オプション」と等しい」:、」 気質通知パラメタ
disposition-notification-parameters =
parameter *(";" parameter)
気質通知パラメタはパラメタ*と等しいです。(「」、;、パラメタ)
parameter = attribute "=" importance "," value *("," value)
」 「パラメタ=属性「=」重要性」、値の*(「」、値)
importance = "required" / "optional"
重要性=「必要」/「任意です」。
original-recipient-header =
"Original-Recipient" ":" address-type ";" generic-address
「オリジナルの受取人ヘッダーは「オリジナルの受取人」と等しい」:、」 「アドレスタイプ」;、」 一般的なアドレス
Report content:
内容を報告してください:
disposition-notification-content =
[ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
disposition-field CRLF
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
気質通知内容は最終受理者分野CRLF[元のメッセージイド分野CRLF]気質分野CRLF*(失敗分野CRLF)*(誤り分野CRLF)*(警告分野CRLF)*と等しいです[報告しているua分野CRLF][mdnゲートウェイ分野CRLF][元の受取人分野CRLF]。(拡大分野CRLF)
address-type = atom
アドレスタイプは原子と等しいです。
mta-name-type = atom
mta名前タイプは原子と等しいです。
reporting-ua-field = "Reporting-UA" ":" ua-name [ ";" ua-product ]
「報告しているua分野=「報告-UA」」:、」 ua-名前[「」、;、ua-製品]
ua-name = *text
ua-名前=*テキスト
ua-product = *text
ua-製品=*テキスト
mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
「mdnゲートウェイ分野=「MDN-ゲートウェイ」」:、」 「mta名前タイプ」;、」 mta-名前
mta-name = *text
mta-名前=*テキスト
Hansen & Vaudreuil Standards Track [Page 21] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[21ページ]。
original-recipient-field
= "Original-Recipient" ":" address-type ";"
generic-address
「元の受取人分野は「オリジナルの受取人」と等しい」:、」 「アドレスタイプ」;、」 一般的なアドレス
generic-address = *text
一般的なアドレスは*テキストと等しいです。
final-recipient-field =
"Final-Recipient" ":" address-type ";" generic-address
「最終受理者分野=「最終受理者」」:、」 「アドレスタイプ」;、」 一般的なアドレス
disposition-field =
"Disposition" ":" disposition-mode ";"
disposition-type
[ "/" disposition-modifier
*( "," disposition-modifier ) ]
「気質分野=「気質」」:、」 「気質モード」;、」 気質タイプ[「/」気質修飾語*、(「」、気質修飾語]
disposition-mode = action-mode "/" sending-mode
「気質モード=動作モード」/、」 発信モード
action-mode = "manual-action" / "automatic-action"
動作モードは「手動の動き」/「自動動作」と等しいです。
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
発信モードは「手動で送られたMDN」/「自動的に送られたMDN」と等しいです。
disposition-type = "displayed"
/ "deleted"
=が「表示する」か、または「削除した」気質タイプ
disposition-modifier = "error" / disposition-modifier-extension
気質修飾語気質修飾語=「誤り」/拡大
disposition-modifier-extension = atom
気質修飾語拡大は原子と等しいです。
original-message-id-field = "Original-Message-ID" ":" msg-id
「元のメッセージイド分野は「元のMessage ID」と等しい」:、」 msg-イド
failure-field = "Failure" ":" *text
「失敗分野=「失敗」」:、」 *テキスト
error-field = "Error" ":" *text
「誤り分野=「誤り」」:、」 *テキスト
warning-field = "Warning" ":" *text
「警告分野=「警告」」:、」 *テキスト
extension-field = extension-field-name ":" *text
「拡大分野=拡大フィールド名」:、」 *テキスト
extension-field-name = atom
拡大フィールド名=原子
8. Guidelines for Gatewaying MDNs
8. Gatewaying MDNsのためのガイドライン
NOTE: This section provides non-binding recommendations for the construction of mail gateways that wish to provide semi-transparent disposition notifications between the Internet and another electronic mail system. Specific MDN gateway requirements for a particular pair of mail systems may be defined by other documents.
以下に注意してください。 このセクションはメール・ゲートウェイの建設のためのインターネットと別の電子メール・システムの間に半透明の気質通知を提供したがっている拘束力がない推薦を提供します。 メールシステムの特定の組のための特定のMDNゲートウェイ要件は他のドキュメントによって定義されるかもしれません。
Hansen & Vaudreuil Standards Track [Page 22] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[22ページ]。
8.1. Gatewaying from other mail systems to MDNs
8.1. 他のメールシステムからMDNsまでGatewayingします。
A mail gateway may issue an MDN to convey the contents of a "foreign" disposition notification over Internet Mail. When there are appropriate mappings from the foreign notification elements to MDN fields, the information may be transmitted in those MDN fields. Additional information (such as might be needed to tunnel the foreign notification through the Internet) may be defined in extension MDN fields. (Such fields should be given names that identify the foreign mail protocol, e.g., X400-* for X.400 protocol elements).
メール・ゲートウェイは、「外国」の気質通知のコンテンツをインターネットメールの上に伝えるためにMDNを発行するかもしれません。 外国通知要素からMDN分野まで適切なマッピングがあるとき、情報はそれらのMDN分野で伝えられるかもしれません。 追加情報(インターネットを通した外国通知にトンネルを堀るのに必要であるかもしれない)は拡大MDN分野で定義されるかもしれません。 (そのような分野はX.400プロトコル要素のために外国メールプロトコル、例えば、X400-*を特定する名であるべきです。)
The gateway must attempt to supply reasonable values for the Reporting-UA, Final-Recipient, and Disposition fields. These will normally be obtained by translating the values from the foreign notification into their Internet-style equivalents. However, some loss of information is to be expected.
ゲートウェイは、Reporting-UA、Final-受取人、およびDisposition分野に適正価値を提供するのを試みなければなりません。 通常、値を外国通知からそれらのインターネットスタイル同等物に翻訳することによって、これらを得るでしょう。 しかしながら、情報のいくらかの損失が予想されることになっています。
The sender-specified recipient address and the original message-id, if present in the foreign notification, should be preserved in the Original-Recipient and Original-Message-ID fields.
外国通知に存在しているなら、送付者によって指定された受取人アドレスとオリジナルのメッセージイドはOriginal-受取人とOriginal Message ID分野に保存されるべきです。
The gateway should also attempt to preserve the "final" recipient address from the foreign system. Whenever possible, foreign protocol elements should be encoded as meaningful printable ASCII strings.
また、ゲートウェイは、外国システムからの「最終的な」受取人アドレスを保存するのを試みるはずです。 可能で、外国のプロトコル要素が重要な印刷可能なASCIIストリングとしてコード化されるべきであるときはいつも。
For MDNs produced from foreign disposition notifications, the name of the gateway MUST appear in the MDN-Gateway field of the MDN.
外国気質通知から生産されたMDNsに関しては、ゲートウェイの名前はMDNのMDN-ゲートウェイ分野に現れなければなりません。
8.2. Gatewaying from MDNs to other mail systems
8.2. MDNsから他のメールシステムまでGatewayingします。
It may be possible to gateway MDNs from the Internet into a foreign mail system. The primary purpose of such gatewaying is to convey disposition information in a form that is usable by the destination system. A secondary purpose is to allow "tunneling" of MDNs through foreign mail systems in case the MDN may be gatewayed back into the Internet.
それは外国メールシステムへのインターネットからのゲートウェイMDNsに可能であるかもしれません。 そのようなgatewayingの第一の目的は目的地システムで使用可能なフォームで気質情報を伝えることです。 副次目的はMDNがインターネットにgatewayedして戻されるといけないかもしれないのでMDNsが外国メールシステムを通して「トンネルを堀ること」を許容することです。
In general, the recipient of the MDN (i.e., the sender of the original message) will want to know, for each recipient: the closest available approximation to the original recipient address, and the disposition (displayed, printed, etc.).
一般に、MDN(すなわち、オリジナルのメッセージの送付者)の受取人は知りたくなるでしょう、各受取人のために: オリジナルの受取人アドレス、および気質(表示されて、印刷されたなど)への最も厳密な利用可能な近似。
If possible, the gateway should attempt to preserve the Original- Recipient address and Original-Message-ID (if present) in the resulting foreign disposition report.
できれば、ゲートウェイは、結果として起こる外国気質レポートのOriginal受取人アドレスとOriginal Message ID(存在しているなら)を保持するのを試みるはずです。
Hansen & Vaudreuil Standards Track [Page 23] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[23ページ]。
If it is possible to tunnel an MDN through the destination environment, the gateway specification may define a means of preserving the MDN information in the disposition reports used by that environment.
目的地環境を通してMDNにトンネルを堀るのが可能であるなら、ゲートウェイ仕様はレポートがその環境で使用した気質でMDN情報を保存する手段を定義するかもしれません。
8.3. Gatewaying of MDN-requests to other mail systems
8.3. 他のメールシステムにMDN-要求をGatewayingします。
By use of the separate disposition-notification-to request header, this specification offers a richer functionality than most, if not all, other email systems. In most other email systems, the notification recipient is identical to the message sender as indicated in the "from" address. There are two interesting cases when gatewaying into such systems:
要求ヘッダー、この仕様は大部分、またはすべてより豊かな機能性、他のメールシステムを提供します。別々の使用、気質通知、他のほとんどのメールシステムでは、メッセージ送付者にとって、“from"アドレスにみられるように通知受取人は同じです。 そのようなシステムにgatewayingするとき、2つのおもしろいケースがあります:
1) If the address in the disposition-notification-to header is
identical to the address in the SMTP "MAIL FROM", the expected
behavior will result, even if the disposition-notification-to
information is lost. Systems should propagate the MDN request.
1) 中のアドレスである、気質通知、ヘッダーがSMTPのアドレスと同じである、「メール、」、予想された振舞いが結果として生じる、気質通知、情報は無くなっています。 システムはMDN要求を伝播するはずです。
2) If the address in the disposition-notification-to header is
different from the address in the SMTP "MAIL FROM", gatewaying
into a foreign system without a separate notification address will
result in unintended behavior. This is especially important when
the message arrives via a mailing list expansion software that may
specifically replace the SMTP "MAIL FROM" address with an
alternate address. In such cases, the MDN request should not be
gatewayed and should be silently dropped. This is consistent with
other forms of non-support for MDN.
2) 中のアドレスである、気質通知、ヘッダーがSMTPのアドレスと異なっている、「メール、」、別々の通知アドレスなしで外国システムにgatewayingするのは故意でない振舞いをもたらすでしょう。 メッセージが明確にSMTPを取り替えるかもしれないメーリングリスト拡大ソフトウェアで到着するとき、これが特に重要である、「」 代替アドレスがあるアドレスからのメール。 そのような場合、MDN要求をgatewayedするべきでなくて、静かに落とすべきです。 MDNにおいて、これは他の形式の非サポートと一致しています。
9. Example
9. 例
NOTE: This example is provided as illustration only, and is not considered part of the MDN protocol specification. If the example conflicts with the protocol definition above, the example is wrong.
以下に注意してください。 この例は、イラストだけとして前提とされて、MDNプロトコル仕様の一部であると考えられません。 プロトコル定義が上で例が闘争するなら、例は間違っています。
Likewise, the use of *-type subfield names or extension fields in this example is not to be construed as a definition for those type names or extension fields.
同様に、この例の*タイプ部分体名か拡大分野の使用はそれらの型名か拡大分野のための定義に理解されないことです。
This is an MDN issued after a message has been displayed to the user of an Internet Mail user agent.
これはインターネットメールユーザエージェントのユーザにメッセージを表示した後に発行するMDNです。
Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400 From: Joe Recipient <Joe_Recipient@example.com> Message-Id: <199509200019.12345@example.com> Subject: Disposition notification To: Jane Sender <Jane_Sender@example.org> MIME-Version: 1.0
日付: 水曜日、1995年9月20日の00:19:00(東部夏時間の)-0400From: ジョー Recipient <Joe_Recipient@example.com 、gt;、メッセージイド: <199509200019.12345@example.com>Subject: 気質通知To: ジェーン Sender <Jane_Sender@example.org 、gt;、MIMEバージョン: 1.0
Hansen & Vaudreuil Standards Track [Page 24] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[24ページ]。
Content-Type: multipart/report; report-type=disposition-notification;
boundary="RAA14128.773615765/example.com"
コンテントタイプ: 複合/レポート。 レポートタイプは気質通知と等しいです。 境界="RAA14128.773615765/example.com"
--RAA14128.773615765/example.com
--RAA14128.773615765/example.com
The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe Recipient <Joe_Recipient@example.com> with subject "First draft of report" has been displayed. This is no guarantee that the message has been read or understood.
メッセージが9月19日に13:30:00(東部夏時間の)-0400でジョー Recipient <Joe_Recipient@example.com に1995を転送した、gt;、対象で、「レポートの最初の草稿」を表示しました。 これはメッセージが読まれるか、または理解されているという保証ではありません。
--RAA14128.773615765/example.com content-type: message/disposition-notification
--RAA14128.773615765/example.comの満足しているタイプ: 気質メッセージ/通知
Reporting-UA: joes-pc.cs.example.com; Foomail 97.1 Original-Recipient: rfc822;Joe_Recipient@example.com Final-Recipient: rfc822;Joe_Recipient@example.com Original-Message-ID: <199509192301.23456@example.org> Disposition: manual-action/MDN-sent-manually; displayed
報告しているUA: joes-pc.cs.example.com。 Foomail97.1のオリジナルの受取人: rfc822;Joe_Recipient@example.com 最終受理者: rfc822;Joe_Recipient@example.com の元のMessage ID: <199509192301.23456@example.org>気質: MDNは手動で手動の動き/発信していました。 表示します。
--RAA14128.773615765/example.com content-type: message/rfc822
--RAA14128.773615765/example.comの満足しているタイプ: メッセージ/rfc822
[original message optionally goes here]
[オリジナルのメッセージは任意にここに行きます]
--RAA14128.773615765/example.com--
--RAA14128.773615765/example.com--
10. IANA Considerations
10. IANA問題
This document specifies three types of parameters that must be registered with the Internet Assigned Numbers Authority (IANA).
このドキュメントはインターネットAssigned民数記Authorityに示さなければならない3つのタイプのパラメタ(IANA)を指定します。
The forms below are for use when registering a new parameter name for the Disposition-Notification-Options header, a new disposition modifier name, or a new MDN extension field. Each piece of information required 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 that includes the necessary information. IANA MAY reject registrations because of incomplete registration forms or incomplete specifications.
Disposition通知オプションヘッダー、新しい気質修飾語名、または新しいMDN拡大分野に新しいパラメタ名を登録するとき、以下のフォームは使用のためのものです。 登録用紙によって必要とされたそれぞれの情報は、フォーム自体の情報を提供するか、または必要事項を含んでいる発行されて、公的に利用可能な仕様の指示するものを含んでいることによって、満たされるかもしれません。 IANA MAYは不完全な登録用紙か不完全な仕様で登録証明書を拒絶します。
To register, complete the following applicable form and send it via electronic mail to <IANA@IANA.ORG>.
登録して、以下の適切な用紙に記入して、電子メール to <IANA@IANA.ORG を通してそれを送る、gt。
Hansen & Vaudreuil Standards Track [Page 25] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[25ページ]。
10.1. Disposition-Notification-Options header parameter names
10.1. 気質通知オプションヘッダーパラメタ名
A registration for a Disposition-Notification-Options header parameter name MUST include the following information:
Disposition通知オプションヘッダーパラメタ名のための登録は以下の情報を含まなければなりません:
(a) The proposed parameter name.
(a) 提案されたパラメタ名。
(b) The syntax for parameter values, specified using BNF, ABNF,
regular expressions, or other non-ambiguous language.
(b) BNF、ABNF、正規表現、または他の非あいまいな言語を使用することで指定されたパラメタ値のための構文。
(c) If parameter values 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
Disposition-Notification-Options header.
(c) パラメタであるなら、値は米国-ASCIIレパートリー(それらがグラフィック米国-ASCII文字としてDisposition通知オプションヘッダーでどうコード化されることになっているかためには仕様)から完全な図形文字で構成されません。
(d) A reference to a standards track RFC or experimental RFC
approved by the IESG that describes the semantics of the
parameter values.
(d) RFCか実験的なRFCがパラメタ値の意味論について説明するIESGで承認した標準化過程の参照。
10.2. Disposition modifier names
10.2. 気質修飾語名
A registration for a disposition-modifier name (used in the Disposition field of a message/disposition-notification) MUST include the following information:
気質修飾語名(気質メッセージ/通知のDisposition分野では、使用される)のための登録は以下の情報を含まなければなりません:
(a) The proposed disposition-modifier name.
(a) 提案された気質修飾語名。
(b) A reference to a standards track RFC or experimental RFC
approved by the IESG that describes the semantics of the
disposition modifier.
(b) RFCか実験的なRFCが気質修飾語の意味論について説明するIESGで承認した標準化過程の参照。
10.3. MDN extension field names
10.3. MDN拡大フィールド名
A registration for an MDN extension-field name MUST include the following information:
MDN拡大フィールド名のための登録は以下の情報を含まなければなりません:
(a) The proposed extension field name.
(a) 提案された拡大フィールド名。
(b) The syntax for extension values, specified using BNF, ABNF,
regular expressions, or other non-ambiguous language.
(b) BNF、ABNF、正規表現、または他の非あいまいな言語を使用することで指定された拡大値のための構文。
(c) If extension-field values 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
Disposition-Notification-Options header.
(c) 拡大分野であるなら、値は米国-ASCIIレパートリー(それらがグラフィック米国-ASCII文字としてDisposition通知オプションヘッダーでどうコード化されることになっているかためには仕様)から完全な図形文字で構成されません。
Hansen & Vaudreuil Standards Track [Page 26] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[26ページ]。
(d) A reference to a standards track RFC or experimental RFC
approved by the IESG that describes the semantics of the
extension field.
(d) RFCか実験的なRFCが拡大分野の意味論について説明するIESGで承認した標準化過程の参照。
11. Acknowledgments
11. 承認
This document is an updated version of the original document written by Roger Fajman. His contributions to the definition of Message Disposition Notifications are greatly appreciated.
このドキュメントはロジャーFajmanによって書かれた正本のアップデートされたバージョンです。 Message Disposition Notificationsの定義への彼の貢献に大いに感謝します。
RFC 2298 was based on the Delivery Status Notifications document [RFC-DSN-FORMAT] by Keith Moore and Greg Vaudreuil. Contributions were made by members of the IETF Receipt Working Group, including Harald Alvestrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell, Pete Resnick, and Chuck Shih.
RFC2298はキース・ムーアとグレッグ・ボードルイによってDelivery Status Notificationsドキュメント[RFC-DSN-FORMAT]に基礎づけられました。 貢献はIETF Receipt作業部会のメンバーによってされました、ハラルドAlvestrand、イアン・ベル、ウルスEppenberger、クラウス・Andriフェルバー、ネッド・フリード、ジム・ガルビン、カール・ヘイグ、マイク湖、キース・ムーア、ポールOverell、ピートレズニック、およびチャックShihを含んでいて。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[RFC-SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC-SMTP] Klensin、J.、エド、「簡単なメール転送プロトコル」、RFC2821、4月2001日
[RFC-MSGFMT] Resnick, P., Ed., "Internet Message Format", RFC
2822, April 2001.
[RFC-MSGFMT] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日
[RFC-MIME-BODY] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
解放された[RFC MIMEボディー]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC-MIME-MEDIA] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC
2046, November 1996.
解放された[RFC MIMEメディア]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[RFC-MIME-HEADER] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions
for Non-ASCII Text", RFC 2047, November 1996.
[RFC MIMEヘッダー]ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[RFC-REPORT] Vaudreuil, G., "The Multipart/Report Content Type
for the Reporting of Mail System Administrative
Messages", RFC 3462, January 2003.
[RFC-レポート] ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポート満足しているタイプ」、RFC3462、2003年1月。
[RFC-DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status
Notifications", RFC 3461, January 2003.
[RFC-DSN-SMTP]ムーア、K.、「配送状態通知のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。
Hansen & Vaudreuil Standards Track [Page 27] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[27ページ]。
[RFC-DSN-FORMAT] Moore, K., and G. Vaudreuil, "An Extensible Format
for Delivery Status Notifications (DSNs)", RFC
3464, January 2003.
[RFC-DSN-形式] ムーア、K.、およびG.ボードルイ、「配送状態通知(DSNs)のための広げることができる形式」、RFC3464、2003年1月。
[RFC-KEYWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-キーワード]ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
12.2. Informative References
12.2. 有益な参照
[SEC-SERVICES] Hoffman, P., Ed., "Enhanced Security Services for
S/MIME", RFC 2634, June 1999.
[SEC-サービス] ホフマン、P.、エド、「S/MIMEのための警備の強化サービス」、RFC2634、6月1999日
Hansen & Vaudreuil Standards Track [Page 28] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[28ページ]。
Appendix A - Changes from RFC 2298
付録A--RFC2298からの変化
The document has new editors.
ドキュメントには、新しいエディタがあります。
The dispositions "denied", and "failed" were removed from the document reflecting the lack of implementation or usage at this time.
このとき実現か用法の不足を反映するドキュメントから「否定され」て、「失敗された」気質を取り除きました。
The disposition modifiers "warning", "superseded", "expired", "mailbox-terminated" have not seen actual implementation. They have been deleted from this document. The extension modifier, as of yet unused, has been retained for future extension.
「取って代わられ」て、「満期」の、そして、「メールボックスによって終えられた」気質修飾語「警告」は実際の実現を見ていません。 それらはこのドキュメントから削除されました。 拡大修飾語はまだ未使用現在、今後の拡大のために保有されました。
General editorial cleanups include spelling, grammar, and consistency in usage of terms.
一般編集クリーンアップは用語の語法でスペル、文法、および一貫性を入れます。
The document has modified BNF for disposition notification options to eliminate the need for dummy values where not otherwise needed.
気質通知オプションが別の方法で必要でないところでダミーの値の必要性を排除するように、ドキュメントはBNFを変更しました。
Authors' Addresses
作者のアドレス
Tony Hansen AT&T Laboratories Middletown, NJ 07748 USA Voice: +1-732-420-8934 EMail: tony+rfc3798@maillennium.att.com
トニーハンセンAT&T研究所Middletown、ニュージャージー07748米国声: +1-732-420-8934 メールしてください: しゃれた+ rfc3798@maillennium.att.com
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas, TX 75214 USA Voice: +1 214 823 9325 EMail: GregV@ieee.org
7291年のグレゴリーM.ボードルイルーセントテクノロジーズウィリアムソン・テキサス75214第ダラス(米国)声: +1 9325年の214 823メール: GregV@ieee.org
Hansen & Vaudreuil Standards Track [Page 29] RFC 3798 Message Disposition Notification May 2004
ハンセンとボードルイ規格はメッセージ気質通知2004年5月にRFC3798を追跡します[29ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Hansen & Vaudreuil Standards Track [Page 30]
ハンセンとボードルイ標準化過程[30ページ]
一覧
スポンサーリンク
