RFC2298 日本語訳
2298 An Extensible Message Format for Message DispositionNotifications. R. Fajman. March 1998. (Format: TXT=62059 bytes) (Obsoleted by RFC3798) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Fajman Request for Comments: 2298 National Institutes of Health Category: Standards Track March 1998
Fajmanがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2298年の国立衛生研究所カテゴリ: 1998年の標準化過程行進
An Extensible Message Format
for Message Disposition 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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully 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 the privacy concerns that have often been expressed when such functions have been discussed in the past.
このメモはメールユーザエージェント(UA)か電子メールゲートウェイによって使用される、sucessfullyにそれを受取人に届けた後にメッセージの気質を報告するかもしれない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プロトコルは環境を通信させながらマルチプロトコルで役に立つように設計されています。 このために、このメモで説明されたプロトコルは「外国」のアドレスのキャリッジに備えます、通常、インターネットメールに使用されるものに加えて。 また、追加属性は、インターネットメールを通した外国通知が「トンネルを堀ること」を支持するために定義されるかもしれません。
Fajman Standards Track [Page 1] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ............................................ 2 2. Requesting Message Disposition Notifications ............ 3 3. Format of a Message Disposition Notification ............ 7 4. Timeline of events ...................................... 17 5. Conformance and Usage Requirements ...................... 18 6. Security Considerations ................................. 19 7. Collected Grammar ....................................... 20 8. Guidelines for Gatewaying MDNs .......................... 22 9. Example ................................................. 24 10. IANA Registration Forms ................................. 25 11. Acknowledgments ......................................... 26 12. References .............................................. 26 13. Author's Address ........................................ 27 14. Copyright ............................................... 28
1. 序論… 2 2. メッセージ気質通知を要求します… 3 3. メッセージ気質通知の形式… 7 4. 出来事に関するスケジュール… 17 5. 順応と用法要件… 18 6. セキュリティ問題… 19 7. 文法を集めます… 20 8. Gatewaying MDNsのためのガイドライン… 22 9. 例… 24 10. IANA登録は形成されます… 25 11. 承認… 26 12. 参照… 26 13. 作者のアドレス… 27 14. 著作権… 28
1. Introduction
1. 序論
This memo defines a MIME content-type [5] 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 1892 [7].
このメモはメッセージ気質通知(MDNs)のためのMIME満足しているタイプ[5]を定義します。 うまくいっている配送の後に現れるかもしれないいくつかの状態のどれかに関するメッセージについて送付者に通知するのにMDNを使用できます、メッセージ内容の表示、メッセージの印刷、メッセージの削除(表示のない)、またはMDNsを提供することへの受取人の拒否などのように。 ここに定義された「メッセージ/気質通知」満足しているタイプは使用のためにRFC1892[7]で定義された「複合/レポート」満足しているタイプの枠組みの中で意図します。
This memo defines the format of the notifications and the RFC 822 headers used to request them.
このメモは通知の書式を定義します、そして、RFC822ヘッダーは以前はよく彼らを要求していました。
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 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
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
succcessful delivery, in a manner which is largely independent
of human language;
(a) succcessful配送の後にメッセージの気質について人間に知らせてください、人間の言語から主に独立している方法で。
(b) Allow mail user agents to keep track of the disposition of
messages sent, by associating returned MDNs with earlier message
transmissions;
(b) メールユーザエージェントに以前のメッセージ送信に返されたMDNsを関連づけることによって送られたメッセージの気質に動向をおさえさせてください。
Fajman Standards Track [Page 2] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[2ページ]。
(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, as well as being machine-
parsable.
(a) それはマシン「パー-可能」であることと同様に人間で読み込み可能であるに違いありません。
(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 is 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 accomodate
future requirements.
(d) 仕様は、将来の要件をaccomodateするように広げることができなければなりません。
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 UA in generating the MDN may be provided by including Original-Recipient and/or Disposition- Notification-Options headers in the message.
メッセージ気質通知がaを含んでいることによって要求されている、Disposition通知、メッセージのヘッダー。 メッセージにOriginal-受取人、そして/または、Disposition通知オプションヘッダーを含んでいることによって、MDNを発生させる際に受取人のUAによって使用されるべき詳細を提供するかもしれません。
2.1 The Disposition-Notification-To Header
2.1、気質通知、ヘッダー
A request that the receiving user agent issue message disposition notifications is made by placing a Disposition-Notification-To header into the message. The syntax of the header, using the ABNF of RFC 822 [2], is
aを置くことによって受信ユーザエージェントがメッセージ気質通知を発行するという要求をする、Disposition通知、メッセージへのヘッダー。 RFC822[2]のABNFを使用するヘッダーの構文があります。
Fajman Standards Track [Page 3] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[3ページ]。
mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox
「mdn要求ヘッダー=、「気質通知、」、」、:、」 1#メールボックス
The mailbox token is as specified in RFC 822 [2].
メールボックス象徴がRFC822[2]で指定されるようにあります。
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で「否定された」気質を使用させるかもしれません。
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に対応して、発生してください。
At most one MDN may be issued on behalf of each particular recipient by their user agent. 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 been issued for the recipient doing the forwarding and the recipient of the forwarded message may also cause an MDN to be generated.
最も1つでは、MDNはそれぞれの特定の受取人を代表して彼らのユーザエージェントによって発行されるかもしれません。 すなわち、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 never to 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 822 [2]). 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.
ヘッダーはReturn-経路ヘッダーでアドレスと異なっています。MDNs SHOULD、中のアドレスであるなら自動的に送られないでください、Disposition通知、(RFC822[2])を見てください。 この場合確認、できれば、ユーザ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つを選ぶか、または比較の失敗として状況を扱うかもしれません。
Fajman Standards Track [Page 4] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[4ページ]。
The reason for not automatically sending an MDN if the comparison fails or more than one address is specified is to reduce the possibilities for mail loops and use of MDNs 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 822 [2]. This will permit automatic correlation of MDNs with original messages by user agents.
aを含むメッセージ、Disposition通知、また、ヘッダーSHOULDはRFC822[2]の指定されるとしてのMessage-IDヘッダーを含んでいます。 これはユーザエージェントによるオリジナルのメッセージでMDNsの自動修正を可能にするでしょう。
If it is desired to request message disposition notifications for some recipients and not others, two copies of the message should be sent, one with an 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部を送るべきです、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 UA 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, using the ABNF of RFC 822 [2], is
この仕様への将来の拡張子は、情報がどのように、MDNsが何であるかの上で発生する追加コントロールのために受取人のUAに提供されるのを必要とするかもしれません。 Disposition通知オプションヘッダーは広げることができるメカニズムをそのような情報に提供します。 RFC822[2]のABNFを使用するこのヘッダーの構文があります。
Disposition-Notification-Options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
「気質通知オプションは「気質通知オプション」と等しい」:、」 気質通知パラメタ
disposition-notification-parameters = parameter *(";" parameter)
気質通知パラメタはパラメタ*と等しいです。(「」、;、パラメタ)
parameter = attribute "=" importance "," 1#value
」 「パラメタ=属性「=」重要性」、1つの#値
importance = "required" / "optional"
重要性=「必要」/「任意です」。
The definitions of attribute and value are as in the definition of the Content-Type header in RFC 2045 [4].
属性と価値の定義はそうです。RFC2045[4]とのコンテントタイプヘッダーの定義のように。
Fajman Standards Track [Page 5] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[5ページ]。
An importance of "required" indicates that interpretation of the parameter is necessary for proper generation of an MDN in response to this request. If a UA 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 a UA that does not understand the meaning of this parameter MAY generate an MDN in response anyway, ignoring the value of the parameter.
「必要」の重要性は、パラメタの解釈がこの要求に対応してMDNの適切な世代に必要であることを示します。 UAがパラメタの意味を理解していないなら、それは要求に対応して「失敗される」以外のどんな気質タイプでもMDNを発生させてはいけません。 「任意」の重要性は、このパラメタの意味を理解していないUAが応答で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 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.
パラメタは全くこの仕様に基づき定義されません。 パラメタは将来、この仕様への後の改正か拡大で定義されるかもしれません。 「X」と共に始まるパラメタ属性名は標準の名前と決して定義されないでしょう。 そのような名前は実験用のために予約されます。 数の権威(IANA)が割り当てられて、標準化過程RFCで説明されるインターネットかIESGによって承認される実験的なRFCに「X」と共に始まらないMDNパラメタ名を登録しなければなりません。 登録用紙に関してセクション10を見てください。
If a required parameter is not understood or contains some sort of error, the receiving UA 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 a 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.
必要なパラメタが理解されていないか、またはある種の誤りを含んでいるなら、受信UA 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 preferance 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を送ってはいけないpreferanceを示したなら、「失敗されること」の気質タイプがある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 1891 [8]. If this 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, using the ABNF of RFC 822 [2], is as follows
メッセージがトランジット中である間、電子メールアドレスが書き直されるかもしれないので、オリジナルの受取人アドレスが配送しているMTAによって利用可能にされるのは、役に立ちます。 配送しているMTAはSMTP RCPT TOコマンドのORCPTパラメタからこの情報を得ることができるかもしれません、RFC1891[8]で定義されるように。 この情報が利用可能であるなら、配送しているMTA SHOULDはメールの文頭(Return-経路ヘッダーに伴う)にOriginal-受取人ヘッダーを挿入します。 配送しているMTA MAYはメッセージに起こるいかなる他のOriginal-受取人ヘッダーも削除します。 RFC822[2]のABNFを使用して、このヘッダーの構文は以下の通りです。
original-recipient-header =
"Original-Recipient" ":" address-type ";" generic-address
「オリジナルの受取人ヘッダーは「オリジナルの受取人」と等しい」:、」 「アドレスタイプ」;、」 一般的なアドレス
Fajman Standards Track [Page 6] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[6ページ]。
The address-type and generic-address token are as as specified in the description of the Original-Recipient field in section 3.2.3.
アドレスタイプと一般的なアドレス象徴はそうです。指定されるように、Original-受取人の記述では、セクション3.2で.3をさばいてください。
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の自動修正を可能にすることです。
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 2046 [5]) requires further definition.
ヘッダーの使用、Disposition通知、Disposition通知オプション、およびMIME Message/部分的な満足しているタイプをもっているOriginal-受取人、(RFC2046[5])はさらなる定義を必要とします。
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 2046 [5]). These headers SHOULD NOT be used in the headers of any of the fragments themselves.
メッセージがいつ2に区分されるか、そして、より多くのメッセージ/部分的な断片、3個のヘッダーがSHOULDが「内側」の、または、「同封」のメッセージに置かれると前の段落で言及しました。(RFC2046[5])の用語を使用します。 これらのヘッダー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 to be generated for the fragment. If these headers occur in the headers of the "inner" or "enclosed" message (using the terms of RFC 2046 [5]), they pertain to an MDN to be generated for the reassembled message. Section 5.2.2.1 of RFC 2046 [5]) 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 occurances of the three headers defined here in the headers of the initial enclosing message must not be copied to the reassembled message.
複数のメッセージ/部分的な断片が組み立て直されるとき、以下は適用されます。 これらのヘッダーがメッセージ/部分的な断片メッセージの他のヘッダーと共に起こるなら、彼らは、断片のために発生するようにMDNに関係します。 これらのヘッダーであるなら「内側」の、または、「同封」のメッセージのヘッダーに起こってください。(RFC2046[5])の用語を使用して、それらは組み立て直されたメッセージのために発生するべきMDNに関係します。 セクション5.2 .2 .1RFC2046[5])がこの仕様で説明された3個のヘッダーがそこで指定されたヘッダーに加えて追加されることになっていると指定するために修正されます、オーダーで、組み立て直されたメッセージのヘッダーに。 ここ、初期の同封メッセージのヘッダーで定義された3個のヘッダーの少しのoccurancesも組み立て直されたメッセージにコピーしてはいけません。
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 1892 [7]). When a multipart/report content is used to transmit an MDN:
メッセージ気質通知は最高平らな満足しているタイプの複合/レポートがあるMIMEメッセージです。(RFC1892[7])では、定義されます。 複合/レポート内容が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 1892 [7].
(b) 複合/レポートの最初の成分はMDNの人間の読み込み可能な説明を含んでいます、RFC1892[7]で説明されるように。
(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で説明された満足しているタイプ気質メッセージ/通知のものです。
Fajman Standards Track [Page 7] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[7ページ]。
(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 UA generating the
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.
(d) オリジナルのメッセージかメッセージの部分が送付者に返すことであるなら、それは複合/レポートの3番目の成分として現れます。 メッセージを返すかどうかに関する決定かメッセージの一部がMDNを発生させるUA次第です。 しかしながら、MDNsを要求する暗号化メッセージの場合では、暗号化メッセージテキストを返さなければなりません、それを少しでも返すなら、元のコード化されたフォームだけで。
NOTE: For message dispostion 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 822 headers which
contain equivalent information. In particular, it is very
desirable to preserve the subject and date fields from the
original message.
以下に注意してください。 外国システムからgatewayedされたメッセージdispostion通知には、オリジナルのメッセージのヘッダーは手があいていないかもしれません。 この場合、MDNの3番目の部品が省略されるかもしれませんか、またはそれは同等な情報を含む「シミュレートされた」RFC822ヘッダーを含むかもしれません。 特に、オリジナルのメッセージから対象と日付の分野を保持するのは非常に望ましいです。
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の種類名: メッセージ
Fajman Standards Track [Page 8] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[8ページ]。
MIME subtype name: disposition-notification
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 6 of this memo.
MIME「副-タイプ」は以下を命名します。 気質通知Optionalパラメタ: なにも、Encoding問題: 「7ビット」のコード化を十分であり、非MIMEメール読者によって見られると、読み易さを維持するのに使用しなければなりません。 セキュリティ問題: このメモのセクション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 822 header "fields" (see [2]). Using the ABNF of RFC 822, the syntax of the message/disposition-notification content is as follows:
気質メッセージ/通知のボディーはRFC822ヘッダー「分野」のABNFによると、フォーマットされた1「分野」から成ります。([2])を見てください。 RFC822のABNFを使用して、気質メッセージ/通知内容の構文は以下の通りです:
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 822 [2], the same conventions for continuation lines and comments apply. Notification fields may be continued onto multiple lines by beginning each additional line with a SPACE or HTAB. Text which appears in parentheses is considered a comment and not part of the contents of that notification field. Field names are case-insensitive, so the names of notification fields may be spelled in any combination of upper and lower case letters. Comments in notification fields may use the "encoded-word" construct defined in RFC 2047 [6].
RFC822[2]の規則に従ってこれらの分野が定義されるので、継続行とコメントのための同じコンベンションは適用されます。 通知分野は、SPACEかHTABと共にそれぞれの追加線を始めることによって、複数の線に続けられるかもしれません。 括弧に現れるテキストは部分ではなく、その通知分野のコンテンツのコメントであると考えられます。 フィールド名が大文字と小文字を区別しないので、通知分野の名前は大文字と小文字手紙のどんな組み合わせでもつづられるかもしれません。 通知分野でのコメントはRFC2047[6]で定義された「コード化された単語」構造物を使用するかもしれません。
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-名前の予想された書式を示します。
The "-type" subfields are defined as follows:
「タイプ」部分体は以下の通り定義されます:
Fajman Standards Track [Page 9] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[9ページ]。
(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) will maintain a registry of address-type and mta-name-type values, along with descriptions of the meanings of each, or a reference to a one or more specifications that provide such descriptions. (The "rfc822" address-type is defined in RFC 1891 [8].) Registration forms for address-type and mta-name-type appear in RFC 1894 [9].
インターネットAssigned民数記Authority(IANA)はアドレスタイプとmta名前タイプ値の登録を維持するでしょう、それぞれの意味の記述、またはそのような記述を提供する1つ以上の仕様の参照と共に。 ("rfc822"アドレスタイプはRFC1891[8]で定義されます。) アドレスタイプとmta名前タイプのための登録用紙はRFC1894[9]に現れます。
IANA will not accept registrations for any address-type name that begins with "X-". These type names are reserved for experimental use.
IANAは「X」と共に始まるどんなアドレス型名のための登録証明書も受け入れないでしょう。 これらの型名は実験用のために予約されます。
3.1.3 Lexical tokens imported from RFC 822
3.1.3 RFC822から輸入された字句
The following lexical tokens, defined in RFC 822 [2], are used in the ABNF grammar for MDNs: atom, CRLF, mailbox, msg-id, text.
RFC822[2]で定義された以下の字句はMDNsにABNF文法に使用されます: 原子、CRLF、メールボックス、msg-イド、テキスト。
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分野は以下の通り定義されます:
A MDN describes the disposition of a message after it has been delivered to a recipient. In all cases, the Reporting-UA is the UA that performed the disposition described in the MDN. This field is
それを受取人に届けた後にMDNはメッセージの気質について説明します。 すべての場合では、Reporting-UAはMDNで説明された気質を実行したUAです。 この分野はそうです。
Fajman Standards Track [Page 10] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[10ページ]。
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 UA that generated the MDN and the name of the product. For example,
任意ですが、お勧めです。 インターネットメールユーザエージェントにとって、この分野がMDNを発生させたUAの特定の例のDNS名と製品の名前の両方を含むのは、お勧めです。 例えば
Reporting-UA: rogers-mac.dcrt.nih.gov; Foomail 97.1
報告しているUA: rogers-mac.dcrt.nih.gov。 Foomail97.1
If the reporting UA 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.
報告しているUAが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 which 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-受取人分野はMDNが発行されているメッセージ送信者による指定されるとしてのオリジナルの受取人アドレスを示します。 メールが値を通信させるインターネット
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 UA may choose the one to use or act as if no Original-Recipient header is present.
Original-受取人ヘッダーからMDNが発生しているメッセージからオリジナルの受取人野原を得ます。 メッセージにOriginal-受取人ヘッダーが全くなければ、Original-受取人分野を省略しなければなりません、同じ情報がある他の方法で確かに利用可能でない場合。 オリジナルのメッセージにOriginal受取人ヘッダーがあれば(オリジナルの受取人情報はある他の方法で確かに利用可能です)、Original-受取人野原を供給しなければなりません。 メッセージに1個以上のOriginal-受取人ヘッダーがあれば、まるでどんなOriginal-受取人ヘッダーも出席していないかのようにUAは使用するか、または活動させるものを選ぶかもしれません。
original-recipient-field =
"Original-Recipient" ":" address-type ";" generic-address
「元の受取人分野は「オリジナルの受取人」と等しい」:、」 「アドレスタイプ」;、」 一般的なアドレス
generic-address = *text
一般的なアドレスは*テキストと等しいです。
Fajman Standards Track [Page 11] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[11ページ]。
The address-type field indicates the type of the original recipient address. If the message originated within the Internet, the address-type field field will normally be "rfc822", and the address will be according to the syntax specified in RFC 822 [2]. The value "unknown" should be used if the Reporting UA cannot determine the type of the original recipient address from the message envelope. 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.
アドレスタイプ分野はオリジナルの受取人アドレスのタイプを示します。 メッセージがインターネットの中で由来したなら、通常、アドレスタイプ分野分野は"rfc822"でしょう、そして、RFC822[2]で指定された構文によると、アドレスがあるでしょう。 Reporting UAがメッセージ封筒からのオリジナルの受取人アドレスのタイプを決定できないなら、値の「未知」は使用されるべきです。 このアドレスは、受取人基礎あたりの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 UA.
MDNがUAによって発生した時であるときに、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 an totally unrecognizable mess. However, in the absence of the optional Original-Recipient field, the Final-Recipient field and any returned content may be the only information available with which to correlate the 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
Original Message ID分野はMDNが発行されているメッセージのメッセージIDを示します。 MDNが発行されるメッセージのMessage IDヘッダーからそれを得ます。 オリジナルのメッセージがMessage-IDヘッダーを含んだなら、この分野は存在していなければなりません。 分野の構文はそうです。
Fajman Standards Track [Page 12] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[12ページ]。
original-message-id-field = "Original-Message-ID" ":" msg-id
「元のメッセージイド分野は「元のMessage ID」と等しい」:、」 msg-イド
The msg-id token is as specified in RFC 822 [2].
msg-イド象徴がRFC822[2]で指定されるようにあります。
3.2.6 Disposition field
3.2.6 気質分野
The Disposition field indicates the action performed by the Reporting-UA on behalf of the user. This field MUST be present.
Disposition分野は、動作がReporting-UAでユーザを代表して働いたのを示します。 この分野は存在していなければなりません。
The syntax for the Disposition field is:
Disposition分野への構文は以下の通りです。
disposition-field = "Disposition" ":" disposition-mode ";"
disposition-type
[ '/' disposition-modifier
*( "," dispostion-modifier ) ]
「気質分野=「気質」」:、」 「気質モード」;、」 気質タイプ['/'気質修飾語*、(「」、dispostion-修飾語]
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"
/ "dispatched"
/ "processed"
/ "deleted"
/ "denied"
/ "failed"
「表示される」か、「派遣される」、「処理される」、「削除される」、「否定される」、または「失敗された」気質タイプ=
disposition-modifier = ( "error" / "warning" )
/ ( "superseded" / "expired" /
"mailbox-terminated" )
/ 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.
気質が気質タイプで説明した「手動の動き」はある種の自動的に実行された動作よりむしろユーザによる明白な指示の結果でした。
Fajman Standards Track [Page 13] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[13ページ]。
"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かもう片方を指定しなければなりません。
"MDN-sent-manually" The user explicity gave permission for
this particular MDN to be sent.
ユーザの「手動で送られたMDN」explicityはこの特定のMDNが送られる許可を与えました。
"MDN-sent-automatically" The MDN was sent because the UA had
previously been configured to do so
automatically.
「MDNは自動的に発信しました」。UAが以前にそう自動的にするために構成されたので、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 UA to someone
reading the recipient's mailbox. There is
no guarantee that the content has been
read or understood.
「表示され」て、メッセージは、受信者のメールボックスを読みながら、だれかへのUAによって表示されました。 内容が読まれるか、または理解されているという保証が全くありません。
"dispatched" The message has been sent somewhere in some manner
(e.g., printed, faxed, forwarded) without
necessarily having been previously
displayed to the user. The user may or
may not see the message later.
以前に必ずユーザに表示するというわけではなくて、「派遣され」て、何らかの方法(例えば、ファックスされて、進めた状態で、印刷される)によるどこかにメッセージを送りました。 ユーザは後でメッセージを見るかもしれません。
"processed" The message has been processed in some manner (i.e.,
by some sort of rules or server) without
being displayed to the user. The user may
or may not see the message later, or there
may not even be a human user associated
with the mailbox.
ユーザに表示しないで、「処理され」て、何らかの方法(すなわち、ある種の規則かサーバによる)でメッセージを処理してあります。 ユーザが後でメッセージを見るかもしれませんか、またはメールボックスに関連している人間のユーザさえいないかもしれません。
"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.
「削除され」て、メッセージは削除されました。 受取人はメッセージを見たかもしれません。 受取人は、メッセージが後で"非削除"であり、メッセージを読むかもしれません。
Fajman Standards Track [Page 14] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[14ページ]。
"denied" The recipient does not wish the sender to be informed
of the message's disposition. A UA may
also siliently ignore message disposition
requests in this situation.
受取人が、送付者にメッセージの気質において知識があって欲しくないことを「否定しました」。 また、UAはsilientlyにこの状況におけるメッセージ気質要求を無視するかもしれません。
"failed" A failure occurred that prevented the proper
generation of an MDN. More information
about the cause of the failure may be
contained in a Failure field. The
"failed" disposition type is not to be
used for the situation in which there is
is some problem in processing the message
other than interpreting the request for an
MDN. The "processed" or other disposition
type with appropriate disposition
modifiers is to be used in such
situations.
MDNの適切な世代を防いだ「失敗した」A失敗が起こりました。 失敗の原因に関する詳しい情報はFailure分野に保管されるかもしれません。 「失敗した」気質タイプはMDNを求める要求を解釈する以外に、ある状況に使用されているのが、メッセージを処理することにおいて何らかの問題であるということであることになっていません。 適切な気質修飾語がある「処理された」か他の気質タイプはそのような状況で使用されることになっています。
3.2.6.3 Disposition modifiers
3.2.6.3 気質修飾語
The following disposition modifiers are defined:
以下の気質修飾語は定義されます:
"error" An error of some sort occurred
that prevented successful
processing of the message.
Further information is contained
in an Error field.
メッセージのうまくいっている処理を防いだある種の「誤り」An誤りが発生しました。 詳細はError分野に保管されています。
"warning" The message was successfully
processed but some sort of
exceptional condition occurred.
Further information is contained
in a Warning field.
メッセージが首尾よく処理されましたが、ある種の例外的な状態が現れたと「警告します」。 詳細はWarning分野に保管されています。
"superseded" The message has been
automatically rendered obsolete by
another message received. The
recipient may still access and
read the message later.
「取って代わられ」て、メッセージは受け取られた別のメッセージによって自動的に時代遅れに伝えられました。 受取人は、後でまだメッセージにアクセスして、読んでいるかもしれません。
"expired" The message has reached its
expiration date and has been
automatically removed from the
recipient's mailbox.
「吐き出され」て、メッセージを、有効期限に達して、受信者のメールボックスから自動的に取り除いてあります。
"mailbox-terminated" The recipient's mailbox has been
terminated and all message in it
automatically removed.
受信者のメールボックスが終えられて、それで自動的にすべて通信するのをさせる「メールボックスで終えられること」は取り外されました。
Fajman Standards Track [Page 15] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[15ページ]。
"Obsoleted", "expired", and
"terminated" are to be used with
the "deleted" disposition type and
the "autoaction" and "autosent"
disposition modifiers.
「満期」の、そして、「終えられた」「時代遅れにされたこと」は「削除された」気質タイプと"autoaction"と"autosent"気質修飾語と共に使用されることになっています。
disposition-modifier-extension Additional 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 UA
MAY be silently ignored or placed
in the user's mailbox without
special inter- pretation. They
MUST not cause any error message
to be sent to the sender of the
MDN.
気質修飾語拡大Additional気質修飾語は将来、この仕様への後の改正か拡大で定義されるかもしれません。 「X」と共に始まる気質値の名は基準値と決して定義されないでしょう。 そのような名前は実験用のために予約されます。 数の権威(IANA)が割り当てられて、規格道のRFCで説明されるインターネットかIESGによって承認される実験的なRFCに「X」と共に始まらないMDN気質値の名を登録しなければなりません。 登録用紙に関してセクション10を見てください。 気質修飾語名があるMDNsは受信UA MAYで静かに無視されるように理解もしていませんでしたし、特別な相互pretationなしでユーザのメールボックスで入賞もしませんでした。 彼らはどんなエラーメッセージもMDNの送付者に送らせてはいけません。
If an UA 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 UA
implementation should follow the
"X-", (e.g. "X-Foomail-fratzed").
UA開発者がそのような気質修飾語拡大の意味を登録したくないなら、「X」修飾語はこのために使用されるかもしれません。 名前衝突を避けるために、UA実現の名前は「X」、(例えば、"X-Foomail-fratzed")に続くべきです。
It is not required that a UA be able to generate all of the possible values of the Disposition field.
UAがDisposition分野の可能な値のすべてを発生させることができるのが必要ではありません。
One and only one MDN may be issued on behalf of each particular recipient by their user agent. 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
唯一無二の1MDNがそれぞれの特定の受取人を代表して彼らのユーザエージェントによって発行されるかもしれません。 すなわち、MDNが受取人を代表していったん発行されると、一層のMDNsは全くその受取人を代表して発行されないかもしれません、別の気質がメッセージに実行されても。 しかしながら、メッセージを転送するなら、「派遣された」MDNは転送します。
Fajman Standards Track [Page 16] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[16ページ]。
been issued for the recipient doing the forwarding and the recipient of the forwarded message may also cause an MDN to be generated.
また転送されたメッセージの推進と受取人をするのが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 modifer appear. The syntax is
Failure、Error、およびWarning分野は、「失敗」気質タイプ、「誤り」気質修飾語、そして/または、「警告」気質modiferが現れるとき、テキスト・メッセージの形で追加情報を提供するのに使用されます。 構文はそうです。
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を見てください。
Extension MDN fields may be defined for the following reasons:
拡大MDN分野は以下の理由で定義されるかもしれません:
(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 which is
specific to a particular user agent (UA). The names of such MDN
fields should begin with an indication of the UA implementation
which produced the MDN. (e.g. Foomail-information).
特定のユーザエージェント(UA)に、特定の診断情報の伝達を許す(b)。 そのようなMDN分野の名前はMDNを生産したUA実現のしるしで始まるべきです。 (例えば、Foomail-情報。)
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-EDI-info").
アプリケーション開発者がそのような拡大分野の意味を登録したくないなら、「X」分野はこのために使用されるかもしれません。 名前衝突を避けるために、アプリケーション実現の名前は「X」か、(例えば、「X-Foomail Log ID」か「Xエディインフォメーション」)に続くべきです。
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のメッセージと世代の処理における様々な出来事がいつ起こるかを示します:
Fajman Standards Track [Page 17] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[17ページ]。
-- User composes message
-- ユーザはメッセージを構成します。
-- User tells UA to send message
-- ユーザは、メッセージを送るようにUAに言います。
-- UA passes message to MTA (original recipient information
passed along)
-- UAはメッセージをMTAに通過します。(伝えられたオリジナルの受取人情報)
-- MTA sends message to next MTA
-- MTAは次のMTAにメッセージを送ります。
-- Final MTA receives message
-- 最終的なMTAはメッセージを受け取ります。
-- Final MTA delivers message to UA (possibily generating DSN)
-- 最終的なMTAはメッセージをUAに渡します。(possibilyにDSNを発生させます)
-- UA performs automatic processing and generates corresponding
MDNs ("dispatched", "processed", "deleted", "denied" or "failed"
disposition type with "automatic-action" and "MDN-sent-
automatically" disposition modes)
-- UAは自動処理を実行して、対応するMDNsを発生させます。(「急い」で、「自動動作」で「否定された」か「失敗した」気質タイプを「削除され」て、「処理し」て、気質モードを「-自動的にMDN送ります」)
-- UA displays list of messages to user
-- 表示が記載するユーザへのメッセージのUA
-- User selects a message and requests that some action be
performed on it.
-- ユーザはメッセージと何らかの動作がそれに実行されるという要求を選択します。
-- UA performs requested action and, with user's permission,
sends appropriate MDN ("displayed", "dispatched", "processed",
"deleted", "denied" or "failed" disposition type with "manual-
action" and "MDN-sent-manually" or "MDN-sent-automatically"
disposition mode).
-- UAは要求された動作を実行して、ユーザの許可と共に適切なMDN(「マニュアル動作」と「手動で送られたMDN」か「自動的に送られたMDN」気質モードがある「表示された」か、「派遣された」か、「処理された」か、「削除された」か、「否定された」か「失敗した」気質タイプ)を送ります。
-- User possibly performs other actions on message, but no
further MDNs are generated.
-- ユーザはことによるとメッセージへの他の動作を実行しますが、一層のMDNsは全く発生しません。
5. Conformance and Usage Requirements
5. 順応と用法要件
A UA 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を発生させるなら、UAかゲートウェイがこの仕様に一致しています。 Disposition分野の可能な値のすべてを発生させることができるのは必要ではありません。
UAs 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 1891 [8] 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 UA.
メールプロトコルが服従時点で元々送付者によって指定されたアドレスを提供しないなら、UAsとゲートウェイはMDNのOriginal-受取人分野を発生させてはいけません。 普通のSMTPはその保証をしませんが、それが利用可能であるなら、RFC1891[8]で定義されたSMTP拡張子は、そのような情報が封筒で運ばれることを許可します。 本書では定義されたOriginal-受取人ヘッダーはMTAがオリジナルの受取人アドレスをUAに通過する方法を提供します。
Fajman Standards Track [Page 18] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[18ページ]。
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 1891 [8], section 6.2.7.3), each of the recipients may issue an MDN.
それぞれの送付者によって指定された受取人アドレスは1MDNをもたらすかもしれません。 MDNが「別名」の複数の受取人に送られる受取人のために要求されるなら(RFC1891[8]、セクション6.2.7で.3を定義するので)、受取人各人はMDNを発行するかもしれません。
Successful distribution of a message to a mailing list exploder SHOULD be considered 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 propogated to the members of the list.
aのうまくいっている分配は考えられた決勝がメッセージの気質であったならaメーリングリスト発破器SHOULDへ通信します。 メッセージがリストに転送されたのを示しながら、メーリングリスト発破器は「自動動作」と「MDNは自動的に発信した」「処理」と気質モードの気質タイプでMDNを発行するかもしれません。 この場合、MDNsを求める要求はリストのメンバーに伝播されません。
Alternaively, the mailing list exploder may issue no MDN and propogate 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. It is also permissible for the mailing list exploder to direct MDNs to itself, correlate them, and produce a report to the original sender of the message.
Alternaivelyに、メーリングリスト発破器は、リストのすべてのメンバーにMDNを全く発行しないで、MDNsを求める要求を伝播するかもしれません。 後者の振舞いはいずれにもかかわらず、小さくて、密接に編み物しているリストのために推薦されません、それで多くのMDNsが発生することを引き起こすかもしれなくて、リストへの秘密の加入者を明らかにするとき。 また、メーリングリスト発破器がそれ自体にMDNsを向けて、彼らを関連させて、メッセージの元の送り主に報告書を作成するのも、許されています。
This specification places no restrictions on the processing of MDNs received by user agents or mailing lists.
この仕様はユーザエージェントかメーリングリストによって受け取られたMDNsの処理に関して制限を全く課しません。
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 ocurred,
(a) メッセージの示された気質であるときに、改竄された気質通知は実際にocurredされていません。
(b) Unsolicited MDNs
(b) 求められていないMDNs
6.2 Confidentiality
6.2 秘密性
Another dimension of security is confidentiality. There may be cases in which a message recipient does not wish the disposition of
セキュリティの別次元は秘密性です。 ケースがメッセージ受取人がどれについて気質を願っていないかであるかもしれません。
Fajman Standards Track [Page 19] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[19ページ]。
messages addressed to him to be known or is concerned that the sending of MDNs may reveal other confidential information (e.g., when the message was read). In this situation, it is acceptable for the UA to issue "denied" MDNs or to silently ignore requests for MDNs.
MDNsの発信が他の秘密情報を明らかにするかもしれないという(例えば、メッセージはいつ読まれましたか)知られて、関係があるように彼に記述されたメッセージ。 この状況で、UAが「否定された」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 UA 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 UAサイトかユーザが、分野の包含がサイト秘密性の大き過ぎる妥協を課すと決心しているなら、どんな任意のMDN分野も省略されるかもしれません。 そのような秘密性の必要性はMDNsの省略された情報に関するユーティリティに対してバランスをとらなければなりません。
6.3 Non-Repudiation
6.3 非拒否
Within the framework of today's Internet Mail, the MDNs defined in this document provide valuable information to the mail user; however, MDNs can not be relied upon as a guarantee that a message was or was not not seen by the recipient. Even if MDNs are not actively forged, they may be lost in transit. The MDN issuing mechanism may be bypassed in some manner by the recipient.
今日のインターネットメールの枠組みの中では、本書では定義されたMDNsはメールユーザに貴重な情報を提供します。 しかしながら、MDNsはメッセージがそうであったという保証として当てにすることができませんでしたし、受取人によって見られもしました。 MDNsが活発に鍛造されないでも、彼らはトランジットで失われるかもしれません。 受取人は何らかの方法でメカニズムを発行するMDNを迂回させるかもしれません。
7. Collected Grammar
7. 集まっている文法
NOTE: The following lexical tokens are defined in RFC 822: atom, CRLF, mailbox, msg-id, text. The definitions of attribute and value are as in the definition of the Content-Type header in RFC 2045 [4].
以下に注意してください。 以下の字句はRFC822で定義されます: 原子、CRLF、メールボックス、msg-イド、テキスト。 属性と価値の定義はそうです。RFC2045[4]とのコンテントタイプヘッダーの定義のように。
Message headers:
メッセージヘッダー:
mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox
「mdn要求ヘッダー=、「気質通知、」、」、:、」 1#メールボックス
Disposition-Notification-Options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
「気質通知オプションは「気質通知オプション」と等しい」:、」 気質通知パラメタ
Fajman Standards Track [Page 20] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[20ページ]。
disposition-notification-parameters = parameter *(";" parameter)
気質通知パラメタはパラメタ*と等しいです。(「」、;、パラメタ)
parameter = attribute "=" importance "," 1#value
」 「パラメタ=属性「=」重要性」、1つの#値
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-名前=*テキスト
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
「気質分野=「気質」」:、」 「気質モード」;、」 気質タイプ
Fajman Standards Track [Page 21] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[21ページ]。
[ '/' disposition-modifier
*( "," dispostion-modifier ) ]
['/'気質修飾語*、(「」、dispostion-修飾語]
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"
/ "dispatched"
/ "processed"
/ "deleted"
/ "denied"
/ "failed"
「表示される」か、「派遣される」、「処理される」、「削除される」、「否定される」、または「失敗された」気質タイプ=
disposition-modifier = ( "error" / "warning" )
/ ( "superseded" / "expired" /
"mailbox-terminated" )
/ 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ゲートウェイ要件は他のドキュメントによって定義されるかもしれません。
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
メール・ゲートウェイは、「外国」の気質通知のコンテンツをインターネットメールの上に伝えるためにMDNを発行するかもしれません。 外国通知要素からMDNまで適切なマッピングがあるとき
Fajman Standards Track [Page 22] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[22ページ]。
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分野で定義されるかもしれません。 (そのような分野は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の第一の目的は目的地システムで使用可能なフォームで気質情報を伝えることです。 副次目的はMDNsが外国メールシステムを通して「トンネルを堀ること」を許容することです、MDNがインターネットにgatewayedして戻されるといけないかもしれないので。
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を保持するのを試みるはずです(存在しているなら)、結果として起こる外国気質レポートで。
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情報を保存する手段を定義するかもしれません。
Fajman Standards Track [Page 23] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[23ページ]。
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.
同様に、この例の*タイプ部分体名か拡大分野の使用はそれらの型名か拡大分野のための定義に理解されないことです。
9.1 This is an MDN issued after a message has been displayed to the user of an Internet Mail user agent.
9.1 これはインターネットメールユーザエージェントのユーザにメッセージを表示した後に発行するMDNです。
Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
From: Joe Recipient <Joe_Recipient@mega.edu>
Message-Id: <199509200019.12345@mega.edu>
Subject: Disposition notification
To: Jane Sender <Jane_Sender@huge.com>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
boundary="RAA14128.773615765/mega.edu"
日付: 水曜日、1995年9月20日の00:19:00(東部夏時間の)-0400From: ジョー Recipient <Joe_Recipient@mega.edu 、gt;、メッセージイド: <199509200019.12345@mega.edu>Subject: 気質通知To: ジェーン Sender <Jane_Sender@huge.com 、gt;、MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは気質通知と等しいです。 境界="RAA14128.773615765/mega.edu"
--RAA14128.773615765/mega.edu
--RAA14128.773615765/mega.edu
The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe Recipient <Joe_Recipient@mega.edu> 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@mega.edu に1995を転送した、gt;、対象で、「レポートの最初の草稿」を表示しました。 これはメッセージが読まれるか、または理解されているという保証ではありません。
--RAA14128.773615765/mega.edu content-type: message/disposition-notification
--RAA14128.773615765/mega.eduの満足しているタイプ: 気質メッセージ/通知
Reporting-UA: joes-pc.cs.mega.edu; Foomail 97.1 Original-Recipient: rfc822;Joe_Recipient@mega.edu Final-Recipient: rfc822;Joe_Recipient@mega.edu Original-Message-ID: <199509192301.23456@huge.com> Disposition: manual-action/MDN-sent-manually; displayed
報告しているUA: joes-pc.cs.mega.edu。 Foomail97.1のオリジナルの受取人: rfc822;Joe_Recipient@mega.edu 最終受理者: rfc822;Joe_Recipient@mega.edu の元のMessage ID: <199509192301.23456@huge.com>気質: MDNは手動で手動の動き/発信していました。 表示します。
--RAA14128.773615765/mega.edu content-type: message/rfc822
--RAA14128.773615765/mega.eduの満足しているタイプ: メッセージ/rfc822
[original message goes here]
[オリジナルのメッセージはここに行きます]
--RAA14128.773615765/mega.edu--
--RAA14128.773615765/mega.edu--
Fajman Standards Track [Page 24] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[24ページ]。
10. IANA Registration Forms
10. 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, imprecise specifications, or inappropriate names.
Disposition通知オプションヘッダー、新しい気質修飾語名、または新しいMDN拡大分野に新しいパラメタ名を登録するとき、以下のフォームは使用のためのものです。 登録用紙によって必要とされたそれぞれの情報は、フォーム自体の情報を提供するか、または必要事項を含んでいる発行されて、公的に利用可能な仕様の指示するものを含んでいることによって、満たされるかもしれません。 IANA MAYは不完全な登録用紙、不正確な仕様、または不適当な名前で登録証明書を拒絶します。
To register, complete the applicable form below and send it via electronic mail to <IANA@IANA.ORG>.
登録して、以下の適切な用紙に記入して、電子メール to <IANA@IANA.ORG を通してそれを送る、gt。
10.1 IANA registration form for Disposition-Notification-Options header parameter names
10.1 Disposition通知オプションヘッダーパラメタ名のためのIANA登録用紙
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 IANA registration form for disposition modifer names
10.2 気質modifer名のためのIANA登録用紙
A registration for a disposition-modifier name MUST include the following information:
気質修飾語名のための登録は以下の情報を含まなければなりません:
(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 IANA registration form for MDN extension field names
10.3 MDN拡大フィールド名のためのIANA登録用紙
A registration for an MDN extension field name MUST include the following information:
MDN拡大フィールド名のための登録は以下の情報を含まなければなりません:
Fajman Standards Track [Page 25] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[25ページ]。
(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通知オプションヘッダーでどうコード化されることになっているかためには仕様)から完全な図形文字で構成されません。
(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 based on the Delivery Status Notifications document, RFC 1894 [9], by Keith Moore and Greg Vaudreuil. Contributions were made by members of the IETF Receipt Working Group, including Harald Alverstrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell, Pete Resnick, Chuck Shih.
このドキュメントはDelivery Status Notificationsドキュメント、キース・ムーアによるRFC1894[9]、およびグレッグ・ボードルイに基づいています。 貢献はIETF Receipt作業部会のメンバーによってされました、ハラルドAlverstrand、イアン・ベル、ウルスEppenberger、クラウス・Andriフェルバー、ネッド・フリード、ジム・ガルビン、カール・ヘイグ、マイク湖を含んでいて、キース・ムーア、ポールOverell、ピートレズニック、チャックShih。
12. References
12. 参照
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[1] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[2] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[3] Braden, R. (ed.), "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October 1989.
[3] ブレーデン、R.編、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[4] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[4]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[5] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[5]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[6] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part
Three: Message Header Extensions for Non-Ascii Text", RFC
2047, November 1996.
[6] ムーア、K.、「マルチパーパスインターネットメールエクステンション(MIME)は3を分けます」。 「非アスキーテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[7] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 1892,
January 1996.
[7] ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポート満足しているタイプ」、RFC1892、1996年1月。
Fajman Standards Track [Page 26] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[26ページ]。
[8] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC 1891, January 1996.
[8] ムーア、K.、「配送状態通知のためのSMTPサービス拡張子」、RFC1891、1996年1月。
[9] Moore, K., and G. Vaudreuil, "An Extensible Format for
Delivery Status Notifications, RFC 1894, January 1996.
[9] ムーア、K.とG.ボードルイ、「配送状態通知、RFC1894、1996年1月のための広げることができる形式。」
[10] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[10] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
13. Author's Address
13. 作者のアドレス
Roger Fajman National Institutes of Health Building 12A, Room 3063 12 South Drive MSC 5659 Bethesda, Maryland 20892-5659 USA
ロジャーFajman国立衛生研究所ビル12A、余地の3063 12の南ドライブMSC5659メリーランド20892-5659ベセスダ(米国)
EMail: raf@cu.nih.gov Phone: +1 301 402 4265 Fax: +1 301 480 6241
メール: raf@cu.nih.gov 電話: +1 301 402、4265Fax: +1 301 480 6241
Fajman Standards Track [Page 27] RFC 2298 Message Disposition Notifications March 1998
Fajman規格は1998年のメッセージ気質通知行進のときにRFC2298を追跡します[27ページ]。
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Fajman Standards Track [Page 28]
Fajman標準化過程[28ページ]
一覧
スポンサーリンク
