If you want to evaluate vacation on the relay rather than on the back-end store system to enhance performance, edit the option.dat file and prepend the character # to the autoreply rule in DELIVERY_OPTIONS.
Use an editor to open the option.dat file.
Add or change the DELIVERY_OPTIONS option so the autoreply rule now looks like:
DELIVERY_OPTIONS=*mailbox=$M%$\$2I$_+$2S@ims-ms-daemon, \ &members=*, \ *native=$M@native-daemon, \ /hold=@hold-daemon:$A, \ *unix=$M@native-daemon, \ &file=+$F@native-daemon, \ &@members_offline=* \ ,program=$M%$P@pipe-daemon, \ #forward=**, \ *^!autoreply=$M+$D@bitbucket
This allows the processing to take place on relays. If you have the MTA perform autoreplies on the relays, then either each relay can keep track independently of whether a particular correspondent has sent an away message recently, or this information can be shared between the relays. The former case is simpler, especially if having away messages sent out too many times does not matter. If you want strict application of the away message frequency rules, then the information must be shared between relays. To share the information among the relays, the files should be NFS mounted. For important information on NFS-mounting, see 22.214.171.124 Using NFS-based File Systems for Defragmentation and Vacation Caching
The location of these files is controlled by the option VACATION_TEMPLATE. This option (in option.dat) should be set to /<path>/%A where <path> is the path to a directory that is shared between the various relay machines. The template needs to be a file:URL and you use $U to substitute the name of the user. The default setting is:
See Table 9–6 for metacharacter descriptions.
Vacation file templates now have access to the UID, allowing paths to vacation files to be built based on the user's UID. Additionally, the address used in determining the vacation file path is now the one stored in the user's mail attribute; previously the current recipient address was used.