RFC1892 日本語訳

Network Working Group                                       G. Vaudreuil
Request for Comments: 1892                        Octel Network Services
Category: Standards Track                                   January 1996

コメントを求めるワーキンググループG.ボードルイの要求をネットワークでつないでください: 1892年のOctelネットワーク・サービスカテゴリ: 標準化過程1996年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)の現行版を参照してください。 このメモの分配は無制限です。

1. The Multipart/Report MIME content-type

1. Multipart/レポートMIME 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 4 of this memo.

MIMEの種類名: 複合MIME「副-タイプ」は以下を命名します。 Requiredパラメタを報告してください: 境界、レポートタイプOptionalパラメタ: なにも、Encoding問題: いつも7ビットは適切なSecurity問題であるべきです: このメモのセクション4を見てください。

   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 1]

RFC 1892                    Multipart/Report                January 1996

ボードルイ規格はレポート1996年1月にRFC1892の複合/を追跡します[1ページ]。

   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 an 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) which 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 which generated the delivery service
   report should return the full message content.

内容の復帰はネットワーク回線容量で無駄であるかもしれません、そして、さまざまな実装戦略は使用できます。 一般に送付者は、必要である返された内容の必要なレベルについて適切な戦略を選んで、受取人に知らせるべきです。 [DRPT]、エージェントに提供されたそれなどの内容の復帰のレベルを求める明白な要求がないとき、どれがデリバリ・サービスレポートを作ったかが完全なメッセージ内容を返すべきです。

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

7ビットでコード化されなかったデータが返されることであり、リターンパスが8ビットできるために保証されないとき、2つのオプションが利用可能です。 origionalメッセージが7ビットの法的なMIMEメッセージに再コード化されるかもしれませんか、またはText/RFC822-ヘッダーcontent typeは、origionalメッセージヘッダーだけを返すのに使用されるかもしれません。

Vaudreuil                   Standards Track                     [Page 2]

RFC 1892                    Multipart/Report                January 1996

ボードルイ規格はレポート1996年1月にRFC1892の複合/を追跡します[2ページ]。

2. The Text/RFC822-Headers MIME content-type

2. Text/RFC822-ヘッダーMIME 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, they may be encoded in quoted-printable.
          Security considerations: see section 4 of this memo.

MIMEの種類名: テキストMIME「副-タイプ」は以下を命名します。 RFC822-ヘッダーRequiredパラメタ: なにも、Optionalパラメタ: なにも、Encoding問題: 7ビットが普通のRFC822ヘッダーに十分である、しかしながら、ヘッダーが、壊れて、コード化するのを必要とするなら、彼らは引用されて印刷可能でコード化されるかもしれません。 セキュリティ問題: このメモのセクション4を見てください。

   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. References

3. 参照

   [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
       Delivery Status Notifications", RFC 1894, University of
       Tennessee, Octel Network Services, January 1996.

[DSN] ムーア、K.、およびG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC1894、テネシー大学、Octelはサービス(1996年1月)をネットワークでつなぎます。

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

[RFC822] クロッカー、D.、「ARPAインターネットText Messagesの形式の規格」、STD11、RFC822、UDEL、1982年8月。

   [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
       Extensions", RFC 1521, Bellcore, Innosoft, June 1992.

[まねます] Borenstein、N.と解放されたN.、「マルチパーパスインターネットメールエクステンション」、RFC1521、Bellcore、Innosoft、1992年6月。

   [DRPT] Moore, K., "SMTP Service Extension for Delivery Status
       Notifications", RFC 1891, University of Tennessee, January 1996.

[DRPT] ムーア、K.、「配送状態通知のためのSMTPサービス拡張子」、RFC1891、テネシー大学、1996年1月。

4. Security Considerations

4. セキュリティ問題

   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.

認証のないレポートタイプの自動化された使用はいくつかの安全保障問題を提示します。 レポートがディレクトリかメーリングリストの自動化されたメインテナンスに使用されるとき、否定的な報告を偽造すると、サービス不能攻撃の機会は提示されます。 それが信じていなかったとき、積極的なレポートを偽造するのに、送付者は、メッセージが提供されたと不当に信じるかもしれません。

Vaudreuil                   Standards Track                     [Page 3]

RFC 1892                    Multipart/Report                January 1996

ボードルイ規格はレポート1996年1月にRFC1892の複合/を追跡します[3ページ]。

5. Author's Address

5. 作者のアドレス

   Gregory M. Vaudreuil
   Octel Network Services
   17060 Dallas Parkway
   Dallas, TX 75248-1905

ダラスParkwayダラス、グレゴリーM.ボードルイのOctelネットワーク・サービス17060テキサス75248-1905

   Phone: +1-214-733-2722
   EMail: Greg.Vaudreuil@Octel.com

以下に電話をしてください。 +1-214-733-2722 メールしてください: Greg.Vaudreuil@Octel.com

Vaudreuil                   Standards Track                     [Page 4]

ボードルイ標準化過程[4ページ]