RFC3888 日本語訳

Network Working Group                                          T. Hansen
Request for Comments: 3888                             AT&T Laboratories
Category: Informational                                   September 2004

コメントを求めるワーキンググループT.ハンセン要求をネットワークでつないでください: 3888年のAT&T研究所カテゴリ: 情報の2004年9月

                Message Tracking Model and Requirements

メッセージの追跡モデルと要件

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).

Copyright(C)インターネット協会(2004)。

Abstract

要約

   Customers buying enterprise message systems often ask: Can I track
   the messages?  Message tracking is the ability to find out the path
   that a particular message has taken through a messaging system and
   the current routing status of that message.  This document provides a
   model of message tracking that can be used for understanding the
   Internet-wide message infrastructure and to further enhance those
   capabilities to include message tracking, as well as requirements for
   proposed message tracking solutions.

企業メッセージシステムを買う顧客がしばしば尋ねます: 私はメッセージを追跡してもよいですか? メッセージ追跡は特定のメッセージがメッセージシステムを通して取った経路とそのメッセージの現在のルーティング状態を見つける能力です。 このドキュメントはインターネット全体のメッセージインフラストラクチャを理解して、さらにメッセージ追跡を含むそれらの能力を高めるのに使用できるメッセージ追跡のモデルを提供します、提案されたメッセージ追跡解決のための要件と同様に。

1.  Problem Statement

1. 問題声明

   Consider sending a package through a package delivery company.  Once
   you've sent a package, you would like to be able to find out if the
   package has been delivered or not, and if not, where that package
   currently is and what its status is.  Note that the status of a
   package may not include whether it was delivered to its addressee,
   but just the destination.  Many package carriers provide such
   services today, often via a web interface.

パッケージ運送会社を通して小包を送ると考えてください。 そして、いったん小包を送ると、あなたが、パッケージが提供されたかどうか見つけたがっている、そうでなければ、現在、そのパッケージはどこにあるか、そして、状態は何ですか? パッケージの状態が、それがしかし、受け取り人、まさしく送付先に提供されたかどうかを含まないかもしれないことに注意してください。 多くのパッケージキャリヤーが今日、しばしばウェブインタフェースを通してそのようなサービスを提供します。

   Message tracking extends that capability to the Internet-wide message
   infrastructure, analogous to the service provided by package
   carriers:  the ability to quickly locate where a message (package)
   is, and to determine whether or not the message (package) has been
   delivered to its final destination.  An Internet-standard approach
   will allow the development of message tracking applications that can
   operate in a multi-vendor messaging environment, and will encourage
   the operation of the function across administrative boundaries.

メッセージ追跡はパッケージキャリヤーによって提供されたサービスへの類似のインターネット全体のメッセージインフラストラクチャへのその能力を広げています: メッセージ(パッケージ)が最終的な送付先に提供されたかどうかメッセージ(パッケージ)があるところですぐに場所を見つけて、決定する能力。 インターネット標準アプローチは、マルチベンダメッセージング環境で作動できるメッセージ追跡アプリケーションの開発を許して、管理境界の向こう側に機能の操作を奨励するでしょう。

Hansen                       Informational                      [Page 1]

RFC 3888        Message Tracking Model and Requirements   September 2004

2004年9月にモデルと要件を追跡するハンセン情報[1ページ]のRFC3888Message

   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
   [RFC-KEYWORDS].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14、RFC2119[RFC-キーワード]で説明されるように本書では解釈されることであるべきですか?

2.  Definitions

2. 定義

   The following terms are relevant to message tracking.  The terms
   Tracking User Agent and Tracking Server are new, while all other
   terms have been collected here from other sources.

次の用語はメッセージ追跡に関連しています。 用語Tracking UserエージェントとTracking Serverは新しいです、他のすべての用語を他のソースからここに集めてありますが。

   Originating Mail User Agent (MUA)
             The originating mail user agent is the software used to
             compose and originate a message.  It is the software
             sitting on a person's desktop.

