draft-ietf-msgtrk-mtqp-01.txt   draft-ietf-msgtrk-mtqp-02.txt 
Internet Draft T. Hansen Internet Draft T. Hansen
draft-ietf-msgtrk-mtqp-01.txt AT&T Laboratories draft-ietf-msgtrk-mtqp-02.txt AT&T Laboratories
Valid for six months November 21, 2000 Valid for six months March 2, 2001
Message Tracking Query Protocol Message Tracking Query Protocol
<draft-ietf-msgtrk-mtqp-01.txt> <draft-ietf-msgtrk-mtqp-02.txt>
Authors' version: 1.5 Authors' version: 1.6
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], [RFC-TRACK-ESMTP] or [RFC-SMTPEXT]. ABNF], [RFC-URI], [RFC-TRACK-ESMTP] or [RFC-SMTPEXT].
1.2. To Do 1.2. Changes Made for -02
provide information on finding an MTQP server This section will be removed before publication.
provide TTL info, maximum times for keeping info Provided information on lookup for an MTQP server: SRV MTQP, then
MX, then A.
determine the TCP port to use Provided a section on firewall considerations
Provided a section on service DNS considerations
At IANA's request, left the port number as XXXX and added more
information on the option registry.
Added text on various error conditions and fixed ABNF for error
response codes.
Fleshed out the tracking examples.
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 TBD. the server host starts the MTQP service by listening on TCP port XXXX
When a client wishes to make use of the service, it establishes a TCP (TBD by IANA).
connection with the server host. When the connection is established,
the MTQP server sends a greeting. The client and MTQP server then
exchange commands and responses (respectively) until the connection is
closed or aborted. When an MTQP client wishes to make use of the message tracking ser-
vice, it establishes a TCP connection with the server host. To find the
server host, the MTQP client first does an SRV lookup for the server
host using DNS SRV records, with a service name of "mtqp". (See the
"Usage rules" section in [RFC-SRV] for details.) If the host is not
found, the MTQP client then does an MX lookup for the server host using
DNS MX records. If the host is still not found, the MTQP client then
does an A record lookup for the server host.
2.1. Commands When the connection is established, the MTQP server sends a greet-
ing. The MTQP client and MTQP server then exchange commands and
responses (respectively) until the connection is closed or aborted.
2.1. Tracking Service DNS Considerations
Because of the ways server host lookups are performed, many dif-
ferent tracking server host configurations are supported.
A mail system that uses a single mail server host and has the MTQP
server host on the same server host will most likely have a single MX
record pointing at the server host, and if not, will have an A record.
Both mail and MTQP clients will access that host directly.
A mail system that uses a single mail server host, but wants track-
ing queries to be performed on a different machine, MUST have an SRV
MTQP record pointing at that different machine.
A mail system that uses multiple mail servers has two choices for
providing tracking services: either all mail servers must be running
tracking servers that are able to retrieve information on all messages,
or the tracking service must be performed on one (or more) machine(s)
that are able to retrieve information on all messages. In the former
case, no additional DNS records are needed beyond the MX records already
in place for the mail system. In the latter case, SRV MTQP records are
needed that point at the machine(s) that are running the tracking ser-
vice. In both cases, note that the tracking service for a given mail
domain MUST be able to handle the queries for all messages destined for
that mail domain.
2.2. 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 2.3. 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. Successful commands may also be followed by additional cess or failure. Successful commands may also be followed by additional
lines of data. All response lines are terminated by a CRLF pair and are lines of data. All response lines are terminated by a CRLF pair and are
limited to 998 characters before the CRLF. There are several status limited to 998 characters before the CRLF. There are several status
indicators: "+OK" indicates success; "+OK+" indicates a success fol- indicators: "+OK" indicates success; "+OK+" indicates a success fol-
lowed by additional lines of data, a multi-line success response; "- lowed by additional lines of data, a multi-line success response; "-
TEMP" indicates a temporary failure; "-ERR" indicates a permanent TEMP" indicates a temporary failure; "-ERR" indicates a permanent
failure; and "-BAD" indicates a protocol error (such as for unrecognized failure; and "-BAD" indicates a protocol error (such as for unrecognized
commands). commands).
A status indicator MAY be followed by a series of machine- A status indicator MAY be followed by a series of machine-
parseable, case-insensitive response information giving more data about parseable, case-insensitive response information giving more data about
the errors. These are separated from the status indicator and each the errors. These are separated from the status indicator and each
other by a single slash character ("/", decimal code 47). Following other by a single slash character ("/", decimal code 47). Following
that, there MAY be white space and a human-readable text message. that, there MAY be white space and a human-readable text message. The
human-readable text message is not intended to be presented to the end
user, but should be appropriate for putting in a log for use in debug-
ging problems.
In a multi-line success response, each subsequent line is ter- In a multi-line success response, each subsequent line is ter-
minated by a CRLF pair and limited to 998 characters before the CRLF. minated by a CRLF pair and limited to 998 characters before the CRLF.
When all lines of the response have been sent, a final line is sent con- When all lines of the response have been sent, a final line is sent con-
sisting of a single period (".", decimal code 046) and a CRLF pair. If sisting of a single period (".", decimal code 046) and a CRLF pair. If
any line of the multi-line response begins with a period, the line is any line of the multi-line response begins with a period, the line is
"dot-stuffed" by prepending the period with a second period. When exa- "dot-stuffed" by prepending the period with a second period. When exa-
mining a multi-line response, the client checks to see if the line mining a multi-line response, the client checks to see if the line
begins with a period. If so, and octets other than CRLF follow, the begins with a period. If so, and octets other than CRLF follow, the
first octet of the line (the period) is stripped away. If so, and if first octet of the line (the period) is stripped away. If so, and if
CRLF immediately follows the period, then the response from the MTQP CRLF immediately follows the period, then the response from the MTQP
server is ended and the line containing the ".CRLF" is not considered server is ended and the line containing the ".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 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 or autologout timer. An MTQP server MAY limit the number of commands or
total connection time to prevent denial of service attacks. total connection time to prevent denial of service attacks.
2.5. Firewall Considerations
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 that says the message has been passed on, but no further informa-
tion is available; or it may perform a chaining operation itself, gath-
ering information on the message from the mail hosts behind the
firewall, and returning to the MTQP client the information for each
behind-the-firewall hop, or possibly just the final hop information,
possibly also disguising the names of any hosts behind the firewall.
Which option is picked is an adminstrative decision and is not further
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 indicates its readiness. If server issues an initial status response that indicates its readiness.
the status response is positive (+OK or +OK+), the client may proceed If 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 The initial status response MUST include the response information
"/MTQP". Negative responses MUST include a reason code as response "/MTQP". Negative responses MUST include a reason code as response
information. The following reason codes are defined here; unrecognized information. The following reason codes are defined here; unrecognized
reason codes added in the future may be treated as equivalent to reason codes added in the future may be treated as equivalent to
"unknown". "unknown".
"/" "unavailable" "/" "unavailable"
"/" "admin" "/" "admin"
"/" "unknown" "/" "unknown"
skipping to change at page 5, line 26 skipping to change at page 6, line 41
Example #6 (Referred to another server): Example #6 (Referred to another server):
S: -ERR/MTQP/referral=server42.example.com:37 S: -ERR/MTQP/referral=server42.example.com:37
4. TRACK Command 4. TRACK Command
Syntax: Syntax:
"TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF
mtrk-secret = base64 mtrk-secret = base64
Envid is defined in [RFC-TRACK-ESMTP]. Mtrk-secret is the secret S Envid is defined in [RFC-TRACK-ESMTP]. Mtrk-secret is the secret A
described in [RFC-TRACK-ESMTP], encoded using base64. 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, and the user is vali-
tracking information about an email message. A successful response MUST dated, the MTQP server retrieves tracking information about an email
be multi-line, consisting of a [MIME] body part. The default content- message. To validate the user, the value of mtrk-secret is hashed using
type for this MIME body part is message/tracking-status, as defined in SHA1, as described in [NIST-SHA1]. The hash value is then compared with
[RFC-TRACK-TSN]. The response contains the tracking information about the value passed with the message when it was originally sent. If the
the email message that used the given tracking-id. Multiple responses hash values match, the user is validated.
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].
TBD: Give details on different modes of responses and how they map A successful response MUST be multi-line, consisting of a [MIME]
into message/tracking-status body part. The MIME body part must be of type multipart/related, with
Example #7 : subparts of message/tracking-status, as defined in [RFC-TRACK-TSN]. The
C: TRACK <tracking-id> 1234567890ABCDEF response contains the tracking information about the email message that
used the given tracking-id.
In each of the examples below, the envid is "<12345-
20010101@example.com>", the secret A is "abcdefghijklmnopqrstuvwxyz",
and the SHA1 hash B is TBD. The message came from example.com and the
MTQP server is example2.com.
Example #7 Message Delivered:
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo=
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
S:
S: --%%%%
S: Content-Type: message/tracking-status S: Content-Type: message/tracking-status
S: S:
S: ... details go here when ... S: Original-Envelope-Id: 12345-20010101@example.com
S: ... draft-ietf-msgtrk-trkstat becomes available ... S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S:
S: Original-Recipient: user1
S: Final-Recipient: user1
S: Action: delivered
S: --%%%%--
S: .
Example #8 Message Transferred:
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo=
S: +OK+ Tracking information follows
S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
S:
S: --%%%%
S: Content-Type: message/tracking-status
S:
S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S:
S: Original-Recipient: user1
S: Final-Recipient: user1
S: Action: transferred
S: Remote-MTA: example3.com
S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500
S: --%%%%--
S: .
Example #9 Message Delayed:
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo=
S: +OK+ Tracking information follows
S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
S:
S: --%%%%
S: Content-Type: message/tracking-status
S:
S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S:
S: Original-Recipient: user1
S: Final-Recipient: user1
S: Action: delayed
S: Remote-MTA: example3.com
S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500
S: Will-Retry-Until: Thu, 4 Jan 2001 15:15:15 -0500
S: --%%%%--
S: .
Example #10 Two Users, One Relayed, One Failed:
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo=
S: +OK+ Tracking information follows
S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
S:
S: --%%%%
S: Content-Type: message/tracking-status
S:
S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S:
S: Original-Recipient: user1
S: Final-Recipient: user1
S: Action: relayed
S: Remote-MTA: example3.com
S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500
S:
S: Original-Recipient: user2
S: Final-Recipient: user2
S: Action: failed
S: Remote-MTA: example3.com
S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500
S: --%%%%--
S: .
Example #11 Firewall, Hiding System Names Behind the Firewall:
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo=
S: +OK+ Tracking information follows
S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
S:
S: --%%%%
S: Content-Type: message/tracking-status
S:
S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S:
S: Original-Recipient: user1
S: Final-Recipient: user1
S: Action: relayed
S: Remote-MTA: example2.com
S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500
S: --%%%%
S: Content-Type: message/tracking-status
S:
S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S:
S: Original-Recipient: user1
S: Final-Recipient: user1
S: Action: delivered
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
skipping to change at page 6, line 24 skipping to change at page 10, line 4
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" 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.
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"
If a TLS session is already in progress, then it is a protocol
error and "-BAD" MUST be returned with a response code of "/tlsinpro-
gress".
After receiving a positive response to a STARTTLS command, the After receiving a positive response to a STARTTLS command, the
client MUST start the TLS negotiation before giving any other MTQP com- client MUST start the TLS negotiation before giving any other MTQP com-
mands. mands.
If the MTQP client is using pipelining, the STARTTLS command must If the MTQP client is using pipelining, the STARTTLS command must
be the last command in a group. be the last command in a group.
6.1. Processing After the STARTTLS Command 6.1. Processing After the STARTTLS Command
After the TLS handshake has been completed, both parties MUST After the TLS handshake has been completed, both parties MUST
skipping to change at page 7, line 51 skipping to change at page 11, line 36
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.
The following two examples are identical: The following two examples are identical:
Example #8 : Example #12 :
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: ... tracking details #1 go here ...
S: . S: .
C: TRACK <tracking-id-2> ABCDEF1234567890 C: TRACK <tracking-id-2> ABCDEF1234567890
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: S:
S: ... details #2 go here ... S: ... tracking details #2 go here ...
S: . S: .
Example #9 : Example #13 :
C: TRACK <tracking-id> 1234567890ABCDEF C: TRACK <tracking-id> 1234567890ABCDEF
C: TRACK <tracking-id-2> ABCDEF1234567890 C: TRACK <tracking-id-2> ABCDEF1234567890
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: S:
S: ... details go here ...
S: ... tracking details #1 go here ...
S: . S: .
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: S:
S: ... details #2 go here ... S: ... tracking details #2 go here ...
S: . S: .
9. 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/<envid>/<mtrk-secret> mtqp://<mserver>/track/<envid>/<mtrk-secret>
mtqp://<mserver>:<port>/track/<envid>/<mtrk-secret> mtqp://<mserver>:<port>/track/<envid>/<mtrk-secret>
skipping to change at page 8, line 49 skipping to change at page 12, line 35
is case insensitive, but the envid and mtrk-secret may not be. is case insensitive, but the envid and mtrk-secret may not be.
9.1. MTQP URL Syntax 9.1. MTQP URL Syntax
This is an ABNF description of the MTQP URL. This is an ABNF description of the MTQP URL.
mtqp-url = "mtqp://" net_loc "/track/" envid ":" mtrk-secret mtqp-url = "mtqp://" net_loc "/track/" envid ":" mtrk-secret
10. IANA Considerations 10. IANA Considerations
System port number XXXX - TBA by IANA
The service name to be registered with the Internet Assigned Number The service name to be registered with the Internet Assigned Number
Authority (IANA) is "MTQP". Authority (IANA) is "MTQP".
This document requests that IANA maintain one new registry: MTQP This document requests that IANA maintain one new registry: MTQP
options. options. The registry's purpose is to register options to this proto-
col. Options whose names do not begin with "vnd." MUST be defined in a
Additional options for this protocol whose names do not begin with standards track or IESG approved experimental RFC. New MTQP options
"vnd." MUST be defined in a standards track or IESG approved experimen- MUST include the following information as part of their definition:
tal RFC. New MTQP options MUST include the following information:
option identifier option identifier
option parameters option parameters
added commands added commands
standard commands affected standard commands affected
specification reference specification reference
discussion discussion
Additional vendor-specific options for this protocol whose names
Additional options for this protocol whose names begin with "vnd." begin with "vnd." MUST be registered with IANA on a Firt Come First
MUST be registered with IANA on a Firt Come First Served basis. Served basis. It is expected that after the "vnd." would appear an
abbreviated form of the vendor's name that is registering the option,
followed by a second dot "." and a name for the option itself. For
example, "vnd.example.extinfo" might represent a vendor-specific exten-
sion providing extended information being registered by the "Example,
Inc." company.
11. Security Considerations 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.
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
skipping to change at page 9, line 52 skipping to change at page 13, line 43
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
was achieved is made locally, is implementation-dependant, and is beyond was achieved is made locally, is implementation-dependant, and is beyond
the scope of this document. the scope of this document.
The SMTP client and server should note carefully the result of the The SMTP client and server should note carefully the result of the
TLS negotiation. If the negotiation results in no privacy, or if it TLS negotiation. If the negotiation results in no privacy, or if it
results in privacy using algorithms or key lengths that are deemed not results in privacy using algorithms or key lengths that are deemed not
strong enough, or if the authentication is not good enough for either 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 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 QUIT command, or the server may choose to not accept any more MTQP com-
mands.
commands.
A man-in-the-middle attack can be launched by deleting the A man-in-the-middle attack can be launched by deleting the
"STARTTLS" option response from the server. This would cause the client "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 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 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 TLS during one session and generating an alarm if it does not appear in
an option response for a later session. an option response for a later session.
If TLS is not used, a tracking request is vulnerable to replay 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 attacks, such that a snoop can later replay the same handshake again to
skipping to change at page 11, line 4 skipping to change at page 14, line 43
# 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
opt-text = [WSP *(VCHAR / WSP)] opt-text = [WSP *(VCHAR / WSP)]
error-response = "-ERR" response-info opt-text CRLF error-response = "-ERR" response-info opt-text CRLF
bad-response = "-BAD" response-info opt-text CRLF bad-response = "-BAD" response-info opt-text CRLF
success-response = single-line-success / multi-line-success success-response = single-line-success / multi-line-success
single-line-success = "+OK" response-info opt-text CRLF single-line-success = "+OK" response-info opt-text CRLF
multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf 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 = identifier opt-text *[CRLF WSP opt-text] CRLF option-line = identifier opt-text *[CRLF WSP opt-text] CRLF
identifier = (ALPHA / "_") *(ALPHA / DIGIT / "-" / "_") identifier = (ALPHA / "_") *(ALPHA / DIGIT / "-" / "_")
response-info = *( "/" 1*(ALPHA / DIGIT / "-" / "_")
13. Acknowledgements 13. Acknowledgements
The description of STARTTLS is based on [RFC-SMTP-TLS]. The description of STARTTLS is based on [RFC-SMTP-TLS].
14. References 14. References
[NIST-SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard",
National Institute of Standards and Technology, U.S. Department of Com-
merce, May 1994.
[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. Innosoft, First Virtual, 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
ARPA Internet Text Messages", University of Delaware, August 1982. ARPA Internet Text Messages", University of Delaware, August 1982.
[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", Internet Mail Consortium, Demon
Internet Ltd., 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", MCI, Innosoft, Dover Beach
1994. Consulting, Inc., network Management Associates, Inc., Silicon Graphics,
Inc., July 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", Harvard University, March 1997.
[RFC-MD5] RFC 1321, R. Rivest, MIT Laboratory for Computer Science [RFC-MD5] RFC 1321, R. Rivest, "The MD5 Message-Digest Algorithm",
and RSA Data Security, Inc., "The MD5 Message-Digest Algorithm", April MIT Laboratory for Computer Science and RSA Data Security, Inc., April
1992. 1992.
[RFC-SMTPEXT] RFC 2554, J. Myers, Netscape Communications, "SMTP [RFC-SMTPEXT] RFC 2554, J. Myers, "SMTP Service Extension for
Service Extension for Authentication", March 1999. Authentication", Netscape Communications, March 1999.
[RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for [RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for
Secure SMTP over TLS", Internet Mail Consortium, January 1999. Secure SMTP over TLS", Internet Mail Consortium, January 1999.
[RFC-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-00.txt, E. Allman, T. [RFC-SRV] RFC 2782, A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR
for specifying the location of services (DNS SRV)" Troll Technologies,
Internet Software Consortium, Microsoft Corp., February 2000
[RFC-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T.
Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc., Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc.,
AT&T Laboratories, TBD 2000. AT&T Laboratories, TBD 2000.
[RFC-TRACK-MODEL] draft-ietf-msgtrk-model-03.txt, T. Hansen, "Mes- [RFC-TRACK-MODEL] draft-ietf-msgtrk-model-03.txt, T. Hansen, "Mes-
sage Tracking Models and Requirements", AT&T Laboratories, November sage Tracking Models and Requirements", AT&T Laboratories, November
2000. 2000.
[RFC-TRACK-TSN] draft-ietf-msgtrk-trkstat-00.txt, E. Allman, "The [RFC-TRACK-TSN] draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The
Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2000. Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2000.
[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", August 1998. form Resource Identifiers (URI): Generic Syntax", MIT/LCS, U. C. Irvine,
Xerox Corporation, August 1998.
15. Authors' Addresses 15. Author's Address
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
16. Full Copyright Statement 16. Full Copyright Statement
skipping to change at page 13, line 4 skipping to change at page 17, line 6
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 May 21, 2001. This document expires August 2, 2001.
 End of changes. 49 change blocks. 
68 lines changed or deleted 265 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/