RFC 3885

RFC 3885: SMTP Service Extension for Message Tracking 🎀✨

Okay bestie, here's the deets 💅 This one is written by E. Allman (Sendmail, Inc.) and T. Hansen (AT&T Laboratories). It's a Standards Track document from September 2004, and it updates RFC 3461 🦋 The header doesn't list anything it obsoletes.

Status of This Memo 📝

This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements 💖 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸

Copyright Notice 🌈

Copyright (C) The Internet Society (2004). ⭐

Abstract 🧚

This memo adds an extension to the SMTP service that lets a client mark a message for future tracking 🔥

1. Other Documents and Conformance 💜

The model behind Message Tracking lives in [RFC-MTRK-MODEL] ✨

Okay so, a Message Tracking query is meant to be a "last resort" 🙈 Normally, Delivery Status Notifications (DSNs) [RFC-DSN-SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] are the ones giving you the main delivery status. Only if the message never arrives, or neither of those mechanisms gives you a response, should you send a Message Tracking query 💅

The base64 token is borrowed from section 6.8 of [RFC-MIME]. Formally:

base64 =  %x2b / %x2f / %x30-39 / %x41-5a / %x61-7a

The DIGIT token is borrowed from [RFC-MSGFMT]. Formally:

DIGIT =        %x30-39