メール・ユーザー・エージェント(MUA)を溯源して、起因しているメールユーザエージェントはメッセージを構成して、溯源するのに使用されるソフトウェアです。 それは人のデスクトップの上にあるソフトウェアです。

   Originating Mail Submission Agent (MSA)
             The Mail Submission Agent accepts a message from a User
             Agent, adds or modifies it as required for Internet
             standards and/or site policy, and injects the message into
             the network.  The MSA may be the initial MTA or may hand
             off the message to an MTA.

メールSubmissionエージェント(MSA)を溯源して、メールSubmissionエージェントは、Userエージェントからメッセージを受け入れて、インターネット標準、そして/または、サイト方針のために必要に応じてそれを加えるか、または変更して、ネットワークにメッセージを注ぎます。 または、MSAが初期のMTAであるかもしれない、ハンドオフ、MTAへのメッセージであるかもしれない。

   Message Transfer Agent (MTA)
             A Message Transfer Agent accepts a message and moves it
             forward towards its destination.  That destination may be
             local or reached via another MTA.  It may use a local queue
             to store the message before transferring it further.  Any
             MTA may generate a Non-Delivery Notification.

Message Transferエージェントがメッセージを受け入れて、目的地に向かってそれを前方へ動かせるというメッセージTransferエージェント(MTA。) その目的地は、地方か別のMTAを通して達するかもしれません。 それは、さらにそれを移す前にメッセージを保存するのに地方の待ち行列を使用するかもしれません。 どんなMTAもNon-配送Notificationを生成するかもしれません。

   Intermediate Message Transfer Agent (MTA)
             An Intermediate MTA is an MTA that accepts a message for
             transfer somewhere else.

中間的Message Transferエージェント、(MTA) Intermediate MTAは他のどこかで転送へのメッセージを受け入れるMTAです。

   Final Message Transfer Agent (MTA)
             A Final MTA is an MTA that accepts a message for local
             delivery.  It is the final place that a message is
             accepted.  The final MTA is what sends any Delivery Status
             Notifications (DSNs).  (Intermediate MTA's may also send a
             DSN if it relays to a non-DSN aware MTA.)

最終的なMessage Transferエージェント(MTA)A Final MTAは地方の配送へのメッセージを受け入れるMTAです。 それはそのaメッセージが受け入れられる最終的な場所です。 最終的なMTAはどんなDelivery Status Notifications(DSNs)も送るものです。 (また、それが非DSNに意識しているMTAをリレーするなら、中間的MTAのものはDSNを送るかもしれません。)

   Foreign Message Transfer Agent
             A foreign MTA provides delivery of messages using other
             protocols than those specified for Internet mail, such as
             an X.400 mail system.

外国人のMessage TransferエージェントAの外国MTAはインターネット・メールに指定されたもの以外のプロトコルを使用することでメッセージの配送を提供します、X.400メールシステムのように。

Hansen                       Informational                      [Page 2]

RFC 3888        Message Tracking Model and Requirements   September 2004

2004年9月にモデルと要件を追跡するハンセン情報[2ページ]のRFC3888Message

   Gateway Message Transfer Agent (GW-MTA)
             A gateway MTA accepts a message for transfer to a foreign
             MTA outside of the Internet protocol space.

ゲートウェイMTAがメッセージを受け入れるゲートウェイMessage Transferエージェント(GW-MTA)はインターネットプロトコルスペースの外で外国MTAに移します。

   Local Delivery Agent (LDA)
             The local Delivery Agent delivers the message to the local
             message store.  (The MTA and LDA are often combined into
             the same program.)

地元のDeliveryエージェント(LDA)地元のDeliveryエージェントは地方のメッセージ店にメッセージを提供します。 (MTAとLDAはしばしば同じプログラムに結合されます。)

   Delivery Status Notification (DSN)
             A Delivery Status Notification [RFC-DSN] is produced by an
             MTA when a message is unsuccessfully delivered, either to
             its next hop or the final message store, or when it is
             successfully delivered, either to a foreign MTA, to a local
             delivery agent, or a non-DSN aware MTA.  Positive
             notifications are only performed [RFC-ESMTP-DSN] when
             specifically requested.

