Subject: Re: AD review of msgtrk documents

From: Eric Allman <[email-masked]>
Date: Wed, 23 Oct 2002 09:54:17 -0700

Ned, et al,

Enclosed is the update of smtpext-03 and trkstat-03 per your
comments.  These are still in "draft" format; please let me know if
you want me to update them to "RFC" format.

eric

---

From: Tony Hansen <[email-masked]>
Date: Thu, 24 Oct 2002 22:14:42 -0400

ditto for model-07 and mtqp-09

	Tony

> you want me to update them to "RFC" format.

Internet Draft                                                 T. Hansen
draft-ietf-msgtrk-model-07.txt                         AT&T Laboratories
Valid for six months                                    October 24, 2002

                Message Tracking Model and Requirements

                    <draft-ietf-msgtrk-model-07.txt>

                         Authors' version: 1.20

     Status of this Memo

     This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents at
any time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

     The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

     This memo and its companions are discussed on the MSGTRK working
group mailing list, [email-masked].  To subscribe, send a message
with the word "subscribe" in the body (on a line by itself) to the
address [email-masked].  An archive of the mailing list may
be found at http://www.ietf.org/archive/msgtrk.

Copyright Notice

     Copyright (C) The Internet Society (%Dy%).  All Rights Reserved.

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 provides a model

Hansen                                                          [Page 1]

Internet Draft  Message Tracking Model and Requirements October 24, 2002

of message tracking that can be used for understanding the Internet-wide
message infrastructure and to further enhance those capabilities to
include message tracking, as well as requirements for proposed message
tracking solutions.

1.  Problem Statement

     Consider sending a package through a package delivery company.
Once you've sent a package, you would like to be able to find out if the
package has been delivered or not, and if not, where that package
currently is and what its status is.  Note that the status of a package
may not include whether it was delivered to its addressee, but just the
destination.  Many package carriers provide such services today, often
via a web interface.

     Message tracking extends that capability to the Internet-wide mes-
sage infrastructure, analogous to the service provided by package car-
riers:  the ability to quickly locate where a message (package) is, and
to determine whether or not the message (package) has been delivered to
its final destination.  An Internet-standard approach will allow the
development of message tracking applications that can operate in a
multi-vendor messaging environment, and will encourage the operation of
the function across administrative boundaries.

     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 RFC 2119 [RFC-KEYWORDS].

2.  Definitions
The following terms are relevant to message tracking.  The terms Track-
ing User Agent and Tracking Server are new, while all other terms have
been collected here from other sources.

     Originating Mail User Agent (MUA)
               The originating mail user agent is the software used to
               compose and originate a message.  It is the software sit-
               ting on a person's desktop.

     Originating Mail Submission Agent (MSA)
               The Mail Submission Agent accepts a message from a User
               Agent, adds or modifies it as required for Internet stan-
               dards and/or site policy, and injects the message into
               the network.  The MSA may be the initial MTA or may hand
               off the message to an MTA.

     Message Transfer Agent (MTA)
               A Message Transfer Agent accepts a message and moves it
               forward towards its destination.  That destination may be

Hansen                                                          [Page 2]

Internet Draft  Message Tracking Model and Requirements October 24, 2002

               local or reached via another MTA.  It may use a local
               queue to store the message before transferring it
               further.  Any MTA may generate a Non-Delivery Notifica-
               tion.

     Intermediate Message Transfer Agent (MTA)
               An Intermediate MTA is an MTA that accepts a message for
               transfer somewhere else.

     Final Message Transfer Agent (MTA)
               A Final MTA is an MTA that accepts a message for local
               delivery.  It is the final place that a message is
               accepted.  The final MTA is what sends any Delivery
               Status Notifications (DSNs).  (Intermediate MTA's may
               also send a DSN if it relays to a non-DSN aware MTA.)

     Foreign Message Transfer Agent
               A foreign MTA provides delivery of messages using other
               protocols than those specified for Internet mail, such as
               an X.400 mail system.

     Gateway Message Transfer Agent (GW-MTA)
               A gateway MTA accepts a message for transfer to a foreign
               MTA outside of the Internet protocol space.

     Local Delivery Agent (LDA)
               The local Delivery Agent delivers the message to the
               local message store.  (The MTA and LDA are often combined
               into the same program.)

     Delivery Status Notification (DSN)
               A Delivery Status Notification [RFC-DSN] is produced by
               an MTA when a message is unsuccessfully delivered, either
               to its next hop or the final message store, or when it is
               successfully delivered, either to a foreign MTA, to a
               local delivery agent, or a non-DSN aware MTA.  Positive
               notifications are only performed [RFC-ESMTP-DSN] when
               specifically requested.

     Non-Delivery Notification (NDN)
               A non-delivery notification is a special form of DSN
               indicating unsuccessful delivery.

     Message Disposition Notification (MDN)
               A Message Disposition Notification is used to report the
               disposition of a message after it has been successfully
               delivered to a recipient.

