Internet Draft E. Allman
draft-ietf-msgtrk-protocol-00.txt Sendmail, Inc.
Valid for six months T. Hansen
AT&T Laboratories
March 10, 2000
SMTP Service Extension
for Message Tracking
<draft-ietf-msgtrk-protocol-00.txt>
Authors' version: 1.1
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, ietf-msgtrk[-request]@imc.org. An archive of the
mailing list may be found at http://www.ietf.org/archive/msgtrk.
Copyright Notice
Copyright (C) The Internet Society (1999). 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
Allman,Hansen [Page 1]
Internet Draft SMTP Message Tracking Extensions March 10, 2000
current routing status of that message. This document provides exten-
sions to the ESMTP protocol to enhance its capabilities to include mes-
sage tracking.
1. Introduction
The Message Tracking Models and Requirements document [RFC-TRACK-
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 defines
an extension to the SMTP service that provides a message tracking solu-
tion that satisfies those requirements. Using the model document's ter-
minology, it uses active enabling and active requests with request
referrals.
....
This document is very drafty; its purpose is to promote discussion.
Sections that are obviously in need of filling out have comments begin-
ning with "--".
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 2119 [RFC-KEYWORDS].
2. Framework for the Message Tracking Service Extension
The Message Trackng extension to SMTP is laid out as follows:
** the name of the SMTP service defined here is "Message Track-
ing";
** the EHLO keyword value associated with the extension is
"TRACK";
** the TRACK keyword has no parameters;
** the TRACKID parameter is added to the MAIL FROM command;
** a new SMTP verb, "MTRK", is defined.
The rest of this memo defines how support for the extension effects
the behavior of a message transfer agent.
Allman,Hansen [Page 2]
Internet Draft SMTP Message Tracking Extensions March 10, 2000
3. Message Tracking Enabling
An SMTP client wishing to request message tracking support for a
message may issue the EHLO command to start an SMTP session, to deter-
mine if the server supports any of several service extensions. If the
server responds with code 250 to the EHLO command, and the response
includes the EHLO keyword TRACK, then the Message Tracking extension (as
described in this memo) is supported. In general, an ESMTP server which
implements this service extension will propagate message tracking infor-
mation when relaying mail to other SMTP-based MTAs that also support
this extension, and make a "best effort" to record when messages are
passed into other environments.
4. Additional Parameter for the MAIL FROM Command
The extended MAIL FROM command is issued by a client when it wishes
to request that a server maintain tracking information for the message.
The extended MAIL FROM command is identical to the MAIL commands defined
in [RFC-821], except that the additional parameter may appear after the
recipient address. The general syntax for extended SMTP commands is
defined in [RFC-ESMTP].
4.1. The TRACKID parameter of the ESMTP MAIL FROM Command
The TRACKID esmtp-keyword on the extended MAIL FROM command speci-
fies whether or not the message should be tracked by the server. If the
TRACKID esmtp-keyword is used, it MUST have an associated esmtp-value,
which is constructed as described next.
4.2. Creating the TRACKID Parameter
The TRACKID parameter consists of two parts: a per-message authen-
tication string, the Auth String, and a per-message tracking identifica-
tion string, the Tracking ID.
4.2.1. Tracking ID
A key requirement of message tracking is the ability to uniquely
identify a message with a globally and temporally unique signature. The
Message-Id: header is required by [RFC-822] to identify a message, and
is usually required to be globally and temporally unique. So it is
almost sufficient for tracking identification. However, a Message ID
will be reused under certain circumstances, such as when a message is
resent, and such messages must be able to be tracked separately from the
original message. The Tracking ID is REQUIRED to be the same value as
used for the Message ID, without the angle brackets, and augmented by a
colon ":" and a generational counter. The generational counter will be
an unsigned integer value that SHOULD start at the value of 0. For
Allman,Hansen [Page 3]
Internet Draft SMTP Message Tracking Extensions March 10, 2000
example, if the value of the Message-ID: header is
"<123456.89012391@domain.example>", then the value of the tracking ID
will be "123456.89012391@domain.example:0". If a message is ever resent
or retransmitted for any other reason by an end-user client, then the
generational counter MUST be incremented by one. (The generational
counter MAY additionally be incremented by a small (<10) random number.)
4.2.2. Secret Value
For messages to be tracked, the mail user agent must use a secret
value. This secret value MAY be a per-message secret, such as a 128-bit
(16-byte) random number.
4.2.3. Stored Authentication Value
The value of the Tracking ID, T, is concatentated with the secret
value, S, and passed through the [RFC-MD5] one-way hash function, to
create the Stored Authentication Value, A.
A = H(T + S)
4.2.4. Transmitted Authentication String
The Transitted Authentication String, B, is created by passing the
Stored Authentication Value, A, through the MD5 one-way hash function,
producing a 16-byte value. This value is then expressed as a series of
32 hexadecimal digits, either lower- or upper-case, transmitted in
internet byte order (low-endian ???? ) [RFC-????].
B = hex(H(A))
4.2.5. The TRACKID Parameter
The TRACKID parameter, P, is created from the transmitted authenti-
cation string, B, a colon ":", and the tracking ID, T.
P = B + ":" + T
5. Message Tracking Requests
The MTRK command is issued by the client host when it wishes to
determine the current status of a message previously sent to that server
host. The syntax of this command is as follows:
MTRK <stored-authentication-value>:<tracking-id><CR><LF>
Allman,Hansen [Page 4]
Internet Draft SMTP Message Tracking Extensions March 10, 2000
<tracking-id> is the tracking ID, T, of a message previously sent to
this server. The <stored-authentication-value> is the Stored Authenti-
cation Value A (as calculated above) for that message. The <stored-
authentication-value> is expressed as a series of 32 hexadecimal digits,
either lower- or upper-case, transmitted in internet byte order [RFC-
????]. This command may be issued at any time once a session is esta-
blished, as long as there is not a transaction occurring. Thus, this
command is illegal between a MAIL FROM: command and the end of the DATA
commands and responses.
things to add:
-- data to be returned
-- states to be returned
-- format to be returned
-- responses to the verb, 250, 4xx, 5xx
other things to consider:
-- firewalls? (treat as gateway MTAs and let them do chaining?)
-- affect on SUBMIT? can we ask MSA to return the A and B hash?
-- use message-id directly and require message-id to be in first 1k of
message?
6. Examples
-- examples go here
6.1. Message Tracking Enabling
S: 220 smtp.example.com ESMTP server ready
C: EHLO example.example.com
S: 250-smtp.example.com
S: 250 TRACK
C: MAIL FROM:<user@example.com>
TRACKID=1234567890123456789012:12345.54321@example.com:0
S: 250 <user@example.com> sender ok
C: RCPT TO:<user2@example.com>
S: 25o <user2@example.com> recipient ok
C: DATA
S: 354 okay, send message
C: Message-Id: <12345.54321@example.com>
C: (rest of message here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
Allman,Hansen [Page 5]
Internet Draft SMTP Message Tracking Extensions March 10, 2000
6.2. Message Tracking Request
S: 220 smtp.example.com ESMTP server ready
C: EHLO example.example.com
S: 250-smtp.example.com
S: 250 TRACK
C: MTRK 1234567890123456789012:12345.54321@example.com:0
S: -- response to be determined
7. Security Considerations
things to add:
-- text about no more than a single message can be lost
-- man in the middle attack
-- see RFC 1894 for security considerations on DSNs and RFC 2298 on MDNs
-- We probably cannot get away with the following statement:
This RFC does not discuss security issues and is not believed to raise
any security issues not already endemic in electronic mail and present
in fully conforming implementations of [RFC821], or otherwise made pos-
sible by [MIME].
8. References
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, University of Southern California / Information Sciences Institute,
August 1982.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, University of Delaware, August 1982.
[RFC-ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach
Consulting, Inc., Network Management Associates, Inc., Silicon Graphics,
Inc., July 1994.
[RFC-MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC-MODEL] Hansen, T., "Message Tracking Models and Requirements", RFC
????, AT&T Laboratories, ???? 2000.
[RFC-????] something on internet byte order
Allman,Hansen [Page 6]
Internet Draft SMTP Message Tracking Extensions March 10, 2000
9. Authors' Addresses
Eric Allman
Sendmail, Inc.
street address
city, state zip
Phone: +1
E-Mail: eric@sendmail.com
Tony Hansen
AT&T Laboratories
Lincroft, NJ 07738
USA
Phone: +1 732 576-3207
E-Mail: tony@att.com
10. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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 implmentation 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 organisations,
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 September 10, 2000.
Allman,Hansen [Page 7]
Internet Draft SMTP Message Tracking Extensions March 10, 2000
11. Appendix A -- Sample Code
For the sake of illustration, we provide the following sample C
code for the creation of the saved and transmitted authentication
strings. The code is based on MD5 code as described in [RFC-MD5]. The
input is a secret and transaction ID, the output is two 33-byte strings
containing the values of the two authentication strings, encoded as hex
digits, and NUL-terminated.
-- I have not yet compiled this code or verified that it does indeed
generate network byte order.
/*
** Function: trackauth
*/
#include <md5.h>
void
trackauth(
/* input parameters ... */
unsigned char* secret; /* pointer to secret */
int secret_len; /* length of secret */
unsigned char* transaction_id; /* pointer to transaction ID */
int transaction_id_len; /* length of transaction ID */
/* output parameters ... */
unsigned char saved_auth_str[33]; /* A: saved authentication string */
unsigned char trans_auth_str[33]; /* B: transmitted auth. string */
)
{
MD5_CTX context; /* MD5 engine */
unsigned char outbuf[16]; /* where to store the context */
register int i, j; /* counters */
static char hexdigits[] = "0123456789abcdef";
MD5Init(&context);
MD5Update(&context, secret, secret_len);
MD5Update(&context, transaction_id, transaction_id_len);
MD5Final(outbuf, &context);
for (i = 0, j = 0; i < 16; i++)
{
saved_auth_str[j++] = hexdigits[outbuf[i] & 0xF];
saved_auth_str[j++] = hexdigits[(outbuf[i] >> 4) & 0xF];
}
saved_auth_str[j] = '\0';
MD5Init(&context);
MD5Update(&context, saved_auth_str, 16);
MD5Final(outbuf, &context);
for (i = 0, j = 0; i < 16; i++)
Allman,Hansen [Page 8]
Internet Draft SMTP Message Tracking Extensions March 10, 2000
{
trans_auth_str[j++] = hexdigits[outbuf[i] & 0xF];
trans_auth_str[j++] = hexdigits[(outbuf[i] >> 4) & 0xF];
}
trans_auth_str[j] = '\0';
}
Allman,Hansen [Page 9]
