summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3885.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3885.txt')
-rw-r--r--doc/rfc/rfc3885.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc3885.txt b/doc/rfc/rfc3885.txt
new file mode 100644
index 0000000..bde55ae
--- /dev/null
+++ b/doc/rfc/rfc3885.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group E. Allman
+Request for Comments: 3885 Sendmail, Inc.
+Updates: 3461 T. Hansen
+Category: Standards Track AT&T Laboratories
+ September 2004
+
+
+ SMTP Service Extension
+ for Message Tracking
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This memo defines an extension to the SMTP service whereby a client
+ may mark a message for future tracking.
+
+1. Other Documents and Conformance
+
+ The model used for Message Tracking is described in [RFC-MTRK-MODEL].
+
+ Doing a Message Tracking query is intended as a "last resort"
+ mechanism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN-
+ SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would
+ provide the primary delivery status. Only if the message is not
+ received, or there is no response from either of these mechanisms
+ should a Message Tracking query be issued.
+
+ The definition of the base64 token is imported from section 6.8 of
+ [RFC-MIME]. Formally,
+
+ base64 = %x2b / %x2f / %x30-39 / %x41-5a / %x61-7a
+
+
+
+
+
+
+
+
+
+Allman & Hansen Standards Track [Page 1]
+
+RFC 3885 Message Tracking ESMTP Extension September 2004
+
+
+ The definition of the DIGIT token is imported from [RFC-MSGFMT].
+ Formally,
+
+ DIGIT = %x30-39
+
+ Syntax notation in this document conforms to [RFC-ABNF].
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC-KEYWORDS].
+
+2. SMTP Extension Overview
+
+ The Message Tracking SMTP service extension uses the SMTP service
+ extension mechanism described in [RFC-ESMTP]. The following service
+ extension is hereby defined:
+
+ (1) The name of the SMTP service extension is "Message Tracking".
+
+ (2) The EHLO keyword value associated with this extension is
+ "MTRK".
+
+ (3) No parameters are allowed with this EHLO keyword value. Future
+ documents may extend this specification by specifying
+ parameters to this keyword value.
+
+ (4) One optional parameter using the keyword "MTRK" is added to the
+ MAIL command. In addition, the ENVID parameter of the MAIL
+ command (as defined in RFC 3461) MUST be supported, with
+ extensions as described below. The ORCPT parameter of the RCPT
+ command (as defined in RFC 3461) MUST also be supported. All
+ semantics associated with ENVID and ORCPT described in RFC 3461
+ MUST be supported as part of this extension.
+
+ (5) The maximum length of a MAIL command line is increased by 40
+ characters by the possible addition of the MTRK keyword and
+ value. Note that the 507 character extension of RCPT commands
+ for the ORCPT parameter and the 107 character extension of MAIL
+ commands for the ENVID parameter as mandated by RFC 3461 [RFC-
+ DSN-SMTP] must also be included.
+
+ (6) No SMTP verbs are defined by this extension.
+
+
+
+
+
+
+
+
+Allman & Hansen Standards Track [Page 2]
+
+RFC 3885 Message Tracking ESMTP Extension September 2004
+
+
+3. The Extended MAIL Command
+
+ The extended MAIL command is issued by an SMTP client when it wishes
+ to inform an SMTP server that message tracking information should be
+ retained for future querying. The extended MAIL command is identical
+ to the MAIL command as defined in [RFC-SMTP], except that MTRK,
+ ORCPT, and ENVID parameters appear after the address.
+
+3.1. The MTRK parameter to the ESMTP MAIL command
+
+ Any sender wishing to request the retention of data for further
+ tracking of message must first tag that message as trackable by
+ creating two values A and B:
+
+ A = some-large-random-number
+ B = SHA1(A)
+
+ The large random number A is calculated on a host-dependent basis.
+ See [RFC-RANDOM] for a discussion of choosing good random numbers.
+ This random number MUST be at least 128 bits but MUST NOT be more
+ than 1024 bits.
+
+ The 128-bit hash B of A is then computed using the SHA-1 algorithm as
+ described in [NIST-SHA1].
+
+ The sender then base64 encodes value B and passes that value as the
+ mtrk-certifier on the MAIL command:
+
+ mtrk-parameter = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ]
+ mtrk-certifier = base64 ; authenticator
+ mtrk-timeout = 1*9DIGIT ; seconds until timeout
+
+ A is stored in the originator's tracking database to validate future
+ tracking requests as described in [RFC-MTRK-MTQP]. B is stored in
+ tracking databases of compliant receiver MTAs and used to
+ authenticate future tracking requests.
+
+ The mtrk-timeout field indicates the number of seconds that the
+ client requests that this tracking information be retained on
+ intermediate servers, as measured from the initial receipt of the
+ message at that server. Servers MAY ignore this value if it violates
+ local policy. In particular, servers MAY silently enforce an upper
+ limit to how long they will retain tracking data; this limit MUST be
+ at least one day.
+
+ If no mtrk-timeout field is specified then the server should use a
+ local default. This default SHOULD be 8-10 days and MUST be at least
+ one day. Notwithstanding this clause, the information MUST NOT be
+
+
+
+Allman & Hansen Standards Track [Page 3]
+
+RFC 3885 Message Tracking ESMTP Extension September 2004
+
+
+ expired while the message remains in the queue for this server: that
+ is, an MTQP server MUST NOT deny knowledge of a message while that
+ same message sits in the MTA queue.
+
+ If the message is relayed to another compliant SMTP server, the MTA
+ acting as the client SHOULD pass an mtrk-timeout field equal to the
+ remaining life of that message tracking information. Specifically,
+ the tracking timeout is decremented by the number of seconds the
+ message has lingered at this MTA and then passed to the next MTA. If
+ the decremented tracking timeout is less than or equal to zero, the
+ entire MTRK parameter MUST NOT be passed to the next MTA;
+ essentially, the entire tracking path is considered to be lost at
+ that point.
+
+ See [RFC-DELIVERYBY] section 4 for an explanation of why a timeout is
+ used instead of an absolute time.
+
+3.2. Use of ENVID
+
+ To function properly, Message Tracking requires that each message
+ have a unique identifier that is never reused by any other message.
+ For that purpose, if the MTRK parameter is given, an ENVID parameter
+ MUST be included, and the syntax of ENVID from RFC 3461 is extended
+ as follows:
+
+ envid-parameter = "ENVID=" unique-envid
+ unique-envid = local-envid "@" fqhn
+ local-envid = xtext
+ fqhn = xtext
+
+ The unique-envid MUST be chosen in such a way that the same ENVID
+ will never be used by any other message sent from this system or any
+ other system. In most cases, this means setting fqhn to be the fully
+ qualified host name of the system generating this ENVID, and local-
+ envid to an identifier that is never re-used by that host.
+
+ In some cases, the total length of (local-envid + fqhn + 1) (for the
+ `@' sign) may exceed the total acceptable length of ENVID (100). In
+ this case, the fqhn SHOULD be replaced by the SHA1(fqhn) encoded into
+ BASE64. After encoding, the 160 bit SHA-1 will be a 27 octet string,
+ which limits local-envid to 72 octets. Implementors are encouraged
+ to use an algorithm for the local-envid that is reasonably unique.
+ For example, sequential integers have a high probability of
+ intersecting with sequential integers generated by a different host,
+ but a SHA-1 of the current time of day concatenated with the host's
+ IP address and a random number are unlikely to intersect with the
+ same algorithm generated by a different host.
+
+
+
+
+Allman & Hansen Standards Track [Page 4]
+
+RFC 3885 Message Tracking ESMTP Extension September 2004
+
+
+ Any resubmissions of this message into the message transmission
+ system MUST assign a new ENVID. In this context, "resubmission"
+ includes forwarding or resending a message from a user agent, but
+ does not include MTA-level aliasing or forwarding where the message
+ does not leave and re-enter the message transmission system.
+
+3.3. Forwarding Tracking Certifiers
+
+ MTAs SHOULD forward unexpired tracking certifiers to compliant
+ mailers as the mail is transferred during regular hop-to-hop
+ transfers. If the "downstream" MTA is not MTRK-compliant, then the
+ MTRK= parameter MUST be deleted. If the downstream MTA is DSN-
+ compliant, then the ENVID and ORCPT parameters MUST NOT be deleted.
+
+ If aliasing, forwarding, or other redirection of a recipient occurs,
+ and the result of the redirection is exactly one recipient, then the
+ MTA SHOULD treat this as an ordinary hop-to-hop transfer and forward
+ the MTRK=, ENVID=, and ORCPT= values; these values MUST NOT be
+ modified except for decrementing the mtrk-timeout field of the MTRK=
+ value, which MUST be modified as described in section 4.1 above.
+
+ MTAs MUST NOT copy MTRK certifiers when a recipient is aliased,
+ forwarded, or otherwise redirected and the redirection results in
+ more than one recipient. However, an MTA MAY designate one of the
+ multiple recipients as the "primary" recipient to which tracking
+ requests shall be forwarded; other addresses MUST NOT receive
+ tracking certifiers. MTAs MUST NOT forward MTRK certifiers when
+ doing mailing list expansion.
+
+4. Security Considerations
+
+4.1. Denial of service
+
+ An attacker could attempt to flood the database of a server by
+ submitting large numbers of small, tracked messages. In this case, a
+ site may elect to lower its maximum retention period retroactively.
+
+4.2. Confidentiality
+
+ The mtrk-authenticator value ("A") must be hard to predict and not
+ reused.
+
+ The originating client must take reasonable precautions to protect
+ the secret. For example, if the secret is stored in a message store
+ (e.g., a "Sent" folder), the client must make sure the secret isn't
+ accessible by attackers, particularly on a shared store.
+
+
+
+
+
+Allman & Hansen Standards Track [Page 5]
+
+RFC 3885 Message Tracking ESMTP Extension September 2004
+
+
+ Many site administrators believe that concealing names and topologies
+ of internal systems and networks is an important security feature.
+ MTAs need to balance such desires with the need to provide adequate
+ tracking information.
+
+ In some cases site administrators may want to treat delivery to an
+ alias as final delivery in order to separate roles from individuals.
+ For example, sites implementing "postmaster" or "webmaster" as
+ aliases may not wish to expose the identity of those individuals by
+ permitting tracking through those aliases. In other cases, providing
+ the tracking information for an alias is important, such as when the
+ alias points to the user's preferred public address.
+
+ Therefore, implementors are encouraged to provide mechanisms by which
+ site administrators can choose between these alternatives.
+
+5. IANA Considerations
+
+ IANA has registered the SMTP extension defined in section 3.
+
+6. Acknowledgements
+
+ Several individuals have commented on and enhanced this document,
+ including Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris
+ Newman, and Gregory Neil Shapiro.
+
+7. References
+
+7.1. Normative References
+
+ [RFC-MTRK-MODEL] Hansen, T., "Message Tracking Model and
+ Requirements", RFC 3888, September 2004.
+
+ [RFC-MTRK-MTQP] Hansen, T., "Message Tracking Query Protocol", RFC
+ 3887, September 2004.
+
+ [RFC-ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF
+ for Syntax Specifications: ABNF", RFC 2234,
+ November 1997.
+
+ [RFC-ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E.,
+ and D. Crocker, "SMTP Service Extensions", STD 10,
+ RFC 1869, November 1995.
+
+ [RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to
+ Indicate Requirement Levels", BCP 14, RFC 2119,
+ March 1997.
+
+
+
+
+Allman & Hansen Standards Track [Page 6]
+
+RFC 3885 Message Tracking ESMTP Extension September 2004
+
+
+ [RFC-MIME] Freed, N. and N. Borenstein, "Multipurpose
+ Internet Mail Extensions (MIME) Part One: Format
+ of Internet Message Bodies", RFC 2045, November
+ 1996.
+
+ [NIST-SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard"
+ National Institute of Standards and Technology,
+ U.S. Department of Commerce, May 1994.
+
+ [RFC-SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol",
+ RFC 2821, April 2001.
+
+ [RFC-MSGFMT] Resnick, P., Ed., "Internet Message Format", RFC
+ 2822, April 2001.
+
+7.2. Informational References
+
+ [RFC-DELIVERYBY] Newman, D., "Deliver By SMTP Service Extension",
+ RFC 2852, June 2000.
+
+ [RFC-DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP)
+ Service Extension for Delivery Status
+ Notifications (DSNs)", RFC 3461, January 2003.
+
+ [RFC-MDN] Hansen, T. and G. Vaudreuil, Eds., "Message
+ Disposition Notification", RFC 3798, May 2004.
+
+ [RFC-RANDOM] Eastlake, D., Crocker, S., and J. Schiller,
+ "Randomness Recommendations for Security", RFC
+ 1750, December 1994.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman & Hansen Standards Track [Page 7]
+
+RFC 3885 Message Tracking ESMTP Extension September 2004
+
+
+8. Authors' Addresses
+
+ Eric Allman
+ Sendmail, Inc.
+ 6425 Christie Ave, 4th Floor
+ Emeryville, CA 94608
+ U.S.A.
+
+ Phone: +1 510 594 5501
+ Fax: +1 510 594 5429
+ EMail: eric@Sendmail.COM
+
+
+ Tony Hansen
+ AT&T Laboratories
+ Middletown, NJ 07748
+ U.S.A.
+
+ Phone: +1 732 420 8934
+ EMail: tony+msgtrk@maillennium.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman & Hansen Standards Track [Page 8]
+
+RFC 3885 Message Tracking ESMTP Extension September 2004
+
+
+9. 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/SHE 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 procedures with respect to rights in RFC 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.
+
+
+
+
+
+
+
+
+
+Allman & Hansen Standards Track [Page 9]
+