Subject: I-D ACTION:draft-ietf-msgtrk-mtqp-02.txt

From: [email-masked]
Date: Thu, 08 Mar 2001 06:57:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Message Tracking Protocol Working Group of the IETF.

	Title		: Message Tracking Query Protocol
	Author(s)	: T. Hansen
	Filename	: draft-ietf-msgtrk-mtqp-02.txt
	Pages		: 17
	Date		: 07-Mar-01
	
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 exten-
sions to the ESMTP protocol to provide a complete message tracking solu-
tion for the Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-mtqp-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-msgtrk-mtqp-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-msgtrk-mtqp-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Gregory Neil Shapiro <[email-masked]>
Date: Sat, 17 Mar 2001 16:40:00 -0800

> 2.  Basic Operation
> ...
> If the host is not found, the MTQP client then does an MX lookup for the
> server host using DNS MX records.

This line needs more explanation.  How are these MX records used?  Based on
preference?  Just the first?  How about when equal preferences?

> 2.1.  Tracking Service DNS Considerations
> ...
> In both cases, note that the tracking service for a given mail
> domain MUST be able to handle the queries for all messages destined for
> that mail domain.

Is sending a referral to another MTQP server sufficient in satisfying this
MUST?

> 2.3.  Responses
> ...
> All response lines are terminated by a CRLF pair and are limited to 998
> characters before the CRLF.

Just a note that this differs from RFC821's 512 character (including CRLF)
limit.  This probably doesn't matter.

> 3.  Initialization and Option Response
> ...
>     "/" "unavailable"
>     "/" "admin"
>     "/" "unknown"
>     "/" "referral" "=" net_loc

These should be defined.  Also net_loc should be defined somewhere.

> [Command sections]

Should we add a "HELP" command?

> 4.  TRACK Command
> ...
> Mtrk-secret is the secret A described in [RFC-TRACK-ESMTP], encoded using
> base64.

Reference RFC2045 for the definition of base64?

> 6.1.  Processing After the STARTTLS Command
> ...
> After the TLS handshake has been completed

What is TLS handshake can't be successfully completed?  RFC 2487BIS says:

   After receiving a 220 response to a STARTTLS command, the client MUST
   start the TLS negotiation before giving any other SMTP commands. If,
   after having issued the STARTTLS command, the client finds out that
   some failure prevents it from actually starting a TLS handshake, then
   it SHOULD abort the connection.

> 6.1.  Processing After the STARTTLS Command
> ...
> If the 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
> from the client (other than a QUIT command) with a negative "-BAD" response
> and a response code of "/insecure".

Should also accept the STARTTLS command to renegotiate, possibly with a
different client certificate to gain an acceptable level of authentication.
I'm not convinced that this is necessarily needed or a good idea, but it
may be worth considering.

> 9.  URL Format
> ...
>      mtqp://<mserver>/track/<envid>/<mtrk-secret>
>      mtqp://<mserver>:<port>/track/<envid>/<mtrk-secret>

In both cases, the mtrk-secret appears to be open for sniffing.  Do we need
an mtqps: to indicate STARTTLS is required?

> 9.1.  MTQP URL Syntax
> ...
>      mtqp-url = "mtqp://" net_loc "/track/" envid ":" mtrk-secret

This differs from the text directly above.  Above, envid and mtrk-secret
are separated by "/", here they are separated by ":".

> 11.  Security Considerations
> ...
> Both the STMP client and server must check the result of the TLS

Replace "STMP" with "MTQP".

> 11.  Security Considerations
> ...
> The SMTP client and server should note carefully the result of the
> TLS negotiation.

Replace "SMTP" with "MTQP".  Alternatively, remove this paragraph as it
pretty much repeats what is said in the previous paragraph.

> 12.  Protocol Syntax
> ...
>      client-command = track-command / starttls-command / quit-command / comment-command
> ...
>      command-response = success-response / temp-response / error-response / bad-response

Maybe wrap these better, e.g.:

      client-command = track-command / starttls-command / quit-command /
                       comment-command

      command-response = success-response / temp-response / error-response
                         bad-response

> 16.  Full Copyright Statement
> ...
>      Copyright (C) The Internet Society (1999).  All Rights Reserved.

This should probably include 2000 and 2001.