メッセージが次のホップか最終的なメッセージ店に提供されるか、失敗したまたはそれが首尾よく提供されるとき、配送Status Notification(DSN)A Delivery Status Notification[RFC-DSN]はMTAによって生産されます、地方の新聞販売店への外国MTA、または非DSNの意識しているMTAに。 明確に要求されると、積極的な通知は実行されるだけです[RFC-ESMTP-DSN]。

   Non-Delivery Notification (NDN)
             A non-delivery notification is a special form of DSN
             indicating unsuccessful delivery.

非配送Notification(NDN)A非配送通知は失敗の配送を示すDSNの特別なフォームです。

   Message Disposition Notification (MDN)
             A Message Disposition Notification is used to report the
             disposition of a message after it has been successfully
             delivered to a recipient.

Message Disposition Notificationがそれの後にメッセージの気質を報告するのに使用されるというメッセージDisposition Notification(MDN)は首尾よく受取人に提供されました。

   Tracking User Agent (TUA)
             A tracking user agent wants to find information on a
             message on the behalf of a user.  It is the requestor or
             initiator of such a request.  (The MUA and TUA could be
             combined into the same program.)

Userエージェント(TUA)を追跡して、追跡ユーザエージェントはユーザに代わってメッセージの情報を見つけたがっています。 それは、そのような要求の要請者か創始者です。 (MUAとTUAを同じプログラムに結合できました。)

   Tracking Server
             A tracking server provides tracking information to a
             tracking client.  It is the repository of the information
             about a message for the traversal through a particular MTA.
             (The tracking server and MTA may run on the same system.)

サーバを追跡する追跡Server Aが追跡情報を追跡クライアントに提供します。 それは特定のMTAを通した縦断へのメッセージの情報の倉庫です。 (追跡サーバとMTAは同じシステムで動くかもしれません。)

3.  Entities

3. 実体

   The entities involved in message tracking are: message user agents,
   message submission agents, message transfer agents, tracking user
   agents and tracking servers.

メッセージ追跡にかかわる実体は以下の通りです。 メッセージユーザエージェント、メッセージ服従エージェント、メッセージ転送エージェント、追跡ユーザエージェント、および追跡サーバ。

Hansen                       Informational                      [Page 3]

RFC 3888        Message Tracking Model and Requirements   September 2004

2004年9月にモデルと要件を追跡するハンセン情報[3ページ]のRFC3888Message

4.  Requirements

4. 要件

   These are requirements that any message tracking solution must be
   able to satisfy:

これらはどんなメッセージの追跡解決も満足させることができなければならないという要件です:

   The message tracking solution:

メッセージの追跡解決:

   **   MUST scale to the internet.

** インターネットに比例しなければなりません。

   **   MUST be easy to deploy.

** 配布するのは簡単にするに違いなくなってください。

   **   SHOULD maximize the reuse of existing, already deployed
        technology and infrastructure.

** SHOULDは存在、既に配布している技術、およびインフラストラクチャの再利用を最大にします。

   **   If possible, SHOULD extend existing protocols and not invent new
        ones.

** できれば、SHOULDは既存のプロトコルを広げていて、新しいものを発明しません。

   **   SHOULD have a low implementation cost.  (This makes it easy to
        incorporate into existing products.)

** SHOULDには、低い実装費用があります。 (これで、既存の製品に盛込むのは簡単になります。)

   **   MUST restrict tracking of a message to the originator of the
        message (or a delegate).

** メッセージの追跡をメッセージ(または、代表)の創始者に制限しなければなりません。

   **   MUST be able to do authentication.

** 認証できなければならなくなってください。

   **   MAY allow an originator to delegate this responsibility to a
        third party.

** 創始者がこの責任を第三者へ代表として派遣するのを許容するかもしれません。

   **   SHOULD have the property that they would allow per-message
        delegation of the tracking responsibility.

** SHOULDには、彼らが追跡責任の1メッセージあたりの委譲を許す特性があります。

   **   MUST require a tracking user agent to prove that they are
        permitted to request the tracking information.

** 追跡ユーザエージェントが、彼らが追跡情報を要求することが許可されていると立証するのが必要でなければなりません。

   **   MUST be able to uniquely identify messages.

** 唯一メッセージを特定できなければならなくなってください。

   **   MUST require every message to have unique identification.

** ユニークな識別を持つあらゆるメッセージを必要としなければなりません。

5.  Interaction Models

5. 相互作用モデル

   There are several models by which tracking of messages can be
   enabled, by which messages can be tracked, and by which information
   can be requested and gathered.

情報をどのメッセージを追跡できるかによってメッセージの追跡を可能にすることができて、要求されていて、集めることができる数個のモデルが、あります。

Hansen                       Informational                      [Page 4]

RFC 3888        Message Tracking Model and Requirements   September 2004

2004年9月にモデルと要件を追跡するハンセン情報[4ページ]のRFC3888Message

5.1.  Tracking Enabling Models

5.1. モデルを可能にする追跡

   Either the envelope or message header must contain enough information
   to track a message and securely retrieve information about the
   message.  Any message that does not have enough information to track
   it is by definition not trackable.

封筒かメッセージヘッダーがメッセージを追跡して、しっかりとメッセージの情報を検索できるくらいの情報を含まなければなりません。 それを追跡できるくらいの情報がないどんなメッセージも定義上「道-可能」ではありません。

   If there is not enough information available in current standard
   envelopes or message headers, then the current standards will need to
   be extended.  Either the MUA or MSA must determine the additional
   information and enable the tracking by adding the additional
   information to either the envelope or header.

現在の標準の封筒かメッセージヘッダーで利用可能な十分な情報がないと、現在の規格は、広げられる必要があるでしょう。 MUAかMSAのどちらかが、封筒かヘッダーに追加情報を加えることによって、追加情報を決定して、追跡を可能にしなければなりません。

   This leads to two tracking enabling models: passive enabling and
   active enabling.

これは2つの追跡可能なモデルに通じます: 受け身の可能でアクティブな可能にすること。

5.1.1.  Passive Enabling Model

5.1.1. 受け身の可能なモデル

   The "passive enabling" model assumes that there is sufficient
   information available.  No UA or MSA interaction occurs to turn
   tracking on; it is on by default.

「受動態可能な」モデルは、利用可能な十分な情報があると仮定します。 どんなUAもMSA相互作用も追跡をつけるために現れません。 それはデフォルトでオンです。

5.1.2.  Active Enabling Model

5.1.2. 活発な可能なモデル

   The "active enabling" model requires that the MUA and MSA exchange
   information when the message is submitted.  This exchange indicates
   that logging of the message's traversal should be performed, as well
   as providing enough additional information to allow the message to be
   tracked.  This information will need to be passed on to subsequent
   MTAs as needed.

「アクティブな可能にする」モデルは、MUAとMSAがいつメッセージを提出するかという情報を交換するのを必要とします。 この交換は、追跡されるべきメッセージは許容できるくらいの追加情報を提供することと同様にメッセージの縦断の伐採が実行されるべきであるのを示します。 この情報は、必要であるようにその後のMTAsに通過される必要があるでしょう。

5.2.  Tracking Request Models

5.2. 追跡要求モデル

   There are several models by which tracking information may be
   requested.

追跡情報が要求されているかもしれない数個のモデルがあります。

5.2.1.  Passive Request Model

5.2.1. 受け身の要求モデル

   The "passive request" model requires active enabling to indicate that
   some form of tracking is to be performed.  The tracking information
   can be sent back immediately (as a form of telemetry) or sent to a
   3rd party for later retrieval.

「受け身の要求」モデルは、何らかのフォームの追跡が実行されることであることを示すためにアクティブな可能にすることを必要とします。 追跡情報をすぐに(遠隔測定法のフォームとして)、戻るか、または後の検索のために3番目のパーティーに送ることができます。

Hansen                       Informational                      [Page 5]

RFC 3888        Message Tracking Model and Requirements   September 2004

2004年9月にモデルと要件を追跡するハンセン情報[5ページ]のRFC3888Message

5.2.2.  Passive Request Tracking Information

5.2.2. 受け身の要求追跡情報

   Forms of passive tracking information that could potentially be
   requested are as follows.  Note that mechanisms already exist for
   requesting the information marked with a (+).  The references for
   such mechanisms are listed at the end of each such entry.

潜在的に要求できた受け身の追跡情報のフォームは以下の通りです。 メカニズムが(+)でマークされた情報を要求するために既に存在することに注意してください。 そのようなメカニズムの参照はそのようなそれぞれのエントリーの端のときにリストアップされます。

   **   send a DSN of a message arriving at an intermediate MTA

** メッセージのDSNに中間的MTAに到着させてください。

   **   (+) send a DSN of a message being rejected while at an
        intermediate MTA [RFC-DSN]

** (+) 中間的MTAにある間、メッセージのDSNを拒絶させてください。[RFC-DSN]

   **   (+) send a DSN of a message leaving an intermediate MTA and
        going to another MTA [RFC-DELIVER-BY]

** (+) メッセージのDSNが中間的MTAを残して、別のMTAに行くのを送ってください。[RFCは配送しています]です。

   **   send a DSN of a message arriving at a final MTA

** メッセージのDSNに最終的なMTAに到着させてください。

   **   (+) send a DSN of a message being rejected while at a final MTA
        [RFC-DSN]

** (+) 最終的なMTAにある間、メッセージのDSNを拒絶させてください。[RFC-DSN]

   **   (+) send a DSN of a message being delivered to a user's message
        store [RFC-DSN]

** (+) ユーザのメッセージ店にメッセージのDSNを提供させてください。[RFC-DSN]

   **   (+) send a DSN of a message being delivered to a foreign MTA
        [RFC-DSN]

** (+) メッセージのDSNを外国MTAに提供させてください。[RFC-DSN]

   **   (+) send an MDN of a message being read by an end user [RFC-MDN]

** (+) エンドユーザにメッセージのMDNを読ませてください。[RFC-MDN]

5.3.  Active Request Model

5.3. 活発な要求モデル

   The "active request" model requires an active query by a user's user
   agent to the MSA, intermediate MTAs and final MTA, or to a third
   party, to find the message's status as known by that MTA.  Active
   request will work with either passive enabling or active enabling.

「活発な要求」モデルはユーザのMSA、中間的MTAs、および最終的なMTA、または第三者のユーザエージェントによる活発な質問を必要とします、掘り出し物に。そのMTAによる知られるとしてのメッセージの状態。 活発な要求は受け身の可能にするかアクティブな可能にどちらかで働くでしょう。

5.3.1.  Server Chaining vs. Server Referrals

5.3.1. サーバ推論対サーバ紹介

   When a tracking server has been asked for tracking information, and
   the message has been passed on to another MTA of which this tracking
   server has no tracking knowledge, there are two modelling choices:

追跡サーバに追跡情報を求めて、この追跡サーバが追跡知識を全く持っていない別のMTAにメッセージを通過したとき、2つのモデル化選択があります:

   **   the first tracking server will contact the next tracking server
        to query for status and pass back the combined status (server
        chaining), or

** または最初の追跡サーバが結合した状態(サーバ推論)について状態とパス後部に質問するために次の追跡サーバに連絡する。

   **   the first tracking server will return the address of the next
        MTA and the tracking client has the responsibility of contacting
        the next tracking server (server referrals).

** 最初の追跡サーバは次のMTAのアドレスを返すでしょう、そして、追跡クライアントには、次の追跡サーバ(サーバ紹介)に連絡する責任があります。

Hansen                       Informational                      [Page 6]

RFC 3888        Message Tracking Model and Requirements   September 2004

2004年9月にモデルと要件を追跡するハンセン情報[6ページ]のRFC3888Message

5.3.2.  Active Request Tracking Information

5.3.2. アクティブな要求追跡情報

   Forms of active tracking information that could potentially be
   requested are as follows.  (Note that no mechanisms currently exist
   for requesting such information.)

潜在的に要求できたアクティブな追跡情報のフォームは以下の通りです。 (メカニズムが全く現在そのような情報を要求するために存在しないことに注意してください。)

   **   the message has been queued for later delivery

** 後の配送のためにメッセージを列に並ばせてあります。

   **   the message was delivered locally

** メッセージは局所的に提供されました。

   **   the message was delivered to another MTA,

** メッセージは別のMTAに提供されました。

   **   the message was delivered to a foreign MTA

** メッセージは外国MTAに提供されました。

   **   ask a different tracking server,

** 異なった追跡サーバを尋ねてください。

   **   I know but can't tell you,

** 私は、知っていますが、あなたに言うことができません。

   **   I don't know.

** 私は知りません。

5.4.  Combining DSN and MDN Information with Message Tracking
      Information

5.4. DSNとMDN情報をメッセージの追跡情報に結合します。

   The information that would be retrieved by message tracking and the
   information that is returned for DSN and MDN requests all attempt to
   answer the question of "what happened to message XX"?  The
   information provided by each is complimentary in nature, but similar.
   A tracking user agent could use all three possible information
   sources  to present a total view of the status of a message.

メッセージ追跡、DSNのために返される情報、および答えるすべてが「メッセージXXに起こったこと」に関する質問を試みるMDN要求で検索される情報? それぞれによって提供された情報は、現実に賞賛ですが、同様です。 追跡ユーザエージェントは、メッセージの状態の総視点を提示するのにすべての3つの可能な情報源を使用できました。

   Both DSN and MDN notifications utilize the formats defined by RFC
   3462 [RFC-REPORT].  This suggests that the information returned by
   message tracking solutions should also be similar.

DSNとMDN通知の両方がRFC3462[RFC-REPORT]によって定義された書式を利用します。 これは、また、メッセージの追跡解決によって返された情報も同様であるべきであると示唆します。

6.  Security Considerations

6. セキュリティ問題

6.1.  Security Considerations Summary

6.1. セキュリティ問題概要

   Security vulnerabilities are detailed in [RFC-MTRK-ESMTP], [RFC-
   MTRK-TSN] and [RFC-MTRK-MTQP].  These considerations include:

セキュリティの脆弱性は[RFC-MTRK-ESMTP]、[RFC- MTRK-TSN]、および[RFC-MTRK-MTQP]で詳細です。 これらの問題は:

   **   vulnerability to snooping or replay attacks when using
        unencrypted sessions

** 使用するとき、詮索か反射攻撃への脆弱性はセッションを非暗号化しました。

   **   a dependency on the randomness of the per-message secret

** 1メッセージあたりの秘密の偶発性に関する依存

   **   reliance on TLS

** TLSへの信用

Hansen                       Informational                      [Page 7]

RFC 3888        Message Tracking Model and Requirements   September 2004

2004年9月にモデルと要件を追跡するハンセン情報[7ページ]のRFC3888Message

   **   man-in-the-middle attacks

** 介入者攻撃

   **   reliance on the server maintaining the security level when it
        performs chaining

** 推論を実行するときセキュリティー・レベルを維持するサーバへの信用

   **   denial of service

** サービスの否定

   **   confidentiality concerns

** 機密保持の懸念

   **   forgery by malicious servers

** 悪意があるサーバによる偽造

6.2.  Message Identification and Authentication

6.2. メッセージ識別と認証

   This is a security model for message identification and
   authentication that could be deployed.  (There may be others.)

