RFC 3462 - The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3462
タイトル : RFC 3462 - メールシステム管理メッセージのレポートのためのマルチパート/レポートコンテンツタイプ
翻訳編集 : 自動生成

[要約] RFC 3462は、メールシステムの管理メッセージの報告のためのMultipart/Reportコンテンツタイプについての規格です。このRFCの目的は、メールシステムのエラーや配信状況の報告を効果的に行うための標準化を提供することです。

Network Working Group                                       G. Vaudreuil
Request for Comments: 3462                           Lucent Technologies
Obsoletes: 1892                                             January 2003
Category: Standards Track

The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages

メールシステム管理メッセージのレポートのためのマルチパート/レポートコンテンツタイプ

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.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports.

MultiPart/Report Multipurpose Internet Mail Extensions（MIME）コンテンツタイプは、あらゆる種類の電子メールレポートの一般的な「ファミリー」または「コンテナ」タイプです。このメモは、配信ステータスレポートに関するマルチパート/レポートコンテンツタイプの使用のみを定義しますが、あらゆる種類のレポートに単一のコンテンツタイプが使用される場合、メール処理プログラムはメリットがあります。

This document is part of a four document set describing the delivery status report service. This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure.

このドキュメントは、配信ステータスレポートサービスを説明する4つのドキュメントセットの一部です。このコレクションには、配信ステータスレポートを要求するためのSimple Mail Transfer Protocol（SMTP）拡張機能、配信レポートのレポート用のMIMEコンテンツ、拡張ステータスコードの列挙、配信レポート用のマルチパートコンテナ、元のメッセージ、および失敗の人間に優しい要約。

Table of Contents

   Document Conventions................................................2
   1. The Multipart/Report Content Type................................2
   2. The Text/RFC822-Headers..........................................4
   3. Security Considerations..........................................4
   4. Normative References.............................................5
   Appendix A - Changes from RFC 1893..................................6
   Author's Address....................................................6
   Full Copyright Statement............................................7

Document Conventions

文書規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。

1. The Multipart/Report Content Type

1. マルチパート/レポートコンテンツタイプ

The Multipart/Report MIME content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports.

マルチパート/レポートMIMEコンテンツタイプは、あらゆる種類の電子メールレポートの一般的な「ファミリー」または「コンテナ」タイプです。このメモは、配信ステータスレポートに関するマルチパート/レポートコンテンツタイプの使用のみを定義しますが、あらゆる種類のレポートに単一のコンテンツタイプが使用される場合、メール処理プログラムはメリットがあります。

The Multipart/Report content-type is defined as follows:

マルチパート/レポートコンテンツタイプは次のように定義されています。

MIME type name: multipart MIME subtype name: report Required parameters: boundary, report-type Optional parameters: none Encoding considerations: 7bit should always be adequate Security considerations: see section 3 of this memo

MIMEタイプ名：マルチパートMIMEサブタイプ名：レポート必要パラメーター：境界、レポートタイプのオプションパラメーター：なしエンコーディング考慮事項：7ビットは常に適切なセキュリティ上の考慮事項である必要があります：このメモのセクション3を参照してください

The syntax of Multipart/Report is identical to the Multipart/Mixed content type defined in [MIME]. When used to send a report, the Multipart/Report content-type must be the top-level MIME content type for any report message. The report-type parameter identifies the type of report. The parameter is the MIME content sub-type of the second body part of the Multipart/Report.

MultiPart/レポートの構文は、[MIME]で定義されているマルチパート/混合コンテンツタイプと同一です。レポートの送信に使用する場合、MultiPart/レポートコンテンツタイプは、レポートメッセージのトップレベルMIMEコンテンツタイプでなければなりません。レポートタイプのパラメーターは、レポートのタイプを識別します。パラメーターは、MultiPart/レポートの2番目のボディ部分のMIMEコンテンツサブタイプです。

User agents and gateways must be able to automatically determine that a message is a mail system report and should be processed as such. Placing the Multipart/Report as the outermost content provides a mechanism whereby an auto-processor may detect through parsing the RFC 822 headers that the message is a report.

