Futurerelease Channel Option

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


SMTP Future Release Extension (futurerelease)

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 futurerelease 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'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 deferred 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 deferred on a destination channel opened the door to anyone submitting a message to that channel that would be deferred for some period of time.
  • There'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's last notices 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 deferred channel option has been replaced by two new channel keywords, deferredsource and deferreddestination. (The deferred option is now a synonym for deferreddestination.) Both of these options accept an integer argument (required in unified configurations, optional in imta.cnf) 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*60*24*7, or 7 days. deferredsource 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: