[要約] RFC 3887は、メッセージトラッキングクエリプロトコルに関する仕様であり、メッセージの追跡とクエリを行うための方法を提供します。このRFCの目的は、メッセージの配信状況を追跡し、問い合わせるための標準化されたプロトコルを定義することです。
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）The Internet Society（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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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-abnf]、[rfc-uri]、[rfc-mtrk-esmtp]、[rfc-smtp]、または[rfc-smtpext]で定義されています。
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ルックアップを最初に行います。com。（詳細については、[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レコードを1つ持っており、そうでない場合はアドレスレコードがあります。メールと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.
マルチホームのメールサーバーを使用するメールシステムには、追跡サービスを提供するための2つの選択肢があります。すべてのメールサーバーがすべてのメッセージの情報を取得できるトラッキングサーバーを実行している必要があります。s）すべてのメッセージの情報を取得できます。前者の場合、メールシステムのMXレコードを超えて追加のDNSレコードは必要ありません。後者の場合、トラッキングサービスを実行しているマシンのポイントが必要な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のコマンドは、ケースに依存しないキーワードで構成され、おそらく1つ以上のパラメーターが続く可能性があります。すべてのコマンドはCRLFペアによって終了します。キーワードとパラメーターは、印刷可能なASCII文字で構成されています。キーワードとパラメーターは、Whitespace（1つ以上のスペースまたはタブ文字）で区切られています。コマンドラインは、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.
ステータスインジケータの後に、エラーに関するより多くのデータを提供する一連のマシンの分類可能なケース非感受性応答情報が続く場合があります。これらは、単一のスラッシュ文字（ "/"、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 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文字に制限されます。応答のすべての行が送信されると、最終行が1つの期間（「。」、10進コード046）およびCRLFペアで構成されます。マルチライン応答の任意のラインが期間から始まる場合、2番目の期間で期間を準備することにより、ラインは「ドットスタッフ」されます。マルチラインの応答を調べるとき、クライアントはラインが期間で始まるかどうかを確認します。もしそうなら、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.
MTQPクライアントによってTCP接続が開かれると、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"
"/" "利用できない"/"" 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つの初期ステータス応答のマルチライン応答としてリストされます。オプション仕様は識別子で構成され、オプションでオプション固有のパラメーターが続きます。オプション仕様は、空白で継続ラインを起動することにより、追加のラインに継続できます。オプション識別子は、症例鈍感です。文字「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.
この機能は、MQTPサーバーでオプションのstartTLSコマンドが有効になり、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を使用する必要がある場合、サーバーは「必須」パラメーターを指定する必要があります。
Example #1 (no options):
S: +OK/MTQP MTQP server ready
Example #2 (service temporarily unavailable):
S: -TEMP/MTQP/admin Service down for admin, call back later
Example #3 (service permanently unavailable):
S: -ERR/MTQP/unavailable Service down
Example #4 (alternative for no options):
S: +OK+/MTQP MTQP server ready
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: .
Syntax:
構文：
track-command = "TRACK" 1*WSP unique-envid 1*WSP mtrk-secret CRLF
mtrk-secret = base64
Unique-envid is defined in [RFC-MTRK-ESMTP]. Mtrk-secret is the secret A described in [RFC-MTRK-ESMTP], encoded using base64.
ユニーク環境は[RFC-MTRK-ESMTP]で定義されています。Mtrk-Secretは、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.
クライアントがトラックコマンドを発行し、ユーザーが検証された場合、MTQPサーバーは電子メールメッセージに関する追跡情報を取得します。ユーザーを検証するために、[RFC-Sha1]に記載されているように、Mtrk-Secretの値は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]ボディ部分で構成されるマルチラインでなければなりません。[RFC-MTRK-TSN]で定義されているように、MIMEボディの部分はタイプのマルチパート/関連で、メッセージ/追跡ステータスのサブパートである必要があります。応答には、指定された追跡IDを使用した電子メールメッセージに関する追跡情報が含まれています。トラックコマンドに対する否定的な応答には、これらの理由コードが含まれる場合があります。
"/" "tls-required" "/" "admin" "/" "unavailable" "/" "noinfo" "/" "insecure"
"/" "TLS-Required" "/" "admin" "/" "Unabailable" "/" noinfo "/" "Insecure"
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要求」という理由を使用する必要があります。接続が初期化されたため、管理上の理由により、サーバーが利用できなくなったときに「/admin」という理由を使用する必要があります。接続が初期化されたため、他の理由により、サーバーが利用できなくなったときに「/利用できない」コードを使用する必要があります。「/不安」という理由については、後で説明します。
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.
以下のそれぞれの例では、一意の環境は「<12345-20010101@example.com>」であり、秘密aは「abcdefgh」であり、sha1ハッシュbは（hex） "" 734D6D6D6E249F4E8DA270796C94 "です。メッセージは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: .
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: .
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: .
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: .
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:
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: .
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: .
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: .
Syntax:
構文：
comment-command = "COMMENT" opt-text CRLF
opt-text = [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.
クライアントがコメントコマンドを発行した場合、MTQPサーバーは成功した応答（OKまたはOK）で応答する必要があります。コメントコマンドに提供されるすべてのオプションテキストは無視されます。
Syntax:
構文：
starttls-command = "STARTTLS" 1*WSP domain *WSP CRLF
domain = (sub-domain 1*("." sub-domain))
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.
注：可能な限りMQTPサーバーでTLSを有効にする必要があります。
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"
サーバーが否定的な応答を返す場合、次の応答コードのいずれかを使用する場合があります： "/" "supported" "/" "" ""/"" tls-in-progress ""/"" bad-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がサポートされていない場合、「/サポートされていない」の応答コードを使用する必要があります。TLSが他の理由で利用できない場合は、「/利用できない」という応答コードを使用する必要があります。TLSセッションが既に進行中である場合、それはプロトコルエラーであり、「-BAD」は「/TLS-in-Progress」の応答コードで返される必要があります。供給されたFQDNとサーバーの証明書のsubmictaltname拡張機能のdnsnameフィールド[RFC-x509]のDNSNAMEフィールドに見つかったFQDNの間に不一致がある場合、それはプロトコルエラーであり、「-bad」は、「-bad」は応答コードで返される必要があります。「/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サービスが認証も機密性もなくても実行されていないため、TLS交渉が認証や機密性がなくなっていなくても先に進むことを決定する場合がありますが、一部の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交渉が完了した直後に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コマンドに[QUITコマンド以外）に返信する必要があります。「応答と「/Insecure」の応答コード」。
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交渉自体の前にクライアントから取得した知識を破棄する必要があります。クライアントは、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
quit-command = "quit" 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コマンドにはパラメーターがありません。サーバーは、成功した応答で応答する必要があります。クライアントは、このコマンドを発行した直後にセッションを終了から閉じることができます（クライアントが問題を引き起こさないオペレーティングシステムにいる場合）。
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: .
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: .
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>
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番目のフォームは非標準ポートを指定します。これらのフォームは両方とも、指定された追跡ID（一意環境）と承認秘密（MTRK-Secret）を使用してトラックコマンドが発行されることを指定しています。パス要素 "/act/"は、ケースを慎重に扱う必要がありますが、ユニークな環境とMtrk-Secretはそうであってはなりません。
This is an ABNF description of the MTQP URI.
これは、MTQP URIのABNF説明です。
mtqp-uri = "mtqp://" authority "/track/" unique-envid "/" mtrk-secret
mtqp-uri = "mtqp：//" authority "/track/" unique-envid "/" mtrk-secret
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]で説明されています。Mtrk-Secretは、base64エンコードされる必要があります。「/」の場合、 "？"「％」オクテットは、ユニーク環境またはMtrk-Secretに表示されます。さらに、「％」に続いて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は、インターネットに割り当てられた番号局（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:
このドキュメントは、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:
このドキュメントでは、次の登録定義があります。
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.
中間の攻撃は、サーバーから「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：//" authority "/track/" unique-envid "/" mtrk-secret
conversation = command-response *(client-command command-response)
conversation = command-response *（client-command command-response）
; client side client-command = track-command / starttls-command / quit-command /comment-command
;クライアントサイドクライアントコマンド=トラックコマンド / starttls-command / quit-command / comment-command
track-command = "TRACK" 1*WSP unique-envid 1*WSP mtrk-secret CRLF
mtrk-secret = base64
starttls-command = "STARTTLS" 1*WSP domain *WSP CRLF
domain = (sub-domain 1*("." sub-domain))
quit-command = "QUIT" CRLF
quit-command = "quit" crlf
comment-command = "COMMENT" opt-text CRLF
comment-command = "comment" opt-text crlf
; server side
command-response = success-response / temp-response / error-response /
bad-response
temp-response = "-TEMP" response-info opt-text CRLF
temp-response = "-temp" response-info opt-text crlf
opt-text = [WSP *(VCHAR / WSP)]
error-response = "-ERR" response-info opt-text CRLF
error-response = "-err" response-info opt-text crlf
bad-response = "-BAD" response-info opt-text CRLF
bad-response = "-bad" response-info opt-text crlf
success-response = single-line-success / multi-line-success
single-line-success = "+OK" response-info opt-text CRLF
シングルラインsuccess = "ok" response-info opt-text crlf
multi-line-success = "+OK+" response-info opt-text CRLF
*dataline dotcrlf
dataline = *998OCTET CRLF
dotcrlf = "." CRLF
dotcrlf = "。"CRLF
NAMECHAR = ALPHA / DIGIT / "-" / "_"
response-info = *( "/" ( "admin" / "unavailable" / "unsupported"
/ "tls-in-progress" / "insecure" / "tls-required" / 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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC-ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC-ABNF] Crocker、D.、ed。および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。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC-SMTPEXT] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[RFC-SMTPext] Myers、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] Allman、E。およびT. Hansen、「メッセージ追跡のためのSMTPサービス拡張」、RFC 3885、2004年9月。
[RFC-MTRK-MODEL] Hansen, T., "Message Tracking Models and Requirements", RFC 3885, September 2004.
[RFC-Mtrk-Model] Hansen、T。、「メッセージ追跡モデルと要件」、RFC 3885、2004年9月。
[RFC-MTRK-TSN] Allman, E., "The Message/Tracking-Status MIME Extension", RFC 3886, September 2004.
[RFC-MTRK-TSN] Allman、E。、「The Message/Tracking-Status Mime Extension」、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] Berners-Lee、T.、Fielding、R。and L. Masinter、「Uniform Resource Identiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「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. King、「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] Eastlake、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-Keywords] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Hoffman、P。、「輸送層のセキュリティ上の安全なSMTPのSMTPサービス拡張」、RFC 3207、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.、Polk、W.、Ford、W.、D。Solo、「インターネット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] Myers、J。and M. Rose、「郵便局プロトコル - バージョン3」、STD 53、RFC 1939、1996年5月。
[NNTP] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[NNTP] Kantor、B。およびP. Lapsley、「Network News Transfer Protocol」、RFC 977、1986年2月。
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-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ラボラトリーズミドルタウン、ニュージャージー07748 USA
Phone: +1.732.420.8934
EMail: tony+msgtrk@maillennium.att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。