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

SMTP リレーブロッキングを設定する

アクセス制御マップを使うことによって、Messaging Server システムが SMTP メールのリレーに利用されるのを防ぐことができます。たとえば、ユーザーのメールシステムを利用して何百、何千ものインターネットメールボックスにジャンクメールをリレーしようとする不正操作を阻止できます。

Messaging Server のデフォルトでは、ローカルの POP ユーザーおよび IMAP ユーザーによるリレーを含むすべての SMTP リレー操作が防止されます。

不正なリレーをブロックする一方、正しいローカルユーザーによるリレーを許可するには、2 つのクラスのユーザーを識別するように Messaging Server を設定する必要があります。たとえば、POP または IMAP を使用するローカルユーザーの場合、SMTP リレー操作は Messaging Server に依存しています。

SMTP リレーを阻止するには、次に示すいずれかの操作を行う必要があります。

内部のホストとクライアントによる SMTP リレーを可能にするには、INTERNAL_IP マッピングテーブルに「内部」IP アドレスまたはサブネットを追加します。

MTA による内部メールと外部メールの識別方法

メールのリレー操作をブロックするためには、まず、メールが同じサイトで発信された内部メールなのか、インターネットからシステムを経由して再びインターネットに戻っていく外部メールなのかを MTA が識別できなければなりません。そして、前述のクラスを許可し、後述のクラスをブロックする必要があります。この識別は、受信用 SMTP チャネルの switchchannel キーワードを使うことで実現できます。通常、このチャネルは tcp_local であり、デフォルトで設定されています。

switchchannel キーワードは、SMTP サーバーが着信 SMTP 接続の実際の IP アドレスを調べるようにするものです。この IP アドレスは、Messaging Server によって、ドメイン内の SMTP 接続とドメイン外の接続とを識別するために書き換えルールとともに使用されます。その後、この情報は、内部と外部のメッセージトラフィックを分離するために使用されます。

次に説明している MTA 設定では、デフォルトで、サーバーが内部と外部のメッセージトラフィックを識別できるように設定されています。

この設定ファイルでは、ローカルチャネルの直前に defaults チャネルおよび noswitchchannel キーワードを追加します。
! 最終的な書き換えルール defaults noswitchchannel ! ローカルストア ims-ms ...
着信 TCP/IP チャネルを変更し、switchchannel および remotehost キーワードを指定します。次に例を示します。
tcp_local smtp single_sys mx switchchannel remotehost TCP-DAEMON
着信 TCP/IP チャネル定義のあとに、同様の新しいチャネルを別の名前で追加します。次に例を示します。
tcp_intranet smtp single_sys mx allowswitchchannel routelocal tcp_intranet-daemon
routelocal チャネルキーワードを指定すると、アドレスをチャネルに書き換える際に、MTA はこのチャネルを介してアドレスのすべての明示的ルーティングを「短絡化」しようとします。これにより、明示されたソースルートアドレスを経由した内部 SMTP ホストのループによるリレー試行がブロックされます。

これらの設定により、ドメイン内で生成された SMTP メールは tcp_internal チャネルから入ってくるようになります。それ以外の SMTP メールは、tcp_local チャネルから入ってきます。したがって、メールが入ってくるチャネルに基づいて内部と外部のメールが識別されます。

この設定はどのように機能するのでしょうか。ここでもっとも重要な要素は switchchannel キーワードです。キーワードは、tcp_local チャネルに適用されます。このキーワードにより、SMTP サーバーにメッセージが入ってくると、サーバーが着信接続のソース IP アドレスを調べるようになります。サーバーは、着信接続のリテラル IP アドレスのリバースポインティングのエンベロープ書き換えを試行し、関連するチャネルを探します。ソース IP アドレスが INTERNAL_IP マッピングテーブル内の IP アドレスまたはサブネットと一致する場合は、そのマッピングテーブルを呼び出す書き換えルールによってアドレスが tcp_intranet チャネルに書き換えられます。

tcp_internal チャネルは allowswitchchannel キーワードでマークされているため、メッセージは tcp_internal チャネルに切り替えられて、そのチャネルから入ってきます。IP アドレスが INTERNAL_IP マッピングテーブルにないシステムからメッセージが入ってくる場合、リバースポインティングのエンベロープ書き換えは、tcp_local チャネルあるいはその他のチャネルに対して書き換えを行います。ただし、tcp_internal チャネルに対する書き換えは行われません。それ以外のチャネルはデフォルトで noswitchchannel とマークされているため、メッセージは別のチャネルに切り替えられず、tcp_local チャネルのまま処理されます。

注 –

「 tcp_local」という文字列を使用するマッピングテーブルまたは変換ファイルのエントリは、必要に応じて「tcp_* 」または「tcp_intranet」に変更する必要がある場合があることに注意してください。

認証ユーザーのメールを識別する

サイトには、物理的にネットワークの一部ではない「ローカル」のクライアントユーザーが存在することがあります。これらのユーザーがメールを送信すると、メッセージの送信は外部 IP アドレス (任意のインターネットサービスプロバイダ (ISP) など) から入ってきます。ユーザーが SASL 認証を処理できるメールクライアントを使用している場合には、外部接続と認証接続とを識別できます。その結果に基づいて、認証ユーザーによる送信を許可し、認証されていないユーザーによるリレー送信試行を拒否できます。認証されているかどうかに基づく接続の識別は、受信用 SMTP チャネル (通常、tcp_local チャネル) に saslswitchchannel キーワードを使うことで実現できます。

saslswitchchannel キーワードはチャネルの切り替え先を示す引数をとり、SMTP の差出人が認証されると、送信メッセージが指定した切り替え先チャネルから入ってくるようになります。

認証ユーザーによる送信であるかどうかを識別するには

手順

設定ファイルに新しい TCP/IP チャネル定義を別の名前で追加します。次に例を示します。

tcp_auth smtp single_sys mx mustsaslserver noswitchchannel TCP-INTERNAL

このチャネルでは、通常のチャネル切り替えは行われません。それよりも前のデフォルト行で、noswitchchannel が明示的あるいは暗黙に指定されているはずです。このチャネルには mustsaslserver が必要です。

次の例のように、maysaslserver と saslswitchchannel tcp_auth を追加することにより、tcp_local チャネルを変更します。
tcp_local smtp mx single_sys maysaslserver saslswitchchannel \ tcp_auth switchchannel |TCP-DAEMON
この設定では、ローカルのパスワードによって認証が可能なユーザーが送信した SMTP メールは tcp_auth チャネルから入ってくるようになります。認証されていない SMTP メールが内部ホストから送信された場合、そのメールは tcp_internal から入ってきます。それ以外の SMTP メールは、すべて tcp_local から入ってきます。

メールのリレーを防止する

この例では、承認されていないユーザーがシステムを介して SMTP メールのリレーを行えないようにします。まず、ローカルユーザーによる SMTP メールのリレーは許可することを念頭におきます。たとえば、POP ユーザーおよび IMAP ユーザーは、メールの送信に Messaging Server を使います。ローカルユーザーには、メッセージが内部 IP アドレスから入ってくる物理的なローカルユーザーのほか、ローカルユーザーとして認証され得るリモートユーザーも含まれます。

サーバーにおけるリレーを阻止しなければならないのは、不特定多数のインターネット利用者からのメッセージです。あとの節で説明する設定では、これらのユーザークラスを識別して特定のクラスだけをブロックできます。特に、tcp_local チャネルから入り、同一のチャネルから出るメールをブロックします。そのためには、ORIG_SEND_ACCESS マッピングテーブルを使用します。

ORIG_SEND_ACCESS マッピングテーブルは、ソースチャネルと宛先チャネルに基づいてトラフィックをブロックするために使用できます。ここでは、tcp_local チャネルから入り、同一チャネルから出るトラフィックをブロックします。これは、次の ORIG_SEND_ACCESS マッピングテーブルで実現できます。

ORIG_SEND_ACCESS

   tcp_local|*|tcp_local|*        $NRelaying$ not$ permitted

この例では、メッセージが tcp_local チャネルから入り、同一のチャネルから出ることは許可されないことを示しています。つまり、このエントリを使用すると、外部からのメールを SMTP サーバーで中継してインターネットに転送する処理を禁じることができます。

SEND_ACCESS マッピングテーブルではなく ORIG_SEND_ACCESS マッピングテーブルを使用するのは、ims-ms チャネルに元々一致するアドレスにブロックを適用するのではないからです (アドレスは、エイリアスまたはメーリングリストの定義を介して展開し、外部アドレスとなることがあるため)。SEND_ACCESS マッピングテーブルでは、外部の利用者が外部ユーザーに展開するメーリングリストにメールを送信したり、外部アドレスにメッセージを転送するユーザーにメールを送信したりできるようにするのは困難です。

SMTP リレーブロッキングの RBL チェックを含む DNS 検索を使用するには

Messaging Server には、配信や転送のために受け入れたすべてのメールが、有効な DNS 名を持つアドレスから送信されたものであるかどうかを確認するさまざまな方法があります。もっとも簡単な方法は、tcp_local チャネルに mailfromdnsverify チャネルキーワードを割り当てることです。

また、Messaging Server には、dns_verify というプログラムが用意されています。このプログラムを使うと、配信や転送のために受け入れたすべてのメールが、次に示す ORIG_MAIL_ACCESS のルールを使った有効な DNS 名を持つアドレスから送信されたものであるかどうかを確認することができます。

