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

その他のキーワード

この節では、その他のキーワードを説明します。この章には、次の節があります。

プロセスチャネルのオーバーライド

キーワード: notificationchannel、dispositionchannel

これらのキーワードは、配信ステータス通知 (DSN) および Message Disposition Notification (MDN) をそれぞれ最初にキューに入れるチャネルとして、プロセスチャネルよりも優先されます。指定された名前のチャネルが存在しない場合、Messaging Server はプロセスチャネルの使用を再開します。

notificationchannel は、配信ステータス通知 (DSN) を最初にキューに入れるチャネルとしてプロセスチャネルよりも優先されます。指定された名前のチャネルが存在しない場合、Messaging Server はプロセスチャネルの使用を再開します。

dispositionchannel は、MDN (Message Disposition Notification) を最初にキューに入れるチャネルとしてプロセスチャネルよりも優先されます。指定された名前のチャネルが存在しない場合、Messaging Server はプロセスチャネルの使用を再開します。

チャネル動作のタイプ

キーワード: submit

Messaging Server は、RFC 2476 のメッセージ送信プロトコルをサポートしています。チャネルを送信専用に設定するには、submit キーワードを使用します。これは通常、特別なポートで実行され、メッセージを送信する目的だけに使用される SMTP サーバーなどの TCP/IP チャネルに便利です。RFC 2476 では、このようなメッセージ送信に使用するためにポート 587 を確立します。

pipe チャネル

キーワード: user

user キーワードは、pipe チャネルでどのユーザー名を実行するかを示すのに使用されます。

user の引数は、通常小文字に変換されますが、引数に引用符が付けられている場合は、元の大文字と小文字が維持されます。

メールボックスフィルタファイルの場所を指定する

キーワード: filter、nofilter、channelfilter、nochannelfilter、destinationfilter、nodestinationfilter、sourcefilter、nosourcefilter、fileinto、nofileinto

filter キーワードは、そのチャネル用のユーザーフィルタファイルの場所を指定するために、ネイティブチャネルと ims-ms チャネルに対して使用します。このキーワードは、フィルタファイルの場所を示す URL を必要な引数としてとります。nofilter がデフォルトで、ユーザーメールボックスフィルタがそのチャネルに対して有効にならないことを示します。

一般的な MTA チャネルにチャネルレベルのフィルタを指定するには、受信と送信のメッセージに対してそれぞれ sourcefilter と destinationfilter のキーワードを使用します。これらのキーワードは、チャネルフィルタファイルの場所を示す URL を引数としてとります。nosourcefilter と nodestinationfilter がデフォルトで、チャネルのどちらの方向にもチャネルメールボックスフィルタが無効になります。

旧バージョンの channelfilter キーワードと nochannelfilter キーワードは、それぞれ destinationfilter と nodestinationfilter と同義です。

fileinto キーワードは、現在 ims-ms チャネルおよび LMTP チャネルに対してのみサポートされており、fileinto メールボックスフィルタ演算子が適用された場合、アドレスをどのように変更するかを指定します。ims-ms チャネルの場合、通常の使用方法は次のとおりです。

fileinto $U+$S@$D

上の例では、最初のサブアドレスの代わりに、フォルダ名をサブアドレスとして元のアドレスに挿入するように指定しています。

LMTP チャネルの場合、通常の使用方法は次のとおりです。

fileinto @$4O:$U+$S@$D

この $4O は、数字の 4 と大文字の O です。数字の 0 ではありません。

スパムフィルタのキーワード

キーワード: destinationspamfilterXoptin、sourcespamfilterXoptin

destinationspamfilterXoptin は、このチャネル宛のすべてのメッセージがフィルタリングソフトウェア X を介して実行されることを指定します。(フィルタリングソフトウェア X は、option.dat の spamfilterX_library で定義される。) キーワードのあとにはフィルタパラメータが続き、使用できるパラメータはフィルタ処理プログラムによって異なります。

sourcespamfilterXoptin は、このチャネルから発信されるすべてのメッセージがフィルタリングソフトウェア X を介して実行されることを指定します。(フィルタリングソフトウェア X は、option.dat の spamfilterX_library で定義される。) キーワードのあとにはシステム全体のデフォルトパラメータが続き、使用できるパラメータはフィルタ処理プログラムによって異なります。switchchannel が有効な場合、このキーワードは switched-to チャネルに入れられます。

これらのキーワードの使用方法の詳細については、「チャネルレベルのフィルタ処理を指定するには」を参照してください。

アドレス検証の後、かつアドレス拡張の前のルーティング

キーワード: aliasdetourhost

aliasdetourhost を使用すると、ホストしているユーザーの mailHost 属性値にソースチャネル固有の優先順位を与えられます。特に、aliasdetourhost は、ある種の処理のために別々のホストに送られるローカル (このシステムでホストされている) ユーザー宛のメッセージのルーティングにおいて「迂回経路」を確保するために一般的に使用されています。メッセージは元のホストで検証されて (アドレスが正しいローカルアドレスであるかどうか)、迂回経路で処理ホストに送信され、再び元のホストに返送されて拡張および配信されます。

aliasdetourhost は、よりよい設定を実現し、「中間フィルタ」タイプのチャネルおよびサードパーティーのフィルタリングホストを使用可能にします。aliasdetourhost は通常、代替変換チャネルに追加して使用されます。aliasdetourhost は、ローカル (このシステムでホストされている) ユーザー宛のルーティングに適用されますが、代替変換チャネルはリモートの受取人宛てのルーティングに適用されます。

aliasdetourhost の引数は、ホスト名またはドメイン名か、ホストおよびドメインの仕様です。(書き換えルールでは、ホスト名、IP リテラルアドレス、およびチャネルタグの処理が可能で、これらは黙示的にホスト名とみなされることに注意。) このキーワードをソースチャネルで指定すると、LDAP に保存されたアドレスのエイリアス展開が、メールホスト情報がチェックされるよりも前に (変換タグ情報の処理のあと) 停止します。このとき、メッセージは aliasdetourhost の値に送信されてアドレスの処理は正常に完了していますが、エイリアス展開は実行されておらず、なおかつアドレス検証は完了済みです。

変換チャネルのフィルタ処理に関するさまざまな問題を回避するための aliasdetourhost の使用例を次に示します。システムは、フロントエンド MTA とバックエンドメールストアから構成されているとします。ユーザーは、配信オプションを forward および mailbox に設定しています。MTA は、ウィルス/スパム防止システム用に代替変換チャネルを使用します。このユーザー宛てにメッセージが到着すると、MTA エイリアスは展開され、ローカルとリモートに受取人を 1 人ずつ作成します。リモートの受取人のコピーは直接送信されます。一方、ローカルの受取人のコピーは、変換チャネルに送信されてスキャンされ、返送されます。次に、2 回目のエイリアス展開が行われて、リモートの受取人に対して 2 つ目のコピーが作成され、ローカルの受取人のコピーは通常どおり配信されます。最終結果: リモートの受取人には 2 つのコピー、ローカルの受取人には 1 つのコピーが送信されます。

ローカルにホストされているユーザーに代替変換チャネルを使用せずに (ただし、場合によっては他の受取人に対して代替変換チャネルを使用して)、aliasdetourhost を使用するチャネルを使うと、次のことが可能になります。

メッセージの受け入れ
外部のスパム/ウィルスフィルタへのメッセージのルーティング
アドレス拡張および配信のためのメッセージの再受け付け

例 1:

MTA とは別のホストでサードパーティー製のスキャナが動作していると想定します。次の例では、偽の重複エントリを作成しなくてもユーザーエントリの転送が可能であり、なおかつメッセージを受け入れる前に受取人アドレスの検証を実行する機能は保持されています。

新しいチャネル tcp_scanner を作成します。

作成したチャネルに daemon キーワードを設定し、使用するフィルタ処理システムを指定します。さらに、チャネルに enqueue_removeroute を追加します。tcp_scanner チャネルは、imta.cnf 内で次のようになります。
tcp_scanner smtp mx single_sys subdirs 20 noreverse maxjobs 7 pool SMTP_POOL daemon my_a-v_filter.siroe.com enqueue_removeroute tcp_scanner-daemon

スキャンするすべてのソース tcp チャネルの tcp_local に aliasDetourHost tcp_scanner-daemon を追加します。スキャンの対象となる tcp チャネルには、tcp_local、tcp_submit、tcp_intranet、tcp_auth などがあります。次に、tcp_local と tcp_submit の例を示します。

! tcp_local
tcp_local smtp mx single_sys remotehost inner switchchannel
identnonenumeric subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver
maysaslserver saslswitchchannel tcp_auth missingrecipientpolicy 0
aliasdetourhost tcp_scanner-daemon
tcp-daemon

! tcp_submit
tcp_submit submit smtp mx single_sys mustsaslserver maytlsserver
missingrecipientpolicy 4 aliasdetourhost tcp_scanner-daemon
tcp_submit-daemon

aliasdetourhost の引数 (tcp_scanner-daemon) は、新しいチャネル tcp_scanner の正規のホスト名です。

