test

Sun Java System Messaging Server 6 2005Q4 管理ガイド

自動返信を設定する

配信アドレスは 1 組のパターンによって生成されます。使用されるパターンは、mailDeliveryOption 属性に定義されている値によって異なります。配信アドレスは、有効な mailDeliveryOption ごとに生成されます。パターンは MTA オプションの DELIVERY_OPTIONS によって定義されます。このオプションは option.dat ファイルで定義されます。option.dat ファイルにある DELIVERY_OPTIONS のデフォルトの自動返信ルールは、次のとおりです。

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

MTA は、自動返信 DELIVERY_OPTION MTA オプションにある「^」を認識します。これによって、MTA は不在の日付をチェックします。現在の日付が不在期間内である場合、処理は続行され、MTA は自動返信 DELIVERY_OPTION にある「!」を認識します。次に MTA は、ユーザーエントリのさまざまな自動返信 LDAP 属性に基づいて自動返信 Sieve スクリプトを作成します。自動返信ルールには、プレフィックス文字「!」、「#」、「^」、および「*」を付けることができます。

たとえば、メール配信オプションに「!」フラグを付けることができます。このフラグによって、自動返信スクリプトの生成が無条件で有効になります。ただし、自動返信機能を別の配信オプションで有効化し、自動返信機能がさらに「^」フラグによって制御されるようにするのは理にかなっています。この段階で日付をチェックしたほうが Sieve のロジックを使用するよりも効率的です。

表 16–1 に、自動返信ルールで使用されるプレフィックス文字 (1 列目) とその定義 (2 列目) を示します。

表 16–1 DELIVERY_OPTIONS の自動返信ルールで使用されるプレフィックス文字

プレフィックス文字 

定義 

!

自動返信 Sieve スクリプトの生成を有効にします。 

#

処理がリレーで実行されることを許可します。 

^

評価する必要があると不在の日付から判明した場合にのみ、オプションを評価します。 

*

ルールは、ユーザーにのみ適用可能です。 

自動返信ルール自体は、bitbucket チャネル宛のアドレスを指定します。自動返信が生成されると、メールはこのメソッドによって配信されると見なされますが、MTA 機能には配信アドレスが必要です。bitbucket チャネルに配信された内容はすべて破棄されます。

バックエンドストアシステムで自動返信を設定する

DELIVERY_OPTIONS のデフォルトの自動返信ルールにより、自動返信はユーザーが使用するメールサーバー上で実行されます。バックエンドストアシステムで不在メッセージの評価を実行する場合は、設定を変更する必要はありません。これがデフォルトの動作です。

Procedureリレーでの自動返信を設定するには

パフォーマンスを向上するために、バックエンドストアシステムではなくリレーで不在メッセージの評価を実行する場合は、option.dat ファイルを編集し、文字 # を DELIVERY_OPTIONS の自動返信ルールの先頭に追加します。

手順

  1. an エディタを使用して option.dat ファイルを開きます。

  2. 自動返信ルールが次に示すようになるように、DELIVERY_OPTIONS オプションに追加または変更を行います。

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

    デフォルトの DELIVERY_OPTIONS オプションは次のようになっています。

    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

    これによって、処理がリレーで実行されるようになります。リレーで MTA による自動返信を実行する場合、特定の人物が不在メッセージを最近送信しているかどうかを各リレーで個々に記録するか、その情報をリレー間で共有するかのいずれかとなります。送信された不在メッセージの数が非常に多くても問題ではない場合は特に、前者のほうが簡単です。不在メッセージの頻度ルールを厳しく適用する場合は、情報をリレー間で共有する必要があります。リレー間で情報を共有するには、ファイルは NFS 上にある必要があります。

    これらのファイルの場所はオプション VACATION_TEMPLATE で制御されます。このオプション (option.dat 内) は、/<path>/%A に設定する必要があります。ここで、<path> は、各リレーマシン間で共有されるディレクトリへのパスです。テンプレートは file:URL である必要があります。ユーザーの名前を置換するには、$U を使用します。デフォルト設定は次のとおりです。

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

    メタキャラクタについては、表 9–6 を参照してください。

    注 –

    不在ファイルのテンプレートによる UID へのアクセスが可能になったため、ユーザーの UID に基づいて不在ファイルのパスを構築できるようになりました。また、不在ファイルのパスを決定する際のアドレスとして、以前は現在の受取人アドレスが使用されていましたが、今はユーザーのメール属性に格納されているアドレスが使用されます。