Hansen                                                          [Page 3]

Internet Draft  Message Tracking Model and Requirements October 24, 2002

     Tracking User Agent (TUA)
               A tracking user agent wants to find information on a mes-
               sage on the behalf of a user.  It is the requestor or
               initiator of such a request.  (The MUA and TUA could be
               combined into the same program.)

     Tracking Server
               A tracking server provides tracking information to a
               tracking client.  It is the repository of the information
               about a message for the traversal through a particular
               MTA.  (The tracking server and MTA may run on the same
               system.)

3.  Entities

     The entities involved in message tracking are:  message user
agents, message submission agents, message transfer agents, tracking
user agents and tracking servers.

4.  Requirements

     These are requirements that any message tracking solution must be
able to satisfy:

     The message tracking solution:

     **   MUST scale to the internet.

     **   MUST be easy to deploy.

     **   SHOULD maximize the reuse of existing, already deployed tech-
          nology and infrastructure.

     **   If possible, SHOULD extend existing protocols and not invent
          new ones.

     **   SHOULD have a low implementation cost.  (This makes it easy to
          incorporate into existing products.)

     **   MUST restrict tracking of a message to the originator of the
          message (or a delegate).

     **   MUST be able to do authentication.

     **   MAY allow an originator to delegate this responsibility to a
          third party.

     **   SHOULD have the property that they would allow per-message

Hansen                                                          [Page 4]

Internet Draft  Message Tracking Model and Requirements October 24, 2002

          delegation of the tracking responsibility.

     **   MUST require a tracking user agent to prove that they are per-
          mitted to request the tracking information.

     **   MUST be able to uniquely identify messages.

     **   MUST require every message to have unique identification.

5.  Interaction Models

     There are several models by which tracking of messages can be
enabled, by which messages can be tracked, and by which information can
be requested and gathered.

5.1.  Tracking Enabling Models

     Either the envelope or message header must contain enough informa-
tion to track a message and securely retrieve information about the mes-
sage.  Any message that does not have enough information to track it is
by definition not trackable.

     If there is not enough information available in current standard
envelopes or message headers, then the current standards will need to be
extended.  Either the MUA or MSA must determine the additional informa-
tion and enable the tracking by adding the additional information to
either the envelope or header.

     This leads to two tracking enabling models:  passive enabling and
active enabling.

5.1.1.  Passive Enabling Model
The "passive enabling" model assumes that there is sufficient informa-
tion available.  No UA or MSA interaction occurs to turn tracking on; it
is on by default.

5.1.2.  Active Enabling Model

     The "active  enabling" model requires that the MUA and MSA exchange
information when the message is submitted.  This exchange indicates that
logging of the message's traversal should be performed, as well as pro-
viding enough additional information to allow the message to be tracked.
This information will need to be passed on to subsequent MTAs as needed.

5.2.  Tracking Request Models
There are several models by which tracking information may be requested.

Hansen                                                          [Page 5]

Internet Draft  Message Tracking Model and Requirements October 24, 2002

5.2.1.  Passive Request Model

     The "passive request" model requires active enabling to indicate
that some form of tracking is to be performed.  The tracking information
can be sent back immediately (as a form of telemetry) or sent to a 3rd
party for later retrieval.

5.2.2.  Passive Request Tracking Information

     Forms of passive tracking information that could potentially be
requested are  as  follows.  Note that mechanisms already exist for
requesting the information marked with a (+).  The references for such
mechanisms are listed at the end of each such entry.

     **   send a DSN of a message arriving at an intermediate MTA

     **   (+) send a DSN of a message being rejected while at an inter-
          mediate MTA [RFC-DSN]

     **   (+) send a DSN of a message leaving an intermediate MTA and
          going to another MTA [RFC-DELIVER-BY]

     **   send a DSN of a message arriving at a final MTA

     **   (+) send a DSN of a message being rejected while at a final
          MTA [RFC-DSN]

     **   (+) send a DSN of a message being delivered to a user's mes-
          sage store [RFC-DSN]

     **   (+) send a DSN of a message being delivered to a foreign MTA
          [RFC-DSN]

     **   (+) send an MDN of a message being read by an end user [RFC-
          MDN]

5.3.  Active Request Model

     The "active request" model requires an active query by a user's
user agent to the MSA, intermediate MTAs and final MTA, or to a third
party, to find the message's status as known by that MTA.  Active
request will work with either passive enabling or active enabling.

