Futurerelease Channel Option

SMTP Future Release Extension
Release 7 of the Messaging Server MTA implements support for future release SMTP SUBMIT extension defined in RFC 4865. This support is enabled by placing the  channel option on the   source channel used for initial message submission. The option takes a single integer argument: The maximum number of seconds a message can be deferred.

Care should be used when enabling future release since it allows messages to be in effect stored in the MTA&#x27;s queues. Future release should only be used for channels handling initial message submission and authentication should be required.

Note that similar functionality is available in earlier Messaging Server releases: Specification of a Deferred-delivery: header field in a submitted message coupled with use of the   channel option on the destination channel provided the ability to defer delivery of messages. However, future release provides superior functionality:



 The facility is controlled by a setting on the source channel, allowing it to be provided to a subset of the user population. Placing  option on a  destination channel opens the door to anyone submitting a message to that channel that will be deferred 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 future delivery SMTP extension, on the other hand, lets the client know how long a message can be deferred and an error will be returned to the client if the message cannot be deferred for the time the client wants. 

 There was no way to place a limit on the amount of time a message could be deferred. Instead what happened was that a message deferred 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 future release the old Deferred-delivery: mechanism has been redesigned to address some (but not all) of these points. In particular, the  channel option has been replaced by two new channel keywords,    and. (The  option is now a synonym for  .) Both of these options accept an integer argument (required in unified configurations, optional in  ) 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 deferreddestination 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 the second one - use of a Deferred-delivery: header field still provides no mechanism for informing the client whether or not the setting will be honored.

However, as a purely practical matter, the mechanism chosen to provide delayed release of messages is likely to be dictated by the choice of email client and what mechanisms it supports.

See also:
 * SMTP SUBMIT servers
 * SMTP SUBMIT FUTURERELEASE support
 * submit Option
 * deferred Option
 * notices Option
 * log_times MTA Option
 * SMTP and LMTP protocol channel options
 * Processing control and job submission channel options
 * Channel options