RFC 4865

SMTP Submission Service Extension for Future Message Release

📅 published May 2007, from ietf

RFC 4865: SMTP Submission Service Extension for Future Message Release 💌

Okay so this one is bestie-level important 🎀. It's a Standards Track doc from May 2007 by G. White (Independent) and G. Vaudreuil (Alcatel-Lucent). It updates RFC 3463 and RFC 3464, and it doesn't obsolete anything. Let's get into it 💅

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and requests 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 (C) The IETF Trust (2007).

Abstract 🦋

This memo adds an extension to the SMTP submission protocol that lets a client say when a message should be released for delivery, in the future. The extension lets a client park a message in server-based storage until a set time comes around. It's super useful for clients with no local storage, or for clients that just can't release a message on schedule themselves 🧚

1. Introduction 💖

Okay so the voice messaging world has been doing scheduled sends forever. Think announcements that play right when the workday starts, birthday wishes you send a day early, or a cute little personal reminder service 🎂

This extension uses the SMTP submission protocol [n3] so a client can say, while submitting a message, when that message should be released for delivery. It's giving scheduled send, but for email 📬

2. Terminology 🎀

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 [n1].

3. Framework 🌈

The Future Message Release service extension for SMTP submission rides on the SMTP service extension mechanism [n4] to extend the SMTP submission protocol [n3]. Here's the extension we're defining:

The name of the SMTP submission service extension is "Future Message Release".

  1. The Extended Hello (EHLO) keyword for this service extension is FUTURERELEASE.
  2. Two required parameters, the max-future-release-interval and the max-future-release-date-time, get combined with the EHLO keyword the way [n4] describes 💅

The max-future-release-interval is a positive integer. It's the longest amount of time the message submission server (MSA) will hold messages for future release.

Using ABNF [n2], the syntax of this parameter is:

      future-release-integer = %x31-39 *8DIGIT
                               ; integer in the range 1-999999999
                               ; measured in seconds

      max-future-release-interval = future-release-integer

The max-future-release-date-time is a timestamp, normalized to Universal Coordinated Time (UTC). It's the furthest date and time in the future until which the MSA will hold messages for future release.

Using ABNF [n2], the syntax of this parameter is:

      max-future-release-date-time = date-time

The format of date-time is defined in [n10].

  1. When the EHLO reply includes the FUTURERELEASE keyword, the keyword is followed by the max-future-release-interval, and then by the max-future-release-date-time. The keyword and both values are separated by spaces.

For example, the ABNF for a continuation line in the EHLO response that contains the FUTURERELEASE keyword is:

      line = "250-FUTURERELEASE" SP max-future-release-interval
                                 SP max-future-release-date-time
  1. One required parameter, the hold-param, gets added to the MAIL command using either the keyword "HOLDFOR" or the keyword "HOLDUNTIL" 🫶

The HOLDFOR parameter value is a future-release-interval. It's a positive integer for how long the MSA holds the message before release.

The HOLDUNTIL parameter value is a future-release-date-time. It's a timestamp, normalized to UTC, for the future date and time until which the MSA holds the message before release.

Using ABNF [n2], the syntax of this parameter is:

      future-release-interval = future-release-integer

      future-release-date-time = Internet-style-date-time-UTC

      hold-for-param = "HOLDFOR=" future-release-interval

      hold-until-param = "HOLDUNTIL=" future-release-date-time

      hold-param = hold-for-param / hold-until-param

The absence of this parameter on the MAIL command does not imply a default value for this parameter. No defaults, bestie 🙈

  1. The maximum length of a MAIL command goes up by 34 characters because the hold-param might get added.
  2. No additional SMTP verbs are defined by this extension. 💀 Just the parameters, no new commands.
  3. This service extension is only appropriate for the SMTP submission protocol [n3]. It is not appropriate for standard SMTP [n4]. Don't try it there, periodt 👑

4. Behavior 🍓

It's kind of unfortunate that there are two basically identical ways to say when a message should be released. If the client has accurate time and accurate time zone info, you can calculate either one from the other, no cap. But in the real world, some clients have an accurate local time and no time zone, and some clients don't have a clock that's accurate enough at all. These time-challenged clients will probably only find one of the two mechanisms useful 😭

The good news is that servers are expected to have accurate time, so they can convert between the two mechanisms easily. The overhead of offering both is low too, and few interoperability problems are expected ✨

4.1. SMTP Client 🌸

  1. An SMTP client that's preparing to use Future Message Release MUST first verify that the MSA supports this extension.
  2. An SMTP client using Future Message Release MUST include one, and only one, hold-param with the MAIL command.
  3. An SMTP client using Future Message Release with the "for" option of the hold-param MUST ensure that the future-release-interval is less than or equal to the max-future-release-interval advertised by the MSA.
  4. An SMTP client using Future Message Release with the "until" option of the hold-param MUST ensure that the future-release-date-time is earlier than or equal to the max-future-release-date-time advertised by the MSA.

4.2. MSA 🦋

  1. An MSA supporting Future Message Release MUST comply with the SMTP submission protocol as described in [n3].
  2. An MSA supporting Future Message Release MUST NOT advertise this support (i.e. include the FUTURERELEASE keyword in its EHLO reply) on any port other than the submission port. Only the submission port gets to show off 💅
  3. An MSA supporting Future Message Release MUST include the FUTURERELEASE keyword, along with the associated max-future-release-interval and max-future-release-date-time parameters, in its reply to the EHLO command.
  4. An MSA supporting Future Message Release MUST accept a MAIL command containing a valid hold-param, as long as the MAIL command has no other errors.
  5. An MSA that accepts a message with a request for Future Message Release indicating the "for" option MUST NOT release the message until the amount of time specified in the future-release-interval elapses. ⏳
  6. An MSA that accepts a message with a request for Future Message Release indicating the "until" option MUST NOT release the message until the date and time indicated by the future-release-date-time occurs.
  7. An MSA supporting Future Message Release MUST reject a MAIL command containing the "for" option with a value greater than the advertised max-future-release-interval, or otherwise invalid.
  8. An MSA supporting Future Message Release MUST reject a MAIL command containing the "until" option with a value later than the advertised max-future-release-date-time, or otherwise invalid.
  9. An MSA supporting Future Message Release MUST reject a MAIL command containing more than one hold-param.
  10. An MSA supporting Future Message Release, when rejecting a MAIL command under items 7, 8, or 9 above, SHOULD supply the reply code 501 (syntax error in parameters or arguments [n4]) in the reply.
  11. An MSA supporting Future Message Release, when rejecting a MAIL command under items 7, 8, or 9 above, SHOULD supply the Enhanced Mail System Status Code 5.5.4 (invalid command arguments [i1]) in the reply.

5. Protocol Interactions 🔥

5.1. Interaction with the DSN SMTP Service Extensions 🎀

The Delivery Status Notification (DSN) service extension is described in [n7], and the DSN message format is described in [n8].

5.1.1. SMTP Client Interaction with DSN 💖

  1. An SMTP client MUST NOT request Future Message Release when sending a DSN to the MSA. No time-traveling DSNs, please 🙅‍♀️

5.1.2. MSA Interaction with DSN 🌈

  1. If an MSA generates a DSN for a message that includes a Future Message Release request, the MSA MUST include an Arrival-Date field in the machine-readable body part of the DSN.
  2. If an MSA generates a DSN for a message that includes a Future Message Release request, the MSA MUST include a Future-Release-Request field in the machine-readable body part of the DSN. The value of this field is the value of the HOLD parameter from the MAIL command of the original message.

The Future-Release-Request field is an extension to the set of DSN per-message fields described in [n8]. Using ABNF [n2], the syntax of this new field is:

      orig-hold-param-value = ("for;" future-release-interval) /
                              ("until;" future-release-date-time)
                         ; this is the value of the HOLD param from
                         ; the MAIL command of the original message

      future-release-request-field = "Future-Release-Request:"
                                     orig-hold-param-value

5.2. Interaction with the DELIVERBY SMTP Service Extension ⏰

Okay so if an MSA supports both Future Message Release and Deliver By, a client can ask for both a future release time and a deliver-by time on the same message. The problem is that if the release time is further out than the deliver-by time, you can't honor both. To honor the deliver-by request, the future release request has to be ignored. To honor the future release request, the deliver-by request has to be ignored. This section handles that mess 🫠 The Deliver By extension is described in [n6].

5.2.1. SMTP Client Interaction with DELIVERBY 👑

  1. When an SMTP client wants to use the Future Message Release and Deliver By extensions with the same message, the client MUST ensure that the specified deliver-by time is further in the future than the specified ("until" option) or implied ("for" option) future message release time. Deliver-by has to be the later one, bestie ✨

