SMTP Submission Service Extension for Future Message Release
updates
Extracted elements (21)
Both interval (HOLDFOR) and date-time (HOLDUNTIL) mechanisms are provided because some clients have accurate local time but no time zone information, while others lack a reliable clock entirely; servers can trivially convert between the two forms, and the protocol overhead of supporting both is low.
This service extension is appropriate only for the SMTP submission protocol (RFC 4409) on the submission port, and MUST NOT be advertised or used on standard SMTP (RFC 2821) ports.
An MSA MUST include the FUTURERELEASE keyword with both max-future-release-interval and max-future-release-date-time parameters in its EHLO reply when supporting this extension.
An MSA MUST NOT release a held message before the specified future-release-interval elapses (HOLDFOR) or the future-release-date-time occurs (HOLDUNTIL).
An MSA MUST reject a MAIL command containing a HOLDFOR value exceeding max-future-release-interval, a HOLDUNTIL value later than max-future-release-date-time, or more than one hold-param; SHOULD reply with code 501 and enhanced status code 5.5.4.
An MSA supporting Future Message Release MUST NOT advertise the FUTURERELEASE keyword in its EHLO reply on any port other than the submission port (587).
An SMTP client MUST NOT request Future Message Release when sending a DSN or MDN to the MSA.
An SMTP client MUST verify that the MSA supports the FUTURERELEASE extension before attempting to use it.
An SMTP client using Future Message Release MUST include exactly one hold-param (either HOLDFOR or HOLDUNTIL) with the MAIL command; the absence of this parameter implies no default value.
An SMTP client using HOLDFOR MUST ensure the future-release-interval does not exceed the max-future-release-interval advertised by the MSA; a client using HOLDUNTIL MUST ensure the future-release-date-time is not later than the max-future-release-date-time advertised.
If an MSA generates a DSN for a message with a Future Message Release request, the MSA MUST include both an Arrival-Date field and a Future-Release-Request field in the machine-readable body part of the DSN.
When both Future Message Release and Deliver By extensions are used together, the SMTP client MUST ensure the deliver-by time is farther in the future than the future message release time; the MSA MUST reject the MAIL command if the release time exceeds the deliver-by time.
The FUTURERELEASE SMTP service extension keyword is advertised in EHLO replies with two parameters: max-future-release-interval (maximum seconds the MSA will hold messages) and max-future-release-date-time (most remote UTC timestamp until which the MSA will hold messages).
The FUTURERELEASE keyword has been added to the IANA SMTP Service Extensions registry on the Mail Parameters Web page. Two new Enhanced Mail System Status Codes are defined: X.7.16 (per-user future-release quota exceeded) and X.7.17 (system future-release quota exceeded), updating RFC 3463.
Future message release intentionally delays delivery, creating an element of deception. The RFC 2822 Date header and message trace fields are not required to be modified to reflect the release delay; recipients receive the original submission timestamp.
If a future-release message would exceed the per-user storage quota, the MSA MUST reject the MAIL command with reply code 552 and SHOULD supply new enhanced status code X.7.16 (per-user quota exceeded) or X.7.17 (system quota exceeded).
Inaccurate or changing clocks on the MSA may cause premature or delayed message release; both HOLDFOR and HOLDUNTIL mechanisms are sensitive to clock inaccuracy.
Unauthorized future-release messages can overwhelm MSA storage; existing submission protocol authorization mechanisms are expected to defend against this. Additionally, authorized future-release without per-user quotas poses the same risk, so MSAs SHOULD impose per-user storage quotas.
The EHLO continuation line for FUTURERELEASE has the form: '250-FUTURERELEASE SP max-future-release-interval SP max-future-release-date-time'. The max-future-release-interval is a positive integer (1-999999999) in seconds; the max-future-release-date-time is an RFC 3339 UTC date-time.
The Future-Release-Request DSN field has the form 'Future-Release-Request: (for;future-release-interval) / (until;future-release-date-time)', carrying the original HOLD parameter value from the submitted message's MAIL command.
The MAIL command is extended with a hold-param, which is either HOLDFOR=future-release-interval (positive integer in seconds) or HOLDUNTIL=future-release-date-time (UTC timestamp). The maximum MAIL command length increases by 34 characters.