draft-ietf-msgtrk-smtpext-01.txt   draft-ietf-msgtrk-smtpext-02.txt 
Internet Draft E. Allman Internet Draft E. Allman
draft-ietf-msgtrk-smtpext-01.txt Sendmail, Inc. draft-ietf-msgtrk-smtpext-02.txt Sendmail, Inc.
Valid for six months T. Hansen Valid for six months T. Hansen
Updates: RFC 1891 AT&T Laboratories Updates: RFC 1891 AT&T Laboratories
March 20, 2001 July 6, 2001
SMTP Service Extension SMTP Service Extension
for Message Tracking for Message Tracking
<draft-ietf-msgtrk-smtpext-01.txt> <draft-ietf-msgtrk-smtpext-02.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. Internet-Drafts are with all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also dis- areas, and its working groups. Note that other groups may also dis-
tribute working documents as Internet-Drafts. tribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 2, line ? skipping to change at page 2, line ?
The list of current Internet-Drafts can be accessed at: The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at: The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is a submission by the MSGTRK Working Group of the This document is a submission by the MSGTRK Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the msgtrk@imc.org mailing list. An archive of the mailing list to the ietf-msgtrk@imc.org mailing list. An archive of the mailing
may be found at list may be found at
http://www.ietf.org/archive/msgtrk http://www.imc.org/ietf-msgtrk/index.html
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
1. Abstract 1. Abstract
This memo defines an extension to the SMTP service whereby a This memo defines an extension to the SMTP service whereby a
client may mark a message for future tracking. client may mark a message for future tracking.
2. Other Documents and Conformance 2. Other Documents and Conformance
skipping to change at page 2, line ? skipping to change at page 2, line ?
(4) One optional parameter using the keyword "MTRK" is added to (4) One optional parameter using the keyword "MTRK" is added to
the MAIL FROM command. In addition, the ENVID and ORCPT the MAIL FROM command. In addition, the ENVID and ORCPT
parameters (as defined in RFC 1891 sections 5.4 and 5.2 parameters (as defined in RFC 1891 sections 5.4 and 5.2
respectively) MUST be supported, with extensions as respectively) MUST be supported, with extensions as
described below. described below.
(5) The maximum length of a MAIL FROM command line is increased (5) The maximum length of a MAIL FROM command line is increased
by 40 characters by the possible addition of the MTRK key- by 40 characters by the possible addition of the MTRK key-
word and value. Note that a further extension of 614 char- word and value. Note that a further extension of 614 char-
acters for the ORCPT and ENVID parameters is required by acters for the ORCPT and ENVID parameters is required by
RFC-DSN-EXT]. [RFC-DSN-EXT].
(6) No SMTP verbs are defined by this extension. (6) No SMTP verbs are defined by this extension.
4. The Extended MAIL FROM Command 4. The Extended MAIL FROM Command
The extended MAIL FROM command is issued by an SMTP client The extended MAIL FROM command is issued by an SMTP client
when it wishes to inform an SMTP server that message tracking when it wishes to inform an SMTP server that message tracking
information should be retained for future querying. The extended information should be retained for future querying. The extended
MAIL FROM command is identical to the MAIL FROM command as defined MAIL FROM command is identical to the MAIL FROM command as defined
in [RFC-SMTP], except that MTRK, ORCPT, and ENVID parameters appear in [RFC-SMTP], except that MTRK, ORCPT, and ENVID parameters appear
skipping to change at page 3, line 39 skipping to change at page 3, line 39
The sender then base64 encodes value B and passes that The sender then base64 encodes value B and passes that
value as the mtrk-certifier on the MAIL FROM command: value as the mtrk-certifier on the MAIL FROM command:
mtrk-parameter = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ] mtrk-parameter = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ]
mtrk-certifier = base64 ; authenticator mtrk-certifier = base64 ; authenticator
mtrk-timeout = 1*9digit; seconds until timeout mtrk-timeout = 1*9digit; seconds until timeout
A is stored in the originator's tracking database to vali- A is stored in the originator's tracking database to vali-
date future tracking requests as described in [DRAFT-MTRK-MTQP]. date future tracking requests as described in [DRAFT-MTRK-MTQP].
B is stored in tracking tracking databases of compliant MTAs and B is stored in tracking databases of compliant MTAs and used to
used to authenticate future tracking requests. authenticate future tracking requests.
The mtrk-timeout field indicates the number of seconds that The mtrk-timeout field indicates the number of seconds that
the client requests that this tracking information be retained the client requests that this tracking information be retained
on intermediate servers, as measured from the initial receipt of on intermediate servers, as measured from the initial receipt of
the message at that server. Servers MAY ignore this value if it the message at that server. Servers MAY ignore this value if it
violates local policy. In particular, servers MAY silently violates local policy. In particular, servers MAY silently
enforce an upper limit to how long they will retain tracking enforce an upper limit to how long they will retain tracking
data; this limit MUST be at least one day. data; this limit MUST be at least one day.
If no mtrk-timeout field is specified then the server If no mtrk-timeout field is specified then the server
skipping to change at page 4, line 35 skipping to change at page 4, line 35
local-envid = xtext local-envid = xtext
fqhn = xtext fqhn = xtext
The unique-envid MUST be chosen in such a way that the same The unique-envid MUST be chosen in such a way that the same
ENVID will never be used by any other message sent from this ENVID will never be used by any other message sent from this
system or any other system. In most cases, this means setting system or any other system. In most cases, this means setting
fqhn to be the fully qualified host name of the system generat- fqhn to be the fully qualified host name of the system generat-
ing this ENVID, and local-envid to an identifier that is never ing this ENVID, and local-envid to an identifier that is never
re-used by that host. re-used by that host.
Any retransmissions of this message MUST assign a new Any resubmissions of this message into the message trans-
ENVID. In this context, "retransmission" includes forwarding or mission system MUST assign a new ENVID. In this context,
resending a message. "resubmission" includes forwarding or resending a message from a
user agent, but does not include MTA-level aliasing or forward-
ing where the message does not leave and re-enter the message
transmission system.
4.3. Forwarding Tracking Certifiers 4.3. Forwarding Tracking Certifiers
MTAs SHOULD forward unexpired tracking certifiers to com- MTAs SHOULD forward unexpired tracking certifiers to com-
pliant mailers as the mail is transferred during regular hop-to- pliant mailers as the mail is transferred during regular hop-to-
hop transfers. If the "downstream" MTA is not MTRK-compliant, hop transfers. If the "downstream" MTA is not MTRK-compliant,
then the MTRK= parameter MUST be deleted. If the downstream MTA then the MTRK= parameter MUST be deleted. If the downstream MTA
is DSN-compliant, then the ENVID and ORCPT parameters MUST NOT is DSN-compliant, then the ENVID and ORCPT parameters MUST NOT
be deleted. be deleted.
skipping to change at page 5, line 25 skipping to change at page 5, line 27
The mtrk-authenticator value (``A'') must be hard to pre- The mtrk-authenticator value (``A'') must be hard to pre-
dict and not reused. dict and not reused.
The originating client must take reasonable precautions to The originating client must take reasonable precautions to
protect the secret. For example, if the secret is stored in a protect the secret. For example, if the secret is stored in a
message store (e.g., a "Sent" folder), the client must make sure message store (e.g., a "Sent" folder), the client must make sure
the secret isn't accessible by attackers, particularly on a the secret isn't accessible by attackers, particularly on a
shared store. shared store.
MTAs SHOULD take precautions to make certain that message Many site administrators believe that concealing names and
tracking cannot be used to explore internal topologies of net- topologies of internal systems and networks is an important
works. security feature. MTAs need to balance such desires with the
need to provide adequate tracking information.
In some cases site administrators may want to treat deliv-
ery to an alias as final delivery in order to separate roles
from individuals. For example, sites implementing ``postmas-
ter'' or ``webmaster'' as aliases may not wish to expose the
identity of those individuals by permitting tracking through
those aliases. In other cases, providing the tracking informa-
tion for an alias is important, such as when the alias points to
the user's preferred public address.
6. References 6. References
[DRAFT-MTRK-MODEL] [DRAFT-MTRK-MODEL]
T. Hansen, ``Message Tracking Model and Requirements.'' T. Hansen, ``Message Tracking Model and Requirements.''
draft-ietf-msgtrk-model-03.txt. November 2000. draft-ietf-msgtrk-model-03.txt. November 2000.
[DRAFT-MTRK-MTQP] [DRAFT-MTRK-MTQP]
T. Hansen, ``Message Tracking Query Protocol.'' draft-ietf- T. Hansen, ``Message Tracking Query Protocol.'' draft-ietf-
msgtrk-mtqp-01.txt. November 2000. msgtrk-mtqp-01.txt. November 2000.
skipping to change at page 6, line 32 skipping to change at page 6, line 45
[RFC-MIME] [RFC-MIME]
N. Freed and N. Borenstein, ``Multipurpose Internet Mail N. Freed and N. Borenstein, ``Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bod- Extensions (MIME) Part One: Format of Internet Message Bod-
ies.'' RFC 2045. November 1996. ies.'' RFC 2045. November 1996.
[RFC-MSGFMT] [RFC-MSGFMT]
D. Crocker, ``Standard for the Format of ARPA Internet Text D. Crocker, ``Standard for the Format of ARPA Internet Text
Messages.'' RFC 822. August 1982. Messages.'' RFC 822. August 1982.
[RFC-RANDOM] [RFC-RANDOM]
D. Eastlake, S. Crocker, and J. Schiller, ``Randomness Recom-
mendations for Security.'' RFC 1750. December 1994.
[RFC-RELATED] [RFC-RELATED]
E. Levinson, ``The MIME Multipart/Related Content-type.'' RFC E. Levinson, ``The MIME Multipart/Related Content-type.'' RFC
2387. August 1998. 2387. August 1998.
[NIST-SHA1] [NIST-SHA1]
NIST FIPS PUB 180-1, ``Secure Hash Standard.'' National NIST FIPS PUB 180-1, ``Secure Hash Standard.'' National
Institute of Standards and Technology, U.S. Department of Com- Institute of Standards and Technology, U.S. Department of Com-
merce. May 1994. DRAFT. merce. May 1994. DRAFT.
 End of changes. 10 change blocks. 
15 lines changed or deleted 30 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/