The syntax notation here follows [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 read as described in BCP 14, RFC 2119 [RFC-KEYWORDS] 🔥

2. SMTP Extension Overview 🎀

The Message Tracking SMTP service extension uses the SMTP extension mechanism from [RFC-ESMTP] 💖 Here's what this extension defines:

(1) The name of the SMTP service extension is "Message Tracking" ✨

(2) The EHLO keyword value for this extension is "MTRK" 🌸

(3) No parameters are allowed with this EHLO keyword value. Future documents may extend this spec by adding parameters to this keyword value 🧚

(4) One optional parameter using the keyword "MTRK" gets added to the MAIL command. On top of that, the ENVID parameter of the MAIL command (as defined in RFC 3461) MUST be supported, with the extensions described below. The ORCPT parameter of the RCPT command (as defined in RFC 3461) MUST also be supported. Every ENVID and ORCPT semantic described in RFC 3461 MUST be supported as part of this extension 👑

(5) The maximum length of a MAIL command line goes up by 40 characters, because the MTRK keyword and value might get added. Also 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 required by RFC 3461 [RFC-DSN-SMTP], must also be included 💀

(6) This extension defines no SMTP verbs 🍓

3. The Extended MAIL Command 💜

The extended MAIL command is sent by an SMTP client when it wants an SMTP server to keep message tracking information around for future querying. It's identical to the MAIL command defined in [RFC-SMTP], except that the MTRK, ORCPT, and ENVID parameters show up after the address 🦋

3.1. The MTRK parameter to the ESMTP MAIL command 🔥

Any sender who wants tracking data retained has to tag the message as trackable first, by creating two values, A and B:

A = some-large-random-number
B = SHA1(A)

The big random number A gets calculated on a host-dependent basis. For a discussion of picking good random numbers, see [RFC-RANDOM] 🧚 This random number MUST be at least 128 bits, but MUST NOT be more than 1024 bits 🙈

Next, B is the 128-bit hash of A, computed with the SHA-1 algorithm described in [NIST-SHA1] ✨

The sender base64 encodes 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 gets stored in the originator's tracking database so it can validate future tracking requests, as described in [RFC-MTRK-MTQP] 🫶 B gets stored in the tracking databases of compliant receiver MTAs and is used to authenticate future tracking requests 💖

The mtrk-timeout field says how many seconds the client wants this tracking info kept on intermediate servers. The clock starts when that server first receives the message 👑 Servers MAY ignore this value if it breaks local policy. Servers MAY also quietly enforce an upper limit on how long they keep tracking data, but that limit MUST be at least one day 💅

If there's no mtrk-timeout field, the server should use a local default. That default SHOULD be 8-10 days and MUST be at least one day ✨ Even so, the info MUST NOT expire while the message is still sitting in the queue for this server. In other words, an MTQP server MUST NOT deny knowing about a message while that same message is in the MTA queue 🔥

If the message gets relayed to another compliant SMTP server, the MTA acting as the client SHOULD pass along an mtrk-timeout equal to the remaining life of the tracking info 🦋 The tracking timeout gets decremented by the number of seconds the message lingered at this MTA, and then it's passed to the next MTA. If the decremented tracking timeout is less than or equal to zero, the whole MTRK parameter MUST NOT be passed to the next MTA. Basically, the tracking path is considered lost at that point 💀

For why a timeout gets used instead of an absolute time, see section 4 of [RFC-DELIVERYBY] 🧚

3.2. Use of ENVID 🌸

Message Tracking needs every message to have a unique identifier that is never reused by any other message, or it just doesn't work properly 😭 So if the MTRK parameter is given, an ENVID parameter MUST be included, and the ENVID syntax from RFC 3461 gets extended like this:

envid-parameter = "ENVID=" unique-envid
unique-envid    = local-envid "@" fqhn
local-envid     = xtext
fqhn            = xtext

The unique-envid MUST be picked so the same ENVID is never used by any other message sent from this system or any other system 🔥 In most cases, that means fqhn is the fully qualified host name of the system making the ENVID, and local-envid is an identifier that host never reuses 🍓

Sometimes the total length of (local-envid + fqhn + 1) (for the @ sign) is more than the acceptable ENVID length (100) 😭 When that happens, the fqhn SHOULD be replaced by SHA1(fqhn) encoded into BASE64. After encoding, the 160 bit SHA-1 is a 27 octet string, which leaves room for only 72 octets of local-envid 🦋 Implementors are encouraged to use a reasonably unique algorithm for local-envid. Like, sequential integers have a high chance of colliding with sequential integers from a different host. But a SHA-1 of the time of day concatenated with the host's IP address and a random number is unlikely to collide with the same algorithm running on a different host 🧚

Any resubmission of this message into the message transmission system MUST get a new ENVID. Here, "resubmission" includes forwarding or resending a message from a user agent. It does not include MTA-level aliasing or forwarding where the message never leaves and re-enters the message transmission system 💅

3.3. Forwarding Tracking Certifiers 💜

MTAs SHOULD forward unexpired tracking certifiers to compliant mailers while the mail is transferred during regular hop-to-hop transfers 🌈 If the "downstream" MTA isn't MTRK-compliant, the MTRK= parameter MUST be deleted. If the downstream MTA is DSN-compliant, the ENVID and ORCPT parameters MUST NOT be deleted 🎀

If aliasing, forwarding, or some other redirection of a recipient happens, and the redirection ends up with exactly one recipient, then the MTA SHOULD treat it as an ordinary hop-to-hop transfer and forward the MTRK=, ENVID=, and ORCPT= values. Those values MUST NOT be modified, except that the mtrk-timeout field of the MTRK= value gets decremented, and that MUST be done as described in section 4.1 above 🔥

MTAs MUST NOT copy MTRK certifiers when a recipient gets aliased, forwarded, or otherwise redirected and the redirection results in more than one recipient. However, an MTA MAY pick one of the multiple recipients as the "primary" recipient that tracking requests get forwarded to. The other addresses MUST NOT receive tracking certifiers 🦋 And MTAs MUST NOT forward MTRK certifiers when doing mailing list expansion 🙈

4. Security Considerations 🚨

This section is seriously important, so pay attention 😭

4.1. Denial of service 💀

An attacker could try to flood a server's database by submitting huge numbers of small, tracked messages 😱 To handle that, a site may choose to lower its maximum retention period retroactively 🛡️

4.2. Confidentiality 🔒

The mtrk-authenticator value ("A") needs to be hard to predict and never reused 🔐

The originating client has to take reasonable precautions to protect the secret. For example, if the secret is stored in a message store (like a "Sent" folder), the client must make sure attackers can't access it, especially on a shared store 🫣

Lots of site administrators believe that hiding the names and topologies of internal systems and networks is an important security feature 🙈 MTAs have to balance that wish against the need to provide adequate tracking information ⚖️

Sometimes site administrators want to treat delivery to an alias as final delivery, so they can separate roles from individuals. For example, sites that set up "postmaster" or "webmaster" as aliases may not want to expose the identity of those people by allowing tracking through those aliases 🧑‍💻 In other cases, giving tracking info for an alias really matters, like when the alias points to the user's preferred public address 💖

So implementors are encouraged to provide mechanisms that let site administrators choose between these alternatives 👑

5. IANA Considerations 🌸

IANA has registered the SMTP extension defined in section 3 ✨

6. Acknowledgements 🫶

Several individuals commented on and improved this document, including Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris Newman, and Gregory Neil Shapiro 💜

7. References 📚

7.1. Normative References ✨

Okay bestie, these are the docs the spec literally can't work without 📚💖 Read these first, no skipping!

• [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.
• [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 🦋

These ones are extra-credit reading, lowkey fascinating but not required to get the spec working 🌸

• [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.

8. Authors' Addresses 💌

Meet the girlies who wrote this thing 🫶

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

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. So the authors keep their rights, and the rest of the usual legal stuff applies 📜✨

Now the serious bit, bestie, read it carefully 💅

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 on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or how far they reach 🧐 It also doesn't say whether any license under those rights might be available, and it hasn't independently gone hunting for such rights either.

If you want the details on how rights work for RFC documents, check out BCP 78 and BCP 79 📖 Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that are going to be available, and the results of attempts to get a general license or permission for implementers or users are all posted on the IETF online IPR repository at http://www.ietf.org/ipr 🌈

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🙏

Funding for the RFC Editor function is currently provided by the Internet Society 💖