Network Working Group T. Hansen
Request for Comments: 3887 AT&T Laboratories
Category: Standards Track September 2004
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协议扩展一起使用的消息跟踪查询协议，以提供完整的Internet消息跟踪解决方案。
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在Internet上传输的邮件的状态。备忘录[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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC-关键词]中的描述进行解释。
All syntax descriptions use the ABNF specified by [RFC-ABNF]. Terminal nodes not defined elsewhere in this document are defined in [RFC-ABNF], [RFC-URI], [RFC-MTRK-ESMTP], [RFC-SMTP], or [RFC-SMTPEXT].
所有语法描述都使用[RFC-ABNF]指定的ABNF。本文档其他地方未定义的终端节点在[RFC-ABNF]、[RFC-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客户端首先使用DNS SRV记录对服务器主机执行SRV查找，服务名称为“MTQP”，协议名称为“tcp”，如_MTQP._tcp.smtp3.example.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记录，如果没有，则将具有地址记录。邮件和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.
使用多址邮件服务器的邮件系统有两种提供跟踪服务的选择：所有邮件服务器必须运行能够检索所有邮件信息的跟踪服务器，或者必须在能够检索所有邮件信息的一台（或多台）计算机上执行跟踪服务。在前一种情况下，除了邮件系统已有的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中的命令由不区分大小写的关键字组成，后面可能跟有一个或多个参数。所有命令都由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
在多行成功响应中，每个后续行由CRLF对终止，并限制在CRLF前998个字符。当响应的所有行都已发送时，将发送由单个句点（“.”，十进制代码046）和CRLF对组成的最后一行。如果多行响应的任何一行以句点开头，则该行通过在句点前加上第二个句点而“填满”句点
period. When examining a multi-line response, the client checks to see if the line begins with a period. If so, and octets other than CRLF follow, the first octet of the line (the period) is stripped away. If so, and if CRLF immediately follows the period, then the response from the MTQP server is ended and the line containing the ".CRLF" is not considered part of the multi-line response.
时期当检查多行响应时，客户机会检查该行是否以句点开头。如果是这样的话，然后是除CRLF之外的八位字节，则该行的第一个八位字节（周期）将被剥离。如果是，并且CRLF紧跟在时段之后，则来自MTQP服务器的响应结束，并且包含“.CRLF”的行不被视为多行响应的一部分。
An MTQP server MUST respond to an unrecognized, unimplemented, or syntactically invalid command by responding with a negative -BAD status indicator. A server MUST respond to a command issued when the session is in an incorrect state by responding with a negative -ERR status indicator.
MTQP服务器必须响应无法识别、未实现或语法无效的命令，方法是使用负-坏状态指示器进行响应。服务器必须响应会话处于错误状态时发出的命令，方法是使用负-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.
防火墙邮件网关在接收域内主机的跟踪查询时有两种选择：它可能会返回对查询的响应，表示消息已传递，但没有其他可用信息；或者，它可以自己执行链接操作，从防火墙后面的邮件主机收集消息信息，并将每个防火墙后跃点的信息返回给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"
/“不可用”/“管理员”
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.)
如果服务器启用了任何选项，它们将作为初始状态响应的多行响应列出，每行一个。选项规范由标识符组成，可选地后跟选项特定的参数。选项规范可以通过在续行的开头加上空白来继续到其他行上。选项标识符不区分大小写。以字符“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.
如果在MQTP服务器上启用了可选的STARTTLS命令，并且正确安装了一个或多个证书，则必须列出此功能。
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.
它有一个可选参数：单词“required”（STARTTLS的参数不区分大小写）。如果服务器要求将TLS用于服务器处理的某些域，则服务器必须指定“required”参数。
Example #1 (no options):
S: +OK/MTQP MTQP server ready
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 #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 #3 (service permanently unavailable):
S: -ERR/MTQP/unavailable Service down
Example #4 (alternative for no options):
S: +OK+/MTQP MTQP server ready
S: .
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: .
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
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]中定义了唯一的envid。Mtrk秘密是[RFC-Mtrk-ESMTP]中描述的秘密，使用base64编码。
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服务器检索有关电子邮件的跟踪信息。为了验证用户，使用SHA1对mtrk secret的值进行散列，如[RFC-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正文部分必须为multipart/related类型，具有[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 required”。在连接初始化后，由于管理原因服务器变得不可用时，应使用原因代码“/admin”。由于连接初始化后的其他原因，当服务器变得不可用时，应使用原因代码“/unavailable”。原因代码“/不安全”将在后面描述。
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服务器未看到消息，则服务器必须在两种选择中进行选择：它可能返回肯定响应，跟踪信息中的操作字段为“不透明”，或者它可能返回否定响应，原因代码为“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”。消息来自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 #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 #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 #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 #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:
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: .
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 #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: .
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)]
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.
当客户端发出COMMENT命令时，MTQP服务器必须以成功响应（+OK或+OK+）进行响应。将忽略COMMENT命令提供的所有可选文本。
Syntax:
语法：
starttls-command = "STARTTLS" 1*WSP domain *WSP CRLF
domain = (sub-domain 1*("." sub-domain))
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并具有一个或多个可用证书，则必须在协议启动时在选项规范列表中包含“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"
如果服务器返回否定响应，它可能会使用以下响应代码之一：“/”不支持“/”不可用“/”tls正在进行“/”错误fqdn”
If TLS is not supported, then a response code of "/unsupported" SHOULD be used. If TLS is not available for some other reason, then a response code of "/unavailable" SHOULD be used. If a TLS session is already in progress, then it is a protocol error and "-BAD" MUST be returned with a response code of "/tls-in-progress". If there is a mismatch between the supplied FQDN and the FQDN found in the dNSName field of the subjectAltName extension of the server's certificate [RFC-X509], then it is a protocol error and "-BAD" MUST be returned with a response code of "/bad-fqdn".
如果不支持TLS，则应使用响应代码“/不支持”。如果TLS因其他原因不可用，则应使用响应代码“/不可用”。如果TLS会话已经在进行中，则它是一个协议错误，并且必须返回“-BAD”，响应代码为“/TLS in progress”。如果提供的FQDN与在服务器证书[RFC-X509]的subjectAltName扩展名的dNSName字段中找到的FQDN不匹配，则这是一个协议错误，必须返回“-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客户端和服务器可能会决定继续，即使TLS协商在没有身份验证和/或保密的情况下结束，因为大多数MTQP服务都是在没有身份验证和保密的情况下执行的，但是，某些MTQP客户端或服务器可能只希望在达到特定身份验证和/或保密级别时继续。
If the MTQP client decides that the level of authentication or confidentiality is not high enough for it to continue, it SHOULD issue an MTQP QUIT command immediately after the TLS negotiation is complete.
如果MTQP客户端确定身份验证或保密级别不足以继续，则应在TLS协商完成后立即发出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服务器确定身份验证或机密级别不够高，无法继续，则可能会中止连接。如果它确定身份验证或机密性级别不足以继续，并且没有中止连接，则它应使用否定“-ERR”响应和响应代码“/unsecure”回复来自客户端的每个MTQP命令（退出命令除外）。
Upon completion of the TLS handshake, the MTQP protocol is reset to the initial state (the state in MTQP after a server starts up). The server MUST discard any knowledge obtained from the client prior to the TLS negotiation itself. The client MUST discard any knowledge obtained from the server, such as the list of MTQP options, which was not obtained from the TLS negotiation itself.
TLS握手完成后，MTQP协议重置为初始状态（服务器启动后MTQP中的状态）。在TLS协商之前，服务器必须放弃从客户端获得的任何知识。客户机必须放弃从服务器获得的任何知识，如MTQP选项列表，这些不是从TLS协商本身获得的。
At the end of the TLS handshake, the server acts as if the connection had been initiated and responds with an initial status response and, optionally, a list of server options. The list of MTQP server options received after the TLS handshake MUST be different than the list returned before the TLS handshake. In particular, a server MUST NOT return the STARTTLS option in the list of server options after a TLS handshake has been completed.
在TLS握手结束时，服务器的行为就像连接已经启动一样，并以初始状态响应和服务器选项列表（可选）进行响应。TLS握手后收到的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命令=“退出”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:
以下两个示例是相同的：
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 #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: .
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协议访问的Internet主机上的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>/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服务器，而第二个表单指定非标准端口。这两种形式都指定使用给定的跟踪id（唯一envid）和授权密钥（mtrk密钥）发出跟踪命令。path元素“/track/”必须不区分大小写，但不能区分唯一的envid和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]中讨论了唯一envid的编码。Mtrk机密需要进行base64编码。如果“/”、“？”和“%”八位字节出现在唯一的envid或mtrk密码中，则它们还需要用“%”表示，后跟两个十六进制字符。（这两个字符表示该八位字节的十六进制表示）。
System port number 1038 has been assigned to the Message Tracking Query Protocol by the Internet Assigned Numbers Authority (IANA).
Internet分配号码管理局（IANA）已将系统端口号1038分配给消息跟踪查询协议。
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维护一个新的注册表：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:
本文件中定义了一个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
此协议的其他供应商特定选项的名称以“vnd”开头。在“vnd.”之后会出现供应商的反向域名、另一个点“.”，以及选项本身的名称。例如，“vnd.com.example.exterfo”可能表示
vendor-specific extension providing extended information by the owner of the "example.com" domain. These names MAY be registered with IANA.
特定于供应商的扩展，由“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会话，或者服务器可以选择不接受任何更多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服务器在一个会话期间提供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.
类似地，应该缓存服务器证书中表示的服务器标识，如果它们在以后的会话中不匹配，则会生成警报。
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握手开始之前，任何协议交互都会在clear中执行，并且可能会被活动攻击者修改。因此，在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)
对话=命令响应*（客户端命令响应）
; client side
client-command = track-command / starttls-command / quit-command
/comment-command
; client side
client-command = track-command / starttls-command / quit-command
/comment-command
track-command = "TRACK" 1*WSP unique-envid 1*WSP mtrk-secret CRLF
mtrk-secret = base64
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))
starttls-command = "STARTTLS" 1*WSP domain *WSP CRLF
domain = (sub-domain 1*("." sub-domain))
quit-command = "QUIT" CRLF
quit命令=“退出”CRLF
comment-command = "COMMENT" opt-text CRLF
comment command=“comment”选择文本CRLF
; server side
command-response = success-response / temp-response / error-response /
bad-response
; server side
command-response = success-response / temp-response / error-response /
bad-response
temp-response = "-TEMP" response-info opt-text CRLF
temp response=“-temp”响应信息选项文本CRLF
opt-text = [WSP *(VCHAR / WSP)]
opt-text = [WSP *(VCHAR / WSP)]
error-response = "-ERR" response-info opt-text CRLF
错误响应=“-ERR”响应信息选项文本CRLF
bad-response = "-BAD" response-info opt-text CRLF
错误响应=“-bad”响应信息选项文本CRLF
success-response = single-line-success / multi-line-success
success-response = single-line-success / multi-line-success
single-line-success = "+OK" response-info opt-text CRLF
单行成功=“+OK”响应信息选项文本CRLF
multi-line-success = "+OK+" response-info opt-text CRLF
*dataline dotcrlf
multi-line-success = "+OK+" response-info opt-text CRLF
*dataline dotcrlf
dataline = *998OCTET CRLF
dataline = *998OCTET CRLF
dotcrlf = "." CRLF
dotcrlf=“”CRLF
NAMECHAR = ALPHA / DIGIT / "-" / "_"
NAMECHAR = ALPHA / DIGIT / "-" / "_"
response-info = *( "/" ( "admin" / "unavailable" / "unsupported"
/ "tls-in-progress" / "insecure" / "tls-required" / 1*NAMECHAR ) )
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，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年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.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC-SMTPEXT] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[RFC-SMTPEXT]迈尔斯，J.，“用于身份验证的SMTP服务扩展”，RFC 25541999年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 38852004年9月。
[RFC-MTRK-MODEL] Hansen, T., "Message Tracking Models and Requirements", RFC 3885, September 2004.
[RFC-MTRK-MODEL]Hansen，T，“消息跟踪模型和需求”，RFC 38852004年9月。
[RFC-MTRK-TSN] Allman, E., "The Message/Tracking-Status MIME Extension", RFC 3886, September 2004.
[RFC-MTRK-TSN]Allman，E.“消息/跟踪状态MIME扩展”，RFC 38862004年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.和L.Masinter，“统一资源标识符（URI）：通用语法”，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，“美国安全哈希算法1（SHA1）”，RFC 31742001年9月。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-关键词]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 32802002年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]Kantor，B.和P.Lapsley，“网络新闻传输协议”，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
Phone: +1.732.420.8934
EMail: tony+msgtrk@maillennium.att.com
Phone: +1.732.420.8934
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。