ORIG_MAIL_ACCESS

  TCP|*|*|*|*|SMTP|MAIL|*|*@*|*|*  \
$[msg_svr_base/lib/dns_verify.so,  \
dns_verify,$6|$$y|$$NInvalid$ host:$ $$6$ -$ %e]

上の例に示されている改行記号は、このようなマッピングエントリの構文において非常に重要なものです。円記号は、その行が次の行に続いていることを意味しています。

また、もう 1 つの UBE 対策として、dns_verify イメージを使用し、着信接続を RBL (Realtime Blackhole List)、MAPS (Mail Abuse Prevention System)、DUL (Dial-up User List)、ORBS (Open Relay Behavior-modification System) などのリストに対してチェックすることができます。また、新しい mailfromdnsverify キーワードの場合と同じように、dns_verify 呼び出しを行わなくてもこれらのチェックを実行できる簡単な方法があります。それは dispatcher.cnf ファイルで DNS_VERIFY_DOMAIN オプションを使用する方法です。たとえば、[SERVICE=SMTP] セクションで、オプションのインスタンスをチェック対象のリストに設定します。

[SERVICE=SMTP]
PORT=25
! ...通常のオプションの残りの部分...
DNS_VERIFY_DOMAIN=rbl.maps.vix.com
DNS_VERIFY_DOMAIN=dul.maps.vix.com!
...など...

この場合、メッセージは SMTP レベルで拒否されます。つまり、メッセージは SMTP ダイアログの間に拒否されることになり、MTA に送信されることはありません。この方法の短所は、内部ユーザーからのメッセージを含む、通常の SMTP 着信メッセージすべてに対してチェックが行われるということです。このため効率が下がり、インターネット接続が切断された場合に問題が発生することがあります。別の方法として、PORT_ACCESS マッピングテーブル、または ORIG_MAIL_ACCESS マッピングテーブルから dns_verify を呼び出す方法があります。PORT_ACCESS マッピングテーブルでは、最初の 1 つまたは複数のエントリに対してローカルの内部 IP アドレスまたはメッセージ送信者のチェックを行わないようにし、あとの方のエントリでほかのすべてに対して目的のチェックを行うようにすることができます。また、ORIG_MAIL_ACCESS マッピングテーブルでは、tcp_local チャネルで受信するメッセージのみをチェックする場合、内部システムやクライアントからのメッセージに対するチェックを省略することになります。次に、dns_verify へのエントリポイントを使用した例を示します。

PORT_ACCESS

! 内部接続を無条件で許可する
  *|*|*|*|*  $C$|INTERNAL_IP;$3|$Y$E
! RBL リストに対するほかの接続をチェックする
   TCP|*|25|*|*  \
$C$[msg_svr_base/lib/dns_verify.so,\
dns_verify_domain_port,$1,rbl.maps.vix.com.]EXTERNAL$E


ORIG_MAIL_ACCESS 

  TCP|*|25|*|*|SMTP|*|tcp_local|*@*|*|*  \
$C$[msg_svr_base/lib/dns_verify.so,\
dns_verify_domain,$1,rbl.maps.vix.com.]$E

DNS ベースデータベースのサポート

dns_verify プログラムは DNS ベースのデータベースをサポートします。このデータベースは、不特定多数宛のメールを送る可能性のある着信 SMTP 接続を判別するために使われます。一般に利用可能な DNS データベースの一部には、通常はこの目的のために使われる TXT レコードが含まれていません。その代わりに、A レコードが含まれています。

標準の設定では、特定の IP アドレスの DNS にある TXT レコードには、メッセージを拒否するときに SMTP クライアントに返すためのエラーメッセージが含まれています。しかし、TXT レコードがなく、A レコードがある場合、Messaging Server 5.2 より前のバージョンの dns_verify は「No error text available」というメッセージを返していました。

現在、dns_verify は、TXT レコードを利用できないイベントで使われるデフォルトのテキストを指定するオプションをサポートしています。たとえば、次の PORT_ACCESS マッピングテーブルは、このオプションを有効にする方法を示しています。

PORT_ACCESS 

   *|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E  \
   TCP|*|25|*|*   \
$C$[<msg_svr_base/lib/dns_verify.so \
,dns_verify_domain_port,$1,dnsblock.siroe.com,Your$ host$ ($1)$ \
found$ on$ dnsblock$ list]$E 
    * $YEXTERNAL

この例では、リモートシステムがドメイン dnsblock.siroe.com 内のクエリーで見つかっても、TXT レコードが利用できない場合は、「Your host a.b.c.d found on dnsblock list」というメッセージが返されます。