5.3.1.  Server Chaining vs. Server Referrals
When a tracking server has been asked for tracking information, and the
message has been passed on to another MTA of which this tracking server
has no tracking knowledge, there are two modelling choices:

Hansen                                                          [Page 6]

Internet Draft  Message Tracking Model and Requirements October 24, 2002

     **   the first tracking server will contact the next tracking
          server to query for status and pass back the combined status
          (server chaining), or

     **   the first tracking server will return the address of the next
          MTA and the tracking client has the responsibility of contact-
          ing the next tracking server (server referrals).

5.3.2.  Active Request Tracking Information
Forms of active tracking information that could potentially be requested
are as follows.  (Note that no mechanisms currently exist for requesting
such information.)

     **   the message has been queued for later delivery

     **   the message was delivered locally

     **   the message was delivered to another MTA,

     **   the message was delivered to a foreign MTA

     **   ask a different tracking server,

     **   I know but can't tell you,

     **   I don't know.

5.4.  Combining DSN and MDN Information with Message Tracking Informa-
tion

     The information that would be retrieved by message tracking and the
information that is returned for DSN and MDN requests all attempt to
answer the question of "what happened to message XX"?  The information
provided by each is complementary in nature, but similar.  A tracking
user agent could use all three possible information  sources  to present
a total view of the status of a message.

     Both DSN and MDN notifications utilize the formats defined by RFC
1892 [RFC-REPORT].  This suggests that the information returned by mes-
sage tracking solutions should also be similar.

6.  Security Considerations

6.1.  Security Considerations Summary

     Security vulnerabilities are detailed in [DRAFT-MTRK-ESMTP],
[DRAFT-MTRK-TSN] and [DRAFT-MTRK-MTQP].  These consideratons include:

Hansen                                                          [Page 7]

Internet Draft  Message Tracking Model and Requirements October 24, 2002

     **   vulnerability to snooping or replay attacks when using unen-
          crypted sessions

     **   a dependency on the randomness of the per-message secret

     **   reliance on TLS

     **   man-in-the-middle attacks

     **   reliance on the server maintaining the security level when it
          performs chaining

     **   denial of service

     **   confidentiality concerns

     **   forgery by malicious servers

6.2.  Message Identification and Authentication

     This is a security model for message identification and authentica-
tion that could be deployed.  (There may be others.)

     A Tracking User Agent must prove that they are permitted to request
tracking information about a message.  Every [RFC-822]-compliant message
is supposed to contain a Message-Id header.  One possible mechanism is
for the originator to calculate a one-way hash A from the message ID +
time stamp + a per-user secret.  The user then calculates another one-
way hash B to be the hash of A.  The user includes B in the submitted
message, and retains A.  Later, when the user makes a message tracking
request to the messaging system or tracking entity, it submits A in the
tracking request.  The entity receiving the tracking request then uses A
to calculate B, since it was already provided B, verifying that the
requestor is authentic.  In summary,

     A = H(message ID + time stamp + secret)

     B = H(A)

Another possible mechanism for A is to ignore the message ID and time
stamp and just use a one-way hash from a large (>128 bits) random
number.  B would be calculated as before.  In summary,

     A = H(large-random-number)

     B = H(A)

This is similar in technique to the methods used for One-Time Passwords

Hansen                                                          [Page 8]

Internet Draft  Message Tracking Model and Requirements October 24, 2002

[RFC-OTP].  The success of these techniques is dependent on the random-
ness of the per-user secret or the large random number, which can be
incredibly difficult in some environments.

     If the originator of a message were to delegate his or her tracking
request to a third party by sending it A, this would be vulnerable to
snooping over unencrypted sessions.  The user can decide on a message-
by-message basis if this risk is acceptable.

