SMTP SUBMIT FUTURERELEASE support

New in Messaging Server 7.0-0.04, the MTA supports the  FUTURERELEASE extension to SMTP  SUBMIT, defined in RFC 4865 (SMTP Submission Service Extension for  Future Message Release). FUTURERELEASE permits a client to submit a message to the SMTP SUBMIT server for the server to hold onto in its  (server) queue until releasing for delivery at a specified time in the  future. This can be useful for clients that wish to compose messages "ahead of time", that will only become eligible for delivery  at some later time, or which have issues with saving/retaining messages  locally themselves, or with ensuring submission at the "right  time". A typical use case might be for messages intended as announcements or event reminders.

FUTURERELEASE support is enabled by placing the   channel option on a    source channel used for initial  message submission. The   channel option takes a single integer argument: the  maximum number of seconds a message can be held. Note that FUTURERELEASE is specifically an  SMTP SUBMIT feature: in terms of MTA  configuration, only channel(s) marked with the    keyword are capable of offering FUTURERELEASE support. A client attempt to use a FUTURERELEASE parameter in a MAIL FROM command to an SMTP  SUBMIT server for which FUTURERELEASE has not been enabled will be  rejected with the error: 504 5.7.4 FUTURERELEASE extension not available. or 503 5.7.1 FUTURERELEASE extension not available. Care should be used when enabling future release since it allows messages to be in effect stored in the MTA&#x27;s queues. FUTURERELEASE should only be used for channels handling initial message submission  and authentication of the message submittor should be required.

Additionally, if you wish to make distinctions about just which senders may use FUTURERELEASE (or for how long different classes of senders may  postpone message delivery), consider also using the    user attribute   (or as of 8.0, whatever LDAP attribute is named by the    MTA option) to sort different  classes of senders into different source channels with appropriately  different   settings.

Note that similar functionality was previously available: specification of a Deferred-delivery: header field in a submitted message coupled  with use of the   channel keyword on the  destination channel provided the ability to defer delivery of messages. However, FUTURERELEASE provides superior functionality:



 The FUTURERELEASE facility is controlled by a setting on the source   channel, allowing it to be provided to a subset of the user population. In contrast, placing  on a destination channel    opened the door to anyone submitting a message destined for    that channel to have that message be held for some period of time. 

 There&#x27;s no way for a client which sets a Deferred-delivery: header   field to know whether or not the header has actually caused the message    to be deferred. The FUTURERELEASE SMTP SUBMIT extension, on the other   hand, lets the client know how long a message can be held and an error    will be returned to the client if the message cannot be held for the    time the client requested. 

 With Deferred-delivery:, there was no (automatic) way to place a   limit on the amount of time a message could be held. Instead what   (normally) happened was that a message held longer than the channel&#x27;s    last   value would simply be returned as    undeliverable. 

 Deferred-delivery: settings on messages did not survive a Job   Controller restart. 



As part of the implementation work for FUTURERELEASE, the old Deferred-delivery: mechanism has been redesigned to address some (but  not all) of these points. In particular, the   channel keyword has been replaced by two new channel options,   and. (The   option is now a synonym for   .) Both of these options accept an  optional integer argument specifying in seconds the maximum amount of  time in the future a Deferred-delivery: header can specify and still be  honored. The default if no argument is specified is 60&#x2a;60&#x2a;24&#x2a;7, or 7 days. enables Deferred-delivery: processing on the basis of the source channel while    operates on destination channels. Finally, Deferred-delivery: settings on messages now survive Job Controller restarts. This addresses all of the points on the above list except (2): use of a Deferred-delivery: header field still provides no  mechanism for informing the client whether or not their request will be  honored.

Note that, as discussed above, FUTURERELEASE is an extension defined (and supported by the MTA) solely for use with SMTP SUBMIT. A client attempt to use FUTURERELEASE to the MTA&#x27;s SMTP server will result in  the error: 504 5.7.4 FUTURERELEASE is a SUBMIT extension; it cannot be used in SMTP. or 503 5.7.1 FUTURERELEASE extension not available.

See also:
 * futurerelease Option
 * submit Option
 * deferred Option
 * SMTP SUBMIT servers
 * log_times MTA Option
 * ldap_auth_attr_submit_channel MTA Option