test

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

第 16 章 不在メッセージの自動返信

電子メールへの応答として自動的に生成される返信 (自動返信)、特に不在メッセージを処理するために、MTA では MDN (Message Disposition Notification) および Sieve スクリプト言語が使用されます。MDN は、MTA によって差出人またはポストマスター (あるいはその両方) に送信される電子メールメッセージであり、メッセージの配信状態について報告するものです。MDN は、開封確認、確認通知、受信通知、配信確認とも呼ばれます。Sieve は、メールフィルタの作成に使用される簡単なスクリプト言語です。Messaging Server 5.x と異なり、使われる文字セットは ISO-2022-JP ではなく UTF-8 です。

この章では、不在返信メッセージの自動返信のメカニズムについて説明します。ほとんどの場合、デフォルト設定を変更する必要はありませんが、不在処理がバックエンドメッセージストアではなく MTA リレーマシンで実行されるようにシステムを設定することもできます。

この章には、次の節があります。

不在返信メッセージの自動返信の概要

不在処理の Sieve スクリプトは、さまざまな LDAP Vacation 属性から自動的に生成されます (「不在返信メッセージの自動返信の属性」を参照)。Sieve スクリプトを明示的に指定して柔軟性を高めることもできます。不在メッセージ追跡の基本手段は、目的の受取人ごとに 1 つあるファイルの集合です。このファイルには、各差出人に返信が送信された時間が記録されます。

注 –

不在通知メッセージの文字セットは UTF-8 に変更されました。

デフォルトでは、MTA はバックエンドストアシステムで不在メッセージを評価します。MTA リレーはバックエンドストアほど多くの処理を実行しないため、パフォーマンスを考慮して、バックエンドストアではなくメールリレーマシンで MTA が不在メッセージを評価するように設定することもできます。ただし、この設定を行うと、さまざまなリレーがさまざまなメッセージを処理するため、不在メッセージが意図したよりも頻繁に送信される可能性があります。意図したよりも頻繁に不在メッセージが送信されることを防ぐには、リレー間でファイルの記録を共有します。この方法も容認できない場合は、常にバックエンドストアシステムで不在メッセージを評価してください。

自動返信を設定する

配信アドレスは 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 に基づいて不在ファイルのパスを構築できるようになりました。また、不在ファイルのパスを決定する際のアドレスとして、以前は現在の受取人アドレスが使用されていましたが、今はユーザーのメール属性に格納されているアドレスが使用されます。

不在返信メッセージの自動返信の動作方式

不在処理は、起動されると次のように機能します。

  1. Sun Java System Messaging Server は、不在処理がシステムレベルではなくユーザーレベルの Sieve スクリプトで実行されたことを確認します。不在処理にシステムレベルのスクリプトが使用されている場合は、エラーが発生します。

  2. 内部 MTA フラグの「no vacation notice」がチェックされます。このフラグが設定されている場合、処理は終了し、不在通知は送信されません。

  3. メッセージの返信用アドレスがチェックされます。返信用アドレスが空白の場合、処理は終了し、不在通知は送信されません。

  4. MTA は、現在のメッセージの To:、Cc:、Resent-to:、または Resent-cc: の各ヘッダーフィールドにある :addresses タグ付き引数にユーザーのアドレスまたはその他のアドレスが指定されているかどうかをチェックします。いずれのヘッダーフィールドでもアドレスが見つからない場合、処理は終了し、不在通知は送信されません。

  5. Messaging Server は、:subject 引数と理由文字列のハッシュを作成します。この文字列は現在のメッセージの返信用アドレスとともに、ユーザーごとの不在応答の履歴に照らしてチェックされます。応答が :days 引数で許可されている時間内にすでに送信されている場合、処理は終了し、応答は送信されません。

  6. Messaging Server は、:subject 引数、理由文字列、および :mime 引数から不在通知を作成します。この応答メッセージには、次の 2 つの基本的な形式があります。

    • 最初の部分に理由テキストがある、RFC 2298 で指定されている形式の MDN。

    • 単一パートのテキスト返信 。(この形式は、「reply」自動返信モードの属性の設定をサポートするためにのみ使用される。)

不在メッセージが Messenger Express を使用して設定された場合、mailautoreplymode は自動的に reply に設定されます。

MTA フラグの「no vacation notice」は、デフォルトでは設定解除されています。このフラグは、システムレベルの Sieve スクリプトで標準外の novacation アクションを使用して設定できます。novacation Sieve アクションは、システムレベルの Sieve スクリプトでのみ許可されます。ユーザーレベルのスクリプトで使用された場合は、エラーが発生します。このアクションを使用して、不在返信に関してサイト全体に適用する制約を実装できます。たとえば、サブ文字列「MAILER-DAEMON」を含んでいるアドレスへの返信をブロックするなどです。

ユーザーごと、応答ごとの情報は、一連のフラットテキストファイルに保存されます。ファイルは、ローカルユーザーごとに 1 つあります。これらのファイルの場所およびネーミング方式は、VACATION_TEMPLATE MTA オプションで指定します。このオプションは file:URL に設定する必要があります。

これらのファイルの保守は自動的に行われ、VACATION_CLEANUP MTA オプションの設定 (整数) によって制御されます。これらのファイルのいずれかが開かれるたびに、この値を使用して現在時刻の値 (秒単位) が計算されます。結果がゼロである場合、ファイルがスキャンされ、有効期限切れのエントリはすべて削除されます。このオプションのデフォルト値は 200 です。これは、200 分の 1 の確率でクリーンアップパスが実行されることを意味します。

これらのフラットテキストファイルの読み取りと書き込みに使用される機能は、NFS 上で正しく動作するように設計されています。これによって、複数の MTA が単一のファイルセットを共通のファイルシステム上で共有することが可能になっています。

不在返信メッセージの自動返信の属性

不在処理で使用される LDAP ユーザーディレクトリ属性は、次のとおりです。