Postfix スパムフィルターの設定 - Ubuntu Dapper, MailScanner, SpamAssassin, Razor, Pyzor, DCC, ClamAV

2.3 Postfix アンチスパム設定

前提条件:

クライアント（私たちにメールを送信しようとしているコンピュータ）が Postfix に接続し、通信セッションを開始すると、Postfix はそのセッションに関する情報を記録します。Postfix がそのセッションからのメールを配信のために受け入れる前の時点で、セッションを評価し、main.cf にいくつかの制限を設定することでメールを拒否するオプションがあります。このリンクは、典型的な SMTP セッション中に何が起こるかを示しています: http://helpdesk.islandnet.com/pep/smtp.php。以下の制限は、いくつかのスパムを防ぎ、私たちのシステムがオープンリレーになるのを防ぐのに役立ちます。これらの制限により、Postfix は「玄関」でいくつかのメールを拒否します。これにより、メールは私たちのシステムに入らず、MailScanner（その後 SpamAssassin によって）によってスキャンされることがないため、システムリソースを節約できます。これは良い面と悪い面があります。システムリソースを節約しますが、拒否されたメールを見ることもできません。あなたが見ることができるのは、基本的に「こんにちは、IP アドレス X.X.X.X の「xxxxxxxx」という名前のメールサーバーがメールを送信しようとしましたが、ルール XYZ に違反したため、私はそれを拒否しました」という内容の Postfix のログエントリが1つか2つだけです。これはスパムである可能性があります（スパマーはしばしば目標を達成するために RFC に従わないことを意図的に行います）が、もしそれが「正当な」メールであった場合、例えば顧客の IT 部門が単にメールサーバーを誤設定している場合（これはよくあることです）、あなたは少し困った状況に直面するかもしれません。

私たちに宛てられたすべてのメールを玄関から受け入れ、したがって MailScanner/SpamAssassin にシステム内のすべてのスパム制御を処理させたい場合は、以下の設定のいくつかを変更する必要があります。私は個人的に、Postfix と SpamAssassin のアンチスパム制御の組み合わせが最良だと考えています。少なくとも、Postfix の組み込みのデフォルトのアンチリレー制御（smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination）を無効にしないことを確認する必要があります。

以下の設定は実際には非常に保守的であり、ほとんどのメールが玄関から入ることを許可し、MailScanner と SpamAssassin がそれに対処できるようにします。私にとっては、これにより（安全に）私のユーザー向けのメールの約 35% が拒否されるので、これらの設定は非常に価値があると思います。私はこのアプローチを始めることをお勧めします。追加の制限を追加すると、不適切に構成されたコンピュータからの有効なメールを拒否する可能性が高くなります。将来的に権限/制限を追加または削除することを決定した場合は、一度に1つずつ行い、変更の影響を評価するための十分な時間を確保してください。これらの制限がどのように機能するかを十分に理解してから、以下のエントリを変更することを強くお勧めします。他のことの中で、これを間違えると正当なメールを拒否したり、私たちがオープンリレーになる原因となる可能性があります。制限は常に制限するわけではなく、一部は許可することもあります。

これらの設定をよりよく理解したい場合は、良いリソースは http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt, http://www.postfix.org/SMTPD_ACCESS_README.html, http://www.securitysage.com/antispam/, やや古い（2001年） http://www.mengwong.com/misc/postfix-uce-guide.txt, そしてこの優れた本です。私がこれらと同じ設定をいくつかしか使用していないことに注意してください。したがって、この構成は制限的ではありません。SpamAssassin と MailScanner が少し後に登場し、スパムを認識し操作するためのはるかに柔軟で構成可能なオプションを提供することを考慮してください。

2.3.1 smtpd_helo_required

接続しているメールサーバーに適切な smtp “ハンドシェイク” を行い、その名前を発表させます。インターネット RFC はこれを要求しているので、私たちもそうします。

postconf -e "smtpd_helo_required = yes"

前置き: Postfix の制限段階は次のとおりで、次の順序で処理されます:

smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions
smtpd_data_restrictions

私たちは最後の 3 つの制限段階にのみエントリを置きます。制限段階は、main.cf にリストされている順序に関係なく、この順序で処理されます。

2.3.2 smtpd_sender_restrictions

この制限段階は、このシステムが MAIL FROM: コマンド（エンベロープ送信者）で受け入れる送信者アドレスを制限します。この制限段階に 3 つのテスト（制限）を置きます。