7.  Informational References

     [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
               Text Messages", STD 11, RFC 822, UDEL, August 1982.

     [RFC-DELIVER-BY]
               Newman, D., "Deliver By SMTP Service Extension", draft-
               newman-deliver-02.txt, Innosoft, January 1999.

     [RFC-DSN] Moore, K., and G. Vaudreuil, "An Extensible Message For-
               mat for Delivery Status Notifications", RFC 1894, Univer-
               sity of Tennessee, Octel Network Services, January 1996.

     [RFC-ESMTP-DSN]
               Moore, K., "SMTP Service Extension for Delivery Status
               Notifications", RFC 1891, University of Tennessee, Janu-
               ary 1996.

     [RFC-KEYWORDS]
               Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119, Harvard University, March
               1997.

     [RFC-MDN] Fajman, R., "An Extensible Message Format for Message
               Disposition Notifications", RFC 2298, National Institutes
               of Health, March 1998.

     [RFC-OTP] Haller, N., Metz, C., Nesser, P., Straw, M., "A One-Time
               Password System", RFC 2289, Bellcore, Kaman Sciences Cor-
               poration, Nesser & Nesser Consulting, Bellcore, February
               1998.

     [RFC-REPORT]
               Vaudreuil, G., "The Multipart/Report Content Type for the
               Reporting of Mail System Administrative Messages", RFC
               1892, Octel Network Services, January 1996.

     [RFC-SMTP]Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC

Hansen                                                          [Page 9]

Internet Draft  Message Tracking Model and Requirements October 24, 2002

               821, USC/Information Sciences Institute, August 1982.

     [DRAFT-MTRK-ESMTP]
               draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T. Hansen,
               "SMTP Service Extension for Message Tracking", Sendmail,
               Inc., AT&T Laboratories, TBD 2002.

     [DRAFT-MTRK-TSN]
               draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The
               Message/Tracking-Status MIME Extension", Sendmail, Inc.,
               TBD 2002.

     [DRAFT-MTRK-MTQP]
               draft-ietf-msgtrk-mtqp-01.txt T. Hansen, "Message Track-
               ing Query Protocol", TBD 2000.

8.  Acknowledgements

     This document is the product of input from many people and many
sources, including all of the members of the Message Tracking Working
Group, including Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris
Newman, and Gregory Neil Shapiro.  It owes much to earlier work by Gor-
don Jones, Bruce Ernst and Greg Vaudreuil.  In particular, I'd like to
also thank Ken Lin for his considerable contributions to the early
drafts.

9.  Authors' Addresses
     Tony Hansen
     AT&T Laboratories
     Middletown, NJ 07748
     USA

     Phone: +1.732.420.8934
     E-Mail: [email-masked]

10.  Full Copyright Statement

     Copyright (C) The Internet Society (%Dy%).  All Rights Reserved.

     This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all
such copies and derivative works.  However, this document itself may not
be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in

Hansen                                                         [Page 10]

Internet Draft  Message Tracking Model and Requirements October 24, 2002

which case the procedures for copyrights defined in the Internet Stan-
dards process must be followed, or as required to translate it into
languages other than English.

     The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

     This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.

     This document expires April 24, 2002.

Hansen                                                         [Page 11]

Internet Draft                                                 T. Hansen
draft-ietf-msgtrk-mtqp-09.txt                          AT&T Laboratories
Valid for six months                                    October 24, 2002

                    Message Tracking Query Protocol

                    <draft-ietf-msgtrk-mtqp-09.txt>

                         Authors' version: 1.20

     Status of this Memo

     This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents at
any time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

     The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

     This memo and its companions are discussed on the MSGTRK working
group mailing list, [email-masked].  To subscribe, send a message
with the word "subscribe" in the body (on a line by itself) to the
address [email-masked].  An archive of the mailing list may
be found at http://www.ietf.org/archive/msgtrk.

Copyright Notice

     Copyright (C) The Internet Society (%Dy%).  All Rights Reserved.

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

Hansen                                                          [Page 1]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

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.

1.  Introduction

     The Message Tracking Models and Requirements document [DRAFT-MTRK-
MODEL] discusses the models that message tracking solutions could fol-
low, along with requirements for a message tracking solution that can be
used with the Internet-wide message infrastructure.  This memo and its
companions, [DRAFT-MTRK-ESMTP] and [DRAFT-MTRK-TSN], describe a complete
message tracking solution that satisfies those requirements.  The memo
[DRAFT-MTRK-ESMTP] defines an extension to the SMTP service that pro-
vides 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 [DRAFT-MTRK-TSN]
describes the message/tracking-status [RFC-MIME] media type that is used
to report tracking status information.  Using the model document's ter-
minology, this solution uses active enabling and active requests with
both request and chaining referrals.

1.1.  Terminology

     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 [RFC-KEYWORDS].

     All syntax descriptions use the ABNF specified by [RFC-ABNF].  Ter-
minal nodes not defined elsewhere in this document are defined in [RFC-
ABNF], [RFC-URI], [DRAFT-MTRK-ESMTP] or [RFC-SMTPEXT].

1.2.  Changes Made for...

     The Changes sections will be removed before publication.

1.2.1.  Changes Made for -09

     Fixes for AD comments made on 8/21/2002:

     The copyright date is 1999. This seems wrong...

     Section 2.4. Should say something about client timeouts and how
long it is appropriate to wait for a server.

     Section 4. It seems appropriate to have two qualified error
responses to TRACK:  (1) An indication that TLS must be negotiated
before this message can be tracked and (2) An indication that the search
succeeded but found no result.

Hansen                                                          [Page 2]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

     What happens when no informatio about the message is found?  Does
this come back as an empty response or does it get a negative response?

     The URL registration in section 9 doesn't seem to meet the require-
ments set forth in RFC 2717.  In particular, the URL registration tem-
plate needs to be included.

     Section 10. The IANA considerations should mention that this docu-
ment registers the MQTP URL scheme.

     References need to be split into normative and informative.

1.2.2.  Changes Made for -08

     Change "Option Parameters" back to "none" in STARTTLS registration
definition.

1.2.3.  Changes Made for -07

     Added hostname to STARTTLS registration information.  Corrected
ABNF for STARTTLS.

1.2.4.  Changes Made for -06

     Added opt-parameter to STARTTLS and description.

1.2.5.  Changes Made for -05

     STARTTLS error response changed from "/unsupported" to "/unavail-
able".

     Fixed some minor nits in the examples and some typos.

1.2.6.  Changes Made for -04

     Reworked the SRV lookup description.

     Other comments from the list.

     Changes to the ABNF.

     Changed "must" to "MUST" in section 4.

     Changed "may" to "MAY" in section 4.

     More examples.

     Eliminated the registry of vnd. options.

Hansen                                                          [Page 3]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

     Eliminated lots of unused references.

1.2.7.  Changes Made for -03

     Changed references.

     Worked on error codes.

     Made examples more real with secrets and hashes.

     Fixes to examples.

     Added dot-stuffed example.

     Additional TLS info.

     Better Security Considerations section.

1.2.8.  Changes Made for -02

     Provided information on lookup for an MTQP server: SRV MTQP, then
MX, then A.

     Provided a section on firewall considerations

     Provided a section on service DNS considerations

     At IANA's request, left the port number as XXXX and added more
information on the option registry.

     Added text on various error conditions and fixed ABNF for error
response codes.

     Fleshed out the tracking examples.

2.  Basic Operation

     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 XXXX
(TBD by IANA).

     When an MTQP client wishes to make use of the message tracking ser-
vice, it establishes a TCP connection with the server host, as recorded
from the initial message submission or as returned by a previous track-
ing 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.

Hansen                                                          [Page 4]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

(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 greet-
ing.  The MTQP client and MTQP server then exchange commands and
responses (respectively) until the connection is closed or aborted.

2.1.  Tracking Service DNS Considerations

     Because of the ways server host lookups are performed, many dif-
ferent 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.

     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
MTQP record pointing at that different machine.

     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 ser-
vice.  In both cases, note that the tracking service MUST be able to
handle the queries for all messages accepted by that mail system.

2.2.  Commands

     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 charac-
ters.  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.

2.3.  Responses

     Responses in MTQP consist of a status indicator that indicates suc-
cess 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

Hansen                                                          [Page 5]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

indicators:  "+OK" indicates success; "+OK+" indicates a success fol-
lowed 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).

     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.

     In a multi-line success response, each subsequent line is ter-
minated 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 con-
sisting of a single period (".", decimal code 046) and a CRLF pair.  If
any line of the multi-line response begins with a period, the line is
"dot-stuffed" by prepending the period with a second period.  When exa-
mining 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.

     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 indi-
cator.

2.4.  Firewall Considerations

     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 informa-
tion is available; or it may perform a chaining operation itself, gath-
ering 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.

     If a server chooses to perform a chaining operation itself, it MUST
provide a response within 2 minutes, and SHOULD return a "no further

Hansen                                                          [Page 6]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

information is available" response if it cannot provide an answer at the
end of that time limit.

2.5.  Optional Timers

     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 cri-
teria, to prevent denial of service attacks.

     An MTQP client MAY have an inactivity autologout timer while wait-
ing 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.

3.  Initialization and Option Response

     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.

     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 "una-
vailable".
     "/" "unavailable"
     "/" "admin"

     The reason code "/admin" SHOULD be used when the service is una-
vailable for administrative reasons.  The reason code "/unavailable"
SHOULD be used when the service is unavailable for other reasons.

     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.)

     One option specification is defined here:

     STARTTLS

