Vacation_template MTA option

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

Autoresponse periodicity MTA options: vacation_template (file or memcache URL)

The vacation_template MTA option specifies a template for the name and location of the per-user autoresponse information memcache entries or files. These can be flat text files, one per local user. The value should be a memcache: URL or a file URL (file:path-template).

Various substitution sequences may be used in constructing the file path template; see the MTA's LDAP URL substitution sequences. Note that the $nA and $U substitution metacharacters are likely to prove particularly useful in constructing effective vacation_template settings.

This option must be set to a sensible value in order to support user "vacation" Sieve script actions (and LDAP mailAutoReply* attributes). Prior to Messaging Server 7.4-0.01, there was no default value. As of Messaging Server 7.4-0.01, the default value is:


The machinery used to read and write these flat text files is designed in such a way that it should be able to operate correctly over NFS. This allows multiple MTAs to share a single set of files on a common filesystem. Note that when intending to use NFS to share vacation response files among multiple systems, it is important to define the same MTA user account -- same user name and uid (see the user option in restricted.cnf) -- on each system so as to avoid permission problems.

As of the 8.0 release, memcache is also supported as a back end for vacation timeout information. This is accomplished by specifying a memcache: URL. A typical setting would be:


in which case the memcache server is specified by the memcache_host and memcache_port MTA options. These options can be overidden by specifying the host and port in the URL, e.g.,


The content of the URL after the host and port specifies the key used to store information in memcache. The $U substitution provides the necessary information for the key, but a prefix or suffix can also be included if there is a need to distinguish the keys from other information stored in the memcache instance.

As of MS, Redis URLs are also supported. These have the same semantics as memcache URLs, so a sensible setting would be:


See also: