RFC3887 日本語訳
3887 Message Tracking Query Protocol. T. Hansen. September 2004. (Format: TXT=42763 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Hansen Request for Comments: 3887 AT&T Laboratories Category: Standards Track September 2004
コメントを求めるワーキンググループT.ハンセン要求をネットワークでつないでください: 3887年のAT&T研究所カテゴリ: 標準化過程2004年9月
Message Tracking Query Protocol
メッセージの追跡質問プロトコル
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 (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 describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet.
企業メッセージシステムを買う顧客がしばしば尋ねます: 私はメッセージを追跡してもよいですか? メッセージ追跡は特定のメッセージがメッセージシステムを通して取った経路とそのメッセージの現在のルーティング状態を見つける能力です。 このドキュメントは完全なメッセージ追跡解決法をインターネットに提供するのにESMTPプロトコルへの拡大に関連して使用されるMessage Tracking Queryプロトコルについて説明します。
1. Introduction
1. 序論
The Message Tracking Models and Requirements document [RFC-MTRK-MODEL] discusses the models that message tracking solutions could follow, along with requirements for a message tracking solution that can be used with the Internet-wide message infrastructure. This memo and its companions, [RFC-MTRK-ESMTP] and [RFC-MTRK-TSN], describe a complete message tracking solution that satisfies those requirements. The memo [RFC-MTRK-ESMTP] defines an extension to the SMTP service that provides the information necessary to track messages. This memo defines a protocol that can be used to query the status of messages that have been transmitted on the Internet via SMTP. The memo [RFC-MTRK-TSN] describes the message/tracking-status [RFC-MIME] media type that is used to report tracking status information. Using the model document's terminology, this solution uses active enabling and active requests with both request and chaining referrals.
メッセージの追跡解決がインターネット全体のメッセージインフラストラクチャと共に使用できるメッセージの追跡解決のための要件と共に従うことができたモデルについて議論します[RFC-MTRK-MODEL]Message Tracking ModelsとRequirementsが、ドキュメントである。 このメモとその仲間[RFC-MTRK-ESMTP]と[RFC-MTRK-TSN]は、それらの要件を満たす完全なメッセージ追跡解決について説明します。 メモ[RFC-MTRK-ESMTP]はメッセージを追跡するために必要情報を提供するSMTPサービスと拡大を定義します。 このメモはSMTPを通してインターネットで送られたメッセージの状態について質問するのに使用できるプロトコルを定義します。 メモ[RFC-MTRK-TSN]は状態情報を追跡すると報告するのに使用される追跡メッセージ/状態[RFC-MIME]メディアタイプについて説明します。 モデルドキュメントの用語を使用して、このソリューションは要求と推論紹介の両方がある活発な可能で活発な要求を使用します。
Hansen Standards Track [Page 1] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[1ページ]RFC3887メッセージ
1.1. Terminology
1.1. 用語
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-キーワード]で説明されるように本書では解釈されることであるべきですか?
All syntax descriptions use the ABNF specified by [RFC-ABNF]. Terminal nodes not defined elsewhere in this document are defined in [RFC-ABNF], [RFC-URI], [RFC-MTRK-ESMTP], [RFC-SMTP], or [RFC-SMTPEXT].
すべての構文記述が[RFC-ABNF]によって指定されたABNFを使用します。 ほかの場所で定義されなかった端末のノードは[RFC-ABNF]、[RFC-ユリ]、[RFC-MTRK-ESMTP]、[RFC-SMTP]、または[RFC-SMTPEXT]で本書では定義されます。
2. Basic Operation
2. 基本的な操作
The Message Tracking Query Protocol (MTQP) is similar to many other line-oriented Internet protocols, such as [POP3] and [NNTP]. Initially, the server host starts the MTQP service by listening on TCP port 1038.
Message Tracking Queryプロトコル(MTQP)は[POP3]や[NNTP]などの他の多くの系列指向のインターネットプロトコルと同様です。 初めは、MTQPがTCPで聴くことによって修理するサーバー・ホスト開始は1038を移植します。
When an MTQP client wishes to make use of the message tracking service, it establishes a TCP connection with the server host, as recorded from the initial message submission or as returned by a previous tracking request. To find the server host, the MTQP client first does an SRV lookup for the server host using DNS SRV records, with a service name of "mtqp" and a protocol name of "tcp", as in _mtqp._tcp.smtp3.example.com. (See the "Usage rules" section in [RFC-SRV] for details.) If the SRV records do not exist, the MTQP client then does an address record lookup for the server host. When the connection is established, the MTQP server sends a greeting. The MTQP client and MTQP server then exchange commands and responses (respectively) until the connection is closed or aborted.
MTQPクライアントがメッセージの追跡サービスを利用したがっているとき、サーバー・ホストとのTCP接続を確立します、初期のメッセージ提案か前の追跡要求で返すように記録されるように。 サーバー・ホストを見つけるために、MTQPクライアントは最初にサーバー・ホストのためにDNS SRV記録を使用することでSRVルックアップをします、"mtqp"のサービス名と"tcp"のプロトコル名で、_mtqp_tcp.smtp3.example.comのように。 ([RFC-SRV]で詳細に関して「用法規則」セクションを見てください。) SRV記録が存在していないなら、MTQPクライアントはサーバー・ホストのためにアドレス記録ルックアップをします。 接続が確立されるとき、MTQPサーバは挨拶を送ります。 そして、接続が閉店するか、または中止されるまで、MTQPクライアントとMTQPサーバはコマンドと応答(それぞれ)を交換します。
2.1. Tracking Service DNS Considerations
2.1. 追跡サービスDNS問題
Because of the ways server host lookups are performed, many different tracking server host configurations are supported.
サーバー・ホストルックアップが実行される方法のために、多くの異なった追跡サーバー・ホスト構成がサポートされます。
A mail system that uses a single mail server host and has the MTQP server host on the same server host will most likely have a single MX record pointing at the server host, and if not, will have an address record. Both mail and MTQP clients will access that host directly.
独身のメールサーバー・ホストを使用して、MTQPサーバー・ホストが同じサーバー・ホストの上にいるメールシステムで、独身のMXはたぶんサーバー・ホストを指し示しながら、記録するでしょう、そして、そうでなければ、アドレス記録を持つでしょう。 メールとMTQPクライアントの両方が直接そのホストにアクセスするでしょう。
A mail system that uses a single mail server host, but wants tracking queries to be performed on a different machine, MUST have an SRV MTQP record pointing at that different machine.
独身のメールサーバー・ホストを使用しますが、異なったマシンに追跡質問を実行するのを必要があるメールシステムで、SRV MTQPは、その異なったマシンを指し示しながら、記録しなければなりません。
Hansen Standards Track [Page 2] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[2ページ]RFC3887メッセージ
A mail system that uses multihomed mail servers has two choices for providing tracking services: either all mail servers must be running tracking servers that are able to retrieve information on all messages, or the tracking service must be performed on one (or more) machine(s) that are able to retrieve information on all messages. In the former case, no additional DNS records are needed beyond the MX records already in place for the mail system. In the latter case, SRV MTQP records are needed that point at the machine(s) that are running the tracking service. In both cases, note that the tracking service MUST be able to handle the queries for all messages accepted by that mail system.
「マルチ-家へ帰」っているメールサーバを使用するメールシステムは追跡サービスを提供するための2つの選択を持っています: すべてのメールサーバがすべてのメッセージの情報を検索できる追跡サーバを実行しなければなりませんか、またはすべてのメッセージの情報を検索できる1台(さらに)のマシンに追跡サービスを実行しなければなりません。 前の場合では、MX記録を超えてどんな追加DNS記録も適所で既にメールシステムに必要ではありません。 後者の場合では、追跡サービスを実行しているマシンを指し示すSRV MTQP記録が必要です。 どちらの場合も、追跡サービスがそのメールシステムによって受け入れられたすべてのメッセージのための質問を扱うことができなければならないことに注意してください。
2.2. Commands
2.2. コマンド
Commands in MTQP consist of a case-insensitive keyword, possibly followed by one or more parameters. All commands are terminated by a CRLF pair. Keywords and parameters consist of printable ASCII characters. Keywords and parameters are separated by whitespace (one or more space or tab characters). A command line is limited to 998 characters before the CRLF.
MTQPのコマンドは1つ以上のパラメタがことによるとあとに続いた大文字と小文字を区別しないキーワードから成ります。 すべてのコマンドがCRLF組によって終えられます。 キーワードとパラメタは印刷可能なASCII文字から成ります。 空白(1つ以上のスペースかタブキャラクタ)によってキーワードとパラメタは切り離されます。 コマンドラインはCRLFの前の998のキャラクタに制限されます。
2.3. Responses
2.3. 応答
Responses in MTQP consist of a status indicator that indicates success or failure. Successful commands may also be followed by additional lines of data. All response lines are terminated by a CRLF pair and are limited to 998 characters before the CRLF. There are several status indicators: "+OK" indicates success; "+OK+" indicates a success followed by additional lines of data, a multi- line success response; "-TEMP" indicates a temporary failure; "-ERR" indicates a permanent failure; and "-BAD" indicates a protocol error (such as for unrecognized commands).
MTQPの応答は成否を示す自動運転表示灯から成ります。 また、データの追加系列はうまくいっているコマンドのあとに続くかもしれません。 すべての応答系列が、CRLF組によって終えられて、CRLFの前の998のキャラクタに制限されます。 いくつかの自動運転表示灯があります: 「+OK」は成功を示します。 a成功がデータの追加系列、マルチ系列成功応答で続いた、「+ OK+」が、示す。 "-TEMP"は一時障害を示します。 "-ERR"は永久的な失敗を示します。 そして、「-ひどい」はプロトコル誤り(認識されていないコマンドなどの)を示します。
A status indicator MAY be followed by a series of machine-parsable,
case-insensitive response information giving more data about the
errors. These are separated from the status indicator and each other
by a single slash character ("/", decimal code 47). Following that,
there MAY be white space and a human-readable text message. The
human-readable text message is not intended to be presented to the
end user, but should be appropriate for putting in a log for use in
debugging problems.
誤りに関する、より多くのデータを与えるマシン「パー-可能」であって、大文字と小文字を区別しない応答情報のシリーズは自動運転表示灯のあとに続くかもしれません。 これらは単独のスラッシュキャラクタ(「/」、10進コード47)によって自動運転表示灯と互いと切り離されます。 それに続いて、余白と人間読み込み可能なテキストメッセージがあるかもしれません。 人間読み込み可能なテキストメッセージは、エンドユーザに提示されることを意図しませんが、デバッグ問題における使用のためのログを入れるのに、適切であるべきです。
In a multi-line success response, each subsequent line is terminated
by a CRLF pair and limited to 998 characters before the CRLF. When
all lines of the response have been sent, a final line is sent
consisting of a single period (".", decimal code 046) and a CRLF
pair. If any line of the multi-line response begins with a period,
the line is "dot-stuffed" by prepending the period with a second
マルチ系列成功応答では、それぞれのその後の系列は、CRLF組によって終えられて、CRLFの前の998のキャラクタに制限されます。 応答のすべての系列を送ったとき、最終的な系列をただ一つの期間から成らせる、(「」、10進コード046) そして、CRLF組。 何かマルチ系列応答の系列が期間で始まるなら、系列は、1秒で期間をprependingすることによって、「ドットで、詰められます」。
Hansen Standards Track [Page 3] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[3ページ]RFC3887メッセージ
period. When examining a multi-line response, the client checks to see if the line begins with a period. If so, and octets other than CRLF follow, the first octet of the line (the period) is stripped away. If so, and if CRLF immediately follows the period, then the response from the MTQP server is ended and the line containing the ".CRLF" is not considered part of the multi-line response.
以上。 マルチ系列応答を調べるとき、クライアントは、系列が期間で始まるかどうか確認するためにチェックします。 そうだとすれば、そして、CRLF尾行、遠くの剥取られた系列(期間)の最初の八重奏以外の八重奏。 そうだとすれば、CRLFがすぐに期間に続くなら、MTQPサーバからの応答は終わります、そして、".CRLF"を含む系列はマルチ系列応答の一部であると考えられません。
An MTQP server MUST respond to an unrecognized, unimplemented, or syntactically invalid command by responding with a negative -BAD status indicator. A server MUST respond to a command issued when the session is in an incorrect state by responding with a negative -ERR status indicator.
MTQPサーバは、否定的-BAD自動運転表示灯で応じることによって、認識されていないか、非実装しているか、シンタクス上無効のコマンドに反応しなければなりません。 サーバはセッションが不正確な状態に否定的-ERR自動運転表示灯で応じることによってあるとき発行されたコマンドに反応しなければなりません。
2.4. Firewall Considerations
2.4. ファイアウォール問題
A firewall mail gateway has two choices when receiving a tracking query for a host within its domain: it may return a response to the query that says the message has been passed on, but no further information is available; or it may perform a chaining operation itself, gathering information on the message from the mail hosts behind the firewall, and returning to the MTQP client the information for each behind-the-firewall hop, or possibly just the final hop information, possibly also disguising the names of any hosts behind the firewall. Which option is picked is an administrative decision and is not further mandated by this document.
ファイアウォールメール・ゲートウェイには、ドメインの中のホストのための追跡質問を受けるとき、2つの選択があります: それはメッセージが伝えられたと言う質問への応答を返すかもしれませんが、どんな詳細も利用可能ではありません。 または、推論操作自体を実行するかもしれません、ファイアウォールの後ろにメッセージにメールホストから情報を収集して、ファイアウォールの後ろの各ホップのための情報、またはことによるとまさしく最終的なホップ情報をMTQPクライアントに返して、また、ことによるとファイアウォールの後ろのどんなホストの名前も変装して。 どのオプションが粒選りであるかは、管理的意思決定であり、このドキュメントによってさらに強制されません。
If a server chooses to perform a chaining operation itself, it MUST provide a response within 2 minutes, and SHOULD return a "no further information is available" response if it cannot provide an answer at the end of that time limit.
サーバが、推論操作自体を実行するのを選ぶなら、2分以内に応答を提供しなければなりません、そして、そのタイムリミットの終わりで答えを提供できないなら、SHOULDは「どんな詳細も利用可能でない」という応答を返します。
2.5. Optional Timers
2.5. 任意のタイマ
An MTQP server MAY have an inactivity autologout timer. Such a timer MUST be of at least 10 minutes in duration. The receipt of any command from the client during that interval should suffice to reset the autologout timer. An MTQP server MAY limit the number of commands, unrecognized commands, or total connection time, or MAY use other criteria, to prevent denial of service attacks.
MTQPサーバには、不活発自動ログアウト・タイマーがあるかもしれません。 そのようなタイマは持続時間における少なくとも10分のものであるに違いありません。 その間隔の間のクライアントからのどんなコマンドの領収書も、自動ログアウト・タイマーをリセットするために十分であるはずです。 MTQPサーバは、コマンド、認識されていないコマンド、または総接続時間の数を制限するか、またはサービス不能攻撃を防ぐのに他の評価基準を使用するかもしれません。
An MTQP client MAY have an inactivity autologout timer while waiting for a response from the server. Since an MTQP server may be a firewall, and may be chaining information from other servers, such a timer MUST be at least 2 minutes in duration.
MTQPクライアントはサーバから応答を待っている間、不活発自動ログアウト・タイマーを持っているかもしれません。MTQPサーバがファイアウォールであるかもしれなく、他のサーバからの情報をチェーニングしていることであるかもしれないので、そのようなタイマは持続時間で少なくとも2分でなければなりません。
Hansen Standards Track [Page 4] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[4ページ]RFC3887メッセージ
3. Initialization and Option Response
3. 初期設定とオプション応答
Once the TCP connection has been opened by an MTQP client, the MTQP server issues an initial status response that indicates its readiness. If the status response is positive (+OK or +OK+), the client may proceed with other commands.
TCP接続がMTQPクライアントによっていったん開かれると、MTQPサーバは準備を示す初期の状態応答を発行します。 状態応答が積極的であるなら(+ OKか+ OK+)、クライアントは他のコマンドを続けるかもしれません。
The initial status response MUST include the response information "/MTQP". Negative responses MUST include a reason code as response information. The following reason codes are defined here; unrecognized reason codes added in the future may be treated as equivalent to "unavailable".
「初期の状態応答は応答情報」 /MTQPを含まなければなりません。」 否定応答は応答情報として理由コードを含まなければなりません。 以下の理由コードはここで定義されます。 将来加えられた認識されていない理由コードは「入手できません」と同等物として扱われるかもしれません。
"/" "unavailable"
"/" "admin"
「「/」「入手できません」」/、」 「アドミン」
The reason code "/admin" SHOULD be used when the service is unavailable for administrative reasons. The reason code "/unavailable" SHOULD be used when the service is unavailable for other reasons.
理由は」 」 /アドミンSHOULDをコード化します。「サービスが管理理由を入手できないときに、使用されます。 「理由は」 入手できない/をコード化する」SHOULD、サービスが他の理由を入手できないときには、使用されてください。
If the server has any options enabled, they are listed as the multi- line response of the initial status response, one per line. An option specification consists of an identifier, optionally followed by option-specific parameters. An option specification may be continued onto additional lines by starting the continuation lines with white space. The option identifier is case insensitive. Option identifiers beginning with the characters "vnd." are reserved for vendor use. (See below.)
サーバでどんなオプションも可能にするなら、それらは初期の状態応答(1系列あたり1つ)のマルチ系列応答として記載されます。 オプション仕様はオプション特有のパラメタが任意にあとに続いた識別子から成ります。 オプション仕様は、余白から継続行を始めることによって、追加系列に続けられるかもしれません。 オプション識別子は大文字と小文字を区別しないです。 キャラクタと共に始まるオプション識別子は"vndする"です。. ベンダー使用のために、予約されます。 (以下を見てください。)
One option specification is defined here:
1つのオプション仕様がここで定義されます:
STARTTLS [1*WSP "required"]
STARTTLS[「必要であった」1*WSP]
This capability MUST be listed if the optional STARTTLS command is enabled on the MQTP server and one or more certificates have been properly installed.
任意のSTARTTLSコマンドがMQTPサーバで可能にされるなら、この能力を記載しなければなりません、そして、1通以上の証明書が適切にインストールされました。
It has one optional parameter: the word "required" (The parameters for STARTTLS are case-insensitive). If the server requires that TLS be used for some of the domains the server handles, the server MUST specify the "required" parameter.
それには、1つの任意のパラメタがあります: 単語が「必要である」(STARTTLSのためのパラメタは大文字と小文字を区別しないです)。 サーバが、TLSがサーバが扱うドメインのいくつかに使用されるのを必要とするなら、サーバは「必要な」パラメタを指定しなければなりません。
Hansen Standards Track [Page 5] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[5ページ]RFC3887メッセージ
3.1. Examples
3.1. 例
Example #1 (no options): S: +OK/MTQP MTQP server ready
例#1(オプションがありません): S: +OK/MTQP MTQPサーバ準備ができています。
Example #2 (service temporarily unavailable): S: -TEMP/MTQP/admin Service down for admin, call back later
例#2(一時入手できないサービス): S: -Serviceが後でアドミンのために倒して、戻ると言うTEMP/MTQP/アドミン
Example #3 (service permanently unavailable): S: -ERR/MTQP/unavailable Service down
例#3(永久に入手できないサービス): S: -間違え、下に/MTQP/入手できないサービス
Example #4 (alternative for no options): S: +OK+/MTQP MTQP server ready S: .
例#4(オプションがないのにおける代替の): S: + OK+/MTQP MTQPサーバ持ち合わせのS: .
Example #5 (options available): S: +OK+/MTQP MTQP server ready S: starttls S: vnd.com.example.option2 with parameters private to example.com S: vnd.com.example.option3 with a very long S: list of parameters S: .
例#5(利用可能なオプション): S: + OK+/MTQP MTQPサーバ持ち合わせのS: starttls S: example.com Sに個人的なパラメタがあるvnd.com.example.option2: 非常に長いSがあるvnd.com.example.option3: パラメタSのリスト: .
4. TRACK Command
4. 道のコマンド
Syntax:
構文:
track-command = "TRACK" 1*WSP unique-envid 1*WSP mtrk-secret CRLF
mtrk-secret = base64
「道」1*WSPユニークなenvid1*WSP mtrk秘密のCRLF mtrk秘密の=道コマンド=base64
Unique-envid is defined in [RFC-MTRK-ESMTP]. Mtrk-secret is the secret A described in [RFC-MTRK-ESMTP], encoded using base64.
ユニークなenvidは[RFC-MTRK-ESMTP]で定義されます。 Mtrk-秘密はbase64を使用することでコード化された[RFC-MTRK-ESMTP]で説明された秘密Aです。
When the client issues the TRACK command, and the user is validated, the MTQP server retrieves tracking information about an email message. To validate the user, the value of mtrk-secret is hashed using SHA1, as described in [RFC-SHA1]. The hash value is then compared with the value passed with the message when it was originally sent. If the hash values match, the user is validated.
クライアントがTRACKコマンドを発行して、ユーザが有効にされるとき、MTQPサーバはメールメッセージの追跡情報を検索します。 ユーザを有効にするために、mtrk-秘密の値は[RFC-SHA1]で説明されるようにSHA1を使用することで論じ尽くされます。 そして、元々それを送ったとき、メッセージで通過される値にハッシュ値をたとえます。 ハッシュ値が合っているなら、ユーザは有効にされます。
A successful response MUST be multi-line, consisting of a [RFC-MIME] body part. The MIME body part MUST be of type multipart/related, with subparts of message/tracking-status, as defined in [RFC-MTRK-TSN]. The response contains the tracking information about the email message that used the given tracking-id. A negative response to the TRACK command may include these reason codes:
[RFC-MIME]身体の部分から成って、うまくいっている応答はマルチ系列でなければなりません。 追跡メッセージ/状態の下位区分で複合の、または、関連するタイプにはMIME身体の部分が[RFC-MTRK-TSN]で定義されるようにあるに違いありません。 応答は与えられた追跡イドを使用したメールメッセージの追跡情報を含んでいます。 TRACKコマンドへの否定応答はこれらの理由コードを含むかもしれません:
Hansen Standards Track [Page 6] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[6ページ]RFC3887メッセージ
"/" "tls-required"
"/" "admin"
"/" "unavailable"
"/" "noinfo"
"/" "insecure"
「「/」「tlsが必要である」」 」 /「」 アドミン」 」 /」 「入手できません」」 /"noinfo"」/」の「不安定です」。
The reason code "/tls-required" SHOULD be used when the server has decided to require TLS. The reason code "/admin" SHOULD be used when the server has become unavailable, due to administrative reasons, since the connection was initialized. The reason code "/unavailable" SHOULD be used when the server has become unavailable, for other reasons, since the connection was initialized. The reason code "/insecure" is described later.
「理由コード」/は」 SHOULDをtls必要としました。サーバが、TLSを必要とすると決めたときには、使用されてください。 管理への支払われるべきものは推論します、サーバが入手できなくなったとき、」 「理由コード」/アドミンSHOULDが使用されて接続が初期化されたので。 サーバが入手できなくなったとき、「理由は」 入手できない/をコード化する」SHOULDが使用されて、接続以来の理由がもう一方のための、そうでした。初期化にされる。 「理由は不安定な状態で」 /をコード化すること」が後で説明されます。
If a message has not been seen by the MTQP server, the server MUST choose between two choices: it MAY return a positive response with an action field of "opaque" in the tracking information, or it MAY return a negative response with a reason code of "noinfo".
メッセージがMTQPサーバによって見られていないなら、サーバは2つの選択を選ばなければなりません: 「不透明なもの」の動作分野が追跡情報にある状態で、それが積極的な応答を返すかもしれませんか、またはそれは"noinfo"の理由コードによる否定応答を返すかもしれません。
4.1. Examples
4.1. 例
In each of the examples below, the unique-envid is "<12345-20010101@example.com>", the secret A is "abcdefgh", and the SHA1 hash B is (in hex) "734ba8b31975d0dbae4d6e249f4e8da270796c94". The message came from example.com and the MTQP server is example2.com.
「ユニークなenvidが以下のそれぞれに関する例では、 "<12345-20010101@example.com である、gt;、」、秘密Aは"abcdefgh"であり、SHA1ハッシュBは(十六進法における)"734ba8b31975d0dbae4d6e249f4e8da270796c94""です。 メッセージはexample.comから来ました、そして、MTQPサーバはexample2.comです。
Example #6 Message Delivered: C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK S: +OK+ Tracking information follows S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status S: S: --%%%% S: Content-Type: message/tracking-status S: S: Original-Envelope-Id: 12345-20010101@example.com S: Reporting-MTA: dns; example2.com S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: S: Original-Recipient: rfc822; user1@example1.com S: Final-Recipient: rfc822; user1@example1.com S: Action: delivered S: Status: 2.5.0 S: S: --%%%%-- S: .
例#6メッセージは配送されました: C: TRACK <12345-20010101@example.com 、gt;、YWJjZGVmZ2gK S: +OK+追跡情報はSに続きます: コンテントタイプ: 複合か関連する。 境界=%%、%%。 =追跡状態Sをタイプしてください: S: --%、%%、%S: コンテントタイプ: 追跡メッセージ/状態S: S: オリジナルの封筒イド: 12345-20010101@example.com S: 報告しているMTA: dns。 example2.com S: 到着日付: 月曜日、15:15:15の0500秒間2001年1月1日: S: オリジナルの受取人: rfc822。 user1@example1.com S: 最終受理者: rfc822。 user1@example1.com S: 動作: Sを提供します: 状態: 2.5 .0秒間: S: --%%、%%--、S: .
Hansen Standards Track [Page 7] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[7ページ]RFC3887メッセージ
Example #7 Message Transferred: C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK S: +OK+ Tracking information follows S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status S: S: --%%%% S: Content-Type: message/tracking-status S: S: Original-Envelope-Id: 12345-20010101@example.com S: Reporting-MTA: dns; example2.com S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: S: Original-Recipient: rfc822; user1@example1.com S: Final-Recipient: rfc822; user1@example1.com S: Action: transferred S: Remote-MTA: dns; example3.com S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 S: Status:2.4.0 S: S: --%%%%-- S: .
例#7メッセージは移されました: C: TRACK <12345-20010101@example.com 、gt;、YWJjZGVmZ2gK S: +OK+追跡情報はSに続きます: コンテントタイプ: 複合か関連する。 境界=%%、%%。 =追跡状態Sをタイプしてください: S: --%、%%、%S: コンテントタイプ: 追跡メッセージ/状態S: S: オリジナルの封筒イド: 12345-20010101@example.com S: 報告しているMTA: dns。 example2.com S: 到着日付: 月曜日、15:15:15の0500秒間2001年1月1日: S: オリジナルの受取人: rfc822。 user1@example1.com S: 最終受理者: rfc822。 user1@example1.com S: 動作: わたっているS: リモートMTA: dns。 example3.com S: 最後に日付:を試みてください。 月曜日、19:15:03の0500秒間2001年1月1日: 状態: 2.4 .0秒間: S: --%%、%%--、S: .
Example #8 Message Delayed and a Dot-Stuffed Header: C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK S: +OK+ Tracking information follows S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status S: ..Dot-Stuffed-Header: as an example S: S: --%%%% S: Content-Type: message/tracking-status S: S: Original-Envelope-Id: 12345-20010101@example.com S: Reporting-MTA: dns; example2.com S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: S: Original-Recipient: rfc822; user1@example1.com S: Final-Recipient: rfc822; user1@example1.com S: Action: delayed S: Status: 4.4.1 (No answer from host) S: Remote-MTA: dns; example3.com S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 S: Will-Retry-Until: Thu, 4 Jan 2001 15:15:15 -0500 S: S: --%%%%-- S: .
8メッセージが遅らせた例#とドットで詰められたヘッダー: C: TRACK <12345-20010101@example.com 、gt;、YWJjZGVmZ2gK S: +OK+追跡情報はSに続きます: コンテントタイプ: 複合か関連する。 境界=%%、%%。 =追跡状態Sをタイプしてください: ..ドットの詰められたヘッダー: 例Sとして: S: --%、%%、%S: コンテントタイプ: 追跡メッセージ/状態S: S: オリジナルの封筒イド: 12345-20010101@example.com S: 報告しているMTA: dns。 example2.com S: 到着日付: 月曜日、15:15:15の0500秒間2001年1月1日: S: オリジナルの受取人: rfc822。 user1@example1.com S: 最終受理者: rfc822。 user1@example1.com S: 動作: Sを遅らせます: 状態: 4.4.1 (ホストからの答えがありません)S: リモートMTA: dns。 example3.com S: 最後に日付:を試みてください。 月曜日、19:15:03の0500秒間2001年1月1日: ウィルRetry、: 木曜日、15:15:15の0500秒間2001年1月4日: S: --%%、%%--、S: .
Hansen Standards Track [Page 8] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[8ページ]RFC3887メッセージ
Example #9 Two Users, One Relayed, One Failed: C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK S: +OK+ Tracking information follows S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status S: S: --%%%% S: Content-Type: message/tracking-status S: S: Original-Envelope-Id: 12345-20010101@example.com S: Reporting-MTA: dns; example2.com S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: S: Original-Recipient: rfc822; user1@example1.com S: Final-Recipient: rfc822; user1@example1.com S: Action: relayed S: Status: 2.1.9 S: Remote-MTA: dns; example3.com S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 S: S: Original-Recipient: rfc822; user2@example1.com S: Final-Recipient: rfc822; user2@example1.com S: Action: failed S: Status 5.2.2 (Mailbox full) S: Remote-MTA: dns; example3.com S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 S: S: --%%%%-- S: .
2人のユーザ、ものがリレーした例#9、失敗されたもの: C: TRACK <12345-20010101@example.com 、gt;、YWJjZGVmZ2gK S: +OK+追跡情報はSに続きます: コンテントタイプ: 複合か関連する。 境界=%%、%%。 =追跡状態Sをタイプしてください: S: --%、%%、%S: コンテントタイプ: 追跡メッセージ/状態S: S: オリジナルの封筒イド: 12345-20010101@example.com S: 報告しているMTA: dns。 example2.com S: 到着日付: 月曜日、15:15:15の0500秒間2001年1月1日: S: オリジナルの受取人: rfc822。 user1@example1.com S: 最終受理者: rfc822。 user1@example1.com S: 動作: Sをリレーします: 状態: 2.1 .9秒間: リモートMTA: dns。 example3.com S: 最後に日付:を試みてください。 月曜日、19:15:03の0500秒間2001年1月1日: S: オリジナルの受取人: rfc822。 user2@example1.com S: 最終受理者: rfc822。 user2@example1.com S: 動作: Sに失敗します: 状態5.2.2(メールボックス満)S: リモートMTA: dns。 example3.com S: 最後に日付:を試みてください。 月曜日、19:15:03の0500秒間2001年1月1日: S: --%%、%%--、S: .
Example #10 Firewall: C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK S: +OK+ Tracking information follows S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status S: S: --%%%% S: Content-Type: message/tracking-status S: S: Original-Envelope-Id: 12345-20010101@example.com S: Reporting-MTA: dns; example2.com S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: S: Original-Recipient: rfc822; user1@example1.com S: Final-Recipient: rfc822; user1@example1.com S: Action: relayed S: Status: 2.1.9 S: Remote-MTA: dns; smtp.example3.com S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 S:
例#10ファイアウォール: C: TRACK <12345-20010101@example.com 、gt;、YWJjZGVmZ2gK S: +OK+追跡情報はSに続きます: コンテントタイプ: 複合か関連する。 境界=%%、%%。 =追跡状態Sをタイプしてください: S: --%、%%、%S: コンテントタイプ: 追跡メッセージ/状態S: S: オリジナルの封筒イド: 12345-20010101@example.com S: 報告しているMTA: dns。 example2.com S: 到着日付: 月曜日、15:15:15の0500秒間2001年1月1日: S: オリジナルの受取人: rfc822。 user1@example1.com S: 最終受理者: rfc822。 user1@example1.com S: 動作: Sをリレーします: 状態: 2.1 .9秒間: リモートMTA: dns。 smtp.example3.com S: 最後に日付:を試みてください。 月曜日、19:15:03の0500秒間2001年1月1日:
Hansen Standards Track [Page 9] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[9ページ]RFC3887メッセージ
S: --%%%% S: Content-Type: message/tracking-status S: S: Original-Envelope-Id: 12345-20010101@example.com S: Reporting-MTA: dns; smtp.example3.com S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: S: Original-Recipient: rfc822; user2@example1.com S: Final-Recipient: rfc822; user4@example3.com S: Action: delivered S: Status: 2.5.0 S: S: --%%%%-- S: .
S: --%、%%、%S: コンテントタイプ: 追跡メッセージ/状態S: S: オリジナルの封筒イド: 12345-20010101@example.com S: 報告しているMTA: dns。 smtp.example3.com S: 到着日付: 月曜日、15:15:15の0500秒間2001年1月1日: S: オリジナルの受取人: rfc822。 user2@example1.com S: 最終受理者: rfc822。 user4@example3.com S: 動作: Sを提供します: 状態: 2.5 .0秒間: S: --%%、%%--、S: .
Example #11 Firewall, Combining Per-Recipient Blocks: C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK S: +OK+ Tracking information follows S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status S: S: --%%%% S: Content-Type: message/tracking-status S: S: Original-Envelope-Id: 12345-20010101@example.com S: Reporting-MTA: dns; example2.com S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: S: Original-Recipient: rfc822; user1@example1.com S: Final-Recipient: rfc822; user1@example1.com S: Action: relayed S: Status: 2.1.9 S: Remote-MTA: dns; smtp.example3.com S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 S: S: Original-Recipient: rfc822; user2@example1.com S: Final-Recipient: rfc822; user4@example3.com S: Action: delivered S: Status:2.5.0 S: S: --%%%%-- S: .
1受取人あたりのブロックを結合する例#11ファイアウォール: C: TRACK <12345-20010101@example.com 、gt;、YWJjZGVmZ2gK S: +OK+追跡情報はSに続きます: コンテントタイプ: 複合か関連する。 境界=%%、%%。 =追跡状態Sをタイプしてください: S: --%、%%、%S: コンテントタイプ: 追跡メッセージ/状態S: S: オリジナルの封筒イド: 12345-20010101@example.com S: 報告しているMTA: dns。 example2.com S: 到着日付: 月曜日、15:15:15の0500秒間2001年1月1日: S: オリジナルの受取人: rfc822。 user1@example1.com S: 最終受理者: rfc822。 user1@example1.com S: 動作: Sをリレーします: 状態: 2.1 .9秒間: リモートMTA: dns。 smtp.example3.com S: 最後に日付:を試みてください。 月曜日、19:15:03の0500秒間2001年1月1日: S: オリジナルの受取人: rfc822。 user2@example1.com S: 最終受理者: rfc822。 user4@example3.com S: 動作: Sを提供します: 状態: 2.5 .0秒間: S: --%%、%%--、S: .
Hansen Standards Track [Page 10] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[10ページ]RFC3887メッセージ
Example #12 Firewall, Hiding System Names Behind the Firewall: C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK S: +OK+ Tracking information follows S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status S: S: --%%%% S: Content-Type: message/tracking-status S: S: Original-Envelope-Id: 12345-20010101@example.com S: Reporting-MTA: dns; example2.com S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: S: Original-Recipient: rfc822; user1@example1.com S: Final-Recipient: rfc822; user1@example1.com S: Action: relayed S: Status: 2.1.9 S: Remote-MTA: dns; example2.com S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 S: S: --%%%% S: Content-Type: message/tracking-status S: S: Original-Envelope-Id: 12345-20010101@example.com S: Reporting-MTA: dns; example2.com S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: S: Original-Recipient: rfc822; user2@example1.com S: Final-Recipient: rfc822; user4@example1.com S: Action: delivered S: Status: 2.5.0 S: S: --%%%%-- S: .
ファイアウォールの後ろにシステム名を隠す例#12ファイアウォール: C: TRACK <12345-20010101@example.com 、gt;、YWJjZGVmZ2gK S: +OK+追跡情報はSに続きます: コンテントタイプ: 複合か関連する。 境界=%%、%%。 =追跡状態Sをタイプしてください: S: --%、%%、%S: コンテントタイプ: 追跡メッセージ/状態S: S: オリジナルの封筒イド: 12345-20010101@example.com S: 報告しているMTA: dns。 example2.com S: 到着日付: 月曜日、15:15:15の0500秒間2001年1月1日: S: オリジナルの受取人: rfc822。 user1@example1.com S: 最終受理者: rfc822。 user1@example1.com S: 動作: Sをリレーします: 状態: 2.1 .9秒間: リモートMTA: dns。 example2.com S: 最後に日付:を試みてください。 月曜日、19:15:03の0500秒間2001年1月1日: S: --%、%%、%S: コンテントタイプ: 追跡メッセージ/状態S: S: オリジナルの封筒イド: 12345-20010101@example.com S: 報告しているMTA: dns。 example2.com S: 到着日付: 月曜日、15:15:15の0500秒間2001年1月1日: S: オリジナルの受取人: rfc822。 user2@example1.com S: 最終受理者: rfc822。 user4@example1.com S: 動作: Sを提供します: 状態: 2.5 .0秒間: S: --%%、%%--、S: .
5. COMMENT Command
5. コメント命令
Syntax:
構文:
comment-command = "COMMENT" opt-text CRLF
opt-text = [WSP *(VCHAR / WSP)]
コメント命令はテキストを選んでいるテキストを選んでいる「コメント」CRLF=と等しいです。[WSP*(VCHAR / WSP)]
When the client issues the COMMENT command, the MTQP server MUST respond with a successful response (+OK or +OK+). All optional text provided with the COMMENT command are ignored.
クライアントがCOMMENTコマンドを発行するとき、MTQPサーバはうまくいっている応答(+ OKか+ OK+)で反応しなければなりません。 任意のテキストが提供したすべてがCOMMENTコマンドで無視されます。
Hansen Standards Track [Page 11] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[11ページ]RFC3887メッセージ
6. STARTTLS Command
6. STARTTLSコマンド
Syntax:
構文:
starttls-command = "STARTTLS" 1*WSP domain *WSP CRLF
domain = (sub-domain 1*("." sub-domain))
「STARTTLS」1*WSPドメイン*WSP CRLF starttls-コマンド=ドメイン=(サブドメイン1*、(「」、サブドメイン)
TLS [TLS] is a popular mechanism for enhancing TCP communications with confidentiality and authentication. All MTQP servers MUST implement TLS. However, TLS MAY be disabled by a server administrator, either explicitly or by failing to install any certificates for TLS to use. If an MTQP server supports TLS and has one or more certificates available it MUST include "STARTTLS" in the option specifications list on protocol startup.
TLS[TLS]は、秘密性と認証とのTCPコミュニケーションを高めるためのポピュラーなメカニズムです。 すべてのMTQPサーバがTLSを実装しなければなりません。 しかしながら、TLS MAYがサーバアドミニストレータによって無効にされて、明らかか明らかでないことによって、TLSが使用するあらゆる証明書をインストールしてください。 MTQPサーバがTLSをサポートして、利用可能な1通以上の証明書を持っているなら、それはプロトコル始動でのオプション仕様リストに「STARTTLS」を含まなければなりません。
Note: TLS SHOULD be enabled on MQTP servers whenever possible.
以下に注意してください。 TLS SHOULD、可能であるときはいつも、MQTPサーバで可能にされてください。
The parameter MUST be a fully qualified domain name (FQDN). A client MUST specify the hostname it believes it is speaking with so that the server may respond with the proper TLS certificate. This is useful for virtual servers that provide message tracking for multiple domains (i.e., virtual hosting).
パラメタは完全修飾ドメイン名であるに違いありません(FQDN)。 クライアントは、サーバが適切なTLS証明書で反応できるように、話しているそれが、信じているホスト名を指定しなければなりません。 これは複数のドメイン(すなわち、仮想の接待)のためのメッセージ追跡を提供する仮想サーバの役に立ちます。
If the server returns a negative response, it MAY use one of the
following response codes:
"/" "unsupported"
"/" "unavailable"
"/" "tls-in-progress"
"/" "bad-fqdn"
サーバが否定応答を返すなら、以下の応答コードの1つを使用するかもしれません: 」 「」 「/」「サポートされない」」 /」 「入手できません」」 /「進行中のtls」」/「悪いfqdn」
If TLS is not supported, then a response code of "/unsupported" SHOULD be used. If TLS is not available for some other reason, then a response code of "/unavailable" SHOULD be used. If a TLS session is already in progress, then it is a protocol error and "-BAD" MUST be returned with a response code of "/tls-in-progress". If there is a mismatch between the supplied FQDN and the FQDN found in the dNSName field of the subjectAltName extension of the server's certificate [RFC-X509], then it is a protocol error and "-BAD" MUST be returned with a response code of "/bad-fqdn".
「TLSであるなら、」 /のサポートしていて、当時のa応答コードはサポートされなくなく」SHOULD、使用されてください。 」 TLSであるなら、」 /の入手できないある他の理由に利用可能で、当時でないa応答コードはSHOULDです。「使用されます。 「TLSセッションが既に進行していて、次に、それがプロトコル誤りであり、「-ひどい」という必須であるなら、」 /の応答コードがtls進行していた状態で、返してください。」 「subjectAltNameのdNSName野原で発見される供給されたFQDNとFQDNの間には、ミスマッチがあれば、」 /の応答コードがfqdnである状態で悪い[RFC-X509]、次に、それがプロトコル誤りであり、「-ひどい」というサーバの証明書の拡大を返さなければなりません。」
After receiving a positive response to a STARTTLS command, the client MUST start the TLS negotiation before giving any other MTQP commands.
STARTTLSコマンドへの積極的な応答を受けた後に、いかなる他のMTQPコマンドも与える前に、クライアントはTLS交渉を始めなければなりません。
If the MTQP client is using pipelining (see below), the STARTTLS command must be the last command in a group.
MTQPクライアントがパイプライン処理を使用しているなら(以下を見てください)、STARTTLSコマンドはグループで持続コマンドであるに違いありません。
Hansen Standards Track [Page 12] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[12ページ]RFC3887メッセージ
6.1. Processing After the STARTTLS Command
6.1. STARTTLSが命令した後に処理
If the TLS handshake fails, the server SHOULD abort the connection.
TLS握手が失敗するなら、サーバSHOULDは接続を中止します。
After the TLS handshake has been completed, both parties MUST immediately decide whether or not to continue based on the authentication and confidentiality achieved. The MTQP client and server may decide to move ahead even if the TLS negotiation ended with no authentication and/or no confidentiality because most MTQP services are performed with no authentication and no confidentiality, but some MTQP clients or servers may want to continue only if a particular level of authentication and/or confidentiality was achieved.
TLS握手が終了した後に、双方は、すぐに、達成された認証と秘密性に基づいて続くかどうか決めなければなりません。 ほとんどのMTQPサービスが認証にもかかわらず、どんな秘密性なしでも実行されないのでTLS交渉が認証にもかかわらず、どんな秘密性なしでも終わらなかったとしても、MTQPクライアントとサーバは、前方に移行すると決めるかもしれませんが、特定のレベルの認証、そして/または、秘密性が達成された場合にだけ、いくつかのMTQPクライアントかサーバが続きたがっているかもしれません。
If the MTQP client decides that the level of authentication or confidentiality is not high enough for it to continue, it SHOULD issue an MTQP QUIT command immediately after the TLS negotiation is complete.
MTQPクライアントが決めるなら、TLS交渉が完全である直後認証か秘密性のレベルが続けることができるくらいには高くなく、それがSHOULDであることはMTQP QUITコマンドを発行します。
If the MTQP server decides that the level of authentication or confidentiality is not high enough for it to continue, it MAY abort the connection. If it decides that the level of authentication or confidentiality is not high enough for it to continue, and it does not abort the connection, it SHOULD reply to every MTQP command from the client (other than a QUIT command) with a negative "-ERR" response and a response code of "/insecure".
MTQPサーバが、認証か秘密性のレベルが続けることができるくらいには高くないと決めるなら、それは接続を中止するかもしれません。 「決めるなら、続くそれ、およびそれには、認証か秘密性のレベルが十分高くないのが接続を中止しないで、それは「-間違えてください」という否定的応答と」 /の応答コードが不安定のクライアント(QUITコマンドを除いた)からのあらゆるMTQPコマンドに関するSHOULD回答です。」
6.2. Result of the STARTTLS Command
6.2. STARTTLSコマンドの結果
Upon completion of the TLS handshake, the MTQP protocol is reset to the initial state (the state in MTQP after a server starts up). The server MUST discard any knowledge obtained from the client prior to the TLS negotiation itself. The client MUST discard any knowledge obtained from the server, such as the list of MTQP options, which was not obtained from the TLS negotiation itself.
TLS握手の完成のときに、MTQPプロトコルは初期状態にリセットされます(サーバの後のMTQPの状態は始動します)。 サーバはTLS交渉自体の前にクライアントから得られたどんな知識も捨てなければなりません。 クライアントはサーバから得られたどんな知識も捨てなければなりません、MTQPオプションのリストなどのように。(オプションはTLS交渉自体から得られませんでした)。
At the end of the TLS handshake, the server acts as if the connection had been initiated and responds with an initial status response and, optionally, a list of server options. The list of MTQP server options received after the TLS handshake MUST be different than the list returned before the TLS handshake. In particular, a server MUST NOT return the STARTTLS option in the list of server options after a TLS handshake has been completed.
TLS握手の終わりに、サーバは、まるで接続が開始されたかのように行動して、初期の状態応答と任意にサーバオプションのリストで反応します。 TLS握手がリストがTLS握手の前に戻ったより異なったに違いない後にMTQPサーバオプションのリストは受信されました。 TLS握手が終了した後に特に、サーバはサーバオプションのリストにおけるSTARTTLSオプションを返してはいけません。
Both the client and the server MUST know if there is a TLS session active. A client MUST NOT attempt to start a TLS session if a TLS session is already active.
クライアントとサーバの両方が、TLSセッション能動態があるかどうかを知らなければなりません。 TLSセッションが既に活発であるなら、クライアントは、TLSセッションを始めるのを試みてはいけません。
Hansen Standards Track [Page 13] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[13ページ]RFC3887メッセージ
7. QUIT Command
7. 辞任コマンド
Syntax:
構文:
quit-command = "QUIT" CRLF
コマンドをやめている=「やめてください」CRLF
When the client issues the QUIT command, the MTQP session terminates. The QUIT command has no parameters. The server MUST respond with a successful response. The client MAY close the session from its end immediately after issuing this command (if the client is on an operating system where this does not cause problems).
クライアントがQUITコマンドを発行するとき、MTQPセッションは終わります。 QUITコマンドには、パラメタが全くありません。 サーバはうまくいっている応答で反応しなければなりません。 このコマンドを発行する直後クライアントは終わりからのセッションを終えるかもしれません(クライアントがこれが問題を起こさないオペレーティングシステムにいるなら)。
8. Pipelining
8. パイプライン処理
The MTQP client may elect to transmit groups of MTQP commands in batches without waiting for a response to each individual command. The MTQP server MUST process the commands in the order received.
MTQPクライアントは、それぞれの個々のコマンドへの応答を待たないでバッチにおけるMTQPコマンドのグループを伝えるのを選ぶかもしれません。 MTQPサーバは受注におけるコマンドを処理しなければなりません。
Specific commands may place further constraints on pipelining. For example, STARTTLS must be the last command in a batch of MTQP commands.
特定のコマンドはパイプライン処理に更なる規制を置くかもしれません。 例えば、STARTTLSはMTQPコマンドのバッチで持続コマンドであるに違いありません。
8.1. Examples
8.1. 例
The following two examples are identical:
以下の2つの例が同じです:
Example #13 : C: TRACK <tracking-id> YWJjZGVmZ2gK S: +OK+ Tracking information follows S: S: ... tracking details #1 go here ... S: . C: TRACK <tracking-id-2> QUJDREVGR0gK S: +OK+ Tracking information follows S: S: ... tracking details #2 go here ... S: .
例#13: C: <の追跡イドの>YWJjZGVmZ2gK Sを追跡してください: +OK+追跡情報はSに続きます: S: … 詳細#1を追跡して、ここに行ってください… S: . C: <追跡イド-2>QUJDREVGR0gK Sを追跡してください: +OK+追跡情報はSに続きます: S: 追跡…詳細#2はここに行きます… S: .
Hansen Standards Track [Page 14] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[14ページ]RFC3887メッセージ
Example #14 : C: TRACK <tracking-id> YWJjZGVmZ2gK C: TRACK <tracking-id-2> QUJDREVGR0gK S: +OK+ Tracking information follows S: S: ... tracking details #1 go here ... S: . S: +OK+ Tracking information follows S: S: ... tracking details #2 go here ... S: .
例#14: C: <の追跡イドの>YWJjZGVmZ2gK Cを追跡してください: <追跡イド-2>QUJDREVGR0gK Sを追跡してください: +OK+追跡情報はSに続きます: S: … 詳細#1を追跡して、ここに行ってください… S: . S: +OK+追跡情報はSに続きます: S: 追跡…詳細#2はここに行きます… S: .
9. The MTQP URI Scheme
9. MTQP URI体系
9.1. Intended usage
9.1. 意図している用法
The MTQP URI scheme is used to designate MTQP servers on Internet hosts accessible using the MTQP protocol. It performs an MTQP query and returns tracking status information.
MTQP URI体系は、MTQPプロトコルを使用することでインターネットのMTQPサーバをアクセスしやすい状態でホストに指定するのに使用されます。 それは、MTQP質問を実行して、追跡状態情報を返します。
9.2. URI Scheme Name
9.2. URI体系名
The name of the URI scheme is "mtqp".
URI体系の名前は"mtqp"です。
9.3. URI Scheme Syntax
9.3. URI体系構文
An MTQP URI takes one of the following forms:
MTQP URIは以下のフォームの1つを取ります:
mtqp://<mserver>/track/<unique-envid>/<mtrk-secret>
mtqp://<mserver>:<port>/track/<unique-envid>/<mtrk-secret>
mtqp://<の<のユニークにenvid>/<mtrk秘密の>mtqp://<mserver mserver>/track/>: <ポートの>の/track/の<のユニークにenvid>/<mtrk秘密の>。
The first form is used to refer to an MTQP server on the standard port, while the second form specifies a non-standard port. Both of these forms specify that the TRACK command is to be issued using the given tracking id (unique-envid) and authorization secret (mtrk- secret). The path element "/track/" MUST BE treated case insensitively, but the unique-envid and mtrk-secret MUST NOT be.
最初のフォームは標準のポートの上にMTQPサーバを示すのに使用されます、2番目のフォームが標準的でないポートを指定しますが。 これらのフォームの両方が、TRACKコマンドが与えられた追跡イド(ユニークなenvid)と承認秘密(mtrk秘密)を使用することで発行されることであると指定します。 経路要素"/track/"は無神経に扱われたケースであるに違いありませんが、ユニークなenvidとmtrk-秘密はそのようなケースであるはずがありません。
9.3.1. Formal Syntax
9.3.1. 正式な構文
This is an ABNF description of the MTQP URI.
これはMTQP URIのABNF記述です。
mtqp-uri = "mtqp://" authority "/track/" unique-envid "/" mtrk-secret
「mtqp-uri=「mtqp://の」 権威の"/track/"ユニークなenvid」/」mtrk-秘密
Hansen Standards Track [Page 15] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[15ページ]RFC3887メッセージ
9.4. Encoding Rules
9.4. 符号化規則
The encoding of unique-envid is discussed in [RFC-MTRK-ESMTP]. Mtrk-secret is required to be base64 encoded. If the "/", "?" and "%" octets appear in unique-envid or mtrk-secret, they are further required to be represented by a "%" followed by two hexadecimal characters. (The two characters give the hexadecimal representation of that octet).
[RFC-MTRK-ESMTP]でユニークなenvidのコード化について議論します。 Mtrk-秘密が、コード化されたbase64になるのに必要です。 「」 /、」、“?"と「%」八重奏はユニークなenvidかmtrk-秘密で見えて、2つの16進キャラクタによって後をつけられた「%」によってそれらによってさらに表されなければなりません。 (2つのキャラクタがその八重奏の16進表現を与えます。)
10. IANA Considerations
10. IANA問題
System port number 1038 has been assigned to the Message Tracking Query Protocol by the Internet Assigned Numbers Authority (IANA).
システムポートNo.1038はインターネットAssigned民数記Authority(IANA)によってMessage Tracking Queryプロトコルに割り当てられました。
The service name "MTQP" has been registered with the IANA.
"MTQP"というサービス名をIANAに登録してあります。
The IANA has also registered the URI registration template found in Appendix A in accordance with [BCP35].
また、IANAは[BCP35]に従ってAppendix Aで見つけられたURI登録テンプレートを登録しました。
This document requests that IANA maintain one new registry: MTQP options. The registry's purpose is to register options to this protocol. Options whose names do not begin with "vnd." MUST be defined in a standards track or IESG approved experimental RFC. New MTQP options MUST include the following information as part of their definition:
このドキュメントは、IANAが1つの新しい登録を維持するよう要求します: MTQPオプション。 登録の目的はこのプロトコルにオプションを登録することです。 名前が"vnd"で始まらないオプション。 標準化過程で定義しなければならなかったか、またはIESGは実験的なRFCを承認しました。 新しいMTQPオプションは彼らの定義の一部として以下の情報を含まなければなりません:
option identifier
option parameters
added commands
standard commands affected
specification reference
discussion
パラメタが加えたオプション識別子オプションは、標準のコマンドが仕様参照議論に影響したと命令します。
One MTQP option is defined in this document, with the following registration definition:
1つのMTQPオプションが以下の登録定義で本書では定義されます:
option identifier: STARTTLS
option parameters: none
added commands: STARTTLS
standard commands affected: none
specification reference: RFC 3887
discussion: see RFC 3887
オプション識別子: STARTTLSオプションパラメタ: なにもコマンドを加えませんでした: STARTTLSの標準のコマンドは影響しました: なにもに、仕様は以下に参照をつけます。 RFC3887議論: RFC3887を見てください。
Additional vendor-specific options for this protocol have names that begin with "vnd.". After the "vnd." would appear the reversed domain name of the vendor, another dot ".", and a name for the option itself. For example, "vnd.com.example.extinfo" might represent a
このプロトコルのための追加ベンダー特有のオプションには、"vnd"で始まる名前があります。 「後に、"vnd"はベンダーの逆にされたドメイン名に現れるでしょう、別のドット。」」 aはそれ自体をオプションにちなんで命名します。 例えば、"vnd.com.example.extinfo"はaを表すかもしれません。
Hansen Standards Track [Page 16] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[16ページ]RFC3887メッセージ
vendor-specific extension providing extended information by the owner of the "example.com" domain. These names MAY be registered with IANA.
ベンダー特有の拡大提供は"example.com"ドメインの所有者で情報を広げました。 これらの名前はIANAに登録されるかもしれません。
11. Security Considerations
11. セキュリティ問題
If the originator of a message were to delegate his or her tracking request to a third party, this would be vulnerable to snooping over unencrypted sessions. The user can decide on a message-by-message basis if this risk is acceptable.
メッセージの創始者がその人の追跡要求を第三者へ代表として派遣するなら、これは非暗号化されたセッションの間、詮索するのに被害を受け易いでしょうに。 このリスクが許容できるなら、ユーザはメッセージごとの基礎を決めることができます。
The security of tracking information is dependent on the randomness of the secret chosen for each message and the level of exposure of that secret. If different secrets are used for each message, then the maximum exposure from tracking any message will be that single message for the time that the tracking information is kept on any MTQP server. If this level of exposure is too much, TLS may be used to reduce the exposure further.
追跡情報のセキュリティは各メッセージに選ばれた秘密の偶発性とその秘密の暴露のレベルに依存しています。 異なった秘密が各メッセージに使用されると、どんなメッセージも追跡するのからの最高支払い責任額は追跡情報がどんなMTQPサーバにも保たれる時間へのそのただ一つのメッセージになるでしょう。このレベルの暴露があまりに多くなら、TLSは、暴露をさらに減少させるのに使用されるかもしれません。
It should be noted that message tracking is not an end-to-end mechanism. Thus, if an MTQP client/server pair decide to use TLS confidentiality, they are not securing tracking queries with any prior or successive MTQP servers.
メッセージ追跡が終わりから終わりへのメカニズムでないことに注意されるべきです。 したがって、MTQPクライアント/サーバ組が、TLS秘密性を使用すると決めるなら、彼らはどんな先の、または、連続したMTQPサーバでも追跡質問を保証していません。
Both the MTQP client and server must check the result of the TLS negotiation to see whether acceptable authentication or confidentiality was achieved. Ignoring this step completely invalidates using TLS for security. The decision about whether acceptable authentication or confidentiality was achieved is made locally, is implementation-dependent, and is beyond the scope of this document.
ともに、MTQPクライアントとサーバは、許容できる認証か秘密性が達成されたかどうかを見るためにTLS交渉の結果をチェックしなければなりません。 このステップを無視すると、使用TLSはセキュリティのために完全に無効にされます。 許容できる認証か秘密性が達成されたかどうかに関する決定は、局所的に作られていて、実装依存していて、このドキュメントの範囲を超えています。
The MTQP client and server should note carefully the result of the TLS negotiation. If the negotiation results in no confidentiality, or if it results in confidentiality using algorithms or key lengths that are deemed not strong enough, or if the authentication is not good enough for either party, the client may choose to end the MTQP session with an immediate QUIT command, or the server may choose to not accept any more MTQP commands.
MTQPクライアントとサーバは慎重にTLS交渉の結果に注意するべきです。 交渉が秘密性を全くもたらさないか、十分強くないと考えられるアルゴリズムかキー長を使用することで秘密性をもたらす、または何れの当事者には、認証が十分良くないなら、クライアントが、即座のQUITコマンドとのMTQPセッションを終わらせるのを選ぶかもしれませんか、またはサーバは、それ以上のMTQPコマンドを受け入れないのを選ぶかもしれません。
A man-in-the-middle attack can be launched by deleting the "STARTTLS" option response from the server. This would cause the client not to try to start a TLS session. An MTQP client can protect against this attack by recording the fact that a particular MTQP server offers TLS during one session and generating an alarm if it does not appear in an option response for a later session.
サーバから「STARTTLS」オプション応答を削除することによって、介入者攻撃に着手できます。これで、クライアントは、TLSセッションを出発させようとしないでしょう。 MTQPクライアントは、特定のMTQPサーバが1つのセッションの間TLSを提供するという事実を記録して、後のセッションに関してオプション応答に現れないならアラームを生成することによって、この攻撃から守ることができます。
Hansen Standards Track [Page 17] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[17ページ]RFC3887メッセージ
Similarly, the identity of the server as expressed in the server's certificate should be cached, and an alarm generated if they do not match in a later session.
サーバの証明書の言い表されるとしてのサーバのアイデンティティは、同様に、キャッシュされていて彼らが後のセッションのときに合っていないなら生成されたアラームであるべきです。
If TLS is not used, a tracking request is vulnerable to replay attacks, such that a snoop can later replay the same handshake again to potentially gain more information about a message's status.
TLSが使用されていないなら、追跡要求は反射攻撃に被害を受け易いです、詮索好きが後で潜在的にメッセージの状態に関する詳しい情報を獲得するために再び同じ握手を再演できるように。
Before the TLS handshake has begun, any protocol interactions are performed in the clear and may be modified by an active attacker. For this reason, clients and servers MUST discard any knowledge obtained prior to the start of the TLS handshake upon completion of the TLS handshake.
TLS握手が始まる前に、どんなプロトコル相互作用も、明確で実行されて、活発な攻撃者によって変更されるかもしれません。 この理由で、クライアントとサーバはTLS握手の完成のTLS握手の始まりの前に得られたどんな知識も捨てなければなりません。
If a client/server pair successfully performs a TLS handshake and the server does chaining referrals, then the server SHOULD attempt to negotiate TLS at the same (or better) security level at the next hop. In a hop-by-hop scenario, STARTTLS is a request for "best effort" security and should be treated as such.
クライアント/サーバ組が首尾よくTLS握手を実行して、サーバが推論紹介をするなら、サーバSHOULDは、次のホップにおける同じで(より良い)のセキュリティー・レベルでTLSを交渉するのを試みます。 ホップごとのシナリオでは、STARTTLSは「ベストエフォート型」のセキュリティを求める要求であり、そういうものとして扱われるべきです。
SASL is not used because authentication is per message rather than per user.
認証がユーザ単位でというよりむしろメッセージ単位であるので、SASLは使用されていません。
12. Protocol Syntax
12. プロトコル構文
This is a collected ABNF description of the MTQP protocol.
これはMTQPプロトコルの集まっているABNF記述です。
mtqp-uri = "mtqp://" authority "/track/" unique-envid "/" mtrk-secret
「mtqp-uri=「mtqp://の」 権威の"/track/"ユニークなenvid」/」mtrk-秘密
conversation = command-response *(client-command command-response)
会話はコマンド応答*と等しいです。(クライアントコマンドコマンド応答)
; client side client-command = track-command / starttls-command / quit-command /comment-command
; コマンドをやめるか、またはコマンドについてstarttlsクライアントサイドクライアントコマンド=道命令/コマンド/論評します。
track-command = "TRACK" 1*WSP unique-envid 1*WSP mtrk-secret CRLF mtrk-secret = base64
「道」1*WSPユニークなenvid1*WSP mtrk秘密のCRLF mtrk秘密の=道コマンド=base64
starttls-command = "STARTTLS" 1*WSP domain *WSP CRLF
domain = (sub-domain 1*("." sub-domain))
「STARTTLS」1*WSPドメイン*WSP CRLF starttls-コマンド=ドメイン=(サブドメイン1*、(「」、サブドメイン)
quit-command = "QUIT" CRLF
コマンドをやめている=「やめてください」CRLF
comment-command = "COMMENT" opt-text CRLF
コメント命令はテキストを選んでいる「コメント」CRLFと等しいです。
Hansen Standards Track [Page 18] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[18ページ]RFC3887メッセージ
; server side command-response = success-response / temp-response / error-response / bad-response
; サーバサイドコマンド応答は誤り臨時成功応答/応答/応答/誤応答と等しいです。
temp-response = "-TEMP" response-info opt-text CRLF
臨時応答はテキストを選んでいる「臨時」応答インフォメーションCRLFと等しいです。
opt-text = [WSP *(VCHAR / WSP)]
テキストを選んでいる=[WSP*(VCHAR / WSP)]
error-response = "-ERR" response-info opt-text CRLF
誤り応答はテキストを選んでいる「-間違えてください」応答インフォメーションCRLFと等しいです。
bad-response = "-BAD" response-info opt-text CRLF
テキストを選んでいる誤応答= 「-ひどい」という応答インフォメーションCRLF
success-response = single-line-success / multi-line-success
成功応答はマルチ系列のただ一つの系列成功/成功と等しいです。
single-line-success = "+OK" response-info opt-text CRLF
」 テキストを選んでいる「ただ一つの系列成功=」+OK応答インフォメーションCRLF
multi-line-success = "+OK+" response-info opt-text CRLF
*dataline dotcrlf
+ 」 テキストを選んでいる「マルチ系列の成功=」+OK応答インフォメーションCRLF*dataline dotcrlf
dataline = *998OCTET CRLF
datalineは*998OCTET CRLFと等しいです。
dotcrlf = "." CRLF
「dotcrlf=」、」 CRLF
NAMECHAR = ALPHA / DIGIT / "-" / "_"
NAMECHARはアルファ/ケタ/「-」/"_"と等しいです。
response-info = *( "/" ( "admin" / "unavailable" / "unsupported" / "tls-in-progress" / "insecure" / "tls-required" / 1*NAMECHAR ) )
応答インフォメーションは*と等しいです。(「/」(/の「進行中のtls」/「不安定」「入手できません」か「アドミン」/「サポートされない」/「tlsが必要な」/1*NAMECHAR))
13. Acknowledgements
13. 承認
The description of STARTTLS is based on [RFC-SMTP-TLS].
STARTTLSの記述は[RFC-SMTP-TLS]に基づいています。
Hansen Standards Track [Page 19] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[19ページ]RFC3887メッセージ
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[RFC-MIME] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies", RFC 2045, November
1996.
解放された[RFC-MIME]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC-ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF
for Syntax Specifications: ABNF", RFC 2234,
November 1997.
エド[RFC-ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[RFC-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS
RR for specifying the location of services (DNS
SRV)", RFC 2782, February 2000.
[RFC-SRV] Gulbrandsen、A.、Vixie、P.、およびL.Esibov、「サービスの位置を指定するためのDNS RR(DNS SRV)」、RFC2782(2000年2月)。
[RFC-SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC
2821, April 2001.
[RFC-SMTP] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC-SMTPEXT] Myers, J., "SMTP Service Extension for
Authentication", RFC 2554, March 1999.
[RFC-SMTPEXT] マイアーズ、J.、「認証のためのSMTPサービス拡張子」、RFC2554、1999年3月。
[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-MODEL] Hansen, T., "Message Tracking Models and
Requirements", RFC 3885, September 2004.
T. [RFC-MTRK-モデル]ハンセン、2004年9月、「メッセージはモデルと要件を追跡すること」でのRFC3885。
[RFC-MTRK-TSN] Allman, E., "The Message/Tracking-Status MIME
Extension", RFC 3886, September 2004.
[RFC-MTRK-TSN] オールマン、E.、「追跡メッセージ/状態MIME拡大」、RFC3886、2004年9月。
[RFC-URI] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic
Syntax", RFC 2396, August 1998.
[RFC-URI]のバーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[TLS] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
Hansen Standards Track [Page 20] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[20ページ]RFC3887メッセージ
14.2. Informational References
14.2. 情報の参照
[BCP35] Petke, R. and I. King, "Registration Procedures
for URL Scheme Names", BCP 35, RFC 2717, November
1999.
[BCP35]Petke、R.とI.キング、「URL体系名のための登録手順」BCP35、1999年11月のRFC2717。
[RFC-SHA1] Eastlake, D. and P. Jones, "US Secure Hash
Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC-SHA1]イーストレークとD.とP.ジョーンズ、「米国安全なハッシュアルゴリズム1(SHA1)」、RFC3174 2001年9月。
[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-SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure
SMTP over Transport Layer Security", RFC 3207,
February 2002.
[RFC-SMTP-TLS]ホフマン、P.、「トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子」、RFC3207、2002年2月。
[RFC-X509] Housley, R., Polk, W., Ford, W. and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002.
[RFC-X509] HousleyとR.とポークとW.とフォードとW.と一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280、2002年4月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol -
Version 3", STD 53, RFC 1939, May 1996.
[POP3] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」
[NNTP] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.
[NNTP] カンターとB.とP.ラプスリー、「ネットワークの電子情報を転送するプロトコル」、RFC977、1986年2月。
Hansen Standards Track [Page 21] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[21ページ]RFC3887メッセージ
Appendix A. MTQP URI Registration Template
付録A.MTQP URI登録テンプレート
Scheme name: mtqp
名前を計画してください: mtqp
Scheme syntax: see section 9.1
構文を計画してください: セクション9.1を見てください。
Character encoding considerations: see section 9.4
文字符号化問題: セクション9.4を見てください。
Intended usage: see section 9.3
意図している用法: セクション9.3を見てください。
Applications and/or protocols which use this scheme: MTQP
この体系を使用するアプリケーション、そして/または、プロトコル: MTQP
Interoperability considerations: as specified for MTQP
相互運用性問題: MTQPに指定されます。
Security considerations: see section 11.0
セキュリティ問題: セクション11.0を見てください。
Relevant publications: [RFC-MTRK-ESMTP], [RFC-MTRK-MODEL], [RFC-MTRK-TSN]
関連刊行物: [RFC-MTRK-ESMTP]、[RFC-MTRK-モデル][RFC-MTRK-TSN]
Contact: MSGTRK Working Group
接触: MSGTRK作業部会
Author/Change Controller: IESG
コントローラを書くか、または変えてください: IESG
Author's Address
作者のアドレス
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 Standards Track [Page 22] RFC 3887 Message Tracking Query Protocol September 2004
質問プロトコル2004年9月に追跡されるハンセン標準化過程[22ページ]RFC3887メッセージ
Full Copyright Statement
完全な著作権宣言文
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 Standards Track [Page 23]
ハンセン標準化過程[23ページ]
一覧
スポンサーリンク
