From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3885.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc3885.txt (limited to 'doc/rfc/rfc3885.txt') 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] + -- cgit v1.2.3