test

Sun Java System Messaging Server 6.3 Administration Guide

Chapter 17 Vacation Automatic Message Reply

For automatically generated responses to email (autoreply), specifically vacation messages, the MTA uses Message Disposition Notifications (MDNs) and the Sieve scripting language. MDNs are email messages sent by the MTA to a sender and/or postmaster reporting on a message’s delivery disposition. MDNs are also known as read receipts, acknowledgements, receipt notifications, or delivery receipts. The Sieve is a simple scripting language used to create mail filters. Unlike the Messaging Server 5.x, the character set used is UTF-8 instead of ISO-2022-JP.

This section describes the vacation autoreply mechanism. In most cases, modification to the default configuration is unnecessary, but there is a case where you may wish to configure your system such that vacation processing is done on MTA relay machines rather than on back-end message stores.

This chapter consists of the following sections:

17.1 Vacation Autoreply Overview

Vacation Sieve scripts are generated automatically from the various LDAP vacation attributes (see 17.4 Vacation Autoreply Attributes). They can also be specified explicitly for additional flexibility. The underlying mechanism for tracking vacations is a set of files, one per intended recipient, that keep track of when replies were sent to the various senders.

Note –

charset of vacation message has changed to UTF-8.

By default, the MTA evaluates vacation on the back-end store systems. However, since MTA relays do not do as much work as back-end stores, for performance reasons, you can have the MTA evaluate vacation on the mail relay machines instead of on the back-end store. Use of this feature, however, can result in vacation responses being sent out more often than intended because different relays handle different messages. If you do not want vacation messages to be sent out more often than you intend, you may share the tracking of files between the relays. If this is also unacceptable to you, you can always have vacation evaluated on the back-end store systems.

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:

*^!autoreply=$M+$D@bitbucket

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 

Definition 

!

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:

    #*^!autoreply=$M+$D@bitbucket

    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=**, \
 *^!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 12.8.2.3 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:

    VACATION_TEMPLATE=file:///opt/SUNWmsgsr/data/vacation/$3I/$1U/$2U/$U.vac

    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.

17.3 Vacation Autoreply Theory of Operation

The vacation action, when invoked, works as follows:

  1. The Sun Java System Messaging Server checks to make sure that the vacation action was performed by a user level rather than a system level Sieve script. An error results if vacation is used in a system level script.

  2. The “no vacation notice” internal MTA flag is checked. If it is set, processing terminates and no vacation notice is sent.

  3. The return address for the message is now checked. If it is blank, processing terminates and no vacation notice is sent.

  4. The MTA checks to see if the user's address or any of the additional addresses specified in the :addresses tagged argument appear in a To:, Cc:, Resent-to:, or Resent-cc: header field for the current message. Processing terminates and no vacation notice is sent if none of the addresses is found in any of the header fields.

  5. The Messaging Server constructs a hash of the :subject argument and the reason string. This string, along with the return address of the current message, is checked against a per-user record of previous vacation responses. Processing terminates and no response is sent if a response has already been sent within the time allowed by the :days argument.

  6. The Messaging Server constructs a vacation notice from the :subject argument, reason string, and :mime argument. Two basic forms for this response message are possible:

    • A message disposition notification of the form specified in RFC 2298, with the first part containing the reason text.

    • A single part text reply. (This form is only used to support the “reply” autoreply mode attribute setting.)

Note that mailautoreplymode is automatically set to reply when vacation messages are configured through Messenger Express.

The “no vacation notice” MTA flag is clear by default. It can be set by a system level Sieve script through the use of the nonstandard novacation action. The novacation Sieve action is only allowed in a system level Sieve script. It will generate an error if it is used in a user level script. You can use this action to implement site-wide restrictions on vacation replies such as blocking replies to addresses containing the substring “MAILER-DAEMON”.

Per-user per-response information is stored in a set of flat text files, one per local user. The location and naming scheme for these files is specified by the setting of the VACATION_TEMPLATE MTA option. This option should be set to a file: URL.

Maintenance of these files is automatic and controlled by the VACATION_CLEANUP integer MTA option setting. Each time one of these files is opened, the value of the current time in seconds modulo this value is computed. If the result is zero the file is scanned and all expired entries are removed. The default value for the option is 200, which means that there is 1-in-200 chance that a cleanup pass will be performed.

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

17.4 Vacation Autoreply Attributes

The set of user LDAP directory attributes that the vacation action uses are:

The MTA can chose between multiple LDAP attributes and attribute values with different language tags and determine the correct value to use. The language tags in effect are compared against the preferred language information associated with the envelope from address. Currently the only attributes receiving this treatment are LDAP_AUTOREPLY_SUBJECT (normally mailAutoReplySubject), LDAP_AUTOREPLY_TEXT (normally mailAutoReplyText), LDAP_AUTOREPLY_TEXT_INT (normally mailAutoReplyTextInternal), LDAP_SPARE_4, LDAP_SPARE_5, LDAP_PREFIX_TEXT and LDAP_SUFFIX_TEXT.

It is expected that each attribute value will have a different language tag value. If different values have the same tag value the choice between them will be essentially random.

17.5 Other Auto Reply Tasks and Issues

This section describes auto reply tasks and issues not described in the configuration section.

17.5.1 To Send Autoreply Messages for Email That Have Been Automatically Forwarded from Another Mail Server

An autoreply problem can occur when the MTA receives a message that has been automatically forwarded from another system in some other administrative domain. For example, if a customer has a home account with sesta.com and the customer sets that account to automatically forward messages to their work account at siroe.com and if siroe.com uses Messaging Server and that user has set his account to autoreply a vacation message, then Messaging Server will have a problem sending out a vacation message.

The problem occurs because the sesta.com mail server changes the envelope To: address from user@sesta.com to user@siroe.com, but it will not change the To: header, which remains user@sesta.com. When the MTA receives the message, it looks at the header address only. It attempts to match this address with an address in the LDAP user directory. If it finds a match with someone who has set autoreply, then a vacation message is sent. Because there is no LDAP address match to user@sesta.com, no vacation message is sent. The problem is that the actual address is in the envelope and not in the header.

Since the recipient's address known to the remote system doing automatic forwarding isn't known to correspond to the user by the local system, there needs to be a way for the recipient to make such addresses known to the local system so vacation replies will be sent when necessary.

The :addresses argument to the Sieve vacation action provides this capability. It accepts a list of addresses that correspond to the recipient for purposes of making this check. The attribute defined by the MTA option LDAP_AUTOREPLY_ADDRESSES allows specification of such addresses in the user's LDAP entry.

To provide autoreply capability for messages that have been automatically forwarded from mail servers in some other administrative domain, the user or administrator would set the email addresses from where those messages may be forwarded to the attribute defined by LDAP_AUTOREPLY_ADDRESSES.