制限段階は制限（テスト）のリストを保持します。通常、テストは DUNNO、REJECT、または OK に評価されます。DUNNO は「どうすればよいかわからない、次のテストに決めさせる」という意味です。REJECT は単にメールを拒否します。OK は、この制限段階でのテストがこれ以上実行されず、テストが次の段階（あれば）に進むことを意味します。Reject* タイプのテストは通常 REJECT または DUNNO に評価されます。Permit タイプのテストは通常 OK または DUNNO に評価され、check__access タイプのテストはさまざまなアクションを実行できます。図は基本的な論理を示しています。

         SMTP セッション
             |
             V
制限段階-------------
  テスト ---------------REJECT->
  |   \
  |    DUNNO
  |     \
  |      V
  |   次のテスト------REJECT->
  |      |   \
  OK     OK   DUNNO
  |      |     \
  |      |      V
  V      V
  次の制限段階------->

2.3.2.1 check_sender_access

http://www.postfix.org/access.5.html を参照してください。ここでは、Postfix にエンベロープ送信者を /etc/postfix/sender_access データベースのエントリと比較し、一致が見つかった場合にそれらのエントリに基づいてアクションを実行するように依頼します。また、送信者ごとにどのアクションが取られるか（OK、DUNNO、REJECT など）を定義します。送信者がファイルにリストされていない場合、テストは DUNNO に評価され、次のテストが実行されます。このファイルの使用の一例は、メールを受信したくない送信者（メールアドレス、ドメイン、ネットワークアドレスなど）のリストを配置することです（ブラックリスト化します）。MailScanner と SpamAssassin でも送信者をブラックリスト化することができますが、ここでブラックリスト化することでリソースを節約できます。また、このファイルを使用して、特定の送信者がこの制限段階の次の 2 つのテストをバイパスできるようにします。ここで OK を与えれば、この制限段階でのテストはこれ以上実行されず、テストは次の制限段階（smtpd_recipient_restrictions）に進みます。ここでこの設定を smtpd_recipient_restrictions 制限段階の reject_unauth_destination テストの前に置いた場合、誰かに OK を与えた場合、そこにある reject_unauth_destination テストはバイパスされます。これは悪いことであり、OK を与えた誰でも私たちのサーバーをオープンリレーとして使用できるようになります。アクセス制限は、リストした順序で評価され、一致が見つかると、さらに制限がどのように（または、評価されるか）に影響を与えます。

2.3.2.2 reject_non_fqdn_sender

エンベロープ送信者のメールアドレスが適切な形式でない場合に拒否します。エンベロープ送信者は、SMTP セッション中に送信メールサーバーが「MAIL FROM:」行に提供するものであり、ヘッダーの「From:」行ではありません。「Joe」は私たちにメールを送信することは許可されていません（「Joe」に返信できないため）が、「[email protected]」は少なくともメールアドレスです。この時点で送信者が拒否されない場合、このテストは「DUNNO」に評価されます。

2.3.2.3 reject_unknown_sender_domain

エンベロープ送信者のメールアドレスのドメイン部分に DNS の「A」または「MX」レコードがまったくない場合に拒否します。この設定は、私のメールサーバーに入ってくるメールの約 35% を排除します。スパマーは、拒否されたメールの反発に対処しなくて済むように、偽のドメイン名を使用することが一般的です。また、送信者のドメインが存在しないために配信できないバウンス通知でキューが埋まることを避けることが重要です。送信者のドメインに「A」または「MX」レコードがある場合、このテストも「DUNNO」に評価されます。時折、あなたが受信したいメールを送信している誰かがこの設定によって拒否されたという報告を見ることがあります。この可能性のある原因は、正当な送信者が意図的に偽のドメイン名を使用して、あなたが彼らに返信しないようにすることです。ここで送信者アクセスリストが役立ちます。ここで OK を与えれば、このテストはバイパスされます。

これらの 3 つの制限を実装するには:

postconf -e "smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access, reject_non_fqdn_sender, reject_unknown_sender_domain"

2.3.3 smtpd_recipient_restrictions

Postfix SMTP サーバーが RCPT TO: コマンドの文脈で適用するアクセス制限。これは、SMTP セッション中にクライアントが「RCPT TO:」行に提供した「エンベロープ受信者」を指し、ヘッダーの「To:」行ではありません。smtpdrecipient_restrictions は、特定の制限のリストを保持する別の制限段階です。smtpd_recipient_restrictions の前に評価される他の制限段階は、smtpd_client_restrictions、smtpd_helo_restrictions、smtpd_sender_restrictions（その順序）です。通常、これらの前の制限段階に配置される制限は、代わりに smtpd_recipient_restrictions に配置できます。したがって、一部の人々は、通常は前の制限段階に配置されるすべての smtpd*_restrictions を smtpd_recipient_restrictions に（適切な順序で）配置し、前の段階を未設定（空）にすることを好みます。私たちの場合、smtpd_sender_restrictions と smtpd_recipient_restrictions を使用する方が安全です。smtpd_recipient_restrictions に配置する特定の制限（テスト）を見てみましょう:

2.3.3.1 permit_mynetworks

“mynetworks” にリストされたマシンがこの制限段階の残りのテストをスキップできるようにします（permit = OK）。言い換えれば、これはこの段階を終了し、次の段階（smtpd_data_restrictions）でテストされます。permit_mynetworks が reject_unauth_destination の前に配置されているため、$mynetworks にあるマシンは任意のドメインにメールを中継することが許可されます。これがなければ、私たちは自分のドメインにのみメールを送信できることになります。送信者の IP アドレスが $mynetworks にリストされていない場合、テストは「DUNNO」に評価され、次のテスト（reject_unauth_destination）に進みます。

2.3.3.2 reject_unauth_destination

これは、permit_mynetworks とともにリレー制御に使用されます。この設定は、本質的に、私たちがメールを受け入れるように構成していない任意のドメインに宛てられたメールは拒否されることを意味します。私たちの場合、Postfix は以前に構成した relay_domains 設定（またはテーブル）を使用して、それらのドメインが何であるかを判断します。詳細については http://www.postfix.org/postconf.5.html#reject_unauth_destination を参照してください。ドメインが relay_domains にリストされている場合、このテストは「DUNNO」に評価され、セッションは次のテスト（あれば）に進むことが許可されます。「mynetworks」と同様に、この設定は非常に重要です。permit_mynetworks を reject_unauth_destination のすぐ前に配置することで、私たちは自分たちのドメイン以外のドメインにメールを送信できることを保証しますが、私たちのネットワーク外のコンピュータから私たちに宛てられたメールのみを受け入れることになります。したがって、permit_mynetworks と reject_unauth_destination はチームとして機能します。

2.3.3.3 reject_unauth_pipelining

パイプラインを使用して配信を加速しようとするバルクメール送信者を拒否しますが、最初にサポートされているかどうかを確認しません（非 RFC、スパマーの間で一般的です）。

これらの 3 つの制限を実装するには:

postconf -e "smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining"

2.3.4 smtpd_data_restrictions

SMTP DATA: コマンドの文脈で Postfix SMTP サーバーが適用するオプションのアクセス制限。smtpd_recipient_restrictions と同様に、これは制限段階です。

2.3.4.1 reject_unauth_pipelining

smtpd_recipient_restrictions に配置されると常に効果的でないため、smtpd_data_restrictions にこの設定を繰り返します。私はこれを smtpd_recipient_restrictions に含めます。ポリシーサーバーの前に配置したいからです。smtpd_data_restrictions をうまく活用する制限はわずかです。

postconf -e "smtpd_data_restrictions = reject_unauth_pipelining"

2.3.5 Postfix コンテンツフィルタリング制御ファイル:

http://www.postfix.org/header_checks.5.html - /etc/postfix/header_checks と /etc/postfix/body_checks

これらのファイルは、特定の「文字列」をリストし、Postfix にこれらの文字列がメールヘッダーやメッセージの本文に出現した場合に何をするかを指示します。サンプルファイルはすでに作成されており、何を入れるべきかを説明するコメントがあります。あなたの自由に編集できます。これらのファイルは「正規表現形式」を使用する必要があることに注意してください。「regexp」は、*nix の世界で生きるために学ぶべきものです。いつか本を手に入れるか、ネットで調べてみてください。態度のある誰かからの詳細な header_checks ファイルの例を見たい場合は、http://www.geekounet.org/filters/header_checks を見てください。しかし、盲目的にこれに従わないでください。これはあくまで例です！以下は body_checks ファイルの例です: http://www.securitysage.com/files/body_checks。あなたが自由な時間を持っているときに http://www.securitysage.com/guides/postfix_uce.html をチェックする価値があります。特に http://www.securitysage.com/antispam/hedchek.html と http://www.securitysage.com/antispam/bodchek.html を見てください。Postfix のどの部分にも多くの変更を加えることはお勧めしません。影響を評価するための十分な時間を与えずに行うべきではありません。亀のように、ゆっくりと、長生きしましょう。

2.3.5.1 header_checks & body_checks

これらの 2 つを main.cf に追加しましょう。header_checks は、MailScanner が機能するためにすべての受信メールを保持できるようにするために必要です:

postconf -e "header_checks = pcre:/etc/postfix/header_checks"  

postconf -e "body_checks = pcre:/etc/postfix/body_checks"

header_checks を編集:

vi /etc/postfix/header_checks

header_checks ファイルにこの行を追加します。これがないと MailScanner は機能しません:

/^Received:/ HOLD

pcre タイプのテーブルを postmap する必要はありません。これらはプレーンテキストのままで、Postfix はそれらを「そのまま」使用します。

mime_header_checks と nested_header_checks を header_checks と body_checks とともに構成することもできます。Postfix でコンテンツフィルタリングを行う際に（header_checks と body_checks を使用して）あまりにも創造的になると、パフォーマンスに大きな影響を与える可能性があります。

2.3.5.2 /etc/postfix/sender_access http://www.postfix.org/access.5.html

私たちは smtpd_sender_restrictions でこのファイルを参照しました。このファイルを使用して、玄関で送信者をチェックします。このファイルでは、特別な処理のために特定の送信者/ドメイン/IP アドレス範囲をリストします。以下は偽の例です。あなたが見合ったものを作成してください。詳細については /etc/postfix/sender_access をお読みください。このファイルはさまざまな目的で使用できますが、smtpd_sender_restrictions での設定方法を考慮すると、送信者をブラックリスト化するか、特定の送信者が smtpd_sender_restrictions の残りのテストをバイパスできるようにすることをお勧めします。

vi /etc/postfix/sender_access

#例の送信者アクセスマップファイル
[email protected] 550 MLM は必要ありません
allspam.tld 550 スパムは受け付けていません
badguy.net REJECT
[email protected] REJECT
newsletter-favorite-lug.org OK
my-really-l337-test-domain.com OK

これはハッシュテーブルなので、通常通り postmap する必要があります:

postmap /etc/postfix/sender_access

2.3.6 Postfix インストールの最終確認

変更を確認:

less /etc/postfix/main.cf

ファイルの内容にエラーがないか確認し、必要に応じて修正します。Postfix を起動します:

postfix start

Postfix が応答するか確認します:

telnet 127.0.0.1 25

次のように表示されるはずです:

220 [yourFQDNhere] ESMTP Postfix (Ubuntu)

[enter] を数回押し、quit と入力して終了します。

このように応答しない場合は、別のターミナルウィンドウを開いて Postfix を停止します: postfix stop。newaliases と上記のすべての postmap コマンドを実行したことを確認してください。main.cf と master.cf のすべての設定を確認してください。Postfix のトラブルシューティングに関する良い論文は http://www.postfix-book.com/debugging.html にありますが、私たちのシステムはこの時点でメールを中継する準備ができていないことに注意してください（それはキューに入ります）。

master.cf または main.cf に変更を加えたり、データテーブルに変更を加えたりするたびに、ほとんど（すべてではありません）の場合、Postfix をリロードする必要があります:

postfix reload

基本的な Postfix 構成ができたので、http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall と http://www.postfix.org/BASIC_CONFIGURATION_README.html は、私たちが使用した設定のいくつかをよりよく理解するための良い場所であり、この時点でこれらの README はより意味を持つでしょう。

デフォルトでは、私たちの Postfix は chroot されています。これが何を意味するのか知らない場合、この時点ではあまり重要ではありません。chroot が何を意味するのかを後で調べることをお勧めします。Postfix が正常に動作するために必要なシステムファイルのいくつかは、インストール中に Postfix の chroot 刑務所（/var/spool/postfix）にコピーされました。時折、元のファイルが変更され、Postfix は持っているコピーが元のものと同じではないと不満を言います。この場合、Postfix が不満を言ったファイルを手動で chroot 刑務所にコピーするか、Postfix ソースコードに付属のスクリプト（LINUX2 と呼ばれる）を実行して、Postfix が必要とするすべてのファイルを再度必要な場所にコピーすることができます。

cd /usr/local/src/postfix-2.3.3/examples/chroot-setup  
postfix start  
chmod +x LINUX2  
cp LINUX2 /usr/bin  
LINUX2  
cd  
postfix check

これにより、LINUX2 スクリプトが実行可能になり、パス内のディレクトリにコピーされ、実行されます。LINUX2 は通常、Postfix が構成ファイルやディレクトリにアクセスする際のログのエラーを解決します。

Postfix スパムフィルターの設定 - Ubuntu Dapper, MailScanner, SpamAssassin, Razor, Pyzor, DCC, ClamAV - ページ 3