Sun Java System Messaging Server 6.3 Administration Guide

17.2 Configuring Autoreply

Delivery addresses are generated through a set of patterns. The patterns used depend upon the values defined for the mailDeliveryOption attribute. A delivery address is generated for each valid mailDeliveryOption. The patterns are defined by the MTA option DELIVERY_OPTIONS, which are defined in the option.dat file. The default autoreply rule in DELIVERY_OPTIONS in the option.dat file is:


The MTA notes the “^” on the autoreply DELIVERY_OPTION MTA option. This causes the MTA to check the vacation dates. If the current date is within the vacation dates, processing continues and the MTA notes the “!” on the autoreply DELIVERY_OPTION. The MTA then creates a vacation Sieve script based on the various autoreply LDAP attributes on the user’s entry. The autoreply rule can have the prefix characters ”!’, ”#’, ”^’, and ”*’.

You could have the ”!’ flag on the mailbox delivery option. This would enable the generation of the vacation script unconditionally. It makes sense, however, to have the autoreply machinery enabled by a separate delivery option so that it can be further gated by the ”^’ flag. Checking the dates at this stage is more efficient than engaging the Sieve logic.

Table 17–1 shows the prefix characters used for the autoreply rule in the first column and their definitions in the second column.

Table 17–1 Prefix Characters for the Autoreply Rule in DELIVERY_OPTIONS

Prefix Character 



Enable the generation of the autoreply Sieve script. 


Allows the processing to take place on relays. 


Option is only evaluated if the vacation dates indicate that it should be evaluated. 


Extract preferred language information from various message header fields as well as from LDAP entries associated with envelope From: addresses. For this information to be available at the correct time, the message must pass through the reprocess channel when autoreply is engaged. This is done by adding the @ flag to the autoreply delivery option. Note that the addition of a channel hop increases message processing overhead.

The autoreply rule itself specifies an address destined for the bitbucket channel. The mail is considered delivered by this method once the autoreply is generated, but the MTA machinery requires a delivery address. Anything delivered to the bitbucket channel is discarded.

17.2.1 Configuring Autoreply on the Back-end Store System

The default autoreply rule in DELIVERY_OPTIONS causes the autoreply to take place on the mail server that serves the user. If you want vacation messages to be evaluated on the back-end store system, you do not have to configure anything. This is the default behavior.

ProcedureTo Configure Autoreply on a Relay

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.

  1. Use an editor to open the option.dat file.

  2. Add or change the DELIVERY_OPTIONS option so the autoreply rule now looks like:


    The default DELIVERY_OPTIONS option 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=**, \

    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 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.

    Note –

    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.