draft-ietf-msgtrk-mtqp-00.txt   draft-ietf-msgtrk-mtqp-01.txt 
Internet Draft T. Hansen Internet Draft T. Hansen
draft-ietf-msgtrk-mtqp-00.txt AT&T Laboratories draft-ietf-msgtrk-mtqp-01.txt AT&T Laboratories
Valid for six months Valid for six months November 21, 2000
July 1, 2000
Message Tracking Query Protocol Message Tracking Query Protocol
<draft-ietf-msgtrk-mtqp-00.txt> <draft-ietf-msgtrk-mtqp-01.txt>
Authors' version: 1.3 Authors' version: 1.5
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 4 skipping to change at page 1, line 48
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
Customers buying enterprise message systems often ask: Can I track Customers buying enterprise message systems often ask: Can I track
the messages? Message tracking is the ability to find out the path that the messages? Message tracking is the ability to find out the path that
a particular message has taken through a messaging system and the a particular message has taken through a messaging system and the
current routing status of that message. This document describes the current routing status of that message. This document describes the
Message Tracking Query Protocol that is used in conjunction with exten- Message Tracking Query Protocol that is used in conjunction with exten-
sions to the ESMTP protocol to provide a complete message tracking solu- sions to the ESMTP protocol to provide a complete message tracking solu-
tion for the Internet. tion for the Internet.
NOTE: This is a straw proposal for the Message Tracking Query Pro-
tocol.
1. Introduction 1. Introduction
The Message Tracking Models and Requirements document [RFC-TRACK- The Message Tracking Models and Requirements document [RFC-TRACK-
MODEL] discusses the models that message tracking solutions could fol- MODEL] discusses the models that message tracking solutions could fol-
low, along with requirements for a message tracking solution that can be low, along with requirements for a message tracking solution that can be
used with the Internet-wide message infrastructure. This memo and its used with the Internet-wide message infrastructure. This memo and its
companions, [RFC-TRACK-ESMTP] and [RFC-TRACK-TSN], describe a complete companions, [RFC-TRACK-ESMTP] and [RFC-TRACK-TSN], describe a complete
message tracking solution that satisfies those requirements. The memo message tracking solution that satisfies those requirements. The memo
[RFC-TRACK-ESMTP] defines an extension to the SMTP service that provides [RFC-TRACK-ESMTP] defines an extension to the SMTP service that provides
the information necessary to track messages. This memo defines a proto- the information necessary to track messages. This memo defines a proto-
skipping to change at page 2, line 36 skipping to change at page 2, line 32
report tracking status information. Using the model document's termi- report tracking status information. Using the model document's termi-
nology, this solution uses active enabling and active requests with both nology, this solution uses active enabling and active requests with both
request and chaining referrals. request and chaining referrals.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-KEYWORDS]. document are to be interpreted as described in [RFC-KEYWORDS].
All syntax descriptions use the ABNF specified by [RFC-ABNF]. All syntax descriptions use the ABNF specified by [RFC-ABNF]. Ter-
Unless otherwise noted, any terminal nodes not defined here are defined minal nodes not defined elsewhere in this document are defined in [RFC-
in [RFC-ABNF]. ABNF], [RFC-URI], [RFC-TRACK-ESMTP] or [RFC-SMTPEXT].
1.2. To Do
provide information on finding an MTQP server
provide TTL info, maximum times for keeping info
determine the TCP port to use
2. Basic Operation 2. Basic Operation
The Message Tracking Query Protocol (MTQP) is similar to many other The Message Tracking Query Protocol (MTQP) is similar to many other
line-oriented Internet protocols, such as [POP3] and [NNTP]. Initially, line-oriented Internet protocols, such as [POP3] and [NNTP]. Initially,
the server host starts the MTQP service by listening on TCP port ????. the server host starts the MTQP service by listening on TCP port TBD.
When a client wishes to make use of the service, it establishes a TCP When a client wishes to make use of the service, it establishes a TCP
connection with the server host. When the connection is established, connection with the server host. When the connection is established,
the MTQP SERVER SENDS A GREETING. The client and MTQP server then the MTQP server sends a greeting. The client and MTQP server then
exchange commands and responses (respectively) until the connection is exchange commands and responses (respectively) until the connection is
closed or aborted. closed or aborted.
2.1. Commands
Commands in MTQP consist of a case-insensitive keyword, possibly Commands in MTQP consist of a case-insensitive keyword, possibly
followed by one or more parameters. All commands are terminated by a followed by one or more parameters. All commands are terminated by a
CRLF pair. Keywords and parameters consist of printable ASCII charac- CRLF pair. Keywords and parameters consist of printable ASCII charac-
ters. Keywords and parameters are separated by whitespace (one or more ters. Keywords and parameters are separated by whitespace (one or more
space or tab characters). A command line is limited to 998 characters space or tab characters). A command line is limited to 998 characters
before the CRLF. before the CRLF.
2.2. Responses
Responses in MTQP consist of a status indicator that indicates suc- Responses in MTQP consist of a status indicator that indicates suc-
cess or failure, possibly followed by whitespace and additional informa- cess or failure. Successful commands may also be followed by additional
tion. Successful commands may also be followed by additional lines of lines of data. All response lines are terminated by a CRLF pair and are
data. All response lines are terminated by a CRLF pair and are limited limited to 998 characters before the CRLF. There are several status
to 998 characters before the CRLF. There are several status indicators: indicators: "+OK" indicates success; "+OK+" indicates a success fol-
"+OK" indicates success; "+OK+" indicates a success followed by addi- lowed by additional lines of data, a multi-line success response; "-
tional lines of data, a multi-line success response; "-TEMP" indicates a TEMP" indicates a temporary failure; "-ERR" indicates a permanent
temporary failure; "-ERR" indicates a permanent failure; and "-BAD" failure; and "-BAD" indicates a protocol error (such as for unrecognized
indicates a protocol error (such as for unrecognized commands). commands).
A multi-line success response may take one of two forms. If the A status indicator MAY be followed by a series of machine-
end of the +OK+ line contains the character "{", a number, and the char- parseable, case-insensitive response information giving more data about
acter "}" before the CRLF, then the rest of the response consists of the errors. These are separated from the status indicator and each
that number of characters. other by a single slash character ("/", decimal code 47). Following
that, there MAY be white space and a human-readable text message.
If the multi-line success response does not end with "{number}", In a multi-line success response, each subsequent line is ter-
each subsequent line is terminated by a CRLF pair and limited to 998 minated by a CRLF pair and limited to 998 characters before the CRLF.
characters before the CRLF. When all lines of the response have been When all lines of the response have been sent, a final line is sent con-
sent, a final line is sent consisting of a single period (".", decimal sisting of a single period (".", decimal code 046) and a CRLF pair. If
code 046) and a CRLF pair. If any line of the multi-line response any line of the multi-line response begins with a period, the line is
begins with a period, the line is "dot-stuffed" by prepending the period "dot-stuffed" by prepending the period with a second period. When exa-
with a second period. When examining a multi-line response, the client mining a multi-line response, the client checks to see if the line
checks to see if the line begins with a period. If so, and other octets begins with a period. If so, and octets other than CRLF follow, the
other than CRLF follow, the first octet of the line (the period) is first octet of the line (the period) is stripped away. If so, and if
stripped away. If so, and if CRLF immediately follows the period, then CRLF immediately follows the period, then the response from the MTQP
the response from the MTQP server is ended and the line containing the server is ended and the line containing the ".CRLF" is not considered
".CRLF" is not considered part of the multi-line response. part of the multi-line response.
An MTQP server MUST respond to an unrecognized, unimplemented, or An MTQP server MUST respond to an unrecognized, unimplemented, or
syntactically invalid command by responding with a negative -BAD status syntactically invalid command by responding with a negative -BAD status
indicator. A server MUST respond to a command issued when the session 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- is in an incorrect state by responding with a negative -ERR status indi-
cator. cator.
2.3. Optional Timers
An MTQP server MAY have an inactivity autologout timer. Such a An MTQP server MAY have an inactivity autologout timer. Such a
timer MUST be of at least 10 minutes' duration. The receipt of any com- timer MUST be of at least 10 minutes in duration. The receipt of any
mand from the client during that interval should suffice to reset the command from the client during that interval should suffice to reset the
autologout timer. autologout timer. An MTQP server MAY limit the number of commands or
total connection time to prevent denial of service attacks.
3. Initialization 3. Initialization and Option Response
Once the TCP connection has been opened by an MTQP client, the MTQP Once the TCP connection has been opened by an MTQP client, the MTQP
server issues an initial status response indicates its readiness. If server issues an initial status response indicates its readiness. If
the status response is positive (+OK or +OK+), the client may proceed the status response is positive (+OK or +OK+), the client may proceed
with other commands. with other commands.
The initial status response MUST include the response information
"/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
"unknown".
"/" "unavailable"
"/" "admin"
"/" "unknown"
"/" "referral" "=" net_loc
If the server has any options enabled, they are listed as the If the server has any options enabled, they are listed as the
multi-line response of the initial status response, one per line. An multi-line response of the initial status response, one per line. An
option specification consists of an identifier, optionally followed by option specification consists of an identifier, optionally followed by
option-specific parameters. An option specification may be continued option-specific parameters. An option specification may be continued
onto additional lines by starting the continuation lines with white onto additional lines by starting the continuation lines with white
space. space. The option identifier is case insensitive. Option identifiers
beginning with the characters "vnd." are reserved for vendor use.
No options are defined in this document. One option specification is defined here:
STARTTLS
This capability MUST be listed if the optional STARTTLS command is sup-
ported by the MTQP server. It has no parameters.
Example #1 (no options): Example #1 (no options):
S: +OK MTQ server ready S: +OK/MTQP MTQP server ready
Example #2 (service temporarily unavailable): Example #2 (service temporarily unavailable):
S: -TEMP Service down for admin, call back later S: -TEMP/MTQP/admin Service down for admin, call back later
Example #3 (service permanently unavailable): Example #3 (service permanently unavailable):
S: -ERR Service down S: -ERR/MTQP/unavailable Service down
Example #4 (alternative for no options): Example #4 (alternative for no options):
S: +OK+ MTQ server ready S: +OK+/MTQP MTQP server ready
S: . S: .
Example #5 (options available): Example #5 (options available):
S: +OK+ MTQ server ready S: +OK+/MTQP MTQP server ready
S: Option1 parameters S: starttls
S: Option2 S: Option2 with parameters
S: Option3 a very long S: Option3 with a very long
S: list of parameters S: list of parameters
S: . S: .
Example #6 (Referred to another server):
S: -ERR/MTQP/referral=server42.example.com:37
4. TRACK Command 4. TRACK Command
Syntax: Syntax:
"TRACK" 1*WS tracking-id 1*WS authorization-cookie *WS CRLF "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF
tracking-id = TBD mtrk-secret = base64
authorization-cookie = TBD Envid is defined in [RFC-TRACK-ESMTP]. Mtrk-secret is the secret S
described in [RFC-TRACK-ESMTP], encoded using base64.
When the client issues the TRACK command, the MTQP server retrieves When the client issues the TRACK command, the MTQP server retrieves
tracking information about an email message. A successful response MUST tracking information about an email message. A successful response MUST
be multi-line, consisting of a [MIME] mail message whose default be multi-line, consisting of a [MIME] body part. The default content-
content-type is message/tracking-status, as defined in [RFC-TRACK-TSN]. type for this MIME body part is message/tracking-status, as defined in
This message contains the tracking information about the email message [RFC-TRACK-TSN]. The response contains the tracking information about
that used the given tracking-id. The tracking-id and authorization- the email message that used the given tracking-id. Multiple responses
would be reported using a multipart/mixed body part with
message/tracking-status internals. The tracking-id and authorization-
cookie are defined in [RFC-TRACK-ESMTP].
cookie are defined in [RFC-TRACK-ESMTP]. The authorization-cookie is TBD: Give details on different modes of responses and how they map
expressed in hexadecimal. into message/tracking-status
Example #6 Example #7 :
C: TRACK <tracking-id> 1234567890ABCDEF C: TRACK <tracking-id> 1234567890ABCDEF
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: Content-Type: message/tracking-status S: Content-Type: message/tracking-status
S: S:
S: ... details go here ... S: ... details go here when ...
S: ... draft-ietf-msgtrk-trkstat becomes available ...
S: . S: .
5. NOOP Command 5. COMMENT Command
Syntax: Syntax:
"NOOP" opt-text CRLF "COMMENT" opt-text CRLF
When the client issues the NOOP command, the MTQP server resets the opt-text = [WSP *(VCHAR / WSP)]
inactivity autologout timer. The server MUST respond with a successful
response (+OK or +OK+). All parameters to the NOOP command are ignored.
6. QUIT Command 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: Syntax:
"QUIT" *WS CRLF "STARTTLS" 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.
If the server returns a negative response, it MAY use one of the
following response codes:
"/" "unsupported"
"/" "unavailable"
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, the STARTTLS command must
be the last command in a group.
6.1. Processing After the STARTTLS Command
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 "-BAD"
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
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- When the client issues the QUIT command, the MTQP session ter-
minates. The QUIT command has no parameters. The server MUST respond minates. The QUIT command has no parameters. The server MUST respond
with a successful response. The client may close the session from its with a successful response. The client may close the session from its
end immediately after issuing this command. end immediately after issuing this command.
7. Pipelining 8. Pipelining
The MTQP client may elect to transmit groups of MTQP commands in The MTQP client may elect to transmit groups of MTQP commands in
batches without waiting for a response to each individual command. The batches without waiting for a response to each individual command. The
MTQP server MUST process the commands in the order received. The fol- MTQP server MUST process the commands in the order received.
lowing two examples are identical:
Example #7 Specific commands may place further constraints on pipelining. For
example, STARTTLS must be the last command in a batch of MTQP commands.
The following two examples are identical:
Example #8 :
C: TRACK <tracking-id> 1234567890ABCDEF C: TRACK <tracking-id> 1234567890ABCDEF
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: S:
S: ... details go here ... S: ... details go here ...
S: . S: .
C: NOOP C: TRACK <tracking-id-2> ABCDEF1234567890
S: +OK Status okay S: +OK+ Tracking information follows
S:
S: ... details #2 go here ...
S: .
Example #8 Example #9 :
C: TRACK <tracking-id> 1234567890ABCDEF C: TRACK <tracking-id> 1234567890ABCDEF
C: NOOP C: TRACK <tracking-id-2> ABCDEF1234567890
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: S:
S: ... details go here ... S: ... details go here ...
S: . S: .
S: +OK Status okay S: +OK+ Tracking information follows
S:
S: ... details #2 go here ...
S: .
8. URL Format 9. URL Format
The MTQP URL scheme is used to designate MTQP servers on Internet The MTQP URL scheme is used to designate MTQP servers on Internet
hosts accessible using the MTQP protocol. An MTQP URL takes one of the hosts accessible using the MTQP protocol. An MTQP URL takes one of the
following forms: following forms:
mtqp://<mserver>/track/<tracking-id>:<cookie> mtqp://<mserver>/track/<envid>/<mtrk-secret>
mtqp://<mserver>:<port>/track/<tracking-id>:<cookie> mtqp://<mserver>:<port>/track/<envid>/<mtrk-secret>
The first form is used to refer to an MTQP server on the standard 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 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 these forms specify that the TRACK command is to be issued using the
given tracking id and authorization cookie. The path element "/track/" given tracking id and authorization cookie. The path element "/track/"
is case insensitive, but the tracking id may not be. is case insensitive, but the envid and mtrk-secret may not be.
8.1. MTQP URL Syntax 9.1. MTQP URL Syntax
This is an ABNF description of the MTQP URL. Terminal nodes not This is an ABNF description of the MTQP URL.
defined here are defined in either [RFC-URL] or [RFC-ABNF].
mtqp-url = "mtqp://" net_loc "/track/" tracking-id ":" cookie mtqp-url = "mtqp://" net_loc "/track/" envid ":" mtrk-secret
tracking-id = TBD 10. IANA Considerations
cookie = 16HEXDIG The service name to be registered with the Internet Assigned Number
Authority (IANA) is "MTQP".
9. IANA Considerations This document requests that IANA maintain one new registry: MTQP
options.
TBD - registering extensions Additional options for this protocol whose names do not begin with
"vnd." MUST be defined in a standards track or IESG approved experimen-
tal RFC. New MTQP options MUST include the following information:
10. Security Considerations option identifier
option parameters
added commands
standard commands affected
specification reference
discussion
Additional options for this protocol whose names begin with "vnd."
MUST be registered with IANA on a Firt Come First Served basis.
11. Security Considerations
Security considerations discussed in [RFC-TRACK-MODEL] and [RFC- Security considerations discussed in [RFC-TRACK-MODEL] and [RFC-
TRACK-ESMTP] are relevant. TRACK-ESMTP] are relevant.
11. Protocol Syntax 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.
This is an ABNF description of MTQP. It should be noted that message tracking is not an end-to-end
command-response = success-response / temp-response / error-response / bad-response 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.
temp-response = "-TEMP" opt-text CRLF Both the STMP client and server must check the result of the TLS
opt-text = [WSP *(VCHAR / WSP)] 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-dependant, and is beyond
the scope of this document.
error-response = "-ERR" opt-text CRLF The SMTP 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
bad-response = "-BAD" opt-text CRLF commands.
success-response = single-line-success / multi-line-success / multi-char-success 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.
single-line-success = "+OK" opt-text CRLF 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.
multi-char-success = "+OK+" opt-text "{" 1*DIGIT "}" *WSP CRLF *OCTET Before the TLS handshake has begun, any protocol interactions are
; the number of characters specified by {number} ; must be performed in the clear and may be modified by an active attacker. For
sent this reason, clients and servers MUST discard any knowledge obtained
prior to the start of the TLS handshake upon completion of the TLS
handshake.
multi-line-success = "+OK+" opt-text CRLF *dataline dotcrlf 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" 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
multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf
dataline = *998OCTET CRLF dataline = *998OCTET CRLF
dotcrlf = "." CRLF dotcrlf = "." CRLF
option-list = *option-line option-list = *option-line
option-line = rulename opt-text *[CRLF WSP opt-text] CRLF option-line = identifier opt-text *[CRLF WSP opt-text] CRLF
12. References identifier = (ALPHA / "_") *(ALPHA / DIGIT / "-" / "_")
13. Acknowledgements
The description of STARTTLS is based on [RFC-SMTP-TLS].
14. References
[MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Internet [MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Message Bodies", Mail Extensions (MIME) Part One: Format of Internet Message Bodies",
November 1996. November 1996.
[RFC-821] STD 10, RFC 821, J. Postel, "Simple Mail Transfer Proto- [RFC-821] STD 10, RFC 821, J. Postel, "Simple Mail Transfer Proto-
col", University of Southern California / Information Sciences Insti- col", University of Southern California / Information Sciences Insti-
tute, August 1982. tute, August 1982.
[RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of [RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of
skipping to change at page 8, line 5 skipping to change at page 11, line 47
[RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented
BNF for Syntax Specifications: ABNF", November 1997. BNF for Syntax Specifications: ABNF", November 1997.
[RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud, [RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud,
and D. Crocker, "SMTP Service Extensions", Silicon Graphics, Inc., July and D. Crocker, "SMTP Service Extensions", Silicon Graphics, Inc., July
1994. 1994.
[RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to
Indicate Requirement Levels", March 1997. Indicate Requirement Levels", March 1997.
[RFC-MD5] RFC 1321, R. Rivest, "The MD5 Message-Digest Algorithm", [RFC-MD5] RFC 1321, R. Rivest, MIT Laboratory for Computer Science
April 1992. and RSA Data Security, Inc., "The MD5 Message-Digest Algorithm", April
1992.
[RFC-TRACK-MODEL] draft-ietf-msgtrk-model-02.txt, T. Hansen, K. [RFC-SMTPEXT] RFC 2554, J. Myers, Netscape Communications, "SMTP
Lin, "Message Tracking Models and Requirements", AT&T Laboratories, Service Extension for Authentication", March 1999.
Lotus Development Corporation, ???? 2000.
[RFC-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, "SMTP [RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for
Service Extension for Message Tracking", Sendmail, Inc., ???? 2000. Secure SMTP over TLS", Internet Mail Consortium, January 1999.
[RFC-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-00.txt, E. Allman, T.
Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc.,
AT&T Laboratories, TBD 2000.
[RFC-TRACK-MODEL] draft-ietf-msgtrk-model-03.txt, T. Hansen, "Mes-
sage Tracking Models and Requirements", AT&T Laboratories, November
2000.
[RFC-TRACK-TSN] draft-ietf-msgtrk-trkstat-00.txt, E. Allman, "The [RFC-TRACK-TSN] draft-ietf-msgtrk-trkstat-00.txt, E. Allman, "The
Message/Tracking-Status MIME Extension", Sendmail, Inc., ???? 2000. Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2000.
[RFC-URL] RFC 1808, R. Fielding, "Relative Uniform Resource Loca- [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni-
tors", June 1995. form Resource Identifiers (URI): Generic Syntax", August 1998.
13. Authors' Addresses 15. Authors' Addresses
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
Lincroft, NJ 07738 Lincroft, NJ 07738
USA USA
Phone: +1.732.576.3207 Phone: +1.732.576.3207
E-Mail: tony@att.com E-Mail: tony@att.com
14. Full Copyright Statement 16. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and dis- assist in its implmentation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or be modified in any way, such as by removing the copyright notice or
skipping to change at page 8, line 49 skipping to change at page 13, line 4
that the above copyright notice and this paragraph are included on all that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organisations, references to the Internet Society or other Internet organisations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet Stan- which case the procedures for copyrights defined in the Internet Stan-
dards process must be followed, or as required to translate it into dards process must be followed, or as required to translate it into
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
This document expires January 1, 2001. This document expires May 21, 2001.
 End of changes. 80 change blocks. 
123 lines changed or deleted 317 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/