ユーザーエージェントとゲートウェイは、メッセージがメールシステムレポートであり、そのように処理する必要があることを自動的に判断できる必要があります。マルチパート/レポートを最も外側のコンテンツとして配置すると、自動プロセッサがメッセージがレポートであるというRFC 822ヘッダーを解析することで検出できるメカニズムを提供します。

The Multipart/Report content-type contains either two or three sub-parts, in the following order:

MultiPart/レポートコンテンツタイプには、次の順序で2つまたは3つのサブパートが含まれています。

1) [Required] The first body part contains human readable message. The purpose of this message is to provide an easily understood description of the condition(s) that caused the report to be generated, for a human reader who may not have a user agent capable of interpreting the second section of the Multipart/Report.

1) [必須]最初のボディパーツには、人間の読み取り可能なメッセージが含まれています。このメッセージの目的は、マルチパート/レポートの2番目のセクションを解釈できないユーザーエージェントを持たない人間の読者に、レポートを生成した条件の簡単に理解できる説明を提供することです。

The text in the first section may be in any MIME standards-track content-type, charset, or language. Where a description of the error is desired in several languages or several media, a Multipart/Alternative construct may be used.

最初のセクションのテキストは、Mime Standards-Trackコンテンツタイプ、Charset、または言語にある場合があります。いくつかの言語またはいくつかのメディアでエラーの説明が必要な場合、マルチパート/代替構造を使用することができます。

This body part may also be used to send detailed information that cannot be easily formatted into a Message/Report body part.

この本体部分は、メッセージ/レポート本体の部分に簡単にフォーマットできない詳細情報を送信するためにも使用できます。

(2) [Required] A machine parsable body part containing an account of the reported message handling event. The purpose of this body part is to provide a machine-readable description of the condition(s) that caused the report to be generated, along with details not present in the first body part that may be useful to human experts. An initial body part, Message/delivery-status is defined in [DSN].

(2) [必須]報告されたメッセージ処理イベントのアカウントを含むマシンの解析可能なボディパーツ。この身体部分の目的は、レポートを生成した条件の機械読み取り可能な説明と、人間の専門家にとって有用な最初の身体部分に存在しない詳細を提供することです。最初のボディパート、メッセージ/配信スタッサスは[DSN]で定義されています。

(3) [Optional] A body part containing the returned message or a portion thereof. This information may be useful to aid human experts in diagnosing problems. (Although it may also be useful to allow the sender to identify the message which the report was issued, it is hoped that the envelope-id and original-recipient-address returned in the Message/Report body part will replace the traditional use of the returned content for this purpose.)

(3) [オプション]返されたメッセージまたはその一部を含むボディ部分。この情報は、人間の専門家が問題の診断を支援するのに役立つ場合があります。（送信者がレポートが発行されたメッセージを特定できるようにすることも有用かもしれませんが、メッセージ/レポート本体の部分で返されたEnvelope-IDおよびOriginal-Recipient-Addressが従来の使用に取って代わることが期待されています。この目的のためにコンテンツを返しました。）

Return of content may be wasteful of network bandwidth and a variety of implementation strategies can be used. Generally the sender should choose the appropriate strategy and inform the recipient of the required level of returned content required. In the absence of an explicit request for level of return of content such as that provided in [DRPT], the agent that generated the delivery service report should return the full message content.

コンテンツの返品は、ネットワーク帯域幅が無駄になる場合があり、さまざまな実装戦略を使用できます。通常、送信者は適切な戦略を選択し、必要な返品コンテンツの必要なレベルを受信者に通知する必要があります。[DRPT]で提供されているようなコンテンツのリターンレベルの明示的な要求がない場合、配信サービスレポートを生成したエージェントは完全なメッセージコンテンツを返す必要があります。

When 8-bit or binary data not encoded in a 7 bit form is to be returned, and the return path is not guaranteed to be 8-bit or binary capable, two options are available. The original message MAY be re-encoded into a legal 7-bit MIME message or the Text/RFC822-Headers content-type MAY be used to return only the original message headers.

7ビットフォームでエンコードされていない8ビットまたはバイナリデータが返され、リターンパスが8ビットまたはバイナリの有能であることが保証されていない場合、2つのオプションが利用可能です。元のメッセージは、合法的な7ビットMIMEメッセージに再エンコードされる場合があります。または、テキスト/RFC822-Headersコンテンツタイプを使用して、元のメッセージヘッダーのみを返すことができます。

