draft-ietf-msgtrk-mtqp-02.txt   draft-ietf-msgtrk-mtqp-03.txt 
Internet Draft T. Hansen Internet Draft T. Hansen
draft-ietf-msgtrk-mtqp-02.txt AT&T Laboratories draft-ietf-msgtrk-mtqp-03.txt AT&T Laboratories
Valid for six months March 2, 2001 Valid for six months July 1, 2001
Message Tracking Query Protocol Message Tracking Query Protocol
<draft-ietf-msgtrk-mtqp-02.txt> <draft-ietf-msgtrk-mtqp-03.txt>
Authors' version: 1.6 Authors' version: 1.7
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
the messages? Message tracking is the ability to find out the path that the messages? Message tracking is the ability to find out the path that
a particular message has taken through a messaging system and the a particular message has taken through a messaging system and the
current routing status of that message. This document describes the current routing status of that message. This document describes the
Message Tracking Query Protocol that is used in conjunction with exten- Message Tracking Query Protocol that is used in conjunction with exten-
sions to the ESMTP protocol to provide a complete message tracking solu- sions to the ESMTP protocol to provide a complete message tracking solu-
tion for the Internet. tion for the Internet.
1. Introduction 1. Introduction
The Message Tracking Models and Requirements document [RFC-TRACK- The Message Tracking Models and Requirements document [DRAFT-
MODEL] discusses the models that message tracking solutions could fol- TRACK-MODEL] discusses the models that message tracking solutions could
low, along with requirements for a message tracking solution that can be follow, along with requirements for a message tracking solution that can
used with the Internet-wide message infrastructure. This memo and its be used with the Internet-wide message infrastructure. This memo and
companions, [RFC-TRACK-ESMTP] and [RFC-TRACK-TSN], describe a complete its companions, [DRAFT-TRACK-ESMTP] and [DRAFT-TRACK-TSN], describe a
message tracking solution that satisfies those requirements. The memo complete message tracking solution that satisfies those requirements.
[RFC-TRACK-ESMTP] defines an extension to the SMTP service that provides The memo [DRAFT-TRACK-ESMTP] defines an extension to the SMTP service
the information necessary to track messages. This memo defines a proto- that provides the information necessary to track messages. This memo
col that can be used to query the status of messages that have been defines a protocol that can be used to query the status of messages that
transmitted on the Internet via SMTP. The memo [RFC-TRACK-TSN] have been transmitted on the Internet via SMTP. The memo [DRAFT-TRACK-
describes the message/tracking-status MIME media type that is used to TSN] describes the message/tracking-status MIME media type that is used
report tracking status information. Using the model document's termi- to report tracking status information. Using the model document's ter-
nology, this solution uses active enabling and active requests with both minology, this solution uses active enabling and active requests with
request and chaining referrals. both request and chaining referrals.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-KEYWORDS]. document are to be interpreted as described in [RFC-KEYWORDS].
All syntax descriptions use the ABNF specified by [RFC-ABNF]. Ter- All syntax descriptions use the ABNF specified by [RFC-ABNF]. Ter-
minal nodes not defined elsewhere in this document are defined in [RFC- minal nodes not defined elsewhere in this document are defined in [RFC-
ABNF], [RFC-URI], [RFC-TRACK-ESMTP] or [RFC-SMTPEXT]. ABNF], [RFC-URI], [DRAFT-TRACK-ESMTP] or [RFC-SMTPEXT].
1.2. Changes Made for -02 1.2. Changes Made for -02
This section will be removed before publication. This section will be removed before publication.
Provided information on lookup for an MTQP server: SRV MTQP, then Provided information on lookup for an MTQP server: SRV MTQP, then
MX, then A. MX, then A.
Provided a section on firewall considerations Provided a section on firewall considerations
skipping to change at page 3, line 20 skipping to change at page 3, line 20
line-oriented Internet protocols, such as [POP3] and [NNTP]. Initially, line-oriented Internet protocols, such as [POP3] and [NNTP]. Initially,
the server host starts the MTQP service by listening on TCP port XXXX the server host starts the MTQP service by listening on TCP port XXXX
(TBD by IANA). (TBD by IANA).
When an MTQP client wishes to make use of the message tracking ser- When an MTQP client wishes to make use of the message tracking ser-
vice, it establishes a TCP connection with the server host. To find the vice, it establishes a TCP connection with the server host. To find the
server host, the MTQP client first does an SRV lookup for the server server host, the MTQP client first does an SRV lookup for the server
host using DNS SRV records, with a service name of "mtqp". (See the host using DNS SRV records, with a service name of "mtqp". (See the
"Usage rules" section in [RFC-SRV] for details.) If the host is not "Usage rules" section in [RFC-SRV] for details.) If the host is not
found, the MTQP client then does an MX lookup for the server host using found, the MTQP client then does an MX lookup for the server host using
DNS MX records. If the host is still not found, the MTQP client then DNS MX records, as specified in [RFC-DNS] and revised by [RFC-HOSTS].
does an A record lookup for the server host. If the host is still not found, the MTQP client then does an A record
lookup for the server host.
When the connection is established, the MTQP server sends a greet- When the connection is established, the MTQP server sends a greet-
ing. The MTQP client and MTQP server then exchange commands and ing. The MTQP client and MTQP server then exchange commands and
responses (respectively) until the connection is closed or aborted. responses (respectively) until the connection is closed or aborted.
2.1. Tracking Service DNS Considerations 2.1. Tracking Service DNS Considerations
Because of the ways server host lookups are performed, many dif- Because of the ways server host lookups are performed, many dif-
ferent tracking server host configurations are supported. ferent tracking server host configurations are supported.
skipping to change at page 5, line 36 skipping to change at page 5, line 36
3. Initialization and Option Response 3. Initialization and Option Response
Once the TCP connection has been opened by an MTQP client, the MTQP Once the TCP connection has been opened by an MTQP client, the MTQP
server issues an initial status response that indicates its readiness. server issues an initial status response that indicates its readiness.
If the status response is positive (+OK or +OK+), the client may proceed If the status response is positive (+OK or +OK+), the client may proceed
with other commands. with other commands.
The initial status response MUST include the response information The initial status response MUST include the response information
"/MTQP". Negative responses MUST include a reason code as response "/MTQP". Negative responses MUST include a reason code as response
information. The following reason codes are defined here; unrecognized information. The following reason codes are defined here; unrecognized
reason codes added in the future may be treated as equivalent to reason codes added in the future may be treated as equivalent to "una-
"unknown". vailable".
"/" "unavailable" "/" "unavailable"
"/" "admin" "/" "admin"
"/" "unknown"
"/" "referral" "=" net_loc The reason code "/admin" may be used when the service is unavail-
able for administrative reasons. The reason code "/unavailable" may be
used when the service is unavailable for other reasons.
If the server has any options enabled, they are listed as the If the server has any options enabled, they are listed as the
multi-line response of the initial status response, one per line. An multi-line response of the initial status response, one per line. An
option specification consists of an identifier, optionally followed by option specification consists of an identifier, optionally followed by
option-specific parameters. An option specification may be continued option-specific parameters. An option specification may be continued
onto additional lines by starting the continuation lines with white onto additional lines by starting the continuation lines with white
space. The option identifier is case insensitive. Option identifiers space. The option identifier is case insensitive. Option identifiers
beginning with the characters "vnd." are reserved for vendor use. beginning with the characters "vnd." are reserved for vendor use.
One option specification is defined here: One option specification is defined here:
skipping to change at page 6, line 31 skipping to change at page 6, line 33
S: . S: .
Example #5 (options available): Example #5 (options available):
S: +OK+/MTQP MTQP server ready S: +OK+/MTQP MTQP server ready
S: starttls S: starttls
S: Option2 with parameters S: Option2 with parameters
S: Option3 with a very long S: Option3 with a very long
S: list of parameters S: list of parameters
S: . S: .
Example #6 (Referred to another server):
S: -ERR/MTQP/referral=server42.example.com:37
4. TRACK Command 4. TRACK Command
Syntax: Syntax:
"TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF
mtrk-secret = base64 mtrk-secret = base64
Envid is defined in [RFC-TRACK-ESMTP]. Mtrk-secret is the secret A Envid is defined in [DRAFT-TRACK-ESMTP]. Mtrk-secret is the secret
described in [RFC-TRACK-ESMTP], encoded using base64. A described in [DRAFT-TRACK-ESMTP], encoded using base64.
When the client issues the TRACK command, and the user is vali- When the client issues the TRACK command, and the user is vali-
dated, the MTQP server retrieves tracking information about an email dated, the MTQP server retrieves tracking information about an email
message. To validate the user, the value of mtrk-secret is hashed using message. To validate the user, the value of mtrk-secret is hashed using
SHA1, as described in [NIST-SHA1]. The hash value is then compared with SHA1, as described in [NIST-SHA1]. The hash value is then compared with
the value passed with the message when it was originally sent. If the the value passed with the message when it was originally sent. If the
hash values match, the user is validated. hash values match, the user is validated.
A successful response MUST be multi-line, consisting of a [MIME] A successful response MUST be multi-line, consisting of a [MIME]
body part. The MIME body part must be of type multipart/related, with body part. The MIME body part must be of type multipart/related, with
subparts of message/tracking-status, as defined in [DRAFT-TRACK-TSN].
subparts of message/tracking-status, as defined in [RFC-TRACK-TSN]. The The response contains the tracking information about the email message
response contains the tracking information about the email message that that used the given tracking-id.
used the given tracking-id.
In each of the examples below, the envid is "<12345- In each of the examples below, the envid is "<12345-
20010101@example.com>", the secret A is "abcdefghijklmnopqrstuvwxyz", 20010101@example.com>", the secret A is "abcdefgh", and the SHA1 hash B
and the SHA1 hash B is TBD. The message came from example.com and the is (in hex) "734ba8b31975d0dbae4d6e249f4e8da270796c94". The message
MTQP server is example2.com. came from example.com and the MTQP server is example2.com.
Example #7 Message Delivered: Example #6 Message Delivered:
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo= C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
S: S:
S: --%%%% S: --%%%%
S: Content-Type: message/tracking-status S: Content-Type: message/tracking-status
S: S:
S: Original-Envelope-Id: 12345-20010101@example.com S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S: S:
S: Original-Recipient: user1 S: Original-Recipient: rfc822; user1@example1.com
S: Final-Recipient: user1 S: Final-Recipient: rfc822; user1@example1.com
S: Action: delivered S: Action: delivered
S: Status: 2.5.0
S:
S: --%%%%-- S: --%%%%--
S: . S: .
Example #8 Message Transferred: Example #7 Message Transferred:
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo= C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
S: S:
S: --%%%% S: --%%%%
S: Content-Type: message/tracking-status S: Content-Type: message/tracking-status
S: S:
S: Original-Envelope-Id: 12345-20010101@example.com S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S: S:
S: Original-Recipient: user1 S: Original-Recipient: rfc822; user1@example1.com
S: Final-Recipient: user1 S: Final-Recipient: rfc822; user1@example1.com
S: Action: transferred S: Action: transferred
S: Remote-MTA: example3.com S: Remote-MTA: dns; example3.com
S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500
S: Status: 2.4.0
S:
S: --%%%%-- S: --%%%%--
S: . S: .
Example #9 Message Delayed: Example #8 Message Delayed and a DotStuffed Header:
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo= C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
S: ..Dot-Stuffed-Header: as an example
S: S:
S: --%%%% S: --%%%%
S: Content-Type: message/tracking-status S: Content-Type: message/tracking-status
S: S:
S: Original-Envelope-Id: 12345-20010101@example.com S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S: S:
S: Original-Recipient: user1 S: Original-Recipient: rfc822; user1@example1.com
S: Final-Recipient: user1 S: Final-Recipient: rfc822; user1@example1.com
S: Action: delayed S: Action: delayed
S: Remote-MTA: example3.com 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: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500
S: Will-Retry-Until: Thu, 4 Jan 2001 15:15:15 -0500 S: Will-Retry-Until: Thu, 4 Jan 2001 15:15:15 -0500
S:
S: --%%%%-- S: --%%%%--
S: . S: .
Example #10 Two Users, One Relayed, One Failed: Example #9 Two Users, One Relayed, One Failed:
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo= C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
S: S:
S: --%%%% S: --%%%%
S: Content-Type: message/tracking-status S: Content-Type: message/tracking-status
S: S:
S: Original-Envelope-Id: 12345-20010101@example.com S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S: S:
S: Original-Recipient: user1 S: Original-Recipient: rfc822; user1@example1.com
S: Final-Recipient: user1 S: Final-Recipient: rfc822; user1@example1.com
S: Action: relayed S: Action: relayed
S: Remote-MTA: example3.com S: Status: 2.1.9
S: Remote-MTA: dns; example3.com
S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500
S: S:
S: Original-Recipient: user2 S: Original-Recipient: rfc822; user2@example1.com
S: Final-Recipient: user2 S: Final-Recipient: rfc822; user2@example1.com
S: Action: failed S: Action: failed
S: Remote-MTA: example3.com 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: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500
S:
S: --%%%%-- S: --%%%%--
S: . S: .
Example #11 Firewall, Hiding System Names Behind the Firewall: Example #10 Firewall, Hiding System Names Behind the Firewall:
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo=
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
S: S:
S: --%%%% S: --%%%%
S: Content-Type: message/tracking-status S: Content-Type: message/tracking-status
S: S:
S: Original-Envelope-Id: 12345-20010101@example.com S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S: S:
S: Original-Recipient: user1 S: Original-Recipient: rfc822; user1@example1.com
S: Final-Recipient: user1 S: Final-Recipient: rfc822; user1@example1.com
S: Action: relayed S: Action: relayed
S: Remote-MTA: example2.com S: Status: 2.1.9
S: Remote-MTA: dns; example2.com
S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500 S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500
S:
S: --%%%% S: --%%%%
S: Content-Type: message/tracking-status S: Content-Type: message/tracking-status
S: S:
S: Original-Envelope-Id: 12345-20010101@example.com S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500 S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S: S:
S: Original-Recipient: user1 S: Original-Recipient: rfc822; user1@example1.com
S: Final-Recipient: user1 S: Final-Recipient: rfc822; user1@example1.com
S: Action: delivered S: Action: delivered
S: Status: 2.5.0
S:
S: --%%%%-- S: --%%%%--
S: . S: .
5. COMMENT Command 5. COMMENT Command
Syntax: Syntax:
"COMMENT" opt-text CRLF "COMMENT" opt-text CRLF
opt-text = [WSP *(VCHAR / WSP)] opt-text = [WSP *(VCHAR / WSP)]
When the client issues the COMMENT command, the MTQP server MUST When the client issues the COMMENT command, the MTQP server MUST
respond with a successful response (+OK or +OK+). All optional text respond with a successful response (+OK or +OK+). All optional text
provided with the COMMENT command are ignored. provided with the COMMENT command are ignored.
6. STARTTLS Command 6. STARTTLS Command
Syntax: Syntax:
"STARTTLS" CRLF "STARTTLS" CRLF
TLS [TLS], more commonly known as SSL, is a popular mechanism for TLS [TLS], more commonly known as SSL, is a popular mechanism for
skipping to change at page 10, line 25 skipping to change at page 10, line 36
After receiving a positive response to a STARTTLS command, the After receiving a positive response to a STARTTLS command, the
client MUST start the TLS negotiation before giving any other MTQP com- client MUST start the TLS negotiation before giving any other MTQP com-
mands. mands.
If the MTQP client is using pipelining, the STARTTLS command must If the MTQP client is using pipelining, the STARTTLS command must
be the last command in a group. be the last command in a group.
6.1. Processing After the STARTTLS Command 6.1. Processing After the STARTTLS Command
If the TLS handshake fails, the server SHOULD abort the connection.
After the TLS handshake has been completed, both parties MUST After the TLS handshake has been completed, both parties MUST
immediately decide whether or not to continue based on the authentica- immediately decide whether or not to continue based on the authentica-
tion and privacy achieved. The MTQP client and server may decide to move tion and privacy achieved. The MTQP client and server may decide to move
ahead even if the TLS negotiation ended with no authentication and/or no ahead even if the TLS negotiation ended with no authentication and/or no
privacy because most MTQP services are performed with no authentication privacy because most MTQP services are performed with no authentication
and no privacy, but some MTQP clients or servers may want to continue and no privacy, but some MTQP clients or servers may want to continue
only if a particular level of authentication and/or privacy was only if a particular level of authentication and/or privacy was
achieved. achieved.
If the MTQP client decides that the level of authentication or If the MTQP client decides that the level of authentication or
privacy is not high enough for it to continue, it SHOULD issue an MTQP privacy is not high enough for it to continue, it SHOULD issue an MTQP
QUIT command immediately after the TLS negotiation is complete. If the QUIT command immediately after the TLS negotiation is complete. If the
MTQP server decides that the level of authentication or privacy is not MTQP server decides that the level of authentication or privacy is not
high enough for it to continue, it SHOULD reply to every MTQP command high enough for it to continue, it SHOULD reply to every MTQP command
from the client (other than a QUIT command) with a negative "-BAD"
from the client (other than a QUIT command) with a negative "-ERR"
response and a response code of "/insecure". response and a response code of "/insecure".
6.2. Result of the STARTTLS Command 6.2. Result of the STARTTLS Command
Upon completion of the TLS handshake, the MTQP protocol is reset to 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 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 server MUST discard any knowledge obtained from the client prior to the
TLS negotiation itself. The client MUST discard any knowledge obtained TLS negotiation itself. The client MUST discard any knowledge obtained
from the server, such as the list of MTQP options, which was not from the server, such as the list of MTQP options, which was not
obtained from the TLS negotiation itself. obtained from the TLS negotiation itself.
skipping to change at page 11, line 36 skipping to change at page 11, line 50
The MTQP client may elect to transmit groups of MTQP commands in The MTQP client may elect to transmit groups of MTQP commands in
batches without waiting for a response to each individual command. The batches without waiting for a response to each individual command. The
MTQP server MUST process the commands in the order received. MTQP server MUST process the commands in the order received.
Specific commands may place further constraints on pipelining. For Specific commands may place further constraints on pipelining. For
example, STARTTLS must be the last command in a batch of MTQP commands. example, STARTTLS must be the last command in a batch of MTQP commands.
The following two examples are identical: The following two examples are identical:
Example #12 : Example #11 :
C: TRACK <tracking-id> 1234567890ABCDEF C: TRACK <tracking-id> YWJjZGVmZ2gK
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: S:
S: ... tracking details #1 go here ... S: ... tracking details #1 go here ...
S: . S: .
C: TRACK <tracking-id-2> ABCDEF1234567890 C: TRACK <tracking-id-2> QUJDREVGR0gK
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: S:
S: ... tracking details #2 go here ... S: ... tracking details #2 go here ...
S: . S: .
Example #13 : Example #12 :
C: TRACK <tracking-id> 1234567890ABCDEF C: TRACK <tracking-id> YWJjZGVmZ2gK
C: TRACK <tracking-id-2> ABCDEF1234567890 C: TRACK <tracking-id-2> QUJDREVGR0gK
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: S:
S: ... tracking details #1 go here ... S: ... tracking details #1 go here ...
S: . S: .
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: S:
S: ... tracking details #2 go here ... S: ... tracking details #2 go here ...
S: . S: .
9. URL Format 9. URL Format
The MTQP URL scheme is used to designate MTQP servers on Internet The MTQP URL scheme is used to designate MTQP servers on Internet
skipping to change at page 13, line 15 skipping to change at page 13, line 29
begin with "vnd." MUST be registered with IANA on a Firt Come First begin with "vnd." MUST be registered with IANA on a Firt Come First
Served basis. It is expected that after the "vnd." would appear an Served basis. It is expected that after the "vnd." would appear an
abbreviated form of the vendor's name that is registering the option, abbreviated form of the vendor's name that is registering the option,
followed by a second dot "." and a name for the option itself. For followed by a second dot "." and a name for the option itself. For
example, "vnd.example.extinfo" might represent a vendor-specific exten- example, "vnd.example.extinfo" might represent a vendor-specific exten-
sion providing extended information being registered by the "Example, sion providing extended information being registered by the "Example,
Inc." company. Inc." company.
11. Security Considerations 11. Security Considerations
Security considerations discussed in [RFC-TRACK-MODEL] and [RFC- If the originator of a message were to delegate his or her tracking
TRACK-ESMTP] are relevant. 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 The security of tracking information is dependent on the randomness
of the secret chosen for each message and the level of exposure of that 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 max- secret. If different secrets are used for each message, then the max-
imum exposure from tracking any message will be that single message for imum exposure from tracking any message will be that single message for
the time that the tracking information is kept on any MTQP server. If 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 expo- this level of exposure is too much, TLS may be used to reduce the expo-
sure further. sure further.
It should be noted that message tracking is not an end-to-end It should be noted that message tracking is not an end-to-end
skipping to change at page 14, line 15 skipping to change at page 14, line 30
If TLS is not used, a tracking request is vulnerable to replay 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 attacks, such that a snoop can later replay the same handshake again to
potentially gain more information about a message's status. potentially gain more information about a message's status.
Before the TLS handshake has begun, any protocol interactions are Before the TLS handshake has begun, any protocol interactions are
performed in the clear and may be modified by an active attacker. For performed in the clear and may be modified by an active attacker. For
this reason, clients and servers MUST discard any knowledge obtained this reason, clients and servers MUST discard any knowledge obtained
prior to the start of the TLS handshake upon completion of the TLS prior to the start of the TLS handshake upon completion of the TLS
handshake. handshake.
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 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.
SASL is not used because authentication is per message rather than
per user.
12. Protocol Syntax 12. Protocol Syntax
This is a collected ABNF description of the MTQP protocol. This is a collected ABNF description of the MTQP protocol.
conversation = command-response *( client-command command-response ) conversation = command-response *( client-command command-response )
# client side # client side
client-command = track-command / starttls-command / quit-command / comment-command client-command = track-command / starttls-command / quit-command / comment-command
track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF
skipping to change at page 15, line 37 skipping to change at page 16, line 16
col", University of Southern California / Information Sciences Insti- col", University of Southern California / Information Sciences Insti-
tute, August 1982. tute, August 1982.
[RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of [RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of
ARPA Internet Text Messages", University of Delaware, August 1982. ARPA Internet Text Messages", University of Delaware, August 1982.
[RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented
BNF for Syntax Specifications: ABNF", Internet Mail Consortium, Demon BNF for Syntax Specifications: ABNF", Internet Mail Consortium, Demon
Internet Ltd., November 1997. Internet Ltd., November 1997.
[RFC-DNS] RFC 974, "Mail routing and the domain system", C. Par-
tridge, January 1986.
[RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud, [RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud,
and D. Crocker, "SMTP Service Extensions", MCI, Innosoft, Dover Beach and D. Crocker, "SMTP Service Extensions", MCI, Innosoft, Dover Beach
Consulting, Inc., network Management Associates, Inc., Silicon Graphics, Consulting, Inc., network Management Associates, Inc., Silicon Graphics,
Inc., July 1994. Inc., July 1994.
[RFC-HOSTS] "Requirements for Internet Hosts - Application and Sup-
port", R. Braden, Ed., October 1989.
[RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to
Indicate Requirement Levels", Harvard University, March 1997. Indicate Requirement Levels", Harvard University, March 1997.
[RFC-MD5] RFC 1321, R. Rivest, "The MD5 Message-Digest Algorithm", [RFC-MD5] RFC 1321, R. Rivest, "The MD5 Message-Digest Algorithm",
MIT Laboratory for Computer Science and RSA Data Security, Inc., April MIT Laboratory for Computer Science and RSA Data Security, Inc., April
1992. 1992.
[RFC-SMTPEXT] RFC 2554, J. Myers, "SMTP Service Extension for [RFC-SMTPEXT] RFC 2554, J. Myers, "SMTP Service Extension for
Authentication", Netscape Communications, March 1999. Authentication", Netscape Communications, March 1999.
[RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for [RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for
Secure SMTP over TLS", Internet Mail Consortium, January 1999. Secure SMTP over TLS", Internet Mail Consortium, January 1999.
[RFC-SRV] RFC 2782, A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR [RFC-SRV] RFC 2782, A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR
for specifying the location of services (DNS SRV)" Troll Technologies, for specifying the location of services (DNS SRV)" Troll Technologies,
Internet Software Consortium, Microsoft Corp., February 2000 Internet Software Consortium, Microsoft Corp., February 2000
[RFC-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T. [DRAFT-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T.
Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc., Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc.,
AT&T Laboratories, TBD 2000. AT&T Laboratories, TBD 2000.
[RFC-TRACK-MODEL] draft-ietf-msgtrk-model-03.txt, T. Hansen, "Mes- [DRAFT-TRACK-MODEL] draft-ietf-msgtrk-model-03.txt, T. Hansen,
sage Tracking Models and Requirements", AT&T Laboratories, November "Message Tracking Models and Requirements", AT&T Laboratories, November
2000. 2000.
[RFC-TRACK-TSN] draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The [DRAFT-TRACK-TSN] draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The
Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2000. Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2000.
[RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni- [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni-
form Resource Identifiers (URI): Generic Syntax", MIT/LCS, U. C. Irvine, form Resource Identifiers (URI): Generic Syntax", MIT/LCS, U. C. Irvine,
Xerox Corporation, August 1998. Xerox Corporation, August 1998.
15. Author's Address 15. Author's Address
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
skipping to change at page 17, line 15 skipping to change at page 17, line 48
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
This document expires August 2, 2001. This document expires January 1, 2002.
 End of changes. 52 change blocks. 
81 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/