SMTP Submission Service Extension for Future Message Release
This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. [STANDARDS-TRACK]
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 20 must, 7 should, 1 may.
4.1 SMTP Client
- MUST1) An SMTP client preparing to use Future Message Release MUST first verify that the MSA supports this extension.
- MUST2) An SMTP client using Future Message Release MUST include one, and only one, hold-param with the MAIL command.
- MUST3) 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.
- MUST4) 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
- MUST1) An MSA supporting Future Message Release MUST comply with the SMTP submission protocol as described in [n3].
- MUST NOT2) 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.
- MUST3) An MSA supporting Future Message Release MUST include the FUTURERELEASE keyword, and associated max-future-release-interval and max-future-release-date-time parameters, in its reply to the EHLO command.
- MUST4) An MSA supporting Future Message Release MUST accept a MAIL command containing a valid hold-param, given that the MAIL command contains no other errors.
- MUST NOT5) 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.
- MUST NOT6) 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.
- MUST7) An MSA supporting Future Message Release MUST reject a MAIL command containing the "for" option specifying a value that is greater than the advertised max-future-release-interval, or otherwise invalid.
- MUST8) An MSA supporting Future Message Release MUST reject a MAIL command containing the "until" option specifying a value that is later than the advertised max-future-release-date-time, or otherwise invalid.
- MUST9) An MSA supporting Future Message Release MUST reject a MAIL command containing more than one hold-param.
- SHOULD10) An MSA supporting Future Message Release, when rejecting a MAIL command per items 7, 8, or 9, above, SHOULD supply the reply code 501 (syntax error in parameters or arguments [n4]) in the reply.
- SHOULD11) An MSA supporting Future Message Release, when rejecting a MAIL command per 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.1.1 SMTP Client Interaction with DSN
- MUST NOT1) An SMTP client MUST NOT request Future Message Release when sending a DSN to the MSA.
5.1.2 MSA Interaction with DSN
- MUST1) 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.
- MUST2) 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.
5.2.1 SMTP Client Interaction with DELIVERBY
- MUST1) When an SMTP client wishes 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 farther in the future than the specified ("until" option) or implied ("for" option) future message release time.
5.2.2 MSA Interaction with DELIVERBY
- MUST1) 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.
- SHOULD2) 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.
- SHOULD3) 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.1 SMTP Client Interaction with MDN
- MUST NOT1) An SMTP client MUST NOT request Future Message Release when sending an MDN to the MSA.
6 Security Considerations
- SHOULDAn MSA's future release message storage SHOULD be subject to a per-user quota.
- MUST3) 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.
- SHOULD4) 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.
- SHOULD5) 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.
- MAYWhile 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.