2. The Text/RFC822-Headers content-type

2. テキスト/RFC822ヘッダーコンテンツタイプ

The Text/RFC822-Headers MIME content-type provides a mechanism to label and return only the RFC 822 headers of a failed message. These headers are not the complete message and should not be returned as a Message/RFC822. The returned headers are useful for identifying the failed message and for diagnostics based on the received lines.

Text/RFC822-Headers Mime Content-Typeは、失敗したメッセージのRFC 822ヘッダーのみにラベルを付けて返すメカニズムを提供します。これらのヘッダーは完全なメッセージではなく、メッセージ/RFC822として返されるべきではありません。返されたヘッダーは、失敗したメッセージを特定し、受信した行に基づいた診断に役立ちます。

The Text/RFC822-Headers content-type is defined as follows:

テキスト/RFC822-Headersコンテンツタイプは次のように定義されています。

MIME type name: Text MIME subtype name: RFC822-Headers Required parameters: None Optional parameters: None Encoding considerations: 7 bit is sufficient for normal RFC822 headers, however, if the headers are broken and require encoding to make them legal 7 bit content, they may be encoded in quoted-printable. Security considerations: See section 3 of this memo.

MIMEタイプ名：テキストMIMEサブタイプ名：RFC822ヘッダー必須パラメーター：なしオプションのパラメーター：なしエンコード考慮事項：7ビットは通常のRFC822ヘッダーに十分ですが、ヘッダーが壊れてエンコードが必要な場合は、7ビットコンテンツを作成する必要があります。それらは引用された印刷可能でエンコードされる場合があります。セキュリティ上の考慮事項：このメモのセクション3を参照してください。

The Text/RFC822-Headers body part should contain all the RFC822 header lines from the message which caused the report. The RFC822 headers include all lines prior to the blank line in the message. They include the MIME-Version and MIME Content-Headers.

Text/RFC822-Headersボディの部分には、レポートを引き起こしたメッセージからすべてのRFC822ヘッダーラインを含める必要があります。RFC822ヘッダーには、メッセージ内の空白行の前にすべての行が含まれています。それらには、mime-versionとmimeのコンテンツヘッダーが含まれます。

3. Security Considerations

3. セキュリティに関する考慮事項

Automated use of report types without authentication presents several security issues. Forging negative reports presents the opportunity for denial-of-service attacks when the reports are used for automated maintenance of directories or mailing lists. Forging positive reports may cause the sender to incorrectly believe a message was delivered when it was not.

認証なしのレポートタイプの自動使用は、いくつかのセキュリティの問題を提示します。否定的な報告書の策定は、レポートがディレクトリまたはメーリングリストの自動メンテナンスに使用される場合、サービス拒否攻撃の機会を提供します。肯定的な報告を策定すると、送信者がそうでないときにメッセージが配信されたと誤って信じることができます。

A signature covering the entire multipart/report structure could be used to prevent such forgeries; such a signature scheme is, however, beyond the scope of this document.

そのような偽造を防ぐために、マルチパート/レポート構造全体をカバーする署名を使用できます。ただし、このような署名スキームは、このドキュメントの範囲を超えています。

4. Normative References

4. 引用文献

[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.

[SMTP] Postel、J。、「Simple Mail Transfer Protocol」、Std 10、RFC 821、1982年8月。

[DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

[DSN] Moore、K。、およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。

[RFC822] Crocker, D., "Standard for the format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.

[RFC822] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。

[MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

[Mime] Borenstein、N。and N. Freed、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。

[DRPT] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 3461, January 2003.

[DRPT]ムーア、K。、「配信ステータス通知のSMTPサービス拡張」、RFC 3461、2003年1月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

Appendix A - Changes from RFC 1892

付録A- RFC 1892から変更

Changed Authors contact information

著者の連絡先情報を変更しました

Updated required standards boilerplate

必要な標準ボイラープレートを更新しました

Edited the text to make it spell-checker and grammar checker compliant

テキストを編集して、それをスペルチェッカーと文法チェッカーに準拠させる

Author's Address

著者の連絡先

Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas Tx, 75214

Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas TX、75214

   Phone: +1 214 823 9325
   EMail: GregV@ieee.org

Full Copyright Statement

完全な著作権声明

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.

このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。