Hansen                                                          [Page 7]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

This capability MUST be listed if the optional STARTTLS command is sup-
ported by the MTQP server.  It has no parameters.

3.1.  Examples

     Example #1 (no options):
     S: +OK/MTQP MTQP server ready

     Example #2 (service temporarily unavailable):
     S: -TEMP/MTQP/admin Service down for admin, call back later

     Example #3 (service permanently unavailable):
     S: -ERR/MTQP/unavailable Service down

     Example #4 (alternative for no options):
     S: +OK+/MTQP MTQP server ready
     S: .

     Example #5 (options available):
     S: +OK+/MTQP MTQP server ready
     S: starttls
     S: vnd.com.example.option2 with parameters private to example.com
     S: vnd.com.example.option3 with a very long
     S:  list of parameters
     S: .

4.  TRACK Command

     Syntax:
          "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF

          mtrk-secret = base64

     Envid is defined in [DRAFT-MTRK-ESMTP].  Mtrk-secret is the secret
A described in [DRAFT-MTRK-ESMTP], encoded using base64.

     When the client issues the TRACK command, and the user is vali-
dated, 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.

     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 [DRAFT-MTRK-
TSN].  The response contains the tracking information about the email

Hansen                                                          [Page 8]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

message that used the given tracking-id.

     A negative response to the TRACK command may include these reason
