RFC1892 Network Working Group G. Vaudreuil Request for Comments: 1892 Octel Network Services Category: Standards Track January 1996 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages メールシステムの管理メッセージをレポートするための マルチパート/レポート コンテントタイプ このメモの位置づけ この文書は、Internet コミュニティへの Internet スタンダードトラックプロトコル の仕様とし、改善への議論と提案をリクエストする。どうか、標準化するための "Internet Official Protocol Standards" (STD 1) の現在の版、および、このプロ トコルの現状を参照してください、このメモの再配布は自由です。 1. The Multipart/Report MIME content-type Multipart/Report MIME content-type は、任意の電子メールレポートの為の一般的 な "family" または "container" タイプである。もちろん、このメモは、ステータス レポートを配信することを尊重すると共に Multipart/Report content-type の使用 だけを定義するが、もし単一の content-type が全ての種類のレポートに使われた なら、メール処理プログラムは利益を得るであろう。 Multipart/Report content-type は以下の様に定義される: MIME type name: multipart MIME subtype name: report Required parameters: boundary, report-type Optional parameters: none Encoding の考察: 7bit は常に適切である Security の考察: このメモの section 4 を見よ Multipart/Report の構文は、[MIME] 内で定義されている、Multipart/Mixed content type と同様である。レポートを送信するために使用された時、Multipart/ Report content-type は任意のレポートメッセージの top-level MIME content type でなければならない。report-type パラメタは、レポートの種類と同様である。 パラメタは、Multipart/Report のセカンドボディパートの MIME content sub-type である。 ユーザエージェントとゲートウェイは、メッセージがメールシステムレポートで あること、およびそのように処理されるべきである、ということを自動的に定め られなければならない。最も外部のコンテントとして Multipart/Report を置く ことは、それによって auto-processor が RFC 822 ヘッダ（メッセージは レポートである）を解析することにより検知する場合のある、メカニズムを提供 する。 Vaudreuil Standards Track [Page 1] RFC 1892 Multipart/Report January 1996 Multipart/Report content-type は 2つ または 3つのサブパートを含み、次の順 である: (1) [required] 最初のボディパートは人間が解読できるメッセージを含む。 このメッセージの意図するところは、簡単に理解できる、作成されたレポート によって原因とされたコンディションの記述を提供することであり、Multipart/ Report における 2番目のセクションを受け取る、有能なユーザエージェントを 持たないであろう、人間のリーダの為である。 最初のセクションにおけるテキストは、任意の MIME standards-track content- type, charset, または language の場合がある。エラーの記述がいくつかの 言語、またはメディアにおいて要求される場合、Multipart/Alternative 構造 は、使用される場合がある。 このボディパートは、Message/Report ボディパートへの Message/Report ボディ パートへ簡単にフォーマットすることのできない、詳細な情報を送信するため にも使用される場合がある、 (2) [required] マシンを解析することが出来るボディパートは、レポートされた メッセージハンドリングイベントのアカウントを含んでいる。このボディパート の意図するところは、人間のエキスパートによって有用な場合の、最初のボディ パート内における現行ではない詳細に沿って作成された、レポートの原因となる コンディションの machine-readable な記述を提供することである。初期の ボディパートである、Message/delivery-status は [DSN] において定義される。 (3) [optional] 戻されたメッセージ、またはその一部を含むボディパート。この情報 は、人間のエキスパートが問題を分析することを援助するのに、有益な場合が ある。（もっとも、レポートが発行された場合、メッセージの識別によって、 送信者を許可することは、有益になる場合もあるが、envelope-id と original-recipient-address は、従来のこの目的のために返されたコンテント の使用を置き換えるであろう Message/Report ボディパート内に返されること が望まれる。） コンテントの返送は、ネットワーク帯域幅および、様々なインプリメンテーション 戦略に使うことの出来るネットワークを浪費している場合がある。一般的に送信者 は、適切な戦略を選び、また返送コンテント要求の要求レベルを受信者へ告げる べきである。その様なコンテントを返すレベルの為の明示的な要求の欠如の中で、 それは [DRPT] の中で提供されており、デリバリーサービスレポートによって作成 されたエージェントは、全てのメッセージコンテントを返すべきである。 7 bits でエンコードされていないデータが 返されることになっている場合、また return path が有為な 8-bit であるとは保証されない時、２つのオプションは、 利用可能である。オリジナルメッセージは、有効な 7 bit MIME メッセージへ再変換 される場合があり、または Text/RFC822-Headers content-type は唯一のオリジナル メッセージヘッダへ返す為に使われる場合がある。 Vaudreuil Standards Track [Page 2] RFC 1892 Multipart/Report January 1996 2. The Text/RFC822-Headers MIME content-type Text/RFC822-Headers MIME content-type はラベルと、失敗したメッセージを単一の RFC 822 ヘッダに返す為のメカニズムを提供する。これらのヘッダは完全なメッセ ージではなく、また Message/RFC822 として返されるべきではない。返されたヘッダ は、失敗したメッセージの識別のため、または received: 行上のベースとなる支援 のために役立つ。 Text/RFC822-Headers MIME content-type は次のように定義される: MIME type name: Text MIME subtype name: RFC822-Headers Required parameters: None Optional parameters: none Encoding の考察: 7 bit 通常の RFC822 ヘッダには充分である、がしかし もし、ヘッダが壊れている、およびエンコーディングを要求している 場合、それらは、quoted-printable によってエンコードされる かもしれない。 Security の考察: このメモの section 4 を見よ Text/RFC822-headers ボディパートはレポートの原因となったメッセージより、 全ての RFC822 ヘッダ行を含むべきである。RFC822 ヘッダはメッセージ中の空白行 に先立った全てのラインを含んでいる。それらは、MIME-Version および MIME Content- ヘッダを含んでいる。 3. References [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, University of Tennessee, Octel Network Services, January 1996. [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1521, Bellcore, Innosoft, June 1992. [DRPT] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, University of Tennessee, January 1996. 4. Security Considerations Authentication されないレポートタイプの自動的な使用は、いくつかのセキュリティ の問題を引き起こす。ネガティブなレポートの製造は、レポートがディレクトリや メーリングリストの自動メンテナンスの為に使われる時、denial-of-service アタッ クの為の機会を引き起こす。それがなかった時、ポジティブなレポートの製造は、 メッセージが配信されたと、不正に信用するための送信者を引き起こすであろう。 Vaudreuil Standards Track [Page 3] RFC 1892 Multipart/Report January 1996 5. Author's Address Gregory M. Vaudreuil Octel Network Services 17060 Dallas Parkway Dallas, TX 75248-1905 Phone: +1-214-733-2722 EMail: Greg.Vaudreuil@Octel.com Vaudreuil Standards Track [Page 4]