Network Working Group T. Hansen
Request for Comments: 3887 AT&T Laboratories
Category: Standards Track September 2004
Message Tracking Query Protocol
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（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プロトコルの拡張機能と組み合わせて使用されているメッセージの追跡照会プロトコルを記述しています。
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]を追跡メッセージは、メッセージ追跡ソリューションは、インターネット全体のメッセージインフラストラクチャで使用することができるメッセージ追跡ソリューションの要件に加えて、従うことができるモデルを議論します。このメモとその仲間、[RFC-MTRK-ESMTP]と[RFC-MTRK-TSN]は、これらの要件を満たす完全なメッセージ追跡ソリューションを記述する。メモ[RFC-MTRK-ESMTP]はメッセージを追跡するために必要な情報を提供するSMTPサービスへの拡張を定義します。このメモはSMTPを介してインターネット上で送信されたメッセージのステータスを照会するために使用することができますプロトコルを定義します。メモ[RFC-MTRK-TSN]はメッセージ/トラッキング状態トラッキング状態情報を報告するために使用される[RFC-MIME]メディアタイプを記述する。モデル文書の用語を使用して、このソリューションは、要求と、連鎖紹介の両方で使用可能アクティブとアクティブな要求を使用しています。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC-KEYWORDS]に記載されているように解釈されます。
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-SMTP]、または[RFC-SMTPEXT]、[RFC-MTRK-ESMTP]、[RFC-URI]、[RFC-ABNF]で定義されている他の場所この文書で定義されていないノード。
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.
メッセージ追跡クエリプロトコル（MTQP）は、[POP3]のような多くの他のライン指向のインターネットプロトコルに類似しており、[NNTP]。最初は、サーバーのホストは、TCPポート1038でリッスンによりMTQPサービスを開始します。
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クライアントは、最初の_mtqp._tcp.smtp3.exampleのように、「mtqp」と「TCP」のプロトコル名のサービス名で、DNS SRVレコードを使用して、サーバホストのSRVルックアップを行います。コム。 （詳細については、[RFC-SRV]で「使用規則」を参照してください。）SRVレコードが存在しない場合は、MTQPクライアントは、サーバーホストのアドレスレコードのルックアップを行います。接続が確立されると、MTQPサーバが挨拶を送ります。接続がクローズまたは中止されるまで、MTQPクライアントとMTQPサーバは、（それぞれ）コマンドとレスポンスを交換します。
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レコードを持たなければなりません。
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.
いずれかのすべてのメールサーバーはすべてのメッセージの情報を取得することができ、または追跡サービスが1つ（またはそれ以上）のマシン上で実行する必要があり、追跡サーバを実行している必要があります（：マルチホームメールサーバーを使用するメールシステムは、追跡サービスを提供するための2つの選択肢がありますすべてのメッセージに関する情報を取得することができます秒）。前者の場合には、追加のDNSレコードは、すでにメールシステムのための場所でMXレコードを超えて必要ありません。後者の場合には、SRV MTQPレコードは追跡サービスを実行しているマシン（複数可）でその点を必要とされています。どちらの場合も、追跡サービスはそのメールシステムによって受け入れられたすべてのメッセージのクエリを処理できなければならないことに注意してください。
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のコマンドは、おそらく一つ以上のパラメータに続いて、大文字と小文字を区別しないキーワードから成ります。すべてのコマンドはCRLFペアで終了します。キーワードとパラメータは、印刷可能なASCII文字で構成されています。キーワードとパラメータは空白（一つ以上のスペースまたはタブ文字）で区切られます。コマンドラインはCRLFの前に998文字に制限されています。
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」の成功を示します。 「+ OK +」は、データ、マルチライン成功応答の追加行に続く成功を示します。 「-tempは、」一時的な失敗を示します。 「-ERRは」永続的な失敗を示します。そして「-Bad」は（そのような認識されないコマンドのような）プロトコルエラーを示します。
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.
ステータスインジケータは、エラーに関するより多くのデータを与える機械解析可能な、大文字と小文字を区別しない応答情報の系列が続いてもよいです。これらは、単一のスラッシュ（「/」、進コード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 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前に998文字に制限します。応答の全ての行が送られた場合、最終行は、単一周期からなる送られる（「」、10進046）とCRLFペア。マルチライン応答の任意の行が期間で始まる場合、行は「ドット詰め」第二周期の期間を付加することです。複数行の応答を調べるとき、クライアントは、行がピリオドで始まるかどうかを確認します。もしそうなら、と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ステータスインジケータに応答することによって、誤った状態にあるときに発行されたコマンドに応答しなければなりません。
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分以内の応答を提供しなければならない、そしてそれはその制限時間の終わりに答えを提供できない場合、「これ以上の情報は利用できません」応答を返すべきです。
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分以上でなければなりません。
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.
サービスは、管理上の理由のために使用できない場合に理由コード「/ adminが」使用されるべきです。サービスは他の理由で利用できないとき、「使用できない/」理由コードを使用する必要があります。
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:
一つのオプション仕様は、ここで定義されています。
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.
単語「必要」（STARTTLSのパラメータは大文字と小文字は区別されません）：これは、1つのオプションのパラメータがあります。サーバがTLSは、ドメイン、サーバー・ハンドルの一部に使用されている必要がある場合、サーバは「必須」パラメータを指定する必要があります。
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：管理者のためのダウン-temp / MTQP /管理サービス、後で電話
Example #3 (service permanently unavailable): S: -ERR/MTQP/unavailable Service down
例＃3（サービス恒久的に利用できません）：S：ダウン-ERR / 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のリスト：。
Syntax:
構文：
track-command = "TRACK" 1*WSP unique-envid 1*WSP mtrk-secret CRLF mtrk-secret = base64
トラック・コマンド= "TRACK" 1 * WSPユニーク-ENVID 1 * 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秘密秘密Aは、Base64でエンコード、[RFC-MTRK-ESMTP]に記載されています。
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サーバは、電子メールメッセージに関する追跡情報を取得します。 [RFC-SHA1]に記載されているようにユーザを検証するために、MTRK秘密の値は、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]で定義されるように、メッセージ/トラッキング状態のサブパートと、型マルチパート/関連でなければなりません。応答は、所与のトラッキングIDを使用する電子メールメッセージに関する追跡情報を含んでいます。 TRACKコマンドに対する否定応答は、これらの理由コードを含めることがあります。
"/" "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.
サーバがTLSを必要とすることを決めたときにコード「/ TLSは、必要な」理由を使用する必要があります。理由コード「/管理」のサーバが使用不能になった場合、接続が初期化されてから、原因管理上の理由に、使用されるべきです。理由コード「/使用できない」サーバーが使用不能になった場合、接続が初期化されてから、他の理由のために、使用されるべきです。 「/安全でない」理由コードについては後述します。
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"。
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>」であり、秘密のAは「ABCDEFGH」であり、SHA1ハッシュB「が734ba8b31975d0dbae4d6e249f4e8da270796c94」（16進数）です。メッセージは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> YWJjZGVmZ2gK S：のContent-Type：+ OK +追跡情報がSに続く関連/マルチ。境界= %%%%。タイプ=トラッキング状態S：S： - %%%% S：のContent-Type：メッセージ/トラッキングステータスS：S：オリジナル-封筒-ID：12345-20010101@example.com S：-MTAをレポート：DNS ; example2.com S：到着-日：月、2001年1月1日15時15分15秒-0500 S：S：オリジナル・受信者：RFC822; user1@example1.com S：最終受信者：RFC822; user1@example1.com S：アクション：Sを配信：ステータス：2.5.0 S：S： - %%%% - S：。
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> YWJjZGVmZ2gK S：のContent-Type：+ OK +追跡情報がSに続く関連/マルチ。境界= %%%%。タイプ=トラッキング状態S：S： - %%%% S：のContent-Type：メッセージ/トラッキングステータスS：S：オリジナル-封筒-ID：12345-20010101@example.com S：-MTAをレポート：DNS ; example2.com S：到着-日：月、2001年1月1日15時15分15秒-0500 S：S：オリジナル・受信者：RFC822; user1@example1.com S：最終受信者：RFC822; user1@example1.com S：アクション：転送S：リモートMTA：DNS; example3.com S：最後の試行 - 日：月、2001年1月1日午後7時15分03秒-0500 S：ステータス：2.4.0 S：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> YWJjZGVmZ2gK S：のContent-Type：+ OK +追跡情報がSに続く関連/マルチ。境界= %%%%。タイプ=トラッキング状態S：..Dot詰め-ヘッダ：S：例えばSとして - %%%% S：のContent-Type：メッセージ/トラッキング状態S：S：元のエンベロープ-ID：12345 -20010101@example.com S：-MTAをレポート：DNS; example2.com S：到着-日：月、2001年1月1日15時15分15秒-0500 S：S：オリジナル・受信者：RFC822; user1@example1.com S：最終受信者：RFC822; user1@example1.com S：アクション：遅れS：ステータス：4.4.1（ホストからの回答なし）S：リモートMTA：DNS; example3.com S：最後の試行 - 日：月、2001年1月1日夜07時15分03秒-0500 S：ウィル・リトライまで：木、2001年1月4日午前15時15分15秒-0500 S：S： - ％ %%% - S：。
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: .
例＃9 2人のユーザー、一つの中継され、ワン失敗しました：C：TRACK <12345-20010101@example.com> YWJjZGVmZ2gK S：+ OK +追跡情報は、以下のS：コンテンツタイプ：マルチパート/関連;境界= %%%%。タイプ=トラッキング状態S：S： - %%%% S：のContent-Type：メッセージ/トラッキングステータスS：S：オリジナル-封筒-ID：12345-20010101@example.com S：-MTAをレポート：DNS ; example2.com S：到着-日：月、2001年1月1日15時15分15秒-0500 S：S：オリジナル・受信者：RFC822; user1@example1.com S：最終受信者：RFC822; user1@example1.com S：アクション：Sを中継：ステータス：2.1.9 S：リモートMTA：DNS; example3.com S：最後の試行 - 日：月、2001年1月1日午後7時15分03秒-0500 S：S：オリジナル・受信者：RFC822; user2@example1.com S：最終受信者：RFC822; user2@example1.comはS：アクション：Sを失敗しました：ステータス5.2.2（フルメールボックス）S：リモートMTA：DNS; example3.com S：最後の試行 - 日：月、2001年1月1日午後7時15分03秒-0500 S：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> YWJjZGVmZ2gK S：のContent-Type：+ OK +追跡情報がSに続く関連/マルチ。境界= %%%%。タイプ=トラッキング状態S：S： - %%%% S：のContent-Type：メッセージ/トラッキングステータスS：S：オリジナル-封筒-ID：12345-20010101@example.com S：-MTAをレポート：DNS ; example2.com S：到着-日：月、2001年1月1日15時15分15秒-0500 S：S：オリジナル・受信者：RFC822; user1@example1.com S：最終受信者：RFC822; user1@example1.com S：アクション：Sを中継：ステータス：2.1.9 S：リモートMTA：DNS; smtp.example3.com S：最後の試行 - 日：月、2001年1月1日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; 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：のContent-Type：メッセージ/トラッキングステータスS：S：オリジナル-封筒-ID：12345-20010101@example.com S：-MTAをレポート：DNS; smtp.example3.com S：到着-日：月、2001年1月1日午後03時15分15秒-0500 S：S：オリジナル・受信者：RFC822; user2@example1.com S：最終受信者：RFC822; user4@example3.com S：アクション：Sを配信：ステータス：2.5.0 S：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: .
例＃11ファイアウォール、パー-受信者のブロックを組み合わせる：C：TRACK <12345-20010101@example.com> YWJjZGVmZ2gK S：コンテンツタイプ：+ OK +追跡情報は、S以下のマルチパートを/関連;境界= %%%%。タイプ=トラッキング状態S：S： - %%%% S：のContent-Type：メッセージ/トラッキングステータスS：S：オリジナル-封筒-ID：12345-20010101@example.com S：-MTAをレポート：DNS ; example2.com S：到着-日：月、2001年1月1日15時15分15秒-0500 S：S：オリジナル・受信者：RFC822; user1@example1.com S：最終受信者：RFC822; user1@example1.com S：アクション：Sを中継：ステータス：2.1.9 S：リモートMTA：DNS; smtp.example3.com S：最後の試行 - 日：月、2001年1月1日19時15分03秒-0500 S：S：オリジナル・受信者：RFC822; user2@example1.com S：最終受信者：RFC822; user4@example3.com S：アクション：Sを配信：ステータス：2.5.0 S：S： - %%%% - S：。
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> YWJjZGVmZ2gK S：+ OK +情報を追跡することはS、次のとおりです。コンテンツタイプ：マルチパート/関連;境界= %%%%。タイプ=トラッキング状態S：S： - %%%% S：のContent-Type：メッセージ/トラッキングステータスS：S：オリジナル-封筒-ID：12345-20010101@example.com S：-MTAをレポート：DNS ; example2.com S：到着-日：月、2001年1月1日15時15分15秒-0500 S：S：オリジナル・受信者：RFC822; user1@example1.com S：最終受信者：RFC822; user1@example1.com S：アクション：Sを中継：ステータス：2.1.9 S：リモートMTA：DNS; example2.com S：最後の試行 - 日：月、2001年1月1日午後7時15分03秒-0500 S：S： - %%%% S：のContent-Type：メッセージ/トラッキングステータスS：S：オリジナル - 封筒-ID：12345-20010101@example.com S：-MTAをレポート：DNS; example2.com S：到着-日：月、2001年1月1日15時15分15秒-0500 S：S：オリジナル・受信者：RFC822; user2@example1.com S：最終受信者：RFC822; user4@example1.com S：アクション：Sを配信：ステータス：2.5.0 S：S： - %%%% - S：。
Syntax:
構文：
comment-command = "COMMENT" opt-text CRLF opt-text = [WSP *(VCHAR / WSP)]
コメント-コマンド= "COMMENT" オプトインテキスト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コマンドで提供されるすべてのオプションのテキストは無視されます。
Syntax:
構文：
starttls-command = "STARTTLS" 1*WSP domain *WSP CRLF domain = (sub-domain 1*("." sub-domain))
STARTTLSコマンド= "STARTTLS" 1 * WSPドメイン* WSP CRLFドメイン=（サブドメイン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は、明示的またはTLSを使用するために任意の証明書をインストールに失敗により、サーバー管理者によって無効にすることができます。 MTQPサーバがTLSをサポートし、利用可能な1つ以上の証明書を持っている場合には、プロトコルの起動時にオプション仕様一覧に「STARTTLS」を含まなければなりません。
Note: TLS SHOULD be enabled on MQTP servers whenever possible.
注意：TLSは、可能な限り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"
「「/」「サポートされていない」「/」「利用できません」「/」「TLS進行中」「/」」悪い-FQDN：サーバーが否定応答を返した場合、それは以下の応答コードの1つを使用することができます
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がサポートされていない場合は、「/サポートされていない」の応答コードを使用すべきです。 TLSは、他の理由で利用できない場合は、「/利用不可」の応答コードを使用する必要があります。 TLSセッションが既に進行中である場合、それはプロトコルエラーであり、「-Bad」は「/ TLS進行中」の応答コードを返さなければなりません。サーバの証明書[RFC-X509]のsubjectAltName拡張ののdNSNameフィールドに見出さ供給FQDNとFQDNの間にミスマッチがある場合、それは、プロトコルエラーおよび「-Bad」の応答コードを返さなければなりませんです"/悪い-FQDN"。
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コマンドはグループ内の最後のコマンドでなければなりません。
If the TLS handshake fails, the server SHOULD abort the connection.
TLSハンドシェイクが失敗した場合、サーバーは接続を中止すべきです。
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クライアントとサーバーは、ほとんどのMTQPサービスは認証なし機密性なしで実行されているが、一部のMTQPクライアントまたはサーバが場合にのみ継続することもできますので、TLSネゴシエーションが認証なしおよび/または無機密で終了した場合でも前進するように決定することができます認証および/または機密性の特定のレベルを達成しました。
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クライアントは、認証や機密性のレベルは、それが継続するために十分に高くないと判断した場合、それはMTQPがTLSネゴシエーションが完了した直後に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コマンドに応答すべき-ERR 「レスポンスとのレスポンスコード 『/安全でありません』。
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.
（サーバの起動後MTQP状態）TLSハンドシェイクが完了すると、MTQPプロトコルは初期状態にリセットされます。サーバはTLS交渉自体に先立って、クライアントから得たすべての知識を捨てなければなりません。クライアントは、TLS交渉自体から得られなかったMTQPオプションのリストとして、サーバから取得したすべての知識を捨てなければなりません。
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ハンドシェイク後に受信MTQPサーバオプションのリストは、TLSハンドシェイクの前に返されたリストと異なっている必要があります。 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セッションを開始するのを試みてはいけません。
Syntax:
構文：
quit-command = "QUIT" CRLF
終了コマンド= CRLFを "QUIT"
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コマンドは、パラメータはありません。サーバーでは、正常な応答で応じなければなりません。 （クライアントはこれが問題を引き起こしていないオペレーティングシステム上にある場合）、クライアントはすぐにこのコマンドを発行した後、その端からセッションを閉じます。
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コマンドのバッチ内の最後のコマンドでなければなりません。
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：TRACK <追跡-ID> YWJjZGVmZ2gK S：+ OK +追跡情報は、Sの後に続く：S：...詳細＃1は、ここに行く追跡... S：。 C：TRACK <追跡-ID-2> QUJDREVGR0gK S：+ OK +追跡情報は、Sの後に続く：S：...詳細＃2は、ここに行く追跡... S：。
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：TRACK <追跡-ID> YWJjZGVmZ2gK C：TRACK <追跡-ID-2> QUJDREVGR0gK S：+ OK +追跡情報は、Sの後に続く：S：...詳細＃1は、ここに行く追跡... S：。 S：...ここにSを行く...追跡詳細＃2：S：+ OK +追跡情報は、Sを、次のとおりです。
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クエリを実行し、トラッキング状態情報を返します。
The name of the URI scheme is "mtqp".
URIスキームの名前は「mtqp」です。
An MTQP URI takes one of the following forms:
MTQP URIは、次のいずれかの形式をとります。
mtqp://<mserver>/track/<unique-envid>/<mtrk-secret> mtqp://<mserver>:<port>/track/<unique-envid>/<mtrk-secret>
mtqp：// <mserver> /トラック/ <ユニーク-ENVID> / <MTRK-秘密> mtqp：// <mserver>：<ポート> /トラック/ <ユニーク-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.
第二の形態は、非標準ポートを指定しつつ、第1の形式は、標準ポートにMTQPサーバを指すために使用されます。これらの形態の両方がTRACKコマンドが与えられた追跡ID（ユニーク-ENVID）と承認秘密（MTRK-秘密）を使用して発行することを指定します。パス要素「/トラック/」鈍感ケースを扱わなければならないが、ユニーク-ENVIDとMTRK-秘密がいるはずがありません。
This is an ABNF description of the MTQP URI.
これはMTQP URIのABNFの記述です。
mtqp-uri = "mtqp://" authority "/track/" unique-envid "/" mtrk-secret
mtqp-URI = "mtqp：//" 権威 "/トラック/" ユニーク-ENVID "/" MTRK秘密
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).
一意ENVIDの符号化は、[RFC-MTRK-ESMTP]で議論されています。 MTRK秘密はbase64エンコードする必要があります。もし "/"、 "？" 「％」オクテットがユニーク-ENVIDまたはMTRK秘密に表示され、それらはさらに2つの16進文字が続き、「％」で表現される必要があります。 （2つの文字は、そのオクテットの16進表現を与えます）。
System port number 1038 has been assigned to the Message Tracking Query Protocol by the Internet Assigned Numbers Authority (IANA).
システムのポート番号1038は、Internet Assigned Numbers Authority（IANA）によってメッセージ追跡照会プロトコルに割り当てられています。
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]に従って付録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:
MTQPオプション：この文書は、IANAは1新しいレジストリを維持することを要求します。レジストリの目的は、このプロトコルにオプションを登録することです。始まる名前のないオプション「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:
一つMTQPオプションは、以下の登録定義で、このドキュメントで定義されています。
option identifier: STARTTLS option parameters: none added commands: STARTTLS standard commands affected: none specification reference: RFC 3887 discussion: see RFC 3887
オプション識別子：STARTTLSのオプションパラメータ：なしコマンドを添加していない：STARTTLS標準影響を受けるコマンド：なし仕様参照：RFC 3887の議論：参照RFC 3887を
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 vendor-specific extension providing extended information by the owner of the "example.com" domain. These names MAY be registered with IANA.
このプロトコルのための追加ベンダー固有のオプションはで始まる名前を持っている「VNDを。」。 「VND。」後「」ベンダー、他のドットの逆転ドメイン名を表示され、オプション自体の名前です。例えば、「vnd.com.example.extinfo」「example.com」ドメインの所有者によって拡張情報を提供するベンダー固有の拡張子を表すかもしれません。これらの名前は、IANAに登録されるかもしれません。
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交渉の結果を注意してください。なし機密での交渉結果ならば、それはアルゴリズムや鍵長を使用して機密性につながる場合、または十分強くないとみなされている、または認証はいずれの当事者には十分でない場合、クライアントは即座にMTQPセッションを終了することもできますQUITコマンドを、またはサーバはそれ以上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.
man-in-the-middle攻撃は、サーバーから「STARTTLS」オプション応答を削除することによって起動することができます。これは、TLSセッションを開始しようとしていないクライアントを引き起こします。 MTQPクライアントは、特定のMTQPサーバが1つのセッション中にTLSを提供しているという事実を記録し、それが後のセッションのためのオプション応答に表示されていない場合にアラームを発生させることにより、この攻撃から保護することができます。
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.
同様に、サーバーの証明書に表されるようなサーバのIDはキャッシュされるべき、と彼らは、後のセッションで一致しない場合、アラームが発生しました。
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ハンドシェイクを実行し、サーバは紹介を連鎖している場合、サーバーは、次のホップで同じ（またはそれ以上）のセキュリティレベルでTLSを交渉しようとすべきです。ホップバイホップのシナリオでは、STARTTLSは、「ベストエフォート」のセキュリティのための要求であり、そのように扱われるべきです。
SASL is not used because authentication is per message rather than per user.
認証はメッセージごとではなく、ユーザーごとにあるので、SASLが使用されていません。
This is a collected ABNF description of the MTQP protocol.
これはMTQPプロトコルの収集ABNF記述です。
mtqp-uri = "mtqp://" authority "/track/" unique-envid "/" mtrk-secret
mtqp-URI = "mtqp：//" 権威 "/トラック/" ユニーク-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
トラック・コマンド= "TRACK" 1 * WSPユニーク-ENVID 1 * WSP MTRK秘密CRLFのMTRK秘密= BASE64
starttls-command = "STARTTLS" 1*WSP domain *WSP CRLF domain = (sub-domain 1*("." sub-domain))
STARTTLSコマンド= "STARTTLS" 1 * WSPドメイン* WSP CRLFドメイン=（サブドメイン1 *（ "" サブドメイン））
quit-command = "QUIT" CRLF
終了コマンド= CRLFを "QUIT"
comment-command = "COMMENT" opt-text CRLF
= "COMMENT" オプトインテキストCRLFコメント-コマンド
; server side command-response = success-response / temp-response / error-response / bad-response
;サーバー側のコマンド応答=成功応答/一時応答/エラー応答/悪い応答
temp-response = "-TEMP" response-info opt-text CRLF
=「-temp」応答情報オプトインテキストCRLF温度応答
opt-text = [WSP *(VCHAR / WSP)]
オプトテキスト= [* WSP（VCHAR / WSP）]
error-response = "-ERR" response-info opt-text CRLF
=「-ERR」応答情報オプトインテキストCRLFエラー応答
bad-response = "-BAD" response-info opt-text CRLF
悪い応答= "-bad" 応答情報OPT-テキストCRLF
success-response = single-line-success / multi-line-success
成功応答=シングルライン-成功/マルチライン-成功
single-line-success = "+OK" response-info opt-text CRLF
シングルライン-成功= "+ OK" 応答情報OPT-テキストCRLF
multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf
複数行-成功= "+ OK +" 応答情報オプトインテキストCRLF *データラインdotcrlf
dataline = *998OCTET CRLF
データライン= * 998OCTET CRLF
dotcrlf = "." CRLF
ドットCRLF = "" CRLF
NAMECHAR = ALPHA / DIGIT / "-" / "_"
NAMECHAR = ALPHA / DIGIT / " - " / "_"
response-info = *( "/" ( "admin" / "unavailable" / "unsupported" / "tls-in-progress" / "insecure" / "tls-required" / 1*NAMECHAR ) )
応答情報= *（ "/"（ "管理者" / "利用できない" / "サポートされていない" / "TLS進行中" / "安全でない" / "TLS-必要" / 1 * NAMECHAR））
The description of STARTTLS is based on [RFC-SMTP-TLS].
STARTTLSの説明は、[RFC-SMTP-TLS]に基づいています。
[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）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、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"、RFC 2234、1997年11月。
[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のSRV）サービスの位置を特定するためのDNS RR"、RFC 2782、2000年2月。
[RFC-SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC-SMTP] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[RFC-SMTPEXT] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[RFC-SMTPEXT]マイヤーズ、J.、 "認証のためのSMTPサービス拡張子"、RFC 2554、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サービス拡張"、RFC 3885、2004年9月。
[RFC-MTRK-MODEL] Hansen, T., "Message Tracking Models and Requirements", RFC 3885, September 2004.
[RFC-MTRK-MODEL]ハンセン、T.、 "メッセージ追跡モデルと要件"、RFC 3885、2004年9月。
[RFC-MTRK-TSN] Allman, E., "The Message/Tracking-Status MIME Extension", RFC 3886, September 2004.
[RFC-MTRK-TSN]オールマン、E.、 "メッセージ/トラッキングステータスMIME拡張"、RFC 3886、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、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[BCP35] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[BCP35] Petke、R.とI.キング、 "URLスキーム名の登録手順"、BCP 35、RFC 2717、1999年11月。
[RFC-SHA1] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC-SHA1]イーストレイク、D.とP.ジョーンズは、RFC 3174、2001年9月、 "米国は、ハッシュアルゴリズム1（SHA1）を固定します"。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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.、RFC 3207、2002年2月 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"。
[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.およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[NNTP] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[NNTP]カンター、B.およびP.ラプスリー、 "ネットワークニュース転送プロトコル"、RFC 977、1986年2月。
Appendix A. MTQP URI Registration Template
付録A. MTQP URI登録テンプレート
Scheme name: mtqp
スキーム名：mtqp
Scheme syntax: see section 9.1
Schemeの構文：セクション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-MODEL]、[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研究所ミドルタウン、NJ 07748 USA
Phone: +1.732.420.8934 EMail: tony+msgtrk@maillennium.att.com
電話：+1.732.420.8934電子メール：tony+msgtrk@maillennium.att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。