codes:
     "/" "tls-required"
     "/" "admin"
     "/" "unavailable"
     "/" "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.

     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".

4.1.  Examples

     In each of the examples below, the envid is "<12345-
[email-masked]>", 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.

     Example #6 Message Delivered:
     C: TRACK <[email-masked]> 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: [email-masked]
     S: Reporting-MTA: dns; example2.com
     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
     S:
     S: Original-Recipient: rfc822; [email-masked]
     S: Final-Recipient: rfc822; [email-masked]
     S: Action: delivered
     S: Status: 2.5.0
     S:
     S: --%%%%--
     S: .

Hansen                                                          [Page 9]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

     Example #7 Message Transferred:
     C: TRACK <[email-masked]> 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: [email-masked]
     S: Reporting-MTA: dns; example2.com
     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
     S:
     S: Original-Recipient: rfc822; [email-masked]
     S: Final-Recipient: rfc822; [email-masked]
     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 <[email-masked]> 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: [email-masked]
     S: Reporting-MTA: dns; example2.com
     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
     S:
     S: Original-Recipient: rfc822; [email-masked]
     S: Final-Recipient: rfc822; [email-masked]
     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 <[email-masked]> YWJjZGVmZ2gK

Hansen                                                         [Page 10]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

     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: [email-masked]
     S: Reporting-MTA: dns; example2.com
     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
     S:
     S: Original-Recipient: rfc822; [email-masked]
     S: Final-Recipient: rfc822; [email-masked]
     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; [email-masked]
     S: Final-Recipient: rfc822; [email-masked]
     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 <[email-masked]> 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: [email-masked]
     S: Reporting-MTA: dns; example2.com
     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
     S:
     S: Original-Recipient: rfc822; [email-masked]
     S: Final-Recipient: rfc822; [email-masked]
     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

Hansen                                                         [Page 11]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

     S:
     S: Original-Envelope-Id: [email-masked]
     S: Reporting-MTA: dns; smtp.example3.com
     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
     S:
     S: Original-Recipient: rfc822; [email-masked]
     S: Final-Recipient: rfc822; [email-masked]
     S: Action: delivered
     S: Status: 2.5.0
     S:
     S: --%%%%--
     S: .

     Example #11 Firewall, Combining Per-Recipient Blocks:
     C: TRACK <[email-masked]> 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: [email-masked]
     S: Reporting-MTA: dns; example2.com
     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
     S:
     S: Original-Recipient: rfc822; [email-masked]
     S: Final-Recipient: rfc822; [email-masked]
     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; [email-masked]
     S: Final-Recipient: rfc822; [email-masked]
     S: Action: delivered
     S: Status: 2.5.0
     S:
     S: --%%%%--
     S: .

     Example #12 Firewall, Hiding System Names Behind the Firewall:
     C: TRACK <[email-masked]> YWJjZGVmZ2gK
     S: +OK+ Tracking information follows
     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
     S:
     S: --%%%%
     S: Content-Type: message/tracking-status
     S:

Hansen                                                         [Page 12]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

     S: Original-Envelope-Id: [email-masked]
     S: Reporting-MTA: dns; example2.com
     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
     S:
     S: Original-Recipient: rfc822; [email-masked]
     S: Final-Recipient: rfc822; [email-masked]
     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: [email-masked]
     S: Reporting-MTA: dns; example2.com
     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
     S:
     S: Original-Recipient: rfc822; [email-masked]
     S: Final-Recipient: rfc822; [email-masked]
     S: Action: delivered
     S: Status: 2.5.0
     S:
     S: --%%%%--
     S: .

5.  COMMENT Command

     Syntax:
          "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.

6.  STARTTLS Command

     Syntax:
          "STARTTLS" [WSP hostname] CRLF

     TLS [TLS], more commonly known as SSL, is a popular mechanism for
enhancing TCP communications with privacy and authentication.  An MTQP
server MAY support TLS.  If an MTQP server supports TLS, it MUST include
"STARTTLS" in the option specifications list on protocol startup.

     The optional parameter, if specified, MUST be a fully qualified

Hansen                                                         [Page 13]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

domain name.  A client MAY specify the hostname it believes it is speak-
ing 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).

     If the server returns a negative response, it MAY use one of the
