draft-ietf-msgtrk-mtqp-05.txt   draft-ietf-msgtrk-mtqp-06.txt 
Internet Draft T. Hansen Internet Draft T. Hansen
draft-ietf-msgtrk-mtqp-05.txt AT&T Laboratories draft-ietf-msgtrk-mtqp-06.txt AT&T Laboratories
Valid for six months January 14, 2002 Valid for six months April 1, 2002
Message Tracking Query Protocol Message Tracking Query Protocol
<draft-ietf-msgtrk-mtqp-05.txt> <draft-ietf-msgtrk-mtqp-06.txt>
Authors' version: 1.13 Authors' version: 1.15
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 36 skipping to change at page 2, line 36
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]. Ter- All syntax descriptions use the ABNF specified by [RFC-ABNF]. Ter-
minal nodes not defined elsewhere in this document are defined in [RFC- minal nodes not defined elsewhere in this document are defined in [RFC-
ABNF], [RFC-URI], [DRAFT-TRACK-ESMTP] or [RFC-SMTPEXT]. ABNF], [RFC-URI], [DRAFT-TRACK-ESMTP] or [RFC-SMTPEXT].
1.2. Changes Made for -04 1.2. Changes Made for -06
Added opt-parameter to STARTTLS and description.
1.3. Changes Made for -05
STARTTLS error response changed from "/unsupported" to "/unavailable".
Fixed some minor nits in the examples and some typos.
1.4. Changes Made for -04
Reworked the SRV lookup description. Reworked the SRV lookup description.
Other comments from the list. Other comments from the list.
Changes to the ABNF. Changes to the ABNF.
Changed "must" to "MUST" in section 4. Changed "must" to "MUST" in section 4.
Changed "may" to "MAY" in section 4. Changed "may" to "MAY" in section 4.
More examples. More examples.
Eliminated the registry of vnd. options. Eliminated the registry of vnd. options.
Eliminated lots of unused references. Eliminated lots of unused references.
1.3. Changes Made for -03 1.5. Changes Made for -03
Changed references. Changed references.
Worked on error codes. Worked on error codes.
Made examples more real with secrets and hashes. Made examples more real with secrets and hashes.
Fixes to examples. Fixes to examples.
Added dot-stuffed example. Added dot-stuffed example.
Additional TLS info. Additional TLS info.
Better Security Considerations section. Better Security Considerations section.
1.4. Changes Made for -02 1.6. Changes Made for -02
This section will be removed before publication. This section will be removed before publication.
Provided information on lookup for an MTQP server: SRV MTQP, then Provided information on lookup for an MTQP server: SRV MTQP, then
MX, then A. MX, then A.
Provided a section on firewall considerations Provided a section on firewall considerations
Provided a section on service DNS considerations Provided a section on service DNS considerations
skipping to change at page 5, line 44 skipping to change at page 5, line 52
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.4. Optional Timers 2.4. 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 in duration. The receipt of any 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 command from the client during that interval should suffice to reset the
autologout timer. An MTQP server MAY limit the number of commands, autologout timer. An MTQP server MAY limit the number of commands,
unrecognized commands, or total connection time, or MAY use other cri- unrecognized commands, or total connection time, or MAY use other
teria, to prevent denial of service attacks.
criteria, to prevent denial of service attacks.
2.5. Firewall Considerations 2.5. Firewall Considerations
A firewall mail gateway has two choices when receiving a tracking 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 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- query that says the message has been passed on, but no further informa-
tion is available; or it may perform a chaining operation itself, tion is available; or it may perform a chaining operation itself, gath-
ering information on the message from the mail hosts behind the
gathering information on the message from the mail hosts behind the
firewall, and returning to the MTQP client the information for each firewall, and returning to the MTQP client the information for each
behind-the-firewall hop, or possibly just the final hop information, behind-the-firewall hop, or possibly just the final hop information,
possibly also disguising the names of any hosts behind the firewall. possibly also disguising the names of any hosts behind the firewall.
Which option is picked is an administrative decision and is not further Which option is picked is an administrative decision and is not further
mandated by this document. mandated by this document.
3. Initialization and Option Response 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 that indicates its readiness. server issues an initial status response that indicates its readiness.
skipping to change at page 6, line 44 skipping to change at page 6, line 52
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. The option identifier is case insensitive. Option identifiers space. The option identifier is case insensitive. Option identifiers
beginning with the characters "vnd." are reserved for vendor use. (See beginning with the characters "vnd." are reserved for vendor use. (See
below.) below.)
One option specification is defined here: One option specification is defined here:
STARTTLS STARTTLS
This capability MUST be listed if the optional STARTTLS command is sup- This capability MUST be listed if the optional STARTTLS command is
ported by the MTQP server. It has no parameters.
supported by the MTQP server. It has no parameters.
Example #1 (no options): Example #1 (no options):
S: +OK/MTQP MTQP server ready S: +OK/MTQP MTQP server ready
Example #2 (service temporarily unavailable): Example #2 (service temporarily unavailable):
S: -TEMP/MTQP/admin 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/MTQP/unavailable Service down S: -ERR/MTQP/unavailable Service down
Example #4 (alternative for no options): Example #4 (alternative for no options):
S: +OK+/MTQP MTQP server ready S: +OK+/MTQP MTQP server ready
S: . S: .
Example #5 (options available): Example #5 (options available):
S: +OK+/MTQP MTQP server ready S: +OK+/MTQP MTQP server ready
S: starttls S: starttls
skipping to change at page 12, line 4 skipping to change at page 12, line 12
S: S:
S: --%%%%-- S: --%%%%--
S: . S: .
5. COMMENT Command 5. COMMENT Command
Syntax: Syntax:
"COMMENT" opt-text CRLF "COMMENT" opt-text CRLF
opt-text = [WSP *(VCHAR / WSP)] opt-text = [WSP *(VCHAR / WSP)]
When the client issues the COMMENT command, the MTQP server MUST When the client issues the COMMENT command, the MTQP server MUST
respond with a successful response (+OK or +OK+). All optional text respond with a successful response (+OK or +OK+). All optional text
provided with the COMMENT command are ignored. provided with the COMMENT command are ignored.
6. STARTTLS Command 6. STARTTLS Command
Syntax: Syntax:
"STARTTLS" CRLF "STARTTLS" [hostname] CRLF
TLS [TLS], more commonly known as SSL, is a popular mechanism for TLS [TLS], more commonly known as SSL, is a popular mechanism for
enhancing TCP communications with privacy and authentication. An MTQP enhancing TCP communications with privacy and authentication. An MTQP
server MAY support TLS. If an MTQP server supports TLS, it MUST include server MAY support TLS. If an MTQP server supports TLS, it MUST include
"STARTTLS" in the option specifications list on protocol startup. "STARTTLS" in the option specifications list on protocol startup.
The optional parameter, if specified, MUST be a fully qualified
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 If the server returns a negative response, it MAY use one of the
following response codes: following response codes:
"/" "unsupported" "/" "unsupported"
"/" "unavailable" "/" "unavailable"
"/" "tlsinprogress" "/" "tlsinprogress"
If TLS is not supported, then a response code of "/unsupported" 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 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 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 already in progress, then it is a protocol error and "-BAD" MUST be
skipping to change at page 13, line 37 skipping to change at page 13, line 52
Both the client and the server MUST know if there is a TLS session 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- active. A client MUST NOT attempt to start a TLS session if a TLS ses-
sion is already active. sion is already active.
7. QUIT Command 7. QUIT Command
Syntax: Syntax:
"QUIT" CRLF "QUIT" CRLF
When the client issues the QUIT command, the MTQP session ter- When the client issues the QUIT command, the MTQP session
minates. The QUIT command has no parameters. The server MUST respond
with a successful response. The client MAY close the session from its terminates. The QUIT command has no parameters. The server MUST
end immediately after issuing this command (if the client is on an respond with a successful response. The client MAY close the session
operating system where this does not cause problems). from its end immediately after issuing this command (if the client is on
an operating system where this does not cause problems).
8. 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. MTQP server MUST process the commands in the order received.
Specific commands may place further constraints on pipelining. For Specific commands may place further constraints on pipelining. For
example, STARTTLS must be the last command in a batch of MTQP commands. example, STARTTLS must be the last command in a batch of MTQP commands.
skipping to change at page 15, line 25 skipping to change at page 15, line 37
standards track or IESG approved experimental RFC. New MTQP options standards track or IESG approved experimental RFC. New MTQP options
MUST include the following information as part of their definition: MUST include the following information as part of their definition:
option identifier option identifier
option parameters option parameters
added commands added commands
standard commands affected standard commands affected
specification reference specification reference
discussion discussion
One MTQP option is defined in this document: One MTQP option is defined in this document, with the following
registration definition:
option identifier: STARTTLS option identifier: STARTTLS
option parameters: none option parameters: none
added commands: STARTTLS added commands: STARTTLS
standard commands affected: none standard commands affected: none
specification reference: RFC TBD specification reference: RFC TBD
discussion: see RFC TBD discussion: see RFC TBD
Additional vendor-specific options for this protocol have names Additional vendor-specific options for this protocol have names
that begin with "vnd.". After the "vnd." would appear the reversed that begin with "vnd.". After the "vnd." would appear the reversed
domain name of the vendor, another dot ".", and a name for the option domain name of the vendor, another dot ".", and a name for the option
skipping to change at page 15, line 52 skipping to change at page 16, line 19
If the originator of a message were to delegate his or her tracking 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 request to a third party, this would be vulnerable to snooping over
unencrypted sessions. The user can decide on a message-by-message basis unencrypted sessions. The user can decide on a message-by-message basis
if this risk is acceptable. if this risk is acceptable.
The security of tracking information is dependent on the randomness The security of tracking information is dependent on the randomness
of the secret chosen for each message and the level of exposure of that 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- secret. If different secrets are used for each message, then the max-
imum exposure from tracking any message will be that single message for 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 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 this level of exposure is too much, TLS may be used to reduce the expo-
sure further.
exposure further.
It should be noted that message tracking is not an end-to-end 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 mechanism. Thus, if an MTQP client/server pair decide to use TLS
privacy, they are not securing tracking queries with any prior or suc- privacy, they are not securing tracking queries with any prior or suc-
cessive MTQP servers. cessive MTQP servers.
Both the MTQP client and server must check the result of the TLS Both the MTQP client and server must check the result of the TLS
negotiation to see whether acceptable authentication or privacy was negotiation to see whether acceptable authentication or privacy was
achieved. Ignoring this step completely invalidates using TLS for secu- achieved. Ignoring this step completely invalidates using TLS for secu-
rity. The decision about whether acceptable authentication or privacy rity. The decision about whether acceptable authentication or privacy
skipping to change at page 17, line 17 skipping to change at page 17, line 32
This is a collected ABNF description of the MTQP protocol. This is a collected ABNF description of the MTQP protocol.
conversation = command-response *( client-command command-response ) conversation = command-response *( client-command command-response )
# client side # client side
client-command = track-command / starttls-command / quit-command / comment-command client-command = track-command / starttls-command / quit-command / comment-command
track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF
mtrk-secret = base64 mtrk-secret = base64
starttls-command = "STARTTLS" CRLF starttls-command = "STARTTLS" [hostname] CRLF
quit-command = "QUIT" CRLF quit-command = "QUIT" CRLF
comment-command = "COMMENT" opt-text CRLF comment-command = "COMMENT" opt-text CRLF
# server side # server side
command-response = success-response / temp-response / error-response / bad-response command-response = success-response / temp-response / error-response / bad-response
temp-response = "-TEMP" response-info opt-text CRLF temp-response = "-TEMP" response-info opt-text CRLF
skipping to change at page 19, line 9 skipping to change at page 19, line 22
Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2001. Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2001.
[RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni- [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni-
form Resource Identifiers (URI): Generic Syntax", MIT/LCS, U. C. Irvine, form Resource Identifiers (URI): Generic Syntax", MIT/LCS, U. C. Irvine,
Xerox Corporation, August 1998. Xerox Corporation, August 1998.
15. Author's Address 15. Author's Address
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
Lincroft, NJ 07738 Middletown, NJ 07748
USA USA
Phone: +1.732.576.3207 Phone: +1.732.420.8934
E-Mail: tony@att.com E-Mail: tony@att.com
16. 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 implementation may be prepared, copied, published and dis- assist in its implementation 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
skipping to change at page 19, line 40 skipping to change at page 20, line 4
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 July 14, 2002. This document expires October 1, 2002.
 End of changes. 21 change blocks. 
27 lines changed or deleted 47 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/