これは配布することができたメッセージ識別と認証のための機密保護モデルです。 (他のものがいるかもしれません。)

   A Tracking User Agent must prove that they are permitted to request
   tracking information about a message.  Every [RFC-822]-compliant
   message is supposed to contain a Message-Id header.  One possible
   mechanism is for the originator to calculate a one-way hash A from
   the message ID + time stamp + a per-user secret.  The user then
   calculates another one-way hash B to be the hash of A.  The user
   includes B in the submitted message, and retains A.  Later, when the
   user makes a message tracking request to the messaging system or
   tracking entity, it submits A in the tracking request.  The entity
   receiving the tracking request then uses A to calculate B, since it
   was already provided B, verifying that the requestor is authentic.
   In summary,

Tracking Userエージェントは、彼らがメッセージの追跡情報を要求することが許可されていると立証しなければなりません。 あらゆる[RFC-822]対応するメッセージがMessage-イドヘッダーを含むべきです。 1台の可能なメカニズムは創始者が、メッセージID+時間からの一方向ハッシュAが+ 1ユーザあたり1つの秘密をスタンプで押すと見込むことです。 次に、ユーザは、A. ユーザのハッシュである別の一方向ハッシュBが提出されたメッセージにBを含んで、A.Laterを保有すると見込みます、ユーザがメッセージの追跡要求をメッセージシステムか追跡実体にするとそれは追跡要求におけるAを提出します。 次に、追跡要求を受け取る実体はBについて計算するのにAを使用します、既にBをそれに提供したので、要請者が正統であることを確かめて。 概要で

      A = H(message ID + time stamp + secret)

=H(メッセージID+タイムスタンプ+秘密)です。

      B = H(A)

BはHと等しいです。(A)

   Another possible mechanism for A is to ignore the message ID and time
   stamp and just use a one-way hash from a large (>128 bits) random
   number.  B would be calculated as before.  In summary,

Aのための別の可能なメカニズムは、メッセージIDとタイムスタンプを無視して、大きい(>128ビット)乱数から一方向ハッシュをただ使用することです。 Bは従来と同様計算されるでしょう。 概要で

      A = H(large-random-number)

=H(大きい乱数)

      B = H(A)

BはHと等しいです。(A)

   This is similar in technique to the methods used for One-Time
   Passwords [RFC-OTP].  The success of these techniques is dependent on
   the randomness of the per-user secret or the large random number,
   which can be incredibly difficult in some environments.

これはOne-時間Passwords[RFC-OTP]に使用されるメソッドへのテクニックにおいて同様です。 これらのテクニックの成功は1ユーザあたりの秘密の偶発性か大きい乱数に依存しています。乱数はいくつかの環境で信じられないほど難しい場合があります。

Hansen                       Informational                      [Page 8]

RFC 3888        Message Tracking Model and Requirements   September 2004

2004年9月にモデルと要件を追跡するハンセン情報[8ページ]のRFC3888Message

   If the originator of a message were to delegate his or her tracking
   request to a third party by sending it A, this would be vulnerable to
   snooping over unencrypted sessions.  The user can decide on a
   message-by-message basis if this risk is acceptable.

メッセージの創始者がAをそれに送ることによってその人の追跡要求を第三者へ代表として派遣するなら、これは非暗号化されたセッションの間、詮索するのに被害を受け易いでしょうに。 このリスクが許容できるなら、ユーザはメッセージごとの基礎を決めることができます。

7.  Informational References

7. 情報の参照

   [RFC-822]          Crocker, D., "Standard for the format of ARPA
                      Internet text messages", STD 11, RFC 822, August
                      1982.

[RFC-822] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。

   [RFC-DELIVER-BY]   Newman, D., "Deliver By SMTP Service Extension",
                      RFC 2852, June 2000.

2000年6月のニューマン、D.、[RFCは配送しています]の「SMTPサービス拡張子で、配送してください」RFC2852。

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

[RFC-DSN] ムーア、K.、およびG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。

   [RFC-ESMTP-DSN]    Moore, K., "Simple Mail Transfer Protocol (SMTP)
                      Service Extension for Delivery Status
                      Notifications (DSNs)", RFC 3461, January 2003.