following response codes:
     "/" "unsupported"
     "/" "unavailable"
     "/" "tlsinprogress"

     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 "/tlsinprogress".

     After receiving a positive response to a STARTTLS command, the
client MUST start the TLS negotiation before giving any other MTQP com-
mands.

     If the MTQP client is using pipelining (see below), the STARTTLS
command must be the last command in a group.

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
immediately decide whether or not to continue based on the authentica-
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
privacy because most MTQP services are performed with no authentication
and no privacy, but some MTQP clients or servers may want to continue
only if a particular level of authentication and/or privacy was
achieved.

     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
QUIT command immediately after the TLS negotiation is complete.  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 "-ERR"
response and a response code of "/insecure".

6.2.  Result of the STARTTLS Command

     Upon completion of the TLS handshake, the MTQP protocol is reset to

Hansen                                                         [Page 14]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

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.

     At the end of the TLS handshake, the server acts as if the connec-
tion 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 completed.

     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 ses-
sion is already active.

7.  QUIT Command

     Syntax:
          "QUIT" CRLF

     When the client issues the QUIT command, the MTQP session ter-
minates.  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).

8.  Pipelining

     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.

     Specific commands may place further constraints on pipelining.  For
example, STARTTLS must be the last command in a batch of MTQP commands.

8.1.  Examples

     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: .

Hansen                                                         [Page 15]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

     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: .

9.  The MTQP URI Scheme

9.1.  Intended usage

     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.

9.2.  URI Scheme Name

     The name of the URI scheme is "mtqp".

9.3.  URI Scheme Syntax

     An MTQP URI takes one of the following forms:

     mtqp://<mserver>/track/<envid>/<mtrk-secret>
     mtqp://<mserver>:<port>/track/<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 (envid) and authorization secret (mtrk-secret).  The
path element "/track/" MUST BE treated case insensitively, but the envid
and mtrk-secret MUST NOT be.

9.3.1.  Formal Syntax

     This is an ABNF description of the MTQP URI.

Hansen                                                         [Page 16]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

     mtqp-uri = "mtqp://" net_loc "/track/" envid "/" mtrk-secret

9.4.  Encoding Rules

     The encoding of envid is discussed in [DRAFT-MTRK-ESMTP].  Mtrk-
secret is required to be base64 encoded.  If the "/", "?" and "%" octets
appear in 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.)

10.  IANA Considerations

     System port number XXXX - TBD by IANA

     The service name to be registered with the Internet Assigned Number
Authority (IANA) is "MTQP".

     The IANA is asked to register the URI registration template found
in Appendix A in accordance with [BCP35].

     This document requests that IANA maintain one new registry: MTQP
options.  The registry's purpose is to register options to this proto-
col.  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:

     option identifier
     option parameters
     added commands
     standard commands affected
     specification reference
     discussion

     One MTQP option is defined in this document, with the following
registration definition:

     option identifier: STARTTLS
     option parameters: none
     added commands: STARTTLS
     standard commands affected: none
     specification reference: RFC TBD
     discussion: see RFC TBD

     Additional vendor-specific options for this protocol have names
that begin with "vnd.".  After the "vnd." would appear the reversed
domain name of the vendor, another dot ".", and a name for the option
itself.  For example, "vnd.com.example.extinfo" might represent a
vendor-specific extension providing extended information by the owner of

Hansen                                                         [Page 17]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

the "example.com" domain.  These names MAY be registered with IANA.

11.  Security Considerations

     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 max-
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
this level of exposure is too much, TLS may be used to reduce the expo-
sure 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
privacy, they are not securing tracking queries with any prior or suc-
cessive MTQP servers.

     Both the MTQP client and server must check the result of the TLS
negotiation to see whether acceptable authentication or privacy was
achieved.  Ignoring this step completely invalidates using TLS for secu-
rity.  The decision about whether acceptable authentication or privacy
was achieved is made locally, is implementation-dependent, and is beyond
the scope of this document.

     The MTQP client and server should note carefully the result of the
TLS negotiation.  If the negotiation results in no privacy, or if it
results in privacy 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 com-
mands.

     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.

     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.

Hansen                                                         [Page 18]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

     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.

     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" secu-
rity and should be treated as such.

     SASL is not used because authentication is per message rather than
per user.

12.  Protocol Syntax

     This is a collected ABNF description of the MTQP protocol.
     conversation = command-response *( client-command command-response )

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

     track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF

     mtrk-secret = base64

     starttls-command = "STARTTLS" [WSP hostname] CRLF

     quit-command = "QUIT" CRLF

     comment-command = "COMMENT" opt-text CRLF

     # server side
     command-response = success-response / temp-response / error-response / bad-response

     temp-response = "-TEMP" response-info opt-text CRLF

     opt-text = [WSP *(VCHAR / WSP)]

     error-response = "-ERR" response-info opt-text CRLF

     bad-response = "-BAD" response-info opt-text CRLF

     success-response = single-line-success / multi-line-success

     single-line-success = "+OK" response-info opt-text CRLF

