$B%a!<%k%5!<%P$G9T$J$&%9%Q%`BP:v(B

======================================================================
Part4 迷惑メイルからの保護
======================================================================

管理者にとって、メイルサーバは最初に設置するまでの苦労は計り知れず大きい。
その分、一度うまく動いてしまえば安定したサービスであるだけに日常の管理の
手間は小さい類であろう。しかし、メイルサーバが正常稼動し続けていると、こ
のような苦情が届き始めるだろう。

  「ねえねえ、最近やたらスパムが多いんだけど、何とかなんない?」

実際問題として、既に迷惑メイルはSMTPの大半を占めている。一般ユーザとして
メイルを読む時間の半分以上をスパムの選別に費やし、管理者としてLAN内の管
理不徹底のPCに感染したウィルス除去作業に追われて一日を無駄にした。そんな
「被害者」は日々増え続けている。Part4では電子メイルを脅かすインターネッ
トの「現代病」ともいえる迷惑メイルから自サイトを守る方法を紹介していこう。


■
■ 迷惑メイル対策
■

●電子メイルの危機

「便利な道具」はわれわれの生活上の労力を軽減してくれる。それと同時に、悪
事を働く人間の労力をも軽減する。電子メイルはその最たるもので、今や「必要
とされて受信されているメイル」よりも「不特定多数に送られる受け取りたくな
い迷惑メイル」のほうが比率が大きいという悲しい状況になっている。

そのせいで「目を通さなければ行けないメイル」が大量の迷惑メイルに埋もれて
見落しやすくなり、円滑なコミュニケーションを阻害されるほどになっている。
ここでは、迷惑メイルを

  * UBE(Unsolicited Bulk Email; 望まれないemail)いわゆるspam
  * ウィルスに感染したWindows-PCがばらまくウィルス
    (ここではワームも同分類とする)

の2つに分けて、それぞれに効果的な「受け取り拒否対策」を考えよう。

●「消防署の方から来ました」

  あなたの家の呼び鈴が鳴った。どなたですかと尋ねたら、

	「消防署の方から来ました○×です」

  と返事があった。あなたはドアを開けるだろうか。賢明な人なら、絶対に開け
  ない。消防署の「方から」と名乗ったらそれは消火器の押し売り、ということ
  は前提知識として持っているだろう。消火器に限らず、ドアを開ける前に撃退
  できる押し売りはいくらでもある。ドアは一度開けてしまったら、それを断っ
  て帰させるのにかなりの精神力を浪費する。

  全く同じことが迷惑メイルにも言える。相手がどのように名乗ったかを調べる
  だけで、それが受け取りたいものか、迷惑メイルなのかの判別がほとんど可能
  である。迷惑メイルの氾濫している現在では、その99%がドアを開ける前、つ
  まりSMTPセッションの本文を受け取る前の段階でそれと判別できる。

●迷惑メイル対策の種類

対策を考える前に、現在のSMTPの仕組みを簡単に理解しておく必要がある。迷惑
メイルであるなしにかかわらず、全ての電子メイルはSMTPを経て届けられる。

  +--+                                             +--+
  |ク|  (1)HELOの送出				   |受|
  |ラ|       「HELO mail.example.com」         →  |信|
  |イ|  ← 「250 ok」 (応答コード)		   |サ|
  |ア|  (2)envelope-fromの送出			   |｜|
  |ン|       「MAIL FROM: 」 →  |バ|
  |ト|  ← 「250 ok」				   |  |
  |  |  (3)Recipient addressの送出		   |  |
  |  |       「RCPT TO: 」   →  |  |
  |  |  ← 「250 ok」				   |  |
  |  |  (4)データ送出宣言			   |  |
  |  |       「DATA」			       →  |  |
  |  |  ← 「354 ok」				   |  |
  |  |  (5)メッセージ本体の送出			   |  |
  |  |        ヘッダと本文全体を送出後	       →  |  |
  |  |        ピリオドのみの行を送出		   |  |
  |  |  ← 「250 ok」			       →  |  |
  +--+                                             +--+

SMTPではメッセージ本体を送出する前に、クライアント側から3つのパラメータ
を送信する。クライアント識別名(HELO)、実際の送信者のアドレス(MAIL FROM)、
実際の受信者のアドレス(RCPT TO)である。


同じ「迷惑メイル」でもspamとウィルス類は送信主体と手段が大きく異なる。
spamは元々悪意を持った者が大量のメッセージを組織的に送りつけて来る。この
ような行為が禁止されていることを彼等も知っているので、メイル送信時に、彼
等の身元が明らかになるような設定はしない。裏を返していえば、身元を隠した
り、偽造したりしているクライアントはspamであるか、あるいは少なくとも受け
取る価値のないメイルであるという判断が下せる。つまり、SMTP接続の3パラメー
タと、クライアントのIPアドレスといった外観的要素によって受信拒否の判定を
下すことができる。

いっぽう、ウィルス類は悪意のない一般利用者のPCがある意味「乗っ取られ」、
その利用者の常用しているメイルリーダをウィルス類に自動操作されてその利用
者の権限でウイルスメイルが送信される事が多い。つまり、送信主体はごく普通
のユーザがごく普通に利用しているプロバイダのSMTPサーバとなることが多いの
で、SMTP接続のパラメータを見ただけではそれが迷惑メイルかどうかは判定でき
ないことが多い。メッセージをいったん受け取り、本文を見て添付されたファイ
ルが特定のパターンにマッチするかどうかを調べる必要がある。市販のメイルウィ
ルス対策ソフトなどはこれに相当する。

以上のことをふまえると、「迷惑メイル」を防ぐ手段には2つの方策が考えられ
る。
	* SMTPセッションフィルタ

	  SMTPクライアントのIPアドレスやSMTPセッション時の3パラメータの
	  正当性を元に受信の許可/不許可を判定する。判断要素が少ないため
	  サーバのCPU負荷は低い。spamの大部分を占める「身元の怪しい」も
	  のは拒否できるが、「身元の確かな」送り方をするものは防げない。
	  SMTPの段階で拒否するので、送信エラーは迷惑メイル送信者(あるい
	  は中継者)のクライアントに返る。

	* コンテンツフィルタ

	  メッセージ本文を統計的処理・パターン照合などの手法で解析し、ロー
	  カルユーザに配送するかを決定する。本文が巨大な場合もあるので一
	  般的にサーバのCPU負荷が相応に掛かる。SMTPレベルではいったん受
	  け取りが完了してしまうので、送信してきたクライアントにエラーは
	  返せないし返してはいけない【註 い】。

---[註 い]------------------------------------------------------------
迷惑メイルの Envelope-from はほとんどが詐称されたものなので、その宛先に
エラーを返しても無実の人に意味のないレポートが届くだけであり、それ自体が
迷惑メイルとなる。したがって、コンテンツフィルタは Envelope-from にエラー
(バウンス)を返してはならない。これに反するコンテンツフィルタは残念ながら多い。
----------------------------------------------------------------------

例外はあるが、概してSMTPセッションフィルタはspamを排除するのに有効であり、
コンテンツフィルタはウィルス類に有効である。コンテンツフィルタを動かすた
めの負荷も無視できない状況になっているため、SMTPセッションフィルタでそれ
と明らかに分かる迷惑メイルを弾き落とし、残ったものをコンテンツフィルタで
精査してゴミ箱に捨てる、というやり方が効率的といえる。

Part3の前半ではSMTPセッションフィルタについて解説し、後半でコンテンツフィ
ルタの一例である Qmail-Scanner について解説する。

●SMTPセッションフィルタ

2002年頃より、筆者は自分の運用しているメイルドメイン宛に届くspamが気にな
り始めた。いよいよ耐え切れなくなった2002年12月に qmail-smptd に修正を加
える形でSMTPセッション時のパラメータを元に、「明らかに不要」と分かるクラ
イアントからの送信に対してSMTPエラー(SMTP応答コード5xx)を返し受信拒否す
る機能を実装した。以後、実運用での判定成績を元に改良を重ねたものが qmail
patches【註 ろ】である。この手法の有効性が確認できたことから、さらに
qmail 以外のMTAでも同様の手法を利用できるように新規に開発したものが今回
紹介する antibadmail である。
---[註 ろ]------------------------------------------------------------
http://www.gentei.org/~yuuji/software/qmpatch/
----------------------------------------------------------------------

なお、antibadmailは開発後間もないもので、qmail以外との組み合わせでの動作
実績が少ない状況である。いずれかのMTAやSMTPクライアントとの通信で不具合
が見つかった場合はぜひ動作報告等により解決に協力して頂きたい。

また、antibadmailの行なっている受信拒否の挙動には、厳密にはRFC違反となる
部分がある。性善説に基づけばRFCをあらゆる面で遵守するのが当然だが、悪意
ある送信者が多くなってしまった現在ではそうも言っていられない。善意の(信
頼できる)送信者にはきまりを破らず、そうでないものは身を守るための拒否動
作を行なう、というのがantibadmailのポリシーとなっている。


  ・antibadmailの概要

  antibadmailはSMTPクライアント(送信ホスト)と、SMTPサーバ(受信サーバ)の
  やりとりの間に入り、クライアントの送って来たセッションパラメータを中継
  すると同時に、その正当性を検査する【図 は】。そして、それが迷惑メイル
  に典型的に見られる値だと判定したときにはクライアントがSMTPの "DATA" コ
  マンドを送る前にSMTPエラーコードを送り、受け取りを拒否する。
---[図 は]------------------------------------------------------------

  +------+					+------+
  | SMTP |					| SMTP |
  | ク   |           +-------------+		| サ   |
  | ラ	 |  -------  | antibadmail | ---------> | ｜   |
  | イ	 |           |             |		| バ   |
  | ア	 |  <------  |		   | ---------	|      |
  | ン	 |	     +-------------+		|      |
  | ト	 |					|      |
  +------+					+------+
 
----------------------------------------------------------------------

  antibadmailはサーバと同じホストで動いても良いし、別のホストでも良い。
  受け取りの許可/不許可は以下の基準を適用して決定する(抜粋)。

	* クライアントホストのDNS登録状況が不健全か
	* クライアントのIPアドレスがブラックリストに登録されているか
	* HELOで送って来た識別名がでたらめか
	* MAIL FROMがでたらめか
	* MAIL FROMがブラックリストに登録されているか
	* RCPT TOがブラックリストに登録されているか

  これらの拒否根拠のうち、「ブラックリスト」と書かれているものは管理者が
  設定したデータベースを参照するので、サイトの都合に合わせた設定ができる。
  また、筆者らが独自に管理しているブラックリストデータベースを利用するこ
  ともできる。

  さらに、ブラックリストにマッチするものの一部の判定条件を覆し、受信を許
  可するようにするための「ホワイトリスト」も登録できるようになっている。

  ・antibadmailの導入

  antibadmailの導入は、以下の手順で進める。

	1. ucspi-tcp(tcpserver)のコンパイル&インストール
	2. antibadmail本体のコンパイル&インストール
	3. 既存のSMTPデーモンのラップ
	4. 拒否データベースの管理

  まずは、antibadmail本体のみを導入(手順1〜3)して、正常に動作するかの確
  認まで済ませよう。ここでは、antibadmail導入予定のSMTPサーバが以下の通
  りであるものとする。

  -------------------------------------
   ホスト名		mail.ymzk.org
   IPアドレス		192.168.0.25
   LANのアドレス	192.168.0.0/24
  -------------------------------------

  (1) ucspi-tcp(tcpserver)のコンパイル&インストール
      =============================================

  ucspi-tcpは、qmailでも利用しているTCP接続を統一的なインタフェースで取
  り扱うためのツール群である。antibadmailでは、ucspi-tcpツール群のうち以
  下の3つを利用する。

	* tcpserver

	  TCPの特定ポートへの接続を管理する。IPアドレスやホスト名ベース
	  で接続の許可/不許可を決定し、実際のデーモンプログラムを起動す
	  る。いわゆるスーパーデーモンの役割をする。起動するデーモンに受
	  け渡す環境変数を設定でき、antibadmailではそれを利用する。

	* tcprules

	  TCP接続クライアントのアドレスに応じて、どんな挙動を示すかのルー
	  ルファイルをcdb形式【註 に】に変換するユーティリティ。ルールファ
	  イルはtcpserverが利用する。

	* mconnect

	  (MTAとしてqmail以外を利用する場合に必要)
	  リモートのSMTPサーバに接続するコマンド。入力をSMTPサーバに渡し、
	  サーバからの出力を標準出力に書き出す。SMTPに必要な改行コードの
	  変換機能が含まれる。
---[註 に]------------------------------------------------------------
高速で信頼性の高いコンスタントデータベース形式。更新がアトミックに行なえ
る、大量のデータからの検索が高速という特徴がある。詳細は、
http://cr.yp.to/cdb.html 参照。
----------------------------------------------------------------------

  ucspi-tcpは http://cr.yp.to/ucspi-tcp/install.html に書かれている手順
  に沿ってインストールする。ソフトウェア本体は
  http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz または、今月号の付録CD
  にあるのでこれを適当なディレクトリコピーし、ソースアーカイブを展開する。

	# gzip -dc ucspi-tcp-0.88.tar.gz | tar xpf -

  任意だが、fefe氏によるIPv6対応パッチ(IPv4でも使用可能)を当てる【註 ほ】。
  このパッチを当てるとオンラインマニュアルが追加されるのでIPv6を使用しな
  くても当てる価値は大きい。パッチファイルはCD-ROMに収録した。

	# bzip2 ucspi-tcp-0.88-ipv6.diff10.bz2 | patch -p0

---[註 ほ]------------------------------------------------------------
fefe氏による最新パッチは「diff 14」だが、そのままでは*BSDで正常に動かない。
筆者は対応パッチを送ったのだが返事が得られなかった。今回は作業量軽減を考
えて*BSDで正常動作し、機能的にも遜色ない diff 10 を利用する。
----------------------------------------------------------------------

  さらに任意だが、tcprulesで作成したルールファイルをantibadmailと組み合
  わせるときに、よりきめ細かに制御を行なえるようにするためのパッチを当てる。

	# patch -p0 < ut088fefe10-paranoid.diff

  使用するコンパイラ、リンカ、インストールディレクトリなどが conf-* ファ
  イルに書かれているので確認し、必要なら各ファイルの1行目を書き換える。

	# cd ucspi-tcp-0.88
	# rm *.orig
	# head conf-*

  デフォルトでは、コマンド群が /usr/local/bin にインストールされる設定に
  なっている。本稿でも、/usr/local/bin にインストールするものとして解説
  する。

	# make && make setup check

  (2) antibadmail本体のコンパイル&インストール
      ========================================

  以下のURLに、より詳しいドキュメントがあるのでそれを参考にしながら作業
  を進めて欲しい。

	http://www.gentei.org/~yuuji/software/antibadmail/

  antibadmailはcvs経由で入手する。適当なディレクトリに移動し、以下のコマ
  ンドにより最新版のソースを取得する。

	% cvs -d :pserver:anonymous@yatex.org:/qmail co antibadmail

  ソースディレクトリに移動しコンパイル&インストールする。

	# cd antibadmail
	# make all install

  make installにより必要なコマンド antibadmail と f2d が /usr/local/bin
  にインストールされる。antibadmailのインストールと動作時の挙動を決定す
  るためのコンパイル変数を【表 ぬ】に示す。Makefile の

	CFLAGS  = -DSYSLOG -g

  の部分を

	CFLAGS  = -DSYSLOG -g -D変数=値

  とすることでサイト固有の設定値に変えることができる。

  また、antibadmail では制御ファイルを格納するディレクトリのデフォルト値
  が /var/qmail/control になっている。これは、コンパイル変数 CONTROLDIR 
  で変更できる。なお、以下の説明では制御ファイルを置くディレクトリを
  $CONTROLDIR と表記する【註 る】。
---[註 る]------------------------------------------------------------
qmailの流儀を踏襲しているので antibadmail の管理ディレクトリも
デフォルトで /var/qmail/control を利用するようになっているが、
qmailの管理ファイルには全く依存していない。別のディレクトリに変えて
も構わない。デフォルトのコンパイル状態の場合でも、
環境変数 CONTROLDIR に別のディレクトリ名を代入した状態で
antibadmailを起動すれば任意のディレクトリに変更可能。
----------------------------------------------------------------------


---[表 ぬ]------------------------------------------------------------
 antibadmailのコンパイル変数と働き

  変数		デフォルト値		意味
  CONTROLDIR	/var/qmail/control	拒否データベースを格納するディレ
					クトリ
  LOG_FACI	LOG_LOCAL1		ログを記録するsyslogファシリティ
----------------------------------------------------------------------


---[コラム netqmail-1.05]--------------------------------------------- 
本文の解説では既に稼動しているMTAがあるものと仮定しているが、これから新
規にメイルサーバを構築する場合は netqmail-1.05 を導入するのが良いだろう。

http://www.qmail.org/netqmail/

netqmailはqmail-1.03に時代の流れに沿った最低限のパッチを付属させた、パッ
ケージである。ソースアーカイブ netqmail-1.05.tar.gz を展開したディレクト
リに移動し、

	# ./collate.sh
	# cd netqmail-1.05
	# make setup check

によりインストールが完了する。設定方法等は qmail-1.03 と全く変わらない。
qmail-1.03のときも迷惑メイル対策として

	* mfcheck patch(MAIL FROMの正当性を確認)
	  http://www.qmail.org/qmail-1.03-mfcheck.3.patch
	* badrcptto patch(拒否したいRCPTTOをbadrcpttoに書ける)
	  http://patch.be/qmail/badrcptto.html

などのパッチが有用だった。antibadmailはこれらに相当する機能を包含して
いるため、qmail本体にあてる「迷惑メイル対策」機能は不要である。それらの
パッチが入っている場合は競合するのでそれらを外した方が良い。それよりも
netqmailに置き換えてしまう方が簡単だろう。
----------------------------------------------------------------------

  (3) 既存のSMTPデーモンのラップ
      ==========================

  【MTAとしてqmail以外を利用している場合】

  標準SMTPポート(25)をantibadmailにラップさせるため、既存のMTAのLISTENポー
  トを25以外に変更する。以下の5つの手順で行なう。

    i. 既存SMTPDのポート番号の変更
       ---------------------------
  たとえばSendmailの場合は sendmail.cf の DaemonPortOptions を以下のよ
  うに変更し、デーモンを再起動する。

	O DaemonPortOptions=Name=MTA
	↓
	O DaemonPortOptions=Name=MTA, Port=10025

  この例ではポート番号を10025に変更している。以下の作業手順でも、本来
  のSMTPデーモンのポート番号が10025であると仮定する。
    %%
    %% Postfixの場合は?
    %%

   ii. antibadmail起動用のユーザ/グループの作成
       ----------------------------------------
  安全のため antibadmail は非特権ユーザで起動する。このためのユーザを作
  成する。ユーザ名/グループ名は何でも良いが、ここでは両方とも "abm" とい
  う名前で作成する。

	(Linux/NetBSD/SunOSの場合)
	# groupadd abm
	# useradd -g abm abm
	(FreeBSDの場合)
	# pw groupadd abm
	# pw useradd abm -g abm

  iii. TCP接続ルールの基本ファイルの作成
       ---------------------------------

  手順(v)で起動するtcpserverのためのルールファイルを作成する。ルールファ
  イルはどこに置いても良いが、/etc/abm に

	ルールファイルのソース → /etc/abm/smtp
	cdb形式に変換したもの  → /etc/abm/smtp.cdb

  というファイル名で置くものとしよう。

	* ローカルホストとLANのアドレスからのSMTP接続は信頼する
	* その他のクライアントからの接続は普通に許可する

  このためのルールファイルは【リスト へ】のように記述する。
---[リスト へ /etc/abm/smtp]------------------------------------------
127.0.0.1:allow,RELAYCLIENT=""
192.168.0.:allow,RELAYCLIENT=""
all:allow
----------------------------------------------------------------------

  ルールファイルをcdb形式に変換するのが楽なように、【リスト と】の内容で
  Makefile を作成しておく。
---[リスト と /etc/abm/Makefile]--------------------------------------
TCPRULES = /usr/local/bin/tcprules
smtp.cdb:  smtp
	cat smtp | ${TCPRULES} smtp.cdb smtp.tmp
----------------------------------------------------------------------

  /etc/abm ディレクトリに移動して make を起動してcdb形式のルールファイル
  を作成する。

	# (cd /etc/abm; make)

   iv. SMTPで受理する宛先ドメインを登録
       --------------------------------
  ローカル配送すべきドメイン、または別サーバのセカンダリとなっている場合
  はリレーすべきドメイン名を登録する。たとえば、ローカルアドレスとして
  foo.ymzk.org を、別サーバにリレーすべきアドレスとして example.com と
  *.example.com を受理する場合は、以下のようにする。

	# mkdir -p $CONTROLDIR     (デフォルトでは /var/qmail/control)
	# cd $CONTROLDIR
	# mkdir rcpthostsdir
	# cd rcpthostsdir
	# touch foo.ymzk.org example.com .example.com

  ドメイン名と同名の空ファイルを作成する。ピリオドで始まるものはワイルド
  カードを意味する。これで rcpthostsdir/ にあるドメイン一覧にマッチしな
  いものがRCPT TOに指定された場合は、不正中継として拒否されるようになる。

  また、もし該当するメイルサーバを外部送信用のSMTPサーバとしても利用して
  いる場合は、SMTP-AUTH などを導入する。POP before SMTP を利用したい場合
  は、許可を出すIPアドレスからのアクセス時に環境変数RELAYCLIENTがセット
  されるようtcpserverのルールファイルを動的更新すれば良い【註 か】。
---[註 か]------------------------------------------------------------
具体的設定は長くなるので紙面では省略する。antibadmailホームページより
abmusers-MLに加入して相談して欲しい。
----------------------------------------------------------------------

   
    v. tcpserver経由のantibadmailの起動
       --------------------------------

  【リスト ち】のようなシェルスクリプトを作成し、システムのスタートアッ
  プ時に起動されるようにする。リスト中「abmのUID」、「abmのGID」とある部
  分にはそれぞれ /etc/passwd, /etc/group ファイルの abm エントリの第3フィー
  ルドに記録されるID番号を記述する。

---[リスト ち /etc/abm/start-abm.sh]----------------------------------
#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/bin:/usr/local/bin
UID=「abmのUID」
GID=「abmのGID」
exec env - \
PATH="$PATH" \
UID=$UID \
GID=$GID \
RELAYCHECK=1 \
tcpserver -x /etc/abm/smtp.cdb -p -U 0 25 \
antibadmail mconnect 192.168.0.25 10025
----------------------------------------------------------------------

  【MTAとしてqmailを利用している場合】

  qmailを利用している場合は既に qmail-smtpd の起動スクリプトがシステムに
  あるはず【註 り】なので、スクリプト中の「qmail-smtpd」の部分を
  「antibadmail qmail-smtpd」 に変更する。具体例は以下のようになる。

	[[ 既存のスクリプト(例) ]]
	PATH=/usr/local/bin:$PATH
	UID=「qmaildのUID」 \
	GID=「qmaildのGID」 \
	tcpserver -vR -c40 -p -U -x /somewhere/smtp.cdb 0 25 \
	  qmail-smtpd 2>&1

	[[ 書き換え後のスクリプト ]]
	PATH=/usr/local/bin:$PATH
	UID=「qmaildのUID」 \
	GID=「qmaildのGID」 \
	tcpserver -vR -c40 -p -U -x /somewhere/smtp.cdb 0 25 \
	  antibadmail qmail-smtpd 2>&1
	  〜〜〜〜〜
	  ↑追加
---[註 り]------------------------------------------------------------
qmail-smptd の起動を未だに inetd 経由で行なっている場合は、この機会に
daemontools+tcpserver での起動に変更することをお勧めする。daemontools と
tcpserverによる起動については本誌2002年7月号 PartII または、
http://www.gentei.org/~yuuji/support/uu/200207/part2.html
を参照。
----------------------------------------------------------------------

  これまで qmail-smtpd の起動に tcpserver を利用していなかった場合は、
  「qmail以外のMTAを利用している場合」に書かれている通りに初期ルールファ
  イルを作成する。

		-	-	-	-	-

  以上で antibadmail の基本設定は完了である。迷惑メイルの拒否リストデー
  タベースが無い状態でも、ごく基本的な拒否設定が働く。まずは、外部のホス
  トからメイルを送信してみてこれまでどおりメイルが到着するか確認する。

  ・システムログの記録設定

  SMTP接続要求に対してantibadmailがメッセージの受信を許可したか拒否した
  かの記録はデフォルトでsyslog経由で書き込まれる。デフォルトのままコンパ
  イルした場合は /etc/syslog.conf に以下のエントリを追加する。

	local1.info			/var/log/smtp-stat
	(ろーかるいちどっといんふぉ)

  初期ファイルを作り syslogd にHUPシグナルを送る。

	# touch /var/log/smtp-stat
  	# killall -1 syslogd		(FreeBSDの場合)
  	# pkill -1 syslogd		(Linux/NetBSD/Solarisの場合)

  大きくなったログファイルを循環させるための設定も入れておくと良いだろう。
  newsyslogを使用しているシステムの場合(*BSD等)は、/etc/newsyslog.conf 
  を、logrotateを使用しているシステムの場合(Linux)は /etc/logroate.conf 
  を、logadmを使用しているシステムの場合(Solaris)の場合は
  /etc/logadm.conf を適宜修正する。

  ・迷惑メイル拒否データベースの構成

  antibadmailは大別して以下の4つの基準で受信か拒否かを決定する。

	* HELOパラメータのブラックリスト

	  - $CONTROLDIR/badhelodir/ に登録。
	  -「localhost.localdomain」のように正規でないメイルサーバが送っ
	   て来る典型的なものや、hotmail.comサーバでもないのに
	   「hotmail.com」と名乗って来る嘘のHELOなどを登録する。

	* MAIL FROMパラメータのブラックリスト

	  - $CONTROLDIR/badmailfromdir/ に登録
	  - 受け取りたくない送信者(MAIL FROM)アドレスを登録する。
	    詐称されやすい @hotmail.com なども登録する。

	* RCPT TOパラメータのブラックリスト

	  - $CONTROLDIR/badrcpttodir/ に登録
	  - 即座に拒否したい受信者(RCPT TO)アドレスを登録する。

	* クライアントアドレスによるブラックリスト

	  - tcpserverのルールファイル(/etc/abm/smtp)に登録。
	  - 典型的なspam発信ブロックに対し、指定したアドレスレンジ、または
	    ドメイン名全体で受信拒否したいものを登録する。


  ・SMTP3パラメータのブラックリスト

  HELO/MAIL FROM/RCPT TO の3パラメータの拒否データベースは「datadir形式」
  で登録する。あるエントリ x をデータベースに登録するときは該当ディレク
  トリに x という名前のファイル(空で良い)を作成する。以下に具体例を示す。

  「HELO localhost.localdomain を拒否したい」
	→ $CONTROLDIR/badhelodir/localhost.localdomain ファイルを作成

  「HELO *.example.com を拒否したい(*は任意)」
	→ $CONTROLDIR/badhelodir/.example.com ファイルを作成

  「MAIL FROM *@hotmail.com を拒否したい(*は任意)」
	→ $CONTROLDIR/badmailfromdir/@hotmail.com ファイルを作成

  「RCPT TO sales@ymzk.org を拒否したい」
	→ $CONTROLDIR/badrcpttodir/sales@ymzk.org ファイルを作成

  ・クライアントアドレスに基づく許可/拒否制御

  クライアントのアドレスに基づく拒否はtcpserver用のルールファイルに記述
  する。特定のクライアントに対して以下の環境変数を設定することで受信を許
  可するか拒否するかの判定操作を制御できる。

	 環境変数		その値の意味
	---------------------------------------------------------------------
	 BADHOST		セットされていれば拒否
	 REQPTR			セットされている場合、クライアントIPアドレ
				スのPTRレコードが正しく登録されてなけれ
				ば拒否する
	 GOODMAILFROM		MAIL FROMがこの値に合致する場合はたとえ
				MAIL FROMブラックリストに載っていても許可
	 PASSONLY		MAIL FROMがこの値に一致しない場合は拒否
	 GOODHELO		HELOがこの値に合致する場合はたとえ
				HELOブラックリストに載っていても許可
	 RELAYCLIENT		全てにおいて信頼する(重度の設定ミス以外
				は受信を許可する)
	 RELIABLECLIENT		RELAYCLIENTと同じ
	---------------------------------------------------------------------

  以下に、/etc/abm/smtp ファイルにどのような行を追加するかの具体例を示す。

    「*.adsl.example.net からのメイルは全て受信拒否(*は任意)」
  	↓
	=.adsl.example.net:allow,BADHOST=""

    「10.0.0.* と 10.0.2.*〜10.0.5.* からのメイルは全てPTRレコードを要求」
  	↓
	10.0.0.:allow,REQPTR=""
	10.0.2-5.:allow,REQPTR=""

    「*.msn.com から送られて来た MAIL FROM が *@msn.com
    または *@*.msn.com のメイルは拒否しない」
    (註: $CONTROLDIR/badmailfromdir/ に @msn.com と .msn.com も作成しておく)
	↓
	=.msn.com:allow,GOODMAILFROM="@msn.com/.msn.com"

    「oldmail.ymzk.org からは MAIL FROM が *@ymzk.org *@*.ymzk.org しか受
    信しない(それ以外は全て拒否)」
	↓
	=oldmail.ymzk.org:allow,PASSONLY="@ymzk.org/.ymzk.org"

    「*.docomo.ne.jp か HELO docomo.ne.jp を送って来ても拒否しない」
    (註: $CONTROLDIR/badhelodir/ に docomo.ne.jp【註 わ】 を作成しておく)
	↓
	=.docomo.ne.jp:allow,GOODHELO="docomo.ne.jp"

    「*.tomodachi.example.org はMTAの設定がショボショボだしウイルスも良
    く送って来るが全面的に受信許可する」
	↓
	=.tomodachi.example.org:allow,RELIABLECLIENT=""

  上記全ての例において、tcpserver的には「allow」を指示している。もしこれ
  を「deny」にしてクライアントからのTCP接続そのものを不許可にしてしまう
  と、クライアントはセカンダリサーバに繋ぎに行く可能性がある。するとセカ
  ンダリサーバまわりで迷惑メイルが流れて来てしまう【註 を】。
---[註 わ]------------------------------------------------------------
docomo.ne.jpのSMTP送信サーバはHELOで "docomo.ne.jp" を送って来る。正しい
FQDNを送って欲しいものである。au(ezweb.ne.jp)やvodafoneの送信サーバはき
ちんとしたHELOを送って来る。
----------------------------------------------------------------------
---[註 を]------------------------------------------------------------
ただしSMTPの送信エラーが返されてもセカンダリサーバに同じメイルを投げるよ
うな極悪クライアントがあったとしたら効果は変わらない。
----------------------------------------------------------------------

  ・データベースの共有

  tcpserver用のルールファイルと $CONTROLDIR 以下に作るパターンエントリを
  全て自分で管理するのもひとつの方法だが、cvsやsubversionなどの分散型リ
  ビジョン管理システムを使って共同管理すると管理の手間が軽減できる。

  筆者らは、自らの運営するメイルサーバに届いた迷惑メイルを分析して、次回
  からの受信を拒否できるようデータベースを構築してきた(以下 spamdbと表記
  する)。このデータベースは anonymous cvs にて誰でも利用できるようにして
  あるので筆者らのデータベースを信用できる(笑)場合は利用して欲しい。登録
  ポリシーとしては、「日本人にとって有用」という基準を心掛けている。もし、
  この公開データベース中に不都合なエントリがあったとしても、ホワイトリス
  トをローカルに設定することによっていくらでも覆すことができる。

  $CONTROLDIR(デフォルトで /var/qmail/control)に移動して anoncvs から
  spamdbを取得する。

	# cd $CONTROLDIR
	# cvs -d :pserver:anonymous@yatex.org:/qmail co spamdb

  $CONTROLDIR/spamdb ディレクトリに以下のファイルがコピーされる。

	badhelo		拒否したいHELOのパターンを1行1エントリで書いたもの
	badmailfrom	拒否したいMAIL FROMのパターンを1行1エントリで書いたもの
	badrcptto	拒否したいHELOのパターンを1行1エントリで書いたもの
	smtp-badhost	接続クライアントに応じたTCP接続許可/拒否と環境変
			数の設定ルール
	Makefile	上記 bad* ファイルを bad*dir 形式に変換するルー
			ルを書いた Makefile
	Makefile.tcprule ローカルの smtp ルールファイルと上記
			smtp-badhostファイルをマージしたものをcdbに変換
			するルールを書いた Makefile の例

  このディレクトリに移動して make を起動することで、datadir形式のブラッ
  クリストデータベースが構築される。これを $CONTROLDIR にシンボリックリ
  ンクすれば良いだろう。デフォルト値を変えていなければ以下の操作で完了す
  る。
	# cd /var/qmail/control/spamdb
	# make
	# cd ..
	# ln -s spamdb/bad*dir .

  定期的に cvs up して datadir を再構成する。

	# (cd /var/qmail/control/spamdb; cvs up; make)

  また、spamdbでは筆者らの判断基準で、「常に受信を拒否する」BADHOST 変数
  をセットするアドレス群を smtp-badhost ファイルに登録している。これを利
  用する場合は tcpserver 用のルールファイルのあるディレクトリに
  Makefile.tcprule を Makefile の名前でコピーするとよい。

	# cp spamdb/Makefile.tcprule /etc/abm/Makefile
	# cd /etc/abm
	# ln -s /var/qmail/control/spamdb/smtp-badhost .
	# make

  spamdbを利用せずとも、この手法は相互援助関係のあるメイルサーバ管理者同
  士で活用することができる。

  ・その他の判定機能

  antibadmailには上記以外にもいくつかの判定機能がある。

  	* Null-Sender なのに2つ以上のRCPT TOを指定したものは拒否する
	* メッセージのヘッダの文字列による受信拒否
	* 全ての迷惑メイルを受け取る特別な RCPT TO アドレス
	* (qmailのみ) 存在しない RCPT TO をSMTPの段階で拒否する

  詳細は http://www.gentei.org/~yuuji/software/antibadmail/ を参照して頂
  きたい。また、antibadmailおよびその前進のqmail patchを利用した場合の迷
  惑メイル撃退結果に関する報告を以下のURLで公開している。

http://www.gentei.org/~yuuji/software/qmpatch/publication/nospam200312.pdf
http://www.gentei.org/~yuuji/software/antibadmail/publication/abm-dsm35.pdf

yuuji@