スキャニングシステムから tcp_scanner チャネルを介して返送されるメッセージを受け入れるように、書き換えルールを作成します。

[1.2.3.4] $E$R$U[1.2.3.4]@tcp_scanner-daemon

1.2.3.4 は、スキャナシステムの IP アドレスです。

この書き換えルールを使用しない場合、メッセージはほかのいずれかの tcp* ソースチャネルを介して送信されます。すべてのメッセージには aliasdetourhost が含まれるため、メッセージは再びスキャンされて、ループが発生します。
設定をコンパイルしなおし、ディスパッチャを再起動します。
#imsimta cnbuild #imsimta restart dispatcher

例 2:

サードパーティー製のスキャナは MTA と同じホストで動作しているが、異なるポートで待機していると想定します。ポート 10024 でメールが受け入れられ、10025 に返送されるとします。

新しいチャネル tcp_scanner を作成します。

! tcp_scanner
tcp_scanner smtp nomx single_sys identnonenumeric subdirs 20 maxjobs 
7 pool SCAN_POOL daemon 127.0.0.1 port 10024 enqueue_removeroute
tcp_scanner-daemon

スキャンするすべてのソース tcp チャネルの tcp_local に aliasDetourHost tcp_scanner-daemon を追加します。スキャンの対象となる tcp チャネルには、tcp_local、tcp_submit、tcp_intranet などがあります。次に、tcp_local と tcp_submit の例を示します。

! tcp_local
tcp_local smtp mx single_sys remotehost inner switchchannel
identnonenumeric subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver
maysaslserversaslswitchchannel tcp_auth missingrecipientpolicy 0
aliasdetourhost tcp_scanner-daemon
tcp-daemon

! tcp_submit
tcp_submit submit smtp mx single_sys mustsaslserver maytlsserver
missingrecipientpolicy 4 aliasdetourhost tcp_scanner-daemon
tcp_submit-daemon

mappings ファイルに次のように追加して、tcp_scanner チャネルを経由して送信メールを再ルーティングします。
```
CONVERSIONS

in-chan=tcp_scanner;out-chan=*;CONVERT     No
in-chan=tcp_*;out-chan=tcp_local;CONVERT   Yes,Channel=tcp_scanner
```
SMTP_POOL の下の job_controller.cnf に、同時スキャン数の制限を追加します。

スキャニングソフトウェアにも制限が必要ですが、同時スキャン数と同じに設定して、メッセージングサーバーがメッセージを受け入れない場合にスキャナへのメール送信を試みないようにすることをお勧めします。
! [POOL=SCAN_POOL] job_limit=2 !
dispatcher.cnf に新しいサービスを追加して、特別なポートのスキャナから返されたメールを受け入れ、再びスキャンしないように tcp_scan を経由させて送信します。
! [SERVICE=SMTP_SCANNING] INTERFACE_ADDRESS=127.0.0.1 PORT=10025 IMAGE=IMTA_BIN:tcp_smtp_server LOGFILE=IMTA_LOG:tcp_smtp_server.log STACKSIZE=2048000 PARAMETER=CHANNEL=tcp_scanner !
設定をコンパイルしなおし、ディスパッチャを再起動します。
# imsimta cnbuild # imsimta restart job_controller # imsimta restart dispatcher

非請求の SMTP 拡張のサポート

キーワード: sourcenosolicit および destinationnosolicit

Internet Draft の draft-malamud-no-soliciting-07.txt に記述されている NO-SOLICIT SMTP 拡張は、プロポーズドスタンダードとして Messaging Server に実装されています。この機能を制御するためには、次のチャネルキーワードが使用できます。

sourcenosolicit は、このチャネルから送信されたメール内でブロックされる請求フィールドの値のコンマ区切りの一覧を指定します。値の一覧は、NO-SOLICIT EHLO 応答に表示されます。値にはグローバルな形式のワイルドカードを使用できますが、ワイルドカードを含む値は EHLO 通知には表示されません。

destinationnosolicit は、このチャネルのキューに入れられたメール内で受け入れられない請求フィールドの値のコンマ区切りの一覧を指定します。

不正な `RCPT TO` アドレスに制限を設定する

キーワード: deferralrejectlimit

1 つのセッション中に許可される不正な RCPT TO: アドレス数を制限します。指定した数の To: アドレスが拒否されると、続くすべての受取人は、正しいものも不正なものも 4xx エラーとして拒否されます。ALLOW_REJECTIONS_BEFORE_DEFERRAL SMTP チャネルキーワードと同じ機能が提供されますが、この場合はチャネル単位です。