[RFC-ESMTP-DSN]ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。

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

[RFC-KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC-MDN]          Hansen, T. and G. Vaudreuil, Eds., "Message
                      Disposition Notifications", RFC 3798, May 2004.

[RFC-MDN] ハンセンとT.とG.ボードルイ、Eds、「メッセージ気質通知」、RFC3798、5月2004日

   [RFC-OTP]          Haller, N., Metz, C., Nesser, P. and M. Straw, "A
                      One-Time Password System", STD 61, RFC 2289,
                      February 1998.

[RFC-OTP] ハラーとN.とメスとC.とNesserとP.とM.わら、「A One-時間パスワードシステム」、STD61、RFC2289、1998年2月。

   [RFC-REPORT]       Vaudreuil, G., "The Multipart/Report Content Type
                      for the Reporting of Mail System Administrative
                      Messages", RFC 3462, January 2003.

ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポートcontent type」という[RFC-レポート]、RFC3462、2003年1月。

   [RFC-MTRK-ESMTP]   Allman, E. and T. Hansen, "SMTP Service Extension
                      for Message Tracking", RFC 3885, September 2004.

[RFC-MTRK-ESMTP] オールマンとE.とT.ハンセン、「メッセージ追跡のためのSMTPサービス拡張子」、RFC3885、2004年9月。

   [RFC-MTRK-TSN]     Allman, E., "The Message/Tracking-Status MIME
                      Extension", RFC 3886, September 2004.

[RFC-MTRK-TSN] オールマン、E.、「追跡メッセージ/状態MIME拡大」、RFC3886、2004年9月。

   [RFC-MTRK-MTQP]    Hansen, T., "Message Tracking Query Protocol", RFC
                      3887, September 2004.

[RFC-MTRK-MTQP] ハンセン、T.、「メッセージの追跡質問プロトコル」、RFC3887、2004年9月。

Hansen                       Informational                      [Page 9]

RFC 3888        Message Tracking Model and Requirements   September 2004

2004年9月にモデルと要件を追跡するハンセン情報[9ページ]のRFC3888Message

8.  Acknowledgements

8. 承認

   This document is the product of input from many people and many
   sources, including all of the members of the Message Tracking Working
   Group: Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris Newman,
   and Gregory Neil Shapiro.  It owes much to earlier work by Gordon
   Jones, Bruce Ernst, and Greg Vaudreuil.  In particular, I'd like to
   also thank Ken Lin for his considerable contributions to the early
   versions of the document.

このドキュメントはMessage Tracking作業部会のメンバーのすべてを含む多くの人々と多くのソースからの入力の成果です: フィリップ・ヘイゼル、Alexeyメリニコフ、リンドン・ネーレンバーグ、クリス・ニューマン、およびグレゴリー・ニール・シャピロ。 それはゴードン・ジョーンズ、ブルース・エルンスト、およびグレッグ・ボードルイによる以前の仕事から多くを借りています。 また、特に、ドキュメントの早めのバージョンへの彼の多大なる貢献についてケン・リンに感謝申し上げます。

9.  Author's Address

9. 作者のアドレス

   Tony Hansen
   AT&T Laboratories
   Middletown, NJ 07748
   USA

トニーハンセンAT&T研究所Middletown、ニュージャージー07748米国

   Phone: +1.732.420.8934
   EMail: tony+msgtrk@maillennium.att.com

以下に電話をしてください。 +1.732 .420 .8934 メール: しゃれた+ msgtrk@maillennium.att.com

Hansen                       Informational                     [Page 10]

RFC 3888        Message Tracking Model and Requirements   September 2004

2004年9月にモデルと要件を追跡するハンセン情報[10ページ]のRFC3888Message

10. Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

Copyright(C)インターネット協会(2004)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Hansen                       Informational                     [Page 11]

ハンセンInformationalです。[11ページ]