9.3. URI Scheme Syntax
An MTQP URI takes one of the following forms:
mtqp://<mserver>/track/<unique-envid>/<mtrk-secret>
mtqp://<mserver>:<port>/track/<unique-envid>/<mtrk-secret>
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
these forms specify that the TRACK command is to be issued using the
given tracking id (unique-envid) and authorization secret (mtrk-
secret). The path element "/track/" MUST BE treated case
insensitively, but the unique-envid and mtrk-secret MUST NOT be.
9.3.1. Formal Syntax
This is an ABNF description of the MTQP URI.
mtqp-uri = "mtqp://" authority "/track/" unique-envid "/" mtrk-secret
9.4. Encoding Rules
The encoding of unique-envid is discussed in [RFC-MTRK-ESMTP].
Mtrk-secret is required to be base64 encoded. If the "/", "?" and
"%" octets appear in unique-envid or mtrk-secret, they are further
required to be represented by a "%" followed by two hexadecimal
characters. (The two characters give the hexadecimal representation
of that octet).
10. IANA Considerations
System port number 1038 has been assigned to the Message Tracking
Query Protocol by the Internet Assigned Numbers Authority (IANA).
The service name "MTQP" has been registered with the IANA.
The IANA has also registered the URI registration template found in
Appendix A in accordance with [BCP35].
This document requests that IANA maintain one new registry: MTQP
options. The registry’s purpose is to register options to this
protocol. Options whose names do not begin with "vnd." MUST be
defined in a standards track or IESG approved experimental RFC. New
MTQP options MUST include the following information as part of their
definition:
option identifier
option parameters
added commands
standard commands affected
specification reference
discussion
One MTQP option is defined in this document, with the following
registration definition:
option identifier: STARTTLS
option parameters: none
added commands: STARTTLS
standard commands affected: none
specification reference: RFC 3887
discussion: see RFC 3887
Additional vendor-specific options for this protocol have names that
begin with "vnd.". After the "vnd." would appear the reversed domain
name of the vendor, another dot ".", and a name for the option
itself. For example, "vnd.com.example.extinfo" might represent a
vendor-specific extension providing extended information by the owner
of the "example.com" domain. These names MAY be registered with
IANA.
11. Security Considerations
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
unencrypted sessions. The user can decide on a message-by-message
basis if this risk is acceptable.
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 maximum 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 exposure further.
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
confidentiality, they are not securing tracking queries with any
prior or successive MTQP servers.
Both the MTQP client and server must check the result of the TLS
negotiation to see whether acceptable authentication or
confidentiality was achieved. Ignoring this step completely
invalidates using TLS for security. The decision about whether
acceptable authentication or confidentiality was achieved is made
locally, is implementation-dependent, and is beyond the scope of this
document.
The MTQP client and server should note carefully the result of the
TLS negotiation. If the negotiation results in no confidentiality,
or if it results in confidentiality 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 commands.
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.
Similarly, the identity of the server as expressed in the server’s
certificate should be cached, and an alarm generated if they do not
match in a later session.
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.
Before the TLS handshake has begun, any protocol interactions are
performed in the clear and may be modified by an active attacker.
For this reason, clients and servers MUST discard any knowledge
obtained prior to the start of the TLS handshake upon completion of
the TLS handshake.
If a client/server pair successfully performs a TLS handshake and the
server does chaining referrals, then the server SHOULD attempt to
negotiate TLS at the same (or better) security level at the next hop.
In a hop-by-hop scenario, STARTTLS is a request for "best effort"
security and should be treated as such.
SASL is not used because authentication is per message rather than
per user.
12. Protocol Syntax
This is a collected ABNF description of the MTQP protocol.
mtqp-uri = "mtqp://" authority "/track/" unique-envid "/" mtrk-secret
conversation = command-response *(client-command command-response)
; client side
client-command = track-command / starttls-command / quit-command
/comment-command
track-command = "TRACK" 1*WSP unique-envid 1*WSP mtrk-secret CRLF
mtrk-secret = base64
starttls-command = "STARTTLS" 1*WSP domain *WSP CRLF
domain = (sub-domain 1*("." sub-domain))
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
dotcrlf = "." CRLF
NAMECHAR = ALPHA / DIGIT / "-" / "_"
response-info = *( "/" ( "admin" / "unavailable" / "unsupported"
/ "tls-in-progress" / "insecure" / "tls-required" / 1*NAMECHAR ) )
13. Acknowledgements
The description of STARTTLS is based on [RFC-SMTP-TLS].
14. References
14.1. Normative References
[RFC-MIME] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies", RFC 2045, November
1996.
[RFC-ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF
for Syntax Specifications: ABNF", RFC 2234,
November 1997.
[RFC-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS
RR for specifying the location of services (DNS
SRV)", RFC 2782, February 2000.
[RFC-SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC
2821, April 2001.
[RFC-SMTPEXT] Myers, J., "SMTP Service Extension for
Authentication", RFC 2554, March 1999.
[RFC-MTRK-ESMTP] Allman, E. and T. Hansen, "SMTP Service Extension
for Message Tracking", RFC 3885, September 2004.
[RFC-MTRK-MODEL] Hansen, T., "Message Tracking Models and
Requirements", RFC 3885, September 2004.
[RFC-MTRK-TSN] Allman, E., "The Message/Tracking-Status MIME
Extension", RFC 3886, September 2004.
[RFC-URI] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic
Syntax", RFC 2396, August 1998.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
14.2. Informational References
[BCP35] Petke, R. and I. King, "Registration Procedures
for URL Scheme Names", BCP 35, RFC 2717, November
1999.
[RFC-SHA1] Eastlake, D. and P. Jones, "US Secure Hash
Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC-SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure
SMTP over Transport Layer Security", RFC 3207,
February 2002.
[RFC-X509] Housley, R., Polk, W., Ford, W. and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002.
[POP3] Myers, J. and M. Rose, "Post Office Protocol -
Version 3", STD 53, RFC 1939, May 1996.
[NNTP] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.
Appendix A. MTQP URI Registration Template
Scheme name: mtqp
Scheme syntax: see section 9.1
Character encoding considerations: see section 9.4
Intended usage: see section 9.3
Applications and/or protocols which use this scheme: MTQP
Interoperability considerations: as specified for MTQP
Security considerations: see section 11.0
Relevant publications: [RFC-MTRK-ESMTP], [RFC-MTRK-MODEL],
[RFC-MTRK-TSN]
Contact: MSGTRK Working Group
Author/Change Controller: IESG
Author’s Address
Tony Hansen
AT&T Laboratories
Middletown, NJ 07748
USA
Phone: +1.732.420.8934
EMail: tony+msgtrk@maillennium.att.com
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.