7Network Working Group E. Allman
8Request for Comments: 3885 Sendmail, Inc.
10Category: Standards Track AT&T Laboratories
14 SMTP Service Extension
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
27 Copyright (C) The Internet Society (2004).
31 This memo defines an extension to the SMTP service whereby a client
32 may mark a message for future tracking.
341. Other Documents and Conformance
36 The model used for Message Tracking is described in [RFC-MTRK-MODEL].
38 Doing a Message Tracking query is intended as a "last resort"
39 mechanism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN-
40 SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would
41 provide the primary delivery status. Only if the message is not
42 received, or there is no response from either of these mechanisms
43 should a Message Tracking query be issued.
45 The definition of the base64 token is imported from section 6.8 of
48 base64 = %x2b / %x2f / %x30-39 / %x41-5a / %x61-7a
58Allman & Hansen Standards Track [Page 1]
60RFC 3885 Message Tracking ESMTP Extension September 2004
63 The definition of the DIGIT token is imported from [RFC-MSGFMT].
68 Syntax notation in this document conforms to [RFC-ABNF].
70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
72 document are to be interpreted as described in BCP 14, RFC 2119
752. SMTP Extension Overview
77 The Message Tracking SMTP service extension uses the SMTP service
78 extension mechanism described in [RFC-ESMTP]. The following service
79 extension is hereby defined:
81 (1) The name of the SMTP service extension is "Message Tracking".
83 (2) The EHLO keyword value associated with this extension is
86 (3) No parameters are allowed with this EHLO keyword value. Future
87 documents may extend this specification by specifying
88 parameters to this keyword value.
90 (4) One optional parameter using the keyword "MTRK" is added to the
91 MAIL command. In addition, the ENVID parameter of the MAIL
92 command (as defined in RFC 3461) MUST be supported, with
93 extensions as described below. The ORCPT parameter of the RCPT
94 command (as defined in RFC 3461) MUST also be supported. All
95 semantics associated with ENVID and ORCPT described in RFC 3461
96 MUST be supported as part of this extension.
98 (5) The maximum length of a MAIL command line is increased by 40
99 characters by the possible addition of the MTRK keyword and
100 value. Note that the 507 character extension of RCPT commands
101 for the ORCPT parameter and the 107 character extension of MAIL
102 commands for the ENVID parameter as mandated by RFC 3461 [RFC-
103 DSN-SMTP] must also be included.
105 (6) No SMTP verbs are defined by this extension.
114Allman & Hansen Standards Track [Page 2]
116RFC 3885 Message Tracking ESMTP Extension September 2004
1193. The Extended MAIL Command
121 The extended MAIL command is issued by an SMTP client when it wishes
122 to inform an SMTP server that message tracking information should be
123 retained for future querying. The extended MAIL command is identical
124 to the MAIL command as defined in [RFC-SMTP], except that MTRK,
125 ORCPT, and ENVID parameters appear after the address.
1273.1. The MTRK parameter to the ESMTP MAIL command
129 Any sender wishing to request the retention of data for further
130 tracking of message must first tag that message as trackable by
131 creating two values A and B:
133 A = some-large-random-number
136 The large random number A is calculated on a host-dependent basis.
137 See [RFC-RANDOM] for a discussion of choosing good random numbers.
138 This random number MUST be at least 128 bits but MUST NOT be more
141 The 128-bit hash B of A is then computed using the SHA-1 algorithm as
142 described in [NIST-SHA1].
144 The sender then base64 encodes value B and passes that value as the
145 mtrk-certifier on the MAIL command:
147 mtrk-parameter = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ]
148 mtrk-certifier = base64 ; authenticator
149 mtrk-timeout = 1*9DIGIT ; seconds until timeout
151 A is stored in the originator's tracking database to validate future
152 tracking requests as described in [RFC-MTRK-MTQP]. B is stored in
153 tracking databases of compliant receiver MTAs and used to
154 authenticate future tracking requests.
156 The mtrk-timeout field indicates the number of seconds that the
157 client requests that this tracking information be retained on
158 intermediate servers, as measured from the initial receipt of the
159 message at that server. Servers MAY ignore this value if it violates
160 local policy. In particular, servers MAY silently enforce an upper
161 limit to how long they will retain tracking data; this limit MUST be
164 If no mtrk-timeout field is specified then the server should use a
165 local default. This default SHOULD be 8-10 days and MUST be at least
166 one day. Notwithstanding this clause, the information MUST NOT be
170Allman & Hansen Standards Track [Page 3]
172RFC 3885 Message Tracking ESMTP Extension September 2004
175 expired while the message remains in the queue for this server: that
176 is, an MTQP server MUST NOT deny knowledge of a message while that
177 same message sits in the MTA queue.
179 If the message is relayed to another compliant SMTP server, the MTA
180 acting as the client SHOULD pass an mtrk-timeout field equal to the
181 remaining life of that message tracking information. Specifically,
182 the tracking timeout is decremented by the number of seconds the
183 message has lingered at this MTA and then passed to the next MTA. If
184 the decremented tracking timeout is less than or equal to zero, the
185 entire MTRK parameter MUST NOT be passed to the next MTA;
186 essentially, the entire tracking path is considered to be lost at
189 See [RFC-DELIVERYBY] section 4 for an explanation of why a timeout is
190 used instead of an absolute time.
194 To function properly, Message Tracking requires that each message
195 have a unique identifier that is never reused by any other message.
196 For that purpose, if the MTRK parameter is given, an ENVID parameter
197 MUST be included, and the syntax of ENVID from RFC 3461 is extended
200 envid-parameter = "ENVID=" unique-envid
201 unique-envid = local-envid "@" fqhn
205 The unique-envid MUST be chosen in such a way that the same ENVID
206 will never be used by any other message sent from this system or any
207 other system. In most cases, this means setting fqhn to be the fully
208 qualified host name of the system generating this ENVID, and local-
209 envid to an identifier that is never re-used by that host.
211 In some cases, the total length of (local-envid + fqhn + 1) (for the
212 `@' sign) may exceed the total acceptable length of ENVID (100). In
213 this case, the fqhn SHOULD be replaced by the SHA1(fqhn) encoded into
214 BASE64. After encoding, the 160 bit SHA-1 will be a 27 octet string,
215 which limits local-envid to 72 octets. Implementors are encouraged
216 to use an algorithm for the local-envid that is reasonably unique.
217 For example, sequential integers have a high probability of
218 intersecting with sequential integers generated by a different host,
219 but a SHA-1 of the current time of day concatenated with the host's
220 IP address and a random number are unlikely to intersect with the
221 same algorithm generated by a different host.
226Allman & Hansen Standards Track [Page 4]
228RFC 3885 Message Tracking ESMTP Extension September 2004
231 Any resubmissions of this message into the message transmission
232 system MUST assign a new ENVID. In this context, "resubmission"
233 includes forwarding or resending a message from a user agent, but
234 does not include MTA-level aliasing or forwarding where the message
235 does not leave and re-enter the message transmission system.
2373.3. Forwarding Tracking Certifiers
239 MTAs SHOULD forward unexpired tracking certifiers to compliant
240 mailers as the mail is transferred during regular hop-to-hop
241 transfers. If the "downstream" MTA is not MTRK-compliant, then the
242 MTRK= parameter MUST be deleted. If the downstream MTA is DSN-
243 compliant, then the ENVID and ORCPT parameters MUST NOT be deleted.
245 If aliasing, forwarding, or other redirection of a recipient occurs,
246 and the result of the redirection is exactly one recipient, then the
247 MTA SHOULD treat this as an ordinary hop-to-hop transfer and forward
248 the MTRK=, ENVID=, and ORCPT= values; these values MUST NOT be
249 modified except for decrementing the mtrk-timeout field of the MTRK=
250 value, which MUST be modified as described in section 4.1 above.
252 MTAs MUST NOT copy MTRK certifiers when a recipient is aliased,
253 forwarded, or otherwise redirected and the redirection results in
254 more than one recipient. However, an MTA MAY designate one of the
255 multiple recipients as the "primary" recipient to which tracking
256 requests shall be forwarded; other addresses MUST NOT receive
257 tracking certifiers. MTAs MUST NOT forward MTRK certifiers when
258 doing mailing list expansion.
2604. Security Considerations
2624.1. Denial of service
264 An attacker could attempt to flood the database of a server by
265 submitting large numbers of small, tracked messages. In this case, a
266 site may elect to lower its maximum retention period retroactively.
270 The mtrk-authenticator value ("A") must be hard to predict and not
273 The originating client must take reasonable precautions to protect
274 the secret. For example, if the secret is stored in a message store
275 (e.g., a "Sent" folder), the client must make sure the secret isn't
276 accessible by attackers, particularly on a shared store.
282Allman & Hansen Standards Track [Page 5]
284RFC 3885 Message Tracking ESMTP Extension September 2004
287 Many site administrators believe that concealing names and topologies
288 of internal systems and networks is an important security feature.
289 MTAs need to balance such desires with the need to provide adequate
290 tracking information.
292 In some cases site administrators may want to treat delivery to an
293 alias as final delivery in order to separate roles from individuals.
294 For example, sites implementing "postmaster" or "webmaster" as
295 aliases may not wish to expose the identity of those individuals by
296 permitting tracking through those aliases. In other cases, providing
297 the tracking information for an alias is important, such as when the
298 alias points to the user's preferred public address.
300 Therefore, implementors are encouraged to provide mechanisms by which
301 site administrators can choose between these alternatives.
3035. IANA Considerations
305 IANA has registered the SMTP extension defined in section 3.
309 Several individuals have commented on and enhanced this document,
310 including Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris
311 Newman, and Gregory Neil Shapiro.
3157.1. Normative References
317 [RFC-MTRK-MODEL] Hansen, T., "Message Tracking Model and
318 Requirements", RFC 3888, September 2004.
320 [RFC-MTRK-MTQP] Hansen, T., "Message Tracking Query Protocol", RFC
321 3887, September 2004.
323 [RFC-ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF
324 for Syntax Specifications: ABNF", RFC 2234,
327 [RFC-ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E.,
328 and D. Crocker, "SMTP Service Extensions", STD 10,
329 RFC 1869, November 1995.
331 [RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to
332 Indicate Requirement Levels", BCP 14, RFC 2119,
338Allman & Hansen Standards Track [Page 6]
340RFC 3885 Message Tracking ESMTP Extension September 2004
343 [RFC-MIME] Freed, N. and N. Borenstein, "Multipurpose
344 Internet Mail Extensions (MIME) Part One: Format
345 of Internet Message Bodies", RFC 2045, November
348 [NIST-SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard"
349 National Institute of Standards and Technology,
350 U.S. Department of Commerce, May 1994.
352 [RFC-SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol",
353 RFC 2821, April 2001.
355 [RFC-MSGFMT] Resnick, P., Ed., "Internet Message Format", RFC
3587.2. Informational References
360 [RFC-DELIVERYBY] Newman, D., "Deliver By SMTP Service Extension",
363 [RFC-DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP)
364 Service Extension for Delivery Status
365 Notifications (DSNs)", RFC 3461, January 2003.
367 [RFC-MDN] Hansen, T. and G. Vaudreuil, Eds., "Message
368 Disposition Notification", RFC 3798, May 2004.
370 [RFC-RANDOM] Eastlake, D., Crocker, S., and J. Schiller,
371 "Randomness Recommendations for Security", RFC
394Allman & Hansen Standards Track [Page 7]
396RFC 3885 Message Tracking ESMTP Extension September 2004
403 6425 Christie Ave, 4th Floor
407 Phone: +1 510 594 5501
409 EMail: eric@Sendmail.COM
417 Phone: +1 732 420 8934
418 EMail: tony+msgtrk@maillennium.att.com
450Allman & Hansen Standards Track [Page 8]
452RFC 3885 Message Tracking ESMTP Extension September 2004
4559. Full Copyright Statement
457 Copyright (C) The Internet Society (2004). This document is subject
458 to the rights, licenses and restrictions contained in BCP 78, and
459 except as set forth therein, the authors retain all their rights.
461 This document and the information contained herein are provided on an
462 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
463 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
464 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
465 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
466 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
467 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
471 The IETF takes no position regarding the validity or scope of any
472 Intellectual Property Rights or other rights that might be claimed to
473 pertain to the implementation or use of the technology described in
474 this document or the extent to which any license under such rights
475 might or might not be available; nor does it represent that it has
476 made any independent effort to identify any such rights. Information
477 on the procedures with respect to rights in RFC documents can be
478 found in BCP 78 and BCP 79.
480 Copies of IPR disclosures made to the IETF Secretariat and any
481 assurances of licenses to be made available, or the result of an
482 attempt made to obtain a general license or permission for the use of
483 such proprietary rights by implementers or users of this
484 specification can be obtained from the IETF on-line IPR repository at
485 http://www.ietf.org/ipr.
487 The IETF invites any interested party to bring to its attention any
488 copyrights, patents or patent applications, or other proprietary
489 rights that may cover technology that may be required to implement
490 this standard. Please address the information to the IETF at ietf-
495 Funding for the RFC Editor function is currently provided by the
506Allman & Hansen Standards Track [Page 9]