5.2.2. MSA Interaction with DELIVERBY 💌

Okay, MSA time 🫶 If an MSA supports both Future Message Release and Deliver By, and gets a message that asks for both, here's the rule:

  1. If an MSA supports Future Message Release and Deliver By extensions, and receives a message requesting the use of both extensions, the MSA MUST reject the MAIL command if it determines that the future message release time is farther in the future than the deliver-by time. 🚫
  2. When an MSA is rejecting a MAIL command per item 1, above, it SHOULD supply the reply code 501 (syntax error in parameters or arguments [n4]) in the reply. 💀
  3. When an MSA is rejecting a MAIL command per item 1, above, it SHOULD supply the Enhanced Mail System Status Code 5.5.4 (invalid command arguments [i1]) in the reply. ✨

5.3. Interaction with the MDN Function

The Message Disposition Notification (MDN) function is described in [n9]. 📬

5.3.1. SMTP Client Interaction with MDN

  1. An SMTP client MUST NOT request Future Message Release when sending an MDN to the MSA. 🙅‍♀️

6. Security Considerations 🔐

Okay, this part is serious, so bestie, please read it all 🥺 The Future Message Release service extension comes with a few security considerations:

  1. Unauthorized future-release messages provide a means to overwhelm the storage of an MSA. The authorization mechanisms required for the base mail submission protocol [n3] are expected to provide appropriate defense against such attacks. 🛡️
  2. Authorized future message release without a per-user quota may also provide a way to overwhelm an MSA's storage. An MSA's future release message storage SHOULD be subject to a per-user quota. 🪣
  3. If an MSA is imposing a per-user quota on future-release message storage, and detects that an incoming future-release message will exceed the user's future-release message storage quota, the MSA MUST reject the MAIL command. 🚨
  4. When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply the reply code 552 (requested mail action aborted: exceeded storage allocation [n4]) in the reply. 📦
  5. When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply the new Enhanced Mail System Status Code defined for this purpose. This new status code updates [i1]. 🆕 Here are the two new codes:
X.7.16   Future release per-user message quota exceeded
X.7.17   Future release system message quota exceeded

X.7.16 is the one for when there's not enough per-user quota to queue the message for future release. It suggests the client can try again only after the per-user queue has drained. 🫠

X.7.17 is the one for when there's not enough system quota to queue the message for future release. It suggests the client can try again after the system queue has drained. 🌊

  1. Inaccurate time on the MSA may result in premature or delayed release of messages. Both HOLDUNTIL and HOLDFOR request mechanisms are sensitive to inaccurate or changing clocks on the MSA. ⏰😭
  2. Some element of deception is inherent in the future message release concept. The message release time is intentionally delayed past the time it would otherwise be released; hence, the message delivery time is delayed past the time it would otherwise be delivered. This extension provides no mechanism for hiding this from the message recipient. The RFC 2822 [n5] message header, and specifically the Date field, remain unchanged after submission. While a sending client MAY elect to place the future-message-release-time as the date in the Date field, there is no requirement or expectation that the Received fields and other trace information be modified by the transport system to further this deception. 🎭 Lowkey sneaky, but at least it's documented! 🕵️‍♀️

7. IANA Considerations 🗂️

This extension has been added to the list of SMTP Service Extensions on the Mail Parameters Web page. 🎉

8. Acknowledgments 🌷

Huge credit for this document goes to the LEMONADE working group 🍋 Over many revisions, the discussion led to some fundamental new understandings of this protocol, and the implied requirements and protocol got refined as a result. Special thanks to the people who patiently helped the WG understand that doing both interval and date-time was the pragmatically correct approach to the needs of diverse clients. You're all iconic 👑

9. Normative References 📚

  • [n1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [n2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
  • [n3] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
  • [n4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
  • [n5] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
  • [n6] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
  • [n7] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
  • [n8] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
  • [n9] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
  • [n10] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002

10. Informative References 🌸

  • [i1] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.

Authors' Addresses 🏡

Gregory A. White
6519 Camille Ave.
Dallas, TX  75252
USA
EMail: g.a.white@tx.rr.com

Gregory M. Vaudreuil
Alcatel-Lucent
9489 Bartgis Ct
Frederick, MD 21702
USA
EMail: GregV@ieee.org

Copyright (C) The IETF Trust (2007).

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, THE IETF TRUST 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. ✨

📦 where this page comes from