RFC3462 日本語訳
3462 The Multipart/Report Content Type for the Reporting of MailSystem Administrative Messages. G. Vaudreuil. January 2003. (Format: TXT=12186 bytes) (Obsoletes RFC1892) (Updated by RFC5337) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Vaudreuil Request for Comments: 3462 Lucent Technologies Obsoletes: 1892 January 2003 Category: Standards Track
コメントを求めるワーキンググループG.ボードルイの要求をネットワークでつないでください: 3462 ルーセントテクノロジーズは以下を時代遅れにします。 1892 2003年1月のカテゴリ: 標準化過程
The Multipart/Report Content Type
for the Reporting of
Mail System Administrative Messages
メールのシステムの管理メッセージの報告のための複合/レポートcontent type
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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/レポートマルチパーパスインターネットメールエクステンション(MIME)content typeは、どんな種類の電子メールレポートのための一般的な「ファミリー」か「コンテナ」タイプです。 このメモは/がすべての種類のレポートのために配送現状報告、単独の内容タイプが使用されているなら処理プログラムがためになるメールに関するcontent typeを報告するMultipartの使用だけを定義しますが。
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.
このドキュメントは配送現状報告サービスについて説明する1人の4文献集合の一部です。 この収集は、配送現状報告、配送レポートの報告のためのMIME内容、拡張ステータスコードの列挙、および失敗の配送レポート、オリジナルのメッセージ、および人間に優しい概要のための複合コンテナを要求するためにシンプルメールトランスファプロトコル(SMTP)拡大を含んでいます。
Vaudreuil Standards Track [Page 1] RFC 3462 Multipart/Report January 2003
ボードルイ規格はレポート2003年1月にRFC3462の複合/を追跡します[1ページ]。
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
コンベンションを記録してください…2 1. 複合/レポートcontent type…2 2. RFC822テキスト/ヘッダー…4 3. セキュリティ問題…4 4. 標準の参照…5 付録A--RFC1893からの変化…6作者のアドレス…6 完全な著作権宣言文…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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
1. The Multipart/Report Content Type
1. 複合/レポートcontent type
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.
Multipart/レポートMIME content typeは、どんな種類の電子メールレポートのための一般的な「ファミリー」か「コンテナ」タイプです。 このメモはMultipart/の使用だけを定義しますが、すべての種類のレポートにおいて、配送現状報告に関するcontent type、ただ一つのcontent typeがためになるなら処理プログラムがためになるメールが使用されていると報告してください。
The Multipart/Report content-type is defined as follows:
Multipart/レポートcontent typeは以下の通り定義されます:
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「副-タイプ」は以下を命名します。 Requiredパラメタを報告してください: 境界、レポートタイプOptionalパラメタ: なにも、Encoding問題: いつも7ビットは適切なSecurity問題であるべきです: このメモのセクション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/Mixed content typeと同じです。 レポートを送るのに使用されると、Multipart/レポートcontent typeはどんなレポートメッセージのためのトップレベルMIME content typeでなければなりません。 レポート型引数はレポートのタイプを特定します。 パラメタは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.
ユーザエージェントとゲートウェイは、メッセージがメールシステムレポートであることを自動的に決定できなければならなくて、そういうものとして処理されるべきです。 一番はずれの内容が自動プロセッサがRFC822ヘッダーを分析することでそれを検出するかもしれないメカニズムにメッセージを供給するのに応じてMultipart/レポートを置くのは、レポートです。
Vaudreuil Standards Track [Page 2] RFC 3462 Multipart/Report January 2003
ボードルイ規格はレポート2003年1月にRFC3462の複合/を追跡します[2ページ]。
The Multipart/Report content-type contains either two or three sub- parts, in the following order:
Multipart/レポートcontent typeは以下のオーダーに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) [必要です] 最初の身体の部分は人間の読み込み可能なメッセージを含んでいます。 このメッセージの目的はレポートを作った状態の容易に理解されている記述を提供することです、ユーザエージェントをMultipart/レポートの第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標準化過程content type、charset、または言語でも最初のセクションのテキストがあるかもしれません。 誤りの記述が多言語かいくつかのメディアで望まれているところでは、Multipart/代替手段構造物は使用されるかもしれません。
This body part may also be used to send detailed information that cannot be easily formatted into a Message/Report body part.
また、この身体の部分は、容易にMessage/レポート身体の部分にフォーマットできない詳細な情報を送るのに使用されるかもしれません。
(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) 報告されたメッセージハンドリングイベントのアカウントを含む[必要です]マシン「パー-可能」身体の部分。 この身体の部分の目的はレポートを作った状態の機械可読な記述を提供することです、人間の専門家の役に立つかもしれない最初の身体の部分の現在でない詳細と共に。 原始体部分であり、配送Message/状態は[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) 返されたメッセージかそれの部分を含む[任意の]身体の部分。 この情報は、問題を診断する人間の専門家を支援するために役に立つかもしれません。(また、送付者がレポートが発行されたメッセージを特定するのを許容するのも役に立つかもしれませんが、Message/レポート身体の部分で返された封筒イドとオリジナルの受取人アドレスがこのために返された内容の伝統的な使用を取り替えることが望まれています。)
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.
8ビットか7ビットのフォームでコード化されなかったバイナリ・データが返されることであり、リターンパスが8ビットかバイナリーできるために保証されないとき、2つのオプションが利用可能です。 オリジナルのメッセージが法的な7ビットのMIMEメッセージに再コード化されるかもしれませんか、またはText/RFC822-ヘッダーcontent typeは、オリジナルのメッセージヘッダーだけを返すのに使用されるかもしれません。
Vaudreuil Standards Track [Page 3] RFC 3462 Multipart/Report January 2003
ボードルイ規格はレポート2003年1月にRFC3462の複合/を追跡します[3ページ]。
2. The Text/RFC822-Headers content-type
2. Text/RFC822-ヘッダーcontent type
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-ヘッダーMIME content typeは、失敗したメッセージの822個のヘッダーにRFCだけにレッテルを貼って、返すためにメカニズムを提供します。 これらのヘッダーを完全なメッセージでなく、Message/RFC822として返すべきではありません。 返されたヘッダーは失敗したメッセージを特定して、容認された系列に基づく病気の特徴の役に立ちます。
The Text/RFC822-Headers content-type is defined as follows:
Text/RFC822-ヘッダーcontent typeは以下の通り定義されます:
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-ヘッダーRequiredパラメタ: なにも、Optionalパラメタ: なにも、Encoding問題: 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-ヘッダー身体の部分はレポートを引き起こしたメッセージからのすべてのRFC822ヘッダー系列を含むはずです。 RFC822ヘッダーは空白行の前にメッセージですべての系列を入れます。 彼らはMIMEバージョンとMIME Content-ヘッダーを含んでいます。
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.
そのような偽造を防ぐのに全体の複合/レポート構造をカバーする署名は使用できました。 しかしながら、そのような署名体系はこのドキュメントの範囲を超えています。
Vaudreuil Standards Track [Page 4] RFC 3462 Multipart/Report January 2003
ボードルイ規格はレポート2003年1月にRFC3462の複合/を追跡します[4ページ]。
4. Normative References
4. 引用規格
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
[SMTP] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, January
2003.
[DSN] ムーア、K.、およびG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。
[RFC822] Crocker, D., "Standard for the format of ARPA Internet
Text Messages", STD 11, RFC 822, August 1982.
[RFC822] クロッカー、D.、「ARPAインターネットText Messagesの形式の規格」、STD11、RFC822、1982年8月。
[MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[まねます] Borenstein、N.、およびN.フリード、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[DRPT] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC 3461, January 2003.
[DRPT] ムーア、K.、「配送状態通知のためのSMTPサービス拡張子」、RFC3461、2003年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Vaudreuil Standards Track [Page 5] RFC 3462 Multipart/Report January 2003
ボードルイ規格はレポート2003年1月にRFC3462の複合/を追跡します[5ページ]。
Appendix A - Changes from RFC 1892
付録A--RFC1892からの変化
Changed Authors contact information
変えられたAuthors問い合わせ先
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
グレゴリーM.ボードルイルーセントテクノロジーズ7291ウィリアムソンダラス第Tx、75214
Phone: +1 214 823 9325 EMail: GregV@ieee.org
以下に電話をしてください。 +1 9325年の214 823メール: GregV@ieee.org
Vaudreuil Standards Track [Page 6] RFC 3462 Multipart/Report January 2003
ボードルイ規格はレポート2003年1月にRFC3462の複合/を追跡します[6ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Vaudreuil Standards Track [Page 7]
ボードルイ標準化過程[7ページ]
一覧
スポンサーリンク
