draft-ietf-msgtrk-mtqp-04.txt   draft-ietf-msgtrk-mtqp-05.txt 
Internet Draft T. Hansen Internet Draft T. Hansen
draft-ietf-msgtrk-mtqp-04.txt AT&T Laboratories draft-ietf-msgtrk-mtqp-05.txt AT&T Laboratories
Valid for six months November 20, 2001 Valid for six months January 14, 2002
Message Tracking Query Protocol Message Tracking Query Protocol
<draft-ietf-msgtrk-mtqp-04.txt> <draft-ietf-msgtrk-mtqp-05.txt>
Authors' version: 1.10 Authors' version: 1.13
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 4, line 20 skipping to change at page 4, line 20
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.
A mail system that uses a single mail server host and has the MTQP 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 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 A record. record pointing at the server host, and if not, will have an address
Both mail and MTQP clients will access that host directly. record. Both mail and MTQP clients will access that host directly.
A mail system that uses a single mail server host, but wants track- A mail system that uses a single mail server host, but wants track-
ing queries to be performed on a different machine, MUST have an SRV ing queries to be performed on a different machine, MUST have an SRV
MTQP record pointing at that different machine. MTQP record pointing at that different machine.
A mail system that uses multihomed mail servers has two choices for A mail system that uses multihomed mail servers has two choices for
providing tracking services: either all mail servers must be running providing tracking services: either all mail servers must be running
tracking servers that are able to retrieve information on all messages, tracking servers that are able to retrieve information on all messages,
or the tracking service must be performed on one (or more) machine(s) 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 that are able to retrieve information on all messages. In the former
skipping to change at page 6, line 9 skipping to change at page 6, line 9
A firewall mail gateway has two choices when receiving a tracking 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 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 informa- query that says the message has been passed on, but no further informa-
tion is available; or it may perform a chaining operation itself, tion is available; or it may perform a chaining operation itself,
gathering information on the message from the mail hosts behind the gathering information on the message from the mail hosts behind the
firewall, and returning to the MTQP client the information for each firewall, and returning to the MTQP client the information for each
behind-the-firewall hop, or possibly just the final hop information, behind-the-firewall hop, or possibly just the final hop information,
possibly also disguising the names of any hosts behind the firewall. possibly also disguising the names of any hosts behind the firewall.
Which option is picked is an adminstrative decision and is not further Which option is picked is an administrative decision and is not further
mandated by this document. mandated by this document.
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
skipping to change at page 8, line 42 skipping to change at page 8, line 42
S: Original-Recipient: rfc822; user1@example1.com S: Original-Recipient: rfc822; user1@example1.com
S: Final-Recipient: rfc822; user1@example1.com S: Final-Recipient: rfc822; user1@example1.com
S: Action: transferred S: Action: transferred
S: Remote-MTA: dns; 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: Status: 2.4.0
S: S:
S: --%%%%-- S: --%%%%--
S: . S: .
Example #8 Message Delayed and a DotStuffed Header: Example #8 Message Delayed and a Dot-Stuffed Header:
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK 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: ..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
skipping to change at page 10, line 16 skipping to change at page 10, line 16
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: rfc822; user1@example1.com S: Original-Recipient: rfc822; user1@example1.com
S: Final-Recipient: rfc822; user1@example1.com S: Final-Recipient: rfc822; user1@example1.com
S: Action: relayed S: Action: relayed
S: Status: 2.1.9 S: Status: 2.1.9
S: Remote-MTA: dns; example2.com S: Remote-MTA: dns; smtp.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: 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; smtp.example3.com S: Reporting-MTA: dns; smtp.example3.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: rfc822; user2@example1.com S: Original-Recipient: rfc822; user2@example1.com
skipping to change at page 10, line 50 skipping to change at page 10, line 50
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: rfc822; user1@example1.com S: Original-Recipient: rfc822; user1@example1.com
S: Final-Recipient: rfc822; user1@example1.com S: Final-Recipient: rfc822; user1@example1.com
S: Action: relayed S: Action: relayed
S: Status: 2.1.9 S: Status: 2.1.9
S: Remote-MTA: dns; example2.com S: Remote-MTA: dns; smtp.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: rfc822; user2@example1.com S: Original-Recipient: rfc822; user2@example1.com
S: Final-Recipient: rfc822; user4@example3.com S: Final-Recipient: rfc822; user4@example3.com
S: Action: delivered S: Action: delivered
S: Status: 2.5.0 S: Status: 2.5.0
S: S:
S: --%%%%-- S: --%%%%--
S: . S: .
skipping to change at page 12, line 24 skipping to change at page 12, line 24
enhancing TCP communications with privacy and authentication. An MTQP enhancing TCP communications with privacy and authentication. An MTQP
server MAY support TLS. If an MTQP server supports TLS, it MUST include server MAY support TLS. If an MTQP server supports TLS, it MUST include
"STARTTLS" in the option specifications list on protocol startup. "STARTTLS" in the option specifications list on protocol startup.
If the server returns a negative response, it MAY use one of the If the server returns a negative response, it MAY use one of the
following response codes: following response codes:
"/" "unsupported" "/" "unsupported"
"/" "unavailable" "/" "unavailable"
"/" "tlsinprogress" "/" "tlsinprogress"
If TLS is not suported, then a response code of "/unsupported" 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 SHOULD be used. If TLS is not available for some other reason, then a
reponse code of "/unavailable" SHOULD be used. If a TLS session is 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 already in progress, then it is a protocol error and "-BAD" MUST be
returned with a response code of "/tlsinprogress". returned with a response code of "/tlsinprogress".
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 (see below), the STARTTLS If the MTQP client is using pipelining (see below), the STARTTLS
command must be the last command in a group. command must be the last command in a group.
skipping to change at page 15, line 26 skipping to change at page 15, line 26
MUST include the following information as part of their definition: MUST include the following information as part of their definition:
option identifier option identifier
option parameters option parameters
added commands added commands
standard commands affected standard commands affected
specification reference specification reference
discussion discussion
One MTQP option is defined in this document: One MTQP option is defined in this document:
option identifier: STARTTLS option parameters: none added commands: option identifier: STARTTLS
STARTTLS standard commands affected: none specification reference: option parameters: none
RFC TBD discussion: see RFC TBD added commands: STARTTLS
standard commands affected: none
specification reference: RFC TBD
discussion: see RFC TBD
Additional vendor-specific options for this protocol have names Additional vendor-specific options for this protocol have names
that begin with "vnd.". After the "vnd." would appear the reversed that begin with "vnd.". After the "vnd." would appear the reversed
domain name of the vendor, another dot ".", and a name for the option domain name of the vendor, another dot ".", and a name for the option
itself. For example, "vnd.com.example.extinfo" might represent a itself. For example, "vnd.com.example.extinfo" might represent a
vendor-specific extension providing extended information by the owner of vendor-specific extension providing extended information by the owner of
the "example.com" domain. These names MAY be registered with IANA. the "example.com" domain. These names MAY be registered with IANA.
11. Security Considerations 11. Security Considerations
If the originator of a message were to delegate his or her tracking 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 request to a third party, this would be vulnerable to snooping over
unencrypted sessions. The user can decide on a message-by-message basis unencrypted sessions. The user can decide on a message-by-message basis
if this risk is acceptable. 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
sure further.
It should be noted that message tracking is not an end-to-end exposure further.
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 mechanism. Thus, if an MTQP client/server pair decide to use TLS
privacy, they are not securing tracking queries with any prior or suc- privacy, they are not securing tracking queries with any prior or suc-
cessive MTQP servers. cessive MTQP servers.
Both the MTQP client and server must check the result of the TLS Both the MTQP client and server must check the result of the TLS
negotiation to see whether acceptable authentication or privacy was negotiation to see whether acceptable authentication or privacy was
achieved. Ignoring this step completely invalidates using TLS for secu- achieved. Ignoring this step completely invalidates using TLS for secu-
rity. The decision about whether acceptable authentication or privacy rity. The decision about whether acceptable authentication or privacy
was achieved is made locally, is implementation-dependent, and is beyond was achieved is made locally, is implementation-dependent, and is beyond
the scope of this document. the scope of this document.
skipping to change at page 19, line 37 skipping to change at page 19, line 42
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 May 20, 2002. This document expires July 14, 2002.
 End of changes. 15 change blocks. 
18 lines changed or deleted 21 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/