draft-ietf-msgtrk-mtqp-06.txt   draft-ietf-msgtrk-mtqp-07.txt 
Internet Draft T. Hansen Internet Draft T. Hansen
draft-ietf-msgtrk-mtqp-06.txt AT&T Laboratories draft-ietf-msgtrk-mtqp-07.txt AT&T Laboratories
Valid for six months April 1, 2002 Valid for six months April 9, 2002
Message Tracking Query Protocol Message Tracking Query Protocol
<draft-ietf-msgtrk-mtqp-06.txt> <draft-ietf-msgtrk-mtqp-07.txt>
Authors' version: 1.15 Authors' version: 1.17
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 -06 1.2. Changes Made for -07
Added hostname to STARTTLS registration information. Corrected ABNF for
STARTTLS.
1.3. Changes Made for -06
Added opt-parameter to STARTTLS and description. Added opt-parameter to STARTTLS and description.
1.3. Changes Made for -05 1.4. Changes Made for -05
STARTTLS error response changed from "/unsupported" to "/unavailable". STARTTLS error response changed from "/unsupported" to "/unavailable".
Fixed some minor nits in the examples and some typos. Fixed some minor nits in the examples and some typos.
1.4. Changes Made for -04 1.5. 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.5. Changes Made for -03 1.6. 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.6. Changes Made for -02 1.7. 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 52 skipping to change at page 6, line 11
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 unrecognized commands, or total connection time, or MAY use other cri-
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, gath- tion is available; or it may perform a chaining operation itself, gath-
ering information on the message from the mail hosts behind the ering 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,
skipping to change at page 6, line 46 skipping to change at page 7, line 4
vailable for administrative reasons. The reason code "/unavailable" vailable for administrative reasons. The reason code "/unavailable"
SHOULD be used when the service is unavailable for other reasons. SHOULD be used when the service is unavailable for other reasons.
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. 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 This capability MUST be listed if the optional STARTTLS command is sup-
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
skipping to change at page 12, line 20 skipping to change at page 12, line 27
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" [hostname] CRLF "STARTTLS" [WSP 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 The optional parameter, if specified, MUST be a fully qualified
domain name. A client MAY specify the hostname it believes it is speak- 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. ing with so that the server may respond with the proper TLS certificate.
This is useful for virtual servers that provide message tracking for This is useful for virtual servers that provide message tracking for
skipping to change at page 13, line 52 skipping to change at page 14, line 10
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 When the client issues the QUIT command, the MTQP session ter-
minates. The QUIT command has no parameters. The server MUST respond
terminates. The QUIT command has no parameters. The server MUST with a successful response. The client MAY close the session from its
respond with a successful response. The client MAY close the session end immediately after issuing this command (if the client is on an
from its end immediately after issuing this command (if the client is on operating system where this does not cause problems).
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 41 skipping to change at page 15, line 51
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, with the following One MTQP option is defined in this document, with the following
registration definition: registration definition:
option identifier: STARTTLS option identifier: STARTTLS
option parameters: none option parameters: hostname
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
itself. For example, "vnd.com.example.extinfo" might represent a itself. For example, "vnd.com.example.extinfo" might represent a
vendor-specific extension providing extended information by the owner of vendor-specific extension providing extended information by the owner of
skipping to change at page 17, line 32 skipping to change at page 17, line 41
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" [hostname] CRLF starttls-command = "STARTTLS" [WSP 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 20, line 4 skipping to change at page 20, line 13
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 October 1, 2002. This document expires October 9, 2002.
 End of changes. 17 change blocks. 
25 lines changed or deleted 26 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/