Hansen                                                         [Page 19]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

     multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf

     dataline = *998OCTET CRLF

     dotcrlf = "." CRLF

     option-list = *option-line

     option-line = identifier opt-text *(CRLF WSP opt-text) CRLF

     NAMECHAR = ALPHA / DIGIT / "-" / "_"

     identifier = (ALPHA / "_") *NAMECHAR)

     response-info = *( "/" ( "admin" / "unavailable" / "unsupported" /
             "tlsinprogress" / "insecure" / 1*NAMECHAR ) )

13.  Acknowledgements

     The description of STARTTLS is based on [RFC-SMTP-TLS].

14.  Normative References

     [RFC-MIME]RFC 2045, N. Freed & N. Borenstein, "Multipurpose Inter-
               net Mail Extensions (MIME) Part One: Format of Internet
               Message Bodies", Innosoft, First Virtual, November 1996.

     [RFC-ABNF]RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented
               BNF for Syntax Specifications: ABNF", Internet Mail Con-
               sortium, Demon Internet Ltd., November 1997.

     [RFC-SRV] RFC 2782, A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR
               for specifying the location of services (DNS SRV)" Troll
               Technologies, Internet Software Consortium, Microsoft
               Corp., February 2000

     [RFC-SMTPEXT]
               RFC 2554, J. Myers, "SMTP Service Extension for Authenti-
               cation", Netscape Communications, March 1999.

     [DRAFT-MTRK-ESMTP]
               draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T. Hansen,
               "SMTP Service Extension for Message Tracking", Sendmail,
               Inc., AT&T Laboratories, TBD 2002.

     [DRAFT-MTRK-MODEL]
               draft-ietf-msgtrk-model-*.txt, T. Hansen, "Message

Hansen                                                         [Page 20]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

               Tracking Models and Requirements", AT&T Laboratories, TBD
               2002.

     [DRAFT-MTRK-TSN]
               draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The
               Message/Tracking-Status MIME Extension", Sendmail, Inc.,
               TBD 2002.

     [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni-
               form Resource Identifiers (URI): Generic Syntax",
               MIT/LCS, U. C. Irvine, Xerox Corporation, August 1998.

15.  Informational References

     [BCP35]   BCP 35, RFC 2717, R. Petke, I. King, "Registration Pro-
               cedures for URL Scheme Names", November 1999.

     [RFC-SHA1]RFC 3184, D. Eastlake & P. Jones, "US Secure Hash Stan-
               dard 1 (SHA1)", September 2001.

     [RFC-KEYWORDS]
               RFC 2119, S. Bradner, "Key words for use in RFCs to Indi-
               cate Requirement Levels", Harvard University, March 1997.

     [RFC-SMTP-TLS]
               RFC2487, P. Hoffman, "SMTP Service Extension for Secure
               SMTP over TLS", Internet Mail Consortium, January 1999.

Appendix A. MTQP URI Registration Template

     Scheme name: mtqp

     Scheme syntax: see section 9.1

     Character encoding considerations: see section 9.4

     Intended usage: see section 9.3

     Applications and/or protocols which use this scheme: MTQP

     Interoperability considerations: as specified for MTQP

     Security considerations: see section 11.0

     Relevant publications: [DRAFT-MTRK-ESMTP], [DRAFT-MTRK-MODEL],
[DRAFT-MTRK-TSN]

Hansen                                                         [Page 21]

Internet Draft      Message Tracking Query Protocol     October 24, 2002

     Contact: MSGTRK Working Group

     Author/Change Controller: IESG

16.  Author's Address

     Tony Hansen
     AT&T Laboratories
     Middletown, NJ 07748
     USA

     Phone: +1.732.420.8934
     E-Mail: [email-masked]

17.  Full Copyright Statement

     Copyright (C) The Internet Society (%Dy%).  All Rights Reserved.

     This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all
such copies and derivative works.  However, this document itself may not
be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet Stan-
dards process must be followed, or as required to translate it into
languages other than English.

     The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

     This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.

     This document expires April 24, 2002.

Hansen                                                         [Page 22]

---

From: [email-masked]
Date: Thu, 24 Oct 2002 21:27:37 -0700 (PDT)

> ditto for model-07 and mtqp-09

The new drafts need to be posted as Internet-Drafts in the usual Internet-Draft
format. Once that's done I'll review and ask for a IETF-wide last call.

				Ned