Translated into Japanese language by weio 日本語訳 weio Email: weio@lycos.jp WWW: http://weio.tripod.co.jp/ 　　　　 翻訳 2002年 6月13日 translation 13 Jun. 2002 　　　　 最新版 2002年 7月10日 latest rev. 10 Jul. 2002 日本語に訳者が訳した部分に関する著作権は訳者に帰属します。 訳についての著作権も末尾に記載された著作権全文に従います。 この文書はRFC2298を訳者(weio)が個人的な好奇心で適当に翻訳したものです。従って 翻訳の正確さなどは全く保証いたしません。誤訳や根本的な勘違いなどが多く含まれて いるかもしれません。正確な情報が必要な場合は英語原文を別個に入手してお読みくだ さい。この文書によるいかなる損害からも訳者は免責されるものとします。誤字・誤訳 など翻訳内容についての指摘は歓迎します。 |Network Working Group R. Fajman |Request for Comments: 2298 National Institutes of Health |Category: Standards Track March 1998 | | | An Extensible Message Format | for Message Disposition Notifications メッセージ開封通知のための拡張可能なメッセージフォーマット |Status of this Memo | | This document specifies an Internet standards track protocol for the | Internet community, and requests discussion and suggestions for | improvements. Please refer to the current edition of the "Internet | Official Protocol Standards" (STD 1) for the standardization state | and status of this protocol. Distribution of this memo is unlimited. この文書の位置付け この文書はインターネット共同体のためのインターネット標準トラックプロトコルを示 すものであり、発展のための議論や提案を依頼するものである。このプロトコルの位置 付けや標準化の段階については"Internet Official Protocol Standards"の現在の版を 参照してほしい。この文書の配布は無制限である。 |Copyright Notice | | Copyright (C) The Internet Society (1998). All Rights Reserved. 著作権 (C) The Internet Society (1998) 全ての権利を有す |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）または電子メールゲートウェイにより用いられ得る MIME内容タイプを定義する。この内容タイプは、機械により処理可能であることを意図 している。付加的なメッセージヘッダーは、また、メッセージ開封通知（MDNs）がメッ セージ差出人により要求されることを許すために定義される。MDNsの目的は、インター ネットメールの機能を拡張して、「受け取りの通知」などにしばしば言及するX.400や 他のLANベースの電子メールシステム使用者などをサポートすることである。また、こ のメモの他の意図は、過去にMDNsのような機能が議論された時にしばしば指摘されたプ ライバシーについての注意を紹介することである。 | 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 | | |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. メッセージ開封通知の要求 3. メッセージ開封通知のフォーマット 4. イベントの発生順 5. 対応および用法要求 6. セキュリティ考慮 7. 収集された文法 8. MDNsをゲートウェイするためのガイドライン 9. 例 10. IANA登録フォーム 11. 謝辞 12. 参考文献 13. 著者の連絡先 14. 著作権 |1. Introduction | | 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]. 1. 導入 このメモは、メッセージ開封通知（MDNs）のためのMIME内容タイプ[5]（訳者注：文末 の参考文献[5]の意）を定義する。MDNは成功した配達の後に起こるかもしれないいくつ かの状況すなわちメッセージ内容の表示、メッセージの印刷、メッセージの削除（表示 なしでの）、または受取人による開封通知の拒絶、これらの状況にあるメッセージの差 出人に通知するために使用することができる。ここで定義する "message/disposition- notification"内容タイプは、RFC1892[7]において定義された "multipart/report"内容 タイプの枠組内での使用を意図する。 | 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」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SH OULD NOT」「RECOMMENDED」「MAY」、および「OPTIONAL」というキーワードは、RFC211 9において説明されているように解釈される必要がある。 |1.1 Purposes | | The MDNs defined in this memo are expected to serve several purposes: 1.1 　目的 このメモにおいて定義されるMDNsはいくつかの目的に役立つことが期待される。 | (a) Inform human beings of the disposition of messages after | succcessful delivery, in a manner which 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を使用可能なメッセージシステムまたは第三の通信システムさえもトンネルし て他のオリジナルな通知を発行したオリジナルな通信システムに戻して通知することを 許す。 | (e) Allow language-independent, yet reasonably precise, indications | of the disposition of a message to be delivered. (e) 適度に精密であり、言語独立であり、配達済メッセージの処置の指示を可能とする ものである。 |1.2 Requirements | | These purposes place the following constraints on the notification | protocol: 1.2 　要求 これらの目的から以下の制約が通知プロトコルに課される。 | (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を発行する（もしそのような 情報が入手可能ならば）ことに十分な情報を提供しなければならない。 |Fajman Standards Track [Page 2] | |RFC 2298 Message Disposition Notifications March 1998 | | | (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) これらの明細事項は、将来の要求に対応するために拡張可能でなければならない。 |2. Requesting Message Disposition Notifications | | 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. 2. メッセージ開封通知の要求 メッセージ開封通知は、"Disposition-Notification-To"ヘッダをメッセージに含める ことによって要求される。MDNを生成する時に受取人の UAによって使われるより一層の 情報は、"Original-Recipient"ヘッダおよび／または"Disposition-Notification-Opti ons"ヘッダをメッセージに含むことによって提供される。 |2.1 The Disposition-Notification-To Header | | 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 |Fajman Standards Track [Page 3] | |RFC 2298 Message Disposition Notifications March 1998 | | | mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox 2.1 "Disposition-Notification-To"ヘッダ 受取人のユーザーエージェントにメッセージ開封通知を発行させるための要求は、"Dis position-Notification-To"ヘッダをメッセージに配置することによりなされる。RFC82 2[2]のABNFによるヘッダの構文は | The mailbox token is as specified in RFC 822 [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. "mailbox"とは、RFC822[2]において指定されているのと同じ意味である。 メッセージにおける"Disposition-Notification-To"ヘッダの存在は単に 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はそれ自身が "Disposition-Notification-To"ヘッダを持ってはならない。 MDNは、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. 個々の固有の受取人のためにそれぞれ一つの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. "Disposition-Notification-To"ヘッダ中のアドレスが"Return-Path"ヘッダ中のアドレ スと異なる場合（RFC822[2]を見よ）、MDNsは自動的に送信されるべきでない。この場 合には可能であるならばユーザーからの確認を獲得すべきである。もし同意を獲得する ことが可能でない（例えば、その時ユーザーがオンライン状態ではないため）ならば、 MDNを送信すべきでない。 | 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-Path"ヘッダが全然ないか、または"Disposition-Notificati on-To"ヘッダに複数の別個なアドレスがあるならば、ユーザーからの同意を獲得する （または、どのMDNも送られない）べきである。 | 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-spec（ローカルな部分+ "@"+ドメイン）部分だけを使ってされるべきである。比較はローカルな部分については 大・小文字を区別して、ドメイン部分については大・小文字を区別せずになされなけれ ばならない。 | 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. もしメッセージが複数の"Return-Path"ヘッダを含んでいるならば、実装により、比較 のために一つだけを使うか、または比較が失敗した状況として扱う。 |Fajman Standards Track [Page 4] | |RFC 2298 Message Disposition Notifications March 1998 | | | 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. 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. "Disposition-Notification-To"ヘッダを含むメッセージは、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つのコピー、つまり"Disposition-No tification-To"ヘッダを持つものと持たないもの、が送られるべきである。メッセージ の他のヘッダ（例えばTo、cc）の多くは、両方のコピーで同一にする。誰にメッセージ 開封通知を要求していて誰に要求していないかは、個々のメッセージエンベロープの受 取人から判断される。もし希望するならば、"Message-ID"ヘッダはメッセージの両方の コピーで同じにしてもよい。わずかにヘッダを変更してメッセージの複数のコピーを送 ることが必要な状況（例えばbcc）があることに注意せよ。それらの状況の組み合わせ と受取人の一部にMDNsを要求することは、メッセージの2つより多くのコピー、いくつ かは"Disposition-Notification-To"ヘッダを持ちいくつかは持たない、が送られるこ とに帰着するかもしれない。 | Messages posted to newsgroups SHOULD NOT have a Disposition- | Notification-To header. ニュースグループに投稿されるメッセージは、"Disposition-Notification-To"ヘッダ を持つべきではない。 |2.2 The Disposition-Notification-Options Header | | 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 | | Disposition-Notification-Options = | "Disposition-Notification-Options" ":" | disposition-notification-parameters | | disposition-notification-parameters = parameter *(";" parameter) | | parameter = attribute "=" importance "," 1#value | | importance = "required" / "optional" 2.2 "Disposition-Notification-Options"ヘッダ ここで指定される将来的な拡張は、受取人のUAにとってどのようにおよびどんなMDNsが 生成するかを制御するための情報を供給することに必要とされるかもしれない。"Dispo sition-Notification-Options"ヘッダはそのような情報のために拡張可能なメカニズム を提供する。RFC822[2]のABNFによるこのヘッダの構文は | The definitions of attribute and value are as in the definition of | the Content-Type header in RFC 2045 [4]. 属性と値の定義は、RFC2045[4]の"Content-Type"ヘッダの定義と同じである。 |Fajman Standards Track [Page 5] | |RFC 2298 Message Disposition Notifications March 1998 | | | 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. 重要性が"required"であることは、パラメータの解釈がこの要求に応じるためのMDNの 適切な生成に必要であることを示す。もしUAがパラメータの意味を理解しないならば 「失敗」以外のいかなる処置タイプのMDNも生成してはならない。重要性が"optional" であることは、パラメータの値を無視して、このパラメータの意味を理解しない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-"から始まるパラメータ属性名は、 決して標準の名前として定義されない、つまり、そのような名前は実験的な使用のため に予約される。"X-"から始まらないMDNパラメータは、インターネット番号割り当て公 社(IANA)に登録されて標準化過程RFCまたはIESGにより承認された実験的RFCに記述され なければならない。登録フォームについてはセクション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は「失敗」処置タイプ（セクション3.2.6を見よ）を発行するか、問題の詳 細を説明する"Failure field"（セクション3.2.7を見よ）を含むべきである。また、 「失敗」処置タイプや"Failure field"を含むMDNsは他のタイプのエラーが"Dispositio n-Notification-Options"ヘッダのパラメータに検出された時に生成されてもよい。 | 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が送られないならば「失敗」処置タイプ を持つMDNは生成されてはならない。もし他の処置タイプのMDNを送るためにユーザーの 同意が必要ならば、「失敗」処置タイプを持つMDNを送る前にもまたユーザーの同意を 獲得すべきである。 |2.3 The Original-Recipient Header | | 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 | | original-recipient-header = | "Original-Recipient" ":" address-type ";" generic-address 2.3 "Original-Recipient"ヘッダ メッセージの配送過程で電子メールアドレスが書き直されうるので、元々の受取人のア ドレスが中継MTAによって利用可能になることは有益である。中継MTAは、この情報をRF C1891[8]において定義されるSMTPの"RCPT TO"コマンドのORCPTパラメータから得ること が できるかもしれない。もしこの情報が入手可能ならばメッセージの最初に中継MTAは("R eturn-Path"ヘッダと共に）"Original-Recipient"ヘッダを挿入すべきである。 中継M TAはメッセージに存在するどのような他の"Original-Recipient"ヘッダも削除してよい。 RFC822[2]のABNFによるこのヘッダの構文は次の通り |Fajman Standards Track [Page 6] | |RFC 2298 Message Disposition Notifications March 1998 | | | The address-type and generic-address token are as as specified in the | description of the Original-Recipient field in section 3.2.3. "address-type"および"generic-address"という単語は、セクション3.2.3の"Original- Recipient"フィールドの記述において指定される通りである。 | 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にそれを戻す目的は、受取人に基づき元のメッセージ とMDNsを自動的に関係付けることを可能とすることである。 |2.4 Use with the Message/Partial Content Type | | 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. 2.4 "Message/Partial"内容タイプと合せた使用 "Disposition-Notification-To"ヘッダと"Disposition-Notification-Options"ヘッダ および"Original-Recipient"ヘッダをMIMEの"Message/Partial"内容タイプ(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つ以上の"message/partial"な部分に分割される時、パラグラフの上に記 載される3つのヘッダは「内側」または「囲まれた」メッセージ（RFC2046[5]の用語を 使用）に置かれるべきである。これらのヘッダは部分それ自身のヘッダにおいて使用さ れるべきでない。 | 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. 複数の"message/partial"な部分が再集合される時には、以下があてはまる。もし"mess age/partial"な部分メッセージの他のヘッダとともにこれらのヘッダが使用されるなら ば、それらは、この部分のためにMDNの生成物に付属する。もしこれらのヘッダが「内 側」または「囲まれた」メッセージ（RFC2046[5]の用語を使用）に存在するならば、そ れらが、再集合されるメッセージのために生成されるMDNに付随する。RFC2046[5]のセ クション5.2.2.1は以下のことを定義するために修正される、それはそこで定義された ヘッダだけでなく、ここで規定された3つのヘッダが再集合されるメッセージのヘッダ に順番に付加される必要があることである。いかなる、元々の「囲まれた」メッセージ のヘッダにおいて出現する、ここで定義された3つのヘッダも、再集合されるメッセー ジにコピーしてはならない。 |3. Format of a Message Disposition Notification | | 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: 3. メッセージ開封通知のフォーマット メッセージ開封通知は、"multipart/report"のトップレベルの内容タイプを持つMIMEメ ッセージである（RFC1892[7]において定義されている）。MDNを送るために"multipart/ report"が使用される時： | (a) The report-type parameter of the multipart/report content is | "disposition-notification". (a) "multipart/report"のレポートタイプの値は"disposition-notification"である。 | (b) The first component of the multipart/report contains a human- | readable explanation of the MDN, as described in RFC 1892 [7]. (b) RFC1892[7]において説明されている"multipart/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) "multipart/report"の2番目の構成部分は、この文書のセクション3.1で説明される "message/disposition-notification"内容タイプである。 |Fajman Standards Track [Page 7] | |RFC 2298 Message Disposition Notifications March 1998 | | | (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) もし元のメッセージまたはメッセージの部分を、送信側に戻す必要があるならば、 それは"multipart/report"の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. 注：　他のシステムから渡されたメッセージ開封通知では、元のメッセージのヘッダは 利用可能でないかもしれない。このケースにおいて、MDNの3番目の構成部分は省略され るか、または、同等の情報を含んでいる"simulated"RFC822ヘッダを含むかもしれない。 特に、元のメッセージからの"subject"と"date"フィールドを保護することが非常に望 ましい。 | 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が生成される元のメッセージの"Disposition-Notification-To"ヘッダからアドレス （複数含む）を取得して、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のヘッダ中の"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の"envelope sender address"(すなわち、SMTP"MAIL FROM")は、いかなる配達状況 通知メッセージ、または他の配達成功／不成功を示すメッセージもMDNに対して送られ る必要がないことを指定するために、null(<>)でなければならない。 | A message disposition notification MUST NOT itself request an MDN. | That is, it MUST NOT contain a Disposition-Notification-To header. メッセージ開封通知はそれ自身に対してMDNを要求してはならない。すなわち"Disposit ion-Notification-To"ヘッダを含んではならない。 | 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. MDNの"Message-ID"ヘッダ（存在するならば）は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. 1つのMDNは、ちょうど1つのメッセージの処置をちょうど1人の受取人に説明する。複数 のMDNsは、1回のメッセージ提出の結果として1人の受取人あたり1つ生成できる。しか しながら、セクション2.1で説明された状況のため、MDNsは、MDNsを要求する複数の受 取人のためには生成できない。 |3.1 The message/disposition-notification content-type | | The message/disposition-notification content-type is defined as | follows: | | MIME type name: message |Fajman Standards Track [Page 8] | |RFC 2298 Message Disposition Notifications March 1998 | | | 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. 3.1 "message/disposition-notification"内容タイプ "message/disposition-notification"内容タイプは次の通り定義される： MIME type name: message MIME subtype name: disposition-notification Optional parameters: none Encoding considerations: 「7ビット」符号化を満たすこと、 およびMIME非対応のメールリーダでの可読性を 維持するものを使用しなければならない。 Security considerations: このメモのセクション6で議論される。 | The message/disposition-notification report type for use in the | multipart/report is "disposition-notification". "multipart/report"での使用のための"message/disposition-notification"報告タイプ は"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: | | 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 ) "message/disposition-notification"のボディは、RFC822ヘッダ"fields"（[2]を見 よ）のABNFに従って整形された1つ以上の"fields"から成る。RFC822のABNFを使う"mess age/disposition-notification"の構文は次の通り |3.1.1 General conventions for fields | | 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]. 3.1.1 フィールドの一般的規則 RFC822[2]の規則に従ってこれらのフィールドが定義されるので、連続する行とコメン トには同じ規則が適用される。通知フィールドは、SPACEまたはHTABによるそれぞれの 追加的な行から開始されることによって複数の行の上に続けられ得る。括弧において出 現するテキストは、コメントとその通知フィールドの中身の部分と考えられる。フィー ルド名は大文字・小文字を区別しない、従って、通知フィールドの名前は大文字と小文 字のどのような組み合わせにおいてでも綴られる。通知フィールドのコメントは、RFC2 047[6]において定義された"encoded-word"構成物を使うことができる。 |3.1.2 "*-type" subfields | | 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. | | The "-type" subfields are defined as follows: 3.1.2 "*-type"サブフィールド いくつかのフィールドが、"*text"の後にセミコロンで続いている"-type"サブフィール ドから成っている。これらのフィールドのために、"address-type"または"MTA-type"サ ブフィールドにおいて使われているキーワードは、アドレスまたは後続の"MTA-name"の 予期される形式を示す。 "-type"サブフィールドは次の通り定義される |Fajman Standards Track [Page 9] | |RFC 2298 Message Disposition Notifications March 1998 | | | (a) An "address-type" specifies the format of a mailbox address. | For example, Internet Mail addresses use the "rfc822" address- | type. | | address-type = atom (a) "address-type"はメールボックスアドレスの形式を指定する。例えば、"rfc822"ア ドレスタイプを使用するインターネットメールアドレスは | (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. | | mta-name-type = atom (b) "MTA-name-type"は、メール中継エージェント名の形式を指定する。例えば、イン ターネットホスト上のSMTPサーバー（MTA名はそのホストのドメイン名）のためには、" MTA-name-type"は"dns"が使われる。 | Values for address-type and mta-name-type are case-insensitive. Thus | address-type values of "RFC822" and "rfc822" are equivalent. アドレスタイプとmta-nameタイプのための値は大文字・小文字を区別しない。それゆえ "RFC822"と"rfc822"のアドレスタイプとしての値は等しい。 | The Internet Assigned Numbers Authority (IANA) will maintain a | registry of address-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]. インターネット番号割り当て公社(IANA)は、それぞれの説明を提供するか説明を提供す る1つ以上の仕様書への参照とともに"address-type"および"mta-name-type"値のレジス トリを管理する。（"rfc822"アドレスタイプはRFC1891[8]において定義される）"addre ss-type"と"mta-name-type"のための登録フォームは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 | | The following lexical tokens, defined in RFC 822 [2], are used in the | ABNF grammar for MDNs: atom, CRLF, mailbox, msg-id, text. 3.1.3 語彙はRFC822から導入した RFC822[2]において定義された以下の語彙はMDNsのためのABNF文法において使われる: a tom, CRLF, mailbox, msg-id, text |3.2 Message/disposition-notification Fields | |3.2.1 The Reporting-UA field | | reporting-ua-field = "Reporting-UA" ":" ua-name | [ ";" ua-product ] | | ua-name = *text | | ua-product = *text | | The Reporting-UA field is defined as follows: 3.2 "Message/disposition-notification"のフィールド 3.2.1 "Reporting-UA"フィールド "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 |Fajman Standards Track [Page 10] | |RFC 2298 Message Disposition Notifications March 1998 | | | 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, | | Reporting-UA: rogers-mac.dcrt.nih.gov; Foomail 97.1 メッセージが受取人に配達された後にMDNはその処置を説明する。すべての場合に、報 告UAはMDNにおいて説明された処置を実行したUAである。このフィールドはオプション ではあるが推奨される。インターネットメールユーザーエージェントには、このフィー ルドが、MDNを作成したUAのDNS名と製品名の両方を含むことが推奨される。例えば、 | 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が複数の構成部分（例えば、基本のプログラムおよびプラグイン）から成っ ているならば、これは、製品名のリストを含むことによって示されてもよい。 |3.2.2 The MDN-Gateway field | | 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-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name | | mta-name = *text 3.2.2 "MDN-Gateway"フィールド "MDN-Gateway"フィールドは、他（インターネット以外）のメッセージ開封通知をこのM DNに変換したゲートウェイないしはMTAの名前を示す。他のシステムからゲートウェイ によりMDN形式に翻訳された時に現れなければならず、それ以外には現れてはならない。 | 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-name-type"は"smtp"で あり、"mta-name"はゲートウェイのインターネットドメイン名である。 |3.2.3 Original-Recipient field | | 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 UA may choose the one | to use or act as if no Original-Recipient header is present. | | original-recipient-field = | "Original-Recipient" ":" address-type ";" generic-address | | generic-address = *text 3.2.3 "Original-Recipient"フィールド "Original-Recipient"フィールドは、MDNが発行されるメッセージの差出人により指定 された元の受取人のアドレスを示す。インターネットメールメッセージでは、"Origina l-Recipient"フィールドの値は、MDNが生成されるメッセージの"Original-Recipient" ヘッダから得る。もしメッセージに"Original-Recipient"ヘッダが全然ないならば、な んらかの方法で信頼できる同等の情報を入手可能でない限りは"Original-Recipient"フ ィールドを省略しなければならない。もし元のメッセージに"Original-Recipient"ヘッ ダがある（または"Original-Recipient"情報をなんらかの信頼できる方法で入手可能） ならば、"Original-Recipient"フィールドは供給されなければならない。もしメッセー ジに複数の"Original-Recipient"ヘッダがあるならば、UAは1つだけを使用するかあた かもどの"Original-Recipient"ヘッダも存在しないかのように振る舞うかを選択してよ い。 |Fajman Standards Track [Page 11] | |RFC 2298 Message Disposition Notifications March 1998 | | | 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. "address-type"フィールドは、MDNの受取人のアドレスのタイプを示す。もしインター ネット内でメッセージが発生したならば、"address-type"フィールドは通常"rfc822"で あるだろう、そしてアドレスはRFC822[2]において指定された構文に従う。もし報告UA が、メッセージ封筒から、元のアドレスのタイプを決定できないならば、"unknown"値 が使われるべきである。このアドレスは、差出人により提供されるものと同じであり、 かつ、受取人単位でMDNを元のメッセージと自動的に関係づけるように使用できる。 |3.2.4 Final-Recipient field | | The Final-Recipient field indicates the recipient for which the MDN | is being issued. This field MUST be present. 3.2.4 "Final-Recipient"フィールド "Final-Recipient"フィールドは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. "Final-Recipient"フィールドの"generic-address"サブフィールドは、MDNがUAにより 生成される時に、受取人（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-Recipient"アドレスは、差出人が元々提供したアドレスと異なるかもしれない。 なぜなら、それは転送時やゲートウェイを通過する時に変換されて、完全に識別不能な ほど混乱しているかもしれないからである。しかしながら、"Original-Recipient"フ ィールド（オプション）、"Final-Recipient"フィールド、およびどのような戻された 内容でも、特定のメッセージに対する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". "address-type"サブフィールドは、その状況において報告MTAに予期されるアドレスの タイプを示す。SMTPを経由して得られた受取人のアドレスは、通常、アドレスタイプ"r fc822"を持つ。 | 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 | | 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 |Fajman Standards Track [Page 12] | |RFC 2298 Message Disposition Notifications March 1998 | | | original-message-id-field = "Original-Message-ID" ":" msg-id | | The msg-id token is as specified in RFC 822 [2]. 3.2.5 "Original-Message-ID"フィールド "Original-Message-ID"フィールドは、MDNが発行されるメッセージの"message-ID"を示 す。それは、MDNが発行されるメッセージの"Message-ID"ヘッダから得られる。もし元 のメッセージが"Message-ID"ヘッダを含むならば、このフィールドが存在しなければな らない。フィールドの構文は "msg-id"という語はRFC822[2]において指定されるものと同じ。 |3.2.6 Disposition field | | The Disposition field indicates the action performed by the | Reporting-UA on behalf of the user. This field MUST be present. | | The syntax for the Disposition field is: | | disposition-field = "Disposition" ":" disposition-mode ";" | disposition-type | [ '/' disposition-modifier | *( "," dispostion-modifier ) ] | | disposition-mode = action-mode "/" sending-mode | | action-mode = "manual-action" / "automatic-action" | | sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" | | disposition-type = "displayed" | / "dispatched" | / "processed" | / "deleted" | / "denied" | / "failed" | | disposition-modifier = ( "error" / "warning" ) | / ( "superseded" / "expired" / | "mailbox-terminated" ) | / disposition-modifier-extension | | disposition-modifier-extension = atom 3.2.6 "Disposition"フィールド "Disposition"フィールドは、ユーザーのために報告UAが実行した行動を示す。このフ ィールドは存在しなければならない。 "Disposition"フィールドのための構文は： | 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 | | The following disposition modes are defined: 3.2.6.1 処置モード 以下の処置モードを定義する： | "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. 「手動」　　"Disposition"タイプにより説明された処置は、なんらかの自動的に実行 された行動よりも、むしろユーザーによる明瞭な指示の結果である。 |Fajman Standards Track [Page 13] | |RFC 2298 Message Disposition Notifications March 1998 | | | "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. 「自動」　　"Disposition"タイプにより説明された処置は、このメッセージのための ユーザーによる明瞭な指示よりも、むしろ自動的な行動の結果である。 | "Manual-action" and "automatic-action" are | mutually exclusive. One or the other must | be specified. 「手動」および「自動」は相互に排他的である。一方または他方が指定されなければな らない。 | "MDN-sent-manually" The user explicity gave permission for | this particular MDN to be sent. 「MDN送信手動」　　ユーザーは、この特有の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送信自動」は相互に排他的である。一方または他方が指定され なければならない。 |3.2.6.2 Disposition types | | The following disposition-types are defined: 3.2.6.2 処置タイプ 以下の処置タイプが定義される： | "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. "displayed" メッセージは、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. "dispatched" メッセージは、どこかに、なんらかの方法 （例えばプリントアウト、 ファックス、転送）で、前もってユーザーに表示されたとは限らずに送られた。ユー ザーは後でメッセージを見ることも見ないこともできる。 | "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. "processed" メッセージは、ユーザーに表示されることなしに、なんらかの方法（す なわち何かの規則またはサーバーによる）で処理された。ユーザーは後でメッセージを 見ることも見ないこともできる。またはそのメールボックスには関連する人間のユー ザーがいないことすらあり得る。 | "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. "deleted" メッセージは、削除された。受取人はメッセージを見たかもしれないし、 見なかったかもしれない。受取人は後で"undelete"してメッセージを読むかもしれない。 |Fajman Standards Track [Page 14] | |RFC 2298 Message Disposition Notifications March 1998 | | | "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. "denied" 受取人は差出人にメッセージの処置を知らせることを望まない。この状況 では、UAはメッセージ開封通知の要求を黙って無視することもできる。 | "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. "failed" MDNの正常な生成を妨げる失敗が起きた。失敗の原因についてのより多くの 情報は"Failure"フィールドに含まれる。"failed"処置タイプはMDNのための要求を解釈 する以外のメッセージ処理時の問題には使われない。"processed"または他の処置タイ プは、適切な"disposition"修飾子によってはそのような状況でも使われる。 |3.2.6.3 Disposition modifiers | | The following disposition modifiers are defined: 3.2.6.3 処置修飾子 以下の処置修飾子が定義される： | "error" An error of some sort occurred | that prevented successful | processing of the message. | Further information is contained | in an Error field. "error"　　メッセージの正常な処理を妨げるなんらかのエラーが起きた。 　　　　　詳しい情報は"Error"フィールドに含まれる。 | "warning" The message was successfully | processed but some sort of | exceptional condition occurred. | Further information is contained | in a Warning field. "warning"　　メッセージは首尾よく処理されたが、なんらかの例外的な状況が起きた。 　　　　　　詳しい情報は"Warning"フィールドに含まれる。 | "superseded" The message has been | automatically rendered obsolete by | another message received. The | recipient may still access and | read the message later. "superseded"　　メッセージは、別のメッセージが受け取られたことにより自動的に、 　　　　　　　　廃れたものにされた。受取人は依然としてアクセスして 　　　　　　　　後でメッセージを読むことができる。 | "expired" The message has reached its | expiration date and has been | automatically removed from the | recipient's mailbox. "expired"　　メッセージはその満了日付に達し、自動的に、 　　　　　　受取人のメールボックスから取り除かれた。 | "mailbox-terminated" The recipient's mailbox has been | terminated and all message in it | automatically removed. "mailbox-terminated"　　受取人のメールボックスは閉鎖され、 　　　　　　　　　　　　そのすべてのメッセージは自動的に取り除かれた。 |Fajman Standards Track [Page 15] | |RFC 2298 Message Disposition Notifications March 1998 | | | "Obsoleted", "expired", and | "terminated" are to be used with | the "deleted" disposition type and | the "autoaction" and "autosent" | disposition modifiers. "Obsoleted"、"expired"、および"terminated"は、"deleted"処置タイプ、および"auto action"および"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. "disposition-modifier-extension" 付加的な処置修飾子は、ここでの指定より新しいリビジョンまたは拡張において将来的 に定義され得る。"X-"から始まる名前の処置の値は決して標準値として定義されない； そのような名前は実験的な使用のために予約される。"X-"から始まらないMDNの処置の 値はインターネット番号割り当て公社(IANA)に登録されて標準化過程RFCまたはIESGに より承認された実験的RFCに記述されなければならない。登録フォームについてはセク ション10を見よ。処置修飾子があり受取人のUAによって理解できないMDNsは黙って無視 されるか、または特別な翻訳なしでユーザーのメールボックスに置かれる。それらは差 出人の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が処置フィールドの可能な値すべてを生成できることが必要なわけではない。 | 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 |Fajman Standards Track [Page 16] | |RFC 2298 Message Disposition Notifications March 1998 | | | 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をその受取人は全く発行できない。しか しながら、もしメッセージが転送されるならば、転送者が"dispatched"MDNを発行し、 受取人もまたMDNを生成してよい。 |3.2.7 Failure, Error and Warning fields | | 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-field = "Failure" ":" *text | | error-field = "Error" ":" *text | | warning-field = "Warning" ":" *text 3.2.7 "Failure"、"Error"、および"Warning"フィールド "Failure"、"Error"、および"Warning"フィールドは、"failure"処置タイプと"error" および／または"warning"処置修飾子が現れたとき、テキストメッセージに付加的な情 報を補充するためのフォームとして使用される。構文は |3.3 Extension fields | | 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. | | Extension MDN fields may be defined for the following reasons: 3.3 拡張フィールド 付加的なMDNフィールドは将来にここでの指定より新しいリビジョンまたは拡張により 定義され得る。"X-"から始まる拡張フィールド名は、決して標準のフィールドと定義さ れない；そのような名前は実験的な使用のために予約される。"X-"から始まらないMDN フィールド名は、インターネット番号割り当て公社(IANA)に登録されて標準化過程RFC またはIESGにより承認された実験的RFCに記述されなければならない。登録フォームに ついてはセクション10を見よ 拡張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-Physical-Forwarding-Address"） | (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). (b) あるユーザーエージェント（UA）に特有な診断情報の伝達を許すため。そのような MDNフィールド名前は、MDNを生成したUA実装名から始まるはずである。 （例えば"Foomail-information"） | 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 -EDI-info"） |4. Timeline of events | | The following timeline shows when various events in the processing of | a message and generation of MDNs take place: |Fajman Standards Track [Page 17] | |RFC 2298 Message Disposition Notifications March 1998 | | | -- User composes message | | -- User tells UA to send message | | -- UA passes message to MTA (original recipient information | passed along) | | -- MTA sends message to next MTA | | -- Final MTA receives message | | -- Final MTA delivers message to UA (possibily generating 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 displays list of messages to user | | -- 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). | | -- User possibly performs other actions on message, but no | further MDNs are generated. 4. イベントの発生順 以下の発生順は、いつメッセージの処理における様々なイベントおよびMDNsの生成が起 こるかを明らかにする： -- ユーザーがメッセージを書く -- ユーザーが、メッセージを送るようUAに命じる -- UAはメッセージをMTAに手渡す（元の受取人情報と共に） -- MTAはメッセージを次のMTAに送る -- 最終のMTAがメッセージを受け取る -- 最終のMTAがメッセージをUAに配達する（このときDSNが生成される可能性がある） -- UAは自動的な処理を実行し対応したMDNs（「自動」かつ「MDN送信自動」処置モード を持つ"dispatched"、"processed"、"deleted"、"denied"または"failed"処置タイプ） を生成する -- UAはユーザーにメッセージのリストを提示する -- ユーザーはメッセージを選びそれにいくらかの行動を実行する事を要求する -- UAはユーザーの許可のもと要求された行動を実行し適切なMDN（「手動」かつ「MDN 送信手動」／「MDN送信自動」処置モードを持つ"dispatched"、"processed"、"deleted "、"denied"または"failed"処置タイプ）を送る -- ユーザーがメッセージに他の動作を実行するかもしれないが追加のMDNsは全く生成 されない |5. Conformance and Usage Requirements | | 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. 5. 対応および用法要求 もしこのメモにおいて定義されたプロトコルに従って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-Recipient"フィールドを生成してならない。通常 のSMTPはその保証を提供しない、しかしRFC1891[8]において定義されたSMTP拡張は、も し入手可能ならば封筒にそのような情報が伝えられることを許す。この文書において定 義された"Original-Recipient"ヘッダは、元の受取人のアドレスをUAに渡す方法をMTA に提供する。 |Fajman Standards Track [Page 18] | |RFC 2298 Message Disposition Notifications March 1998 | | | 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. それぞれの差出人指定の受取人アドレスは、複数のMDNをもたらすかもしれない。もし 「エイリアス」の複数の受取人に転送（RFC1891[8]のセクション6.2.7.3において定義 されたように）される受取人のためにMDNが要求されるならば、それぞれの受取人は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. メーリングリストサーバーへのメッセージの成功した配達はメッセージの最終の処置と 考えられるべきである。メーリングリストサーバーは、メッセージがリストに転送され たことを示す"processed"処置タイプおよび「自動」および「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. 代わりに、メーリングリストサーバーはMDNを全く発行せずにリストのすべてのメン バーへMDNsの要求を伝達してもよい。多くのMDNsを生成したり、リストの秘密の加入者 が明らかにされたりするかもしれないので、後者の振る舞いは小さく緊密なリストにも 推薦はされない。また、メーリングリストサーバーがMDNsを自身に送らせ、それらを関 係づけて、メッセージの元の差出人への報告を作成しても差し支えない。 | This specification places no restrictions on the processing of MDNs | received by user agents or mailing lists. ここでの指定は、ユーザーエージェントまたはメーリングリストにより受け取られたMD Nsの処理を全く制限しない。 |6. Security Considerations | | The following security considerations apply when using MDNs: 6. セキュリティ考慮 以下のセキュリティ考慮は、MDNsを使う時にあてはまる： |6.1 Forgery | | 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. 6.1 偽造 MDNsは通常のインターネット電子メールと同じくらい容易に偽造できる。ユーザーエー ジェントとMDNsを自動的に利用するよう希望する自動メール取り扱い設備（メール分配 リストサーバーなど）は、サービス否定攻撃による潜在的な損害を最小限にするために 適切な用心をするべきである。 | Security threats related to forged MDNs include the sending of: | | (a) A falsified disposition notification when the indicated | disposition of the message has not actually ocurred, | | (b) Unsolicited MDNs 偽造MDNsと関連するセキュリティ脅威は以下の送信を含む： (a) メッセージの処置として示されたものが実際には発生していない時の偽造された開 封通知 (b) 要求されないMDNs |6.2 Confidentiality | | 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 | | | 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. 6.2 内密性 別の次元のセキュリティは内密性である。メッセージ受取人が処置を通知することを望 まない場合やMDNsの送信により他の機密情報が明らかにされ得る（例えばメッセージが 読まれた時間）ことを望まない場合があるかもしれない。この状況で、UAは"denied"MD Nsを発行するか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-Notific ation-To"ヘッダが修正されずに通過したならば、リストの加入者は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. "multipart/report"の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. 未暗号化MDNは、特に、もし"multipart/report"の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. 一般に、もし報告UAサイトまたはユーザーが過大フィールドのためサイト内密性を含む と判断するならば、どのようなオプションのMDNフィールドでも省略できる。そのよう な内密性の必要は、MDNsの省略された情報の有用性と比較考量されなければならない。 |6.3 Non-Repudiation | | 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. 6.3 不拒否 今日のインターネットメールの枠組内では、この文書において定義されたMDNsは、メー ルユーザーに貴重な情報を提供する；しかしながら、MDNsはメッセージが受取人により 見られた／見られなかったという保証としては信頼できない。たとえMDNsが積極的に偽 造されなくても、それらは配送中に失われるかもしれない。受取人により、MDN発行メ カニズムはなんらかの方法でバイパスできる。 |7. Collected Grammar | | 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]. 7. 収集された文法 注：　以下の語彙はRFC822において定義される： atom, CRLF, mailbox, msg-id, text。 属性と値の定義はRFC2045[4]の"Content-Type"ヘッダの定義と同じ。 | Message headers: | | mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox | | Disposition-Notification-Options = | "Disposition-Notification-Options" ":" | disposition-notification-parameters |Fajman Standards Track [Page 20] | |RFC 2298 Message Disposition Notifications March 1998 | | | disposition-notification-parameters = parameter *(";" parameter) | | parameter = attribute "=" importance "," 1#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 ) | | address-type = atom | | mta-name-type = atom | | reporting-ua-field = "Reporting-UA" ":" ua-name | [ ";" ua-product ] | | ua-name = *text | | ua-product = *text | | mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name | | mta-name = *text | | 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 | | | [ '/' disposition-modifier | *( "," dispostion-modifier ) ] | | disposition-mode = action-mode "/" sending-mode | | action-mode = "manual-action" / "automatic-action" | | sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" | | 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 | | 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 | | 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. 8. MDNsをゲートウェイするためのガイドライン 注：　このセクションは、非拘束的な勧告を、インターネットと他の電子メールシステ ムの間の半透過な開封通知を提供することを望むメールゲートウェイの作成のために提 供する。特有の1対のメールシステムのための特定のMDNゲートウェイのための要求は、 他の文書により定義され得る。 |8.1 Gatewaying from other mail systems to MDNs | | 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 |Fajman Standards Track [Page 22] | |RFC 2298 Message Disposition Notifications March 1998 | | | 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) 8.1 　他のメールシステムからMDNsへのゲートウェイ メールゲートウェイはインターネットメール上で他の開封通知の中身を運搬するために、 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. ゲートウェイは、適切な値を報告UAおよび最終の受取人および処置フィールドに提供す ることを試みなければならない。これらは、通常、他の通知の値をそれらのインターネ ットスタイルの等価な値に翻訳することによって得られる。しかしながら、情報のある 程度の損失は予期される。 | 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. 差出人に指定される受取人アドレスおよび元の"message-id"が、もし他の通知に存在す るならば、"Original-Recipient"と"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-Gateway"フィールドにゲートウェイ 名が出現しなければならない。 |8.2 Gatewaying from MDNs to other mail systems | | 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. 8.2 MDNsから他のメールシステムへのゲートウェイ インターネットから他メールシステムへのMDNsがゲートウェイに可能であるかもしれな い。そのようなゲートウェイの第1の目的は、宛先システムで使用可能な形式の処置情 報を伝えることである。第2の目的は、MDNがインターネットにゲートウェイから戻され ることに対応する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-Recipient"アドレスと"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 | | |9. Example | | 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. | | 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. 例 注：　この例は説明としてのみ提供され、MDNプロトコル指定の一部と考えられるもの ではない。もし例が上記のプロトコル定義と矛盾しているならば、例が間違っている。 さらに、この例での"*-type"サブフィールド名または拡張フィールドは、それらのタイ プ名または拡張フィールドのための定義と解釈されるものではない。 |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 | Message-Id: <199509200019.12345@mega.edu> | Subject: Disposition notification | To: Jane Sender | MIME-Version: 1.0 | Content-Type: multipart/report; report-type=disposition-notification; | boundary="RAA14128.773615765/mega.edu" | | --RAA14128.773615765/mega.edu | | The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe | Recipient with subject "First draft of | report" has been displayed. This is no guarantee that the message | has been read or understood. 1995年9月19日13時30分00秒(EDT)-0400に、Joe Recipient宛 の題名"First draft of report"のメッセージは表示された。これは、メッセージが読 まれたかまたは理解されたという保証ではない。 | --RAA14128.773615765/mega.edu | content-type: message/disposition-notification | | 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 | | --RAA14128.773615765/mega.edu | content-type: message/rfc822 | | [original message goes here] | | --RAA14128.773615765/mega.edu-- [元のメッセージが続く] |Fajman Standards Track [Page 24] | |RFC 2298 Message Disposition Notifications March 1998 | | |10. IANA Registration Forms | | 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. 10. IANA登録フォーム 下のフォームは、"Disposition-Notification-Options"ヘッダについての新しいパラ メータ名、新しい処置修飾子名、または新しいMDN拡張フィールドを登録する時の使用 に向いている。登録フォームに必要な情報の個々の部分は、フォーム自身についての情 報を提供すること、または必要な情報を含む出版されたか公然と入手可能な指定への参 照を含むことを満たす。不完全な登録フォーム、不正確な仕様書、または不適当な名前 によりIANAは登録を拒否することができる。 | To register, complete the applicable form below and send it via | electronic mail to . 登録するためには、下の適用可能なフォームを完成し、電子メールで に送る。 |10.1 IANA registration form for Disposition-Notification-Options header | parameter names | A registration for a Disposition-Notification-Options header | parameter name MUST include the following information: 10.1 "Disposition-Notification-Options"ヘッダパラメータ名のためのIANA登録フ ォーム "Disposition-Notification-Options"ヘッダパラメータ名のための登録フォームには、 以下の情報を含まなければならない。 | (a) The proposed parameter name. | | (b) The syntax for parameter values, specified using BNF, ABNF, | regular expressions, or other non-ambiguous language. | | (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. | | (d) A reference to a standards track RFC or experimental RFC approved | by the IESG that describes the semantics of the parameter values. (a) 提案するパラメータ名 (b) BNF、ABNF、正規表現、または他の非多義的な言語の使用を指定したパラメータ値 の構文。 (c) もし完全にパラメータ値がUS-ASCII文字により構成されているわけではないならば、 どのようにそれらが"Disposition-Notification-Options"ヘッダにおいてUS-ASCII図形 文字として符号化されることになるかの指定。 (d) パラメータ値の意味論を説明する標準トラックRFCまたはIESGにより承認された実 験的RFCへの参照 |10.2 IANA registration form for disposition modifer names | | A registration for a disposition-modifier name MUST include the | following information: | | (a) The proposed disposition-modifier name. | | (b) A reference to a standards track RFC or experimental RFC approved | by the IESG that describes the semantics of the disposition modifier. 10.2 処置修飾子名のためのIANA登録フォーム 処置修飾子名のための登録フォームには、以下の情報を含まなければならない。 (a) 提案する処置修飾子名 (b) 処置修飾子の意味論を説明する標準トラックRFCまたはIESGにより承認された実験 的RFCへの参照 |10.3 IANA registration form for MDN extension field names | | A registration for an MDN extension field name MUST include the | following information: 10.3 MDN拡張フィールド名のためのIANA登録フォーム MDN拡張フィールド名のための登録フォームには、以下の情報を含まなければならない。 |Fajman Standards Track [Page 25] | |RFC 2298 Message Disposition Notifications March 1998 | | | (a) The proposed extension field name. | | (b) The syntax for extension values, specified using BNF, ABNF, | regular expressions, or other non-ambiguous language. | | (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. | | (d) A reference to a standards track RFC or experimental RFC approved | by the IESG that describes the semantics of the extension field. (a) 提案する拡張フィールド名 (b) BNF、ABNF、正規表現、または他の非多義的な言語の使用を指定したパラメータ値 の構文。 (c) もし完全に拡張フィールドがUS-ASCII文字により構成されているわけではないなら ば、どのようにそれらが"Disposition-Notification-Options"ヘッダにおいてUS-ASCII 図形文字として符号化されることになるかの指定。 (d) 拡張フィールドの意味論を説明する標準トラックRFCまたはIESGにより承認された 実験的RFCへの参照 |11. Acknowledgments | | 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. 11. 謝辞 この文書は、Keith MooreとGreg VaudreuilによるRFC1894[9]の配達状況通知について の文書に基づく。IETF領収書作業部会メンバー(Harald Alverstrand, Ian Bell, Urs E ppenberger, Claus Andri Faerber, Ned Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell, Pete Resnick, Chuck Shihを含む)が寄与した。 |12. References | | [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, | August 1982. 12. 参考文献 [1] Postel,J.,「簡潔なメール転送手順」,STD10,RFC821,1982年8月 | [2] Crocker, D., "Standard for the Format of ARPA Internet Text | Messages", STD 11, RFC 822, August 1982. [2] Crocker,D.,「ARPAインターネットテキストメッセージの書式のための標準」,STD1 1,RFC822,1982年8月 | [3] Braden, R. (ed.), "Requirements for Internet Hosts - | Application and Support", STD 3, RFC 1123, October 1989. [3] Braden,R.(ed.),「インターネットホストへの要求 - アプリケーションとサポー ト」,STD3,RFC1123,1989年10月 | [4] Freed, N., and N. Borenstein, "Multipurpose Internet Mail | Extensions (MIME) Part One: Format of Internet Message | Bodies", RFC 2045, November 1996. [4] Freed, N., and N. Borenstein,「[多目的インターネットメール拡張] (MIME) パート１: インターネットメッセージ本文のフォーマット」,RFC2045,1996年11月 | [5] Freed, N., and N. Borenstein, "Multipurpose Internet Mail | Extensions (MIME) Part Two: Media Types", RFC 2046, November | 1996. [5] Freed, N., and N. Borenstein,「[多目的インターネットメール拡張] (MIME) パート２: メディアタイプ」,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] Moore, K.,「[多目的インターネットメール拡張] (MIME) パート３: 非ASCIIテク ストのためのメッセージヘッダ拡張」,RFC2047,1996年11月 | [7] Vaudreuil, G., "The Multipart/Report Content Type for the | Reporting of Mail System Administrative Messages", RFC 1892, | January 1996. [7] Vaudreuil,G.,「メールシステム管理メッセージの報告のための"Multipart/Report "内容タイプ」,RFC1892,1996年1月 |Fajman Standards Track [Page 26] | |RFC 2298 Message Disposition Notifications March 1998 | | | [8] Moore, K., "SMTP Service Extension for Delivery Status | Notifications", RFC 1891, January 1996. [8] Moore, K.,「配達状況通知のためのSMTPサービス拡張」,RFC1891,1996年1月 | [9] Moore, K., and G. Vaudreuil, "An Extensible Format for | Delivery Status Notifications, RFC 1894, January 1996. [9] Moore, K., and G. Vaudreuil,「配達状態通知のための拡張可能なフォーマット」, RFC1894,1996年1月 | [10] Bradner, S., "Key Words for Use in RFCs to Indicate | Requirement Levels", BCP 14, RFC 2119, March 1997. [10] Bradner,S.,「RFC 中で使われる要求レベル表示のキーワード」,BCP14,RFC2119, 1997年3月 |13. Author's Address | | Roger Fajman | National Institutes of Health | Building 12A, Room 3063 | 12 South Drive MSC 5659 | Bethesda, Maryland 20892-5659 | USA | | EMail: raf@cu.nih.gov | Phone: +1 301 402 4265 | Fax: +1 301 480 6241 13. 著者の連絡先 Roger Fajman 国立予防衛生研究所 |Fajman Standards Track [Page 27] | |RFC 2298 Message Disposition Notifications March 1998 | | |14. Full Copyright Statement | | Copyright (C) The Internet Society (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. 14. 著作権全文 著作権 (C) The Internet Society (1998) 全ての権利を有す この文書とその翻訳は、複製し他人に配布することができる、更に、コメント、あるい は説明又はその実装の補助となる関連作業について、その全て又は一部にかかわらず、 すべてのそのような複製物や関連する作業に、上の著作権表示と、この節を含めていれ ば、いかなる制約もなく、作成、複製、発表、及び配布することができる。しかしなが ら、この文書自体に関して、インターネット標準化プロセスに定義されている著作権の 手続きによってインターネット標準の開発の提案に必要とされる場合や、英語以外の言 語に翻訳する必要がある場合を除いて、著作権表示や The Internet Society あるいは 他のインターネット団体へのリファレンスを削除するような変更をしてはならない。 | The limited permissions granted above are perpetual and will not be | revoked by the Internet Society or its successors or assigns. 上で認めた制限された許諾は永続的であり、The Internet Society 又はその継承者や 譲渡者によって取り消されない。 | 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. この文書とここに含まれた情報は「そのまま(AS IS)」をベースに、提供され、THE INT ERNET SOCIETY 及び THE INTERNET ENGINEERING TASK FORCE は、この中の情報の使用 がいかなる権利も侵害していないことだけでなく、 商用利用及び特定用途のいかなる 暗黙的な保障を含めて、明示的に又は暗黙的に、全ての保障を放棄する。 |Fajman Standards Track [Page 28] |