sendmail の解説書として名高い， 「sendmail 解説」（邦訳：村井純監訳，オーム社発売） の冒頭でBryan Costales はこう述べている。 「フリジアのゴルディオス王はあまりにも複雑な結び目を作ったので， 後のアジアの支配者しかそれをほどけないという神話を生みました。 これはゴルディオスの結び目と呼ばれ， ほどこうとしても全く歯が立たず， ついにアレキサンダー大王がやってきて剣で切断しました。 長年に渡り， 世界中のシステム管理者がゴルディオスの結び目である sendmail を切断するための 剣を待ち望んできました」。
そして， 遂に sendmail を切断する剣――qmail ――が現れた。 もはや sendmail を使い続ける理由は何もない。 sendmail の破綻の反省から，qmail は単純性が追求されている。 図 5 に qmail を構成するプログラム間のデータの流れを示す。
ローカル・ユーザー（このマシン上のユーザー）が送信したメールは， まず qmail-inject プログラムでヘッダーから 送信者および受信者のアドレスが読み取られ， メール本体および送信者と受信者のアドレスが qmail-queue プログラムへ送られる。
一方， 外部のユーザーが送信したメールは， SMTP 接続経由でまず qmail-smtpd プログラムが受け取り， メール本体およびエンベロープ送信者と受信者のアドレスが qmail-queue プログラムへ送られる。
qmail-queue プログラムは送られて来たメール本体および送信者と受信者のアドレスを キュー（メールを一時的に保存する場所）に格納し， qmail-send プログラムに対してトリガー（きっかけ）を送る。
qmail-send プログラムはトリガーを受け取ると， キューに格納された送信者と受信者のアドレスを読み出して， ローカル・ユーザーあては qmail-lspawn プログラムに対して配送コマンドを送り， リモート・ユーザー（このマシンのユーザーでないユーザー）あては qmail-rspawn プログラムに対して配送コマンドを送る。 qmail-lspawn あるいは qmail- rspawn から正常に配送したという返答を受け取ると， qmail-clean プログラムに対してコマンドを送ってメールをキューから削除する。
qmail-lspawn プログラムは配送コマンドを受け取ると， 受信者アドレス, 受信者ユーザーのホーム・ディレクトリなどを引数として， 受信者のユーザー権限で qmail-local プログラムを呼び出す。 そして qmail-local プログラムは受信者のユーザーのホーム・ディレクトリにある .qmail ファイルを参照して， メール・ボックスへメールを格納， ファイルへメールを追加， プログラム実行を行なう。
qmail-rspawn プログラムは配送コマンドを受け取ると， 受信者アドレスなどを引数として， qmail-remote プログラムを呼び出す。 そして qmail-remote プログラムは， DNS で検索して得たあて先 MTA に対して SMTP 接続し， メールを送信する。
|
|
| 図 5 qmail を構成するプログラム間のデータの流れ |
このように， それぞれのプログラムの機能はかなり単純である。 実際， 各プログラムのソース・ファイルは共通ライブラリの部分を除くと 1000 行に満たない。 一番複雑なのは qmail-inject プログラムで， これはローカル・ユーザーがどんな形のメールを与えても， それを解析し， メール・ヘッダーから送信者と受信者のアドレスを 正しく抽出しなければならないからである。 一方， 他のプログラムは入力の形式が極めて単純であり， 解析の必要がない。 そのためソース・ファイルは簡潔なものとなっている。 この qmail の単純さ， および qmail が現代のニーズを第一に設計されたという理由から， 前述した sendmail の問題はすべて解決されている。
しかも，
であるから， sendmail を惰性で使い続けているサイトは qmail への移行を検討すべきだろう。 sendmail の新しいバージョンを追いかけるよりは qmail へ移行する方が簡単なのだから， なおさらである。 以下，順に説明する。
図 5 中， オレンジ色で示したプログラムがデーモンとして常駐しているプログラムである。 root 権限で動くプログラムは qmail-start と qmail-lspawn だけである。 セキュリティ・ホールの原因になりがちな setuid ビットが立っているプログラムは qmail-queue だけであるが， このプログラムのオーナーは root ではなく qmailq であり， qmailq の権限ではキューの読み書きができるだけである。
qmail-start は 4 つのデーモンの立ち上げを担当するのみであり， このうち qmail-lspawn だけが root 権限で動き続ける。 したがって qmail-lspawn のみがセキュリティ上問題を抱える可能性が あるわけであるが， qmail-lspawn はファイルを書き出すことは無いし， root 権限で動くプログラムを呼び出すことはない。 しかも qmail-lspawn のソース・ファイルは， 共通ライブラリを除くと 600 行にも満たない極めて単純なものであり， バグなどによってセキュリティ・ホールが生じる危険を最小限にしている。
さらに， 各プログラムはお互いを信用していない。 プログラム間のインタフェースはあいまいさを残すこと無く定義されていて， 定義から逸脱した内容が送られて来たら， 受け側のプログラムはエラーとして処理する。 したがって， もし qmail-send が侵入者の手に落ちたとして， qmail-lspawn に対して侵入者の思いのままに配送コマンドを与えることが できたとしても， 侵入者にできることと言えば 任意のメールをローカル・ユーザーに送ることだけである。
前述したように， qmail を構成するそれぞれのプログラムの機能は単純であるから， 何か問題が生じてもすぐに原因をつかめる。 qmail の設定ファイルは 30 個以上もあるが， それぞれの内容は以下に紹介するようにいたって単純である。 設定ファイルの単純さは， それを読み込む側のプログラムを簡単にするのに一役かっている。
たくさんある設定ファイルであるが， 特に重要なのは表 3 の 5 つである (~/.qmail* はローカル・ユーザーごとに設定できる)。 ~/.qmail* 以外のファイル名は qmail のルート・ディレクトリ (通常 /var/qmail) からの相対パスである。 以下， 私のメール・サーバー（toyokawa.gcd.org）を例にとり， 各設定ファイルの設定方法を説明する *5。
| 表 3 qmail の重要な設定ファイル | |||||||||||
| ファイル名 | 内容 |
| control/me | qmail を走らせているホストのFQDN |
| control/locals | qmail-send が ローカル・ユーザーあてと見なすアドレスのリスト |
| ~/.qmail* | ローカル・ユーザーごとの転送先等の設定 |
| control/rcpthosts | qmail-smtpd が あて先として許可するアドレスのリスト |
| control/tcprules.dat | qmail-smtpd の SMTP 送信元ホストごとの設定 |
toyokawa.gcd.org
これは qmail を走らせるマシンの FQDN (Fully Qualified Domain Name, ドメイン名を含めたホスト名) である。 起動時に DNS を参照して自分のホスト名を調べる sendmail と異なり， qmail は起動時にDNS を参照することはない。
toyokawa.gcd.org gcd.org
このファイルに基づいて， qmail-send プログラムがメールをローカル・ユーザーあてと リモート・ユーザーあてに振り分ける。 つまり， このファイルに含まれるアドレスがローカル・ユーザーあてであり， それ以外がリモート・ユーザーあてである。 この例の場合， sengoku@toyokawa.gcd.org や sengoku@gcd.org はローカル・ユーザーあてと見なされる。
「~/.qmail*」ファイルは， sendmail の「~/.forward 」ファイルに相当し， ローカル・ユーザーに届いたメールを転送したり (先頭に「&」を付ける)， 特定のファイルあるいはメール・ボックスへ格納したり (ファイル名あるいはメール・ボックス名を書く)， 特定のコマンドを起動してメール本体を標準入力へ与えたり (先頭に「│」を付ける) できる。
なお， 「~/.qmail*」ファイルの指定に従って転送, 格納, 起動を行なうのは qmail-local プログラムの役割である。 qmail-local はローカル・ユーザーの権限で動く。 当然であるが， root 権限を持つユーザーに対して qmail-local が実行されることはない。
qmail が sendmail と大きく異なるのは， qmail ではローカル・ユーザーが複数のあて先を管理することができる という点である。 例えばローカル・ユーザー「sengoku」がホーム・ディレクトリ ( ~sengoku/ ) に，
.qmail .qmail-foo .qmail-bar .qmail-default
のファイルを置いた場合，
| sengoku@gcd.org | 宛メールは， | ~sengoku/.qmail | の設定に従う |
| sengoku-foo@gcd.org | 宛メールは， | ~sengoku/.qmail-foo | の設定に従う |
| sengoku-bar@gcd.org | 宛メールは， | ~sengoku/.qmail-bar | の設定に従う |
| sengoku-*@gcd.org | 宛メールは， | ~sengoku/.qmail-default | の設定に従う |
となる。 なお，「*」は「foo」「bar」以外の任意の文字列である。
つまり， 各ユーザーが管理者の手を煩わすこと無く， 自由にメーリング・リストなどを立ち上げることが可能である。 しかも設定ファイル「control/virtualdomains」と組み合わせると， ローカル・ユーザーにドメインのメール管理を任せることさえ可能になる。 例えば， 「control/virtualdomains」を
haniwa.com:koala-haniwa .haniwa.com:koala-haniwa maczuka.gcd.org:alias-maczuka .maczuka.gcd.org:alias-maczuka
と設定しておき， ローカル・ユーザー「koala」のホーム・ディレクトリ ( ~koala/ ) に，
.qmail-haniwa-koala .qmail-haniwa-hanicom .qmail-haniwa-default
のファイルを置いた場合，
| koala@haniwa.com | 宛メールは， | ~koala/.qmail-haniwa-koala | の設定に従う |
| hanicom@haniwa.com | 宛メールは， | ~koala/.qmail-haniwa-hanicom | の設定に従う |
| それ以外の haniwa.com | 宛メールは， | ~koala/.qmail-haniwa-default | の設定に従う |
ことになる。 同様に， ローカル・ユーザー「alias」のホーム・ディレクトリ (通常 /var/qmail/alias ) に .qmail-maczuka-default を置き， その内容を
|preline -d /usr/bin/uux - -r -gB -z maczuka!rmail "($EXT2@$HOST)"
と設定しておくと， maczuka.gcd.org ドメインあてメールをUUCP *6 で送信する。 ここで，「$EXT2」等は環境変数の参照である。 qmail-local プログラムは， エンベロープ送信者と受信者アドレス等の情報を環境変数に設定した上で， .qmail に設定されたコマンドを呼び出す。
さて， ここで登場したローカル・ユーザー「alias」は， ローカル・ユーザーが存在しない， あるいは root 権限を持つユーザーあて用の .qmail の置場所として使われる。 つまり，
| postmaster@gcd.org 宛メールは， | alias/.qmail-postmaster | の設定に従う |
| root@gcd.org 宛メールは， | alias/.qmail-root | の設定に従う |
| あて先不明メールは， | alias/.qmail-default の設定に従う |
ことになる。 したがって，alias/.qmail-postmaster に
&sengoku
と設定しておくと， postmaster@gcd.org あてメールはローカル・ユーザー「sengoku」に転送される。 管理者が複数いるときは，
&admin1 &admin2 &admin3
などと書き並べればよい。 postmaster のほか，root，abuse，mailer-daemon など 管理上必要なアドレスは忘れずに転送先を設定しておく。
「alias/.qmail-default」を設定しないと， 存在しないアドレスあてのメールが届くと， エンベロープ送信者に対してエラー・メールが返る。 しかし， これは好ましくない。 もし， エンベロープ送信者として攻撃対象のアドレスを詐称し， 存在しないアドレスをエンベロープ受信者としてメールを大量に送りつけられたら どうなるだろうか。 エンベロープ送信者に対して大量のエラー・メールを送りつける結果になってしまう。 これでは次節で説明する 「不特定多数からのメールの中継を許可している SMTP サーバー」と変わらない。
残り 2 つの設定ファイル 「control/rcpthosts」と「control/tcprules.dat」は， qmail-smtpd プログラムのための設定ファイルである。 qmail-smtpd は外部から SMTP 接続でメールを受け取るプログラムであり， 迷惑メールを拒否する役割を果たす。 そこで， この 2 つの設定ファイルについては， 迷惑メール対策について述べる次節で説明する。
gcd.org .gcd.org haniwa.com .haniwa.com
このファイルに基づいて， qmail-smtpd プログラムは SMTP 接続における 「RCPT TO:」コマンドを受け入れるか拒否するかを決める。 この例の場合， 「RCPT TO:<koala＠haniwa.com>」コマンドが送られて来た場合， 「haniwa.com」が「control/rcpthosts」に含まれるので， これを受け入れる。 「.」で始まっているアドレスは任意のサブドメインを表わす。 例えば「.gcd.org 」が「control/rcpthosts 」に含まれているので， 「RCPT TO:<kaz＠maczuka.gcd.org>」コマンドを受け入れる。
「control/rcpthosts」に含まれないアドレスはすべて拒否する。 つまり qmail は， デフォルトでは外部のユーザーからの中継要求は拒否するのである。 したがって， 誤った設定で迷惑メールを中継してしまう可能性はかなり低い。
しかしこのままだと， 自分のサイト内の MUA が この MTA へ SMTP 接続して外部へメールを出そうとした場合も， 拒否してしまう。 そこで「control/tcprules.dat」で自分のサイト内からの SMTP 接続に限り， 中継を許可するように設定する。
「control/tcprules.dat」は， IP アドレスをキーとするハッシュ・テーブル *7 で， tcpserver プログラム（ucspi-tcp に含まれる *8）とともに用いる。
例えば，次のように実行する。
tcpserver -x/var/qmail/control/tcprules.dat \ toyokawa.gcd.org smtp /var/qmail/bin/qmail-smtpd &
tcpserver は， 外部のホストから SMTP 接続があったとき， 接続元のホストの IP アドレスでハッシュ・テーブル 「control/tcprules.dat」を検索し， その結果に基づいて次のどちらかの動作を行なう。
「control/tcprules.dat」はテキスト・ファイルではないので 直接書き換えることはできない。 まず control/tcprules.txt というファイルを作成する。 内容は，
# relayclients 127.0.0.1:allow,RELAYCLIENT="" 192.168.1.:allow,RELAYCLIENT="" 210.161.209.178:allow,RELAYCLIENT="" # :allow
各行それぞれが， SMTP 送信元ホストごとの設定になっていて， 「:」の左側がキー， すなわち接続元ホストの IP アドレスの条件で， 右側がキーごとの登録内容， すなわち接続を受け入れるか拒否するか， 受け入れる場合は追加設定する環境変数のリスト， である。 行頭が「#」の行はコメントである。
「192.168.1.」は， 「192.168.1.」で始まる IP アドレスすべて (つまり 192.168.1.0 から 192.168.1.256) で成立する。 また， 一定の範囲の IP アドレスを「192.168.1.1-10」 (192.168.1.1 から 192.168.1.10) などと指定できる。 条件が成立する行が複数存在する場合， 上の方にある行が優先される。例えば，
192.168.1.5-20:deny 192.168.1.:allow
となっていると， IP アドレスが 192.168.1.10 の場合， 「deny」つまり接続を拒否する。 192.168.1.2 の場合は， 「allow」つまり接続を受け入れる。 「:」の左側に何もない場合は， 任意の IP アドレスで成立する。
「RELAYCLIENT=""」は環境変数の追加設定で， 「RELAYCLIENT」にヌル文字列 (長さが0 の文字列) を設定する。 qmail-smtpd は， 環境変数「RELAYCLIENT」が設定されていると， 中継を許可する。
したがって， 前述の「control/tcprules.txt」の例は， IP アドレスが
| 127.0.0.1 | (ローカルホスト) |
| 210.161.209.178 | (toyokawa.gcd.org の IP アドレス) |
| 192.168.1. | で始まる IP アドレスすべて |
の場合中継を許可し， それ以外の場合， SMTP 接続は許可するが中継は禁止することになる。 つまり，「control/tcprules.txt」にはサイト内の MUA の IP アドレス それぞれに対し， 「allow,RELAYCLIENT=""」を指定しておけば良い。
次に， tcprules コマンドで tcprules.txt ファイルを tcprules.dat ファイルへ変換する。 qmail のルート・ディレクトリ ( /var/qmail ) で
bin/tcprules control/tcprules.dat control/tcprules.tmp < control/tcprules.txt
を実行すれば，control/tcprules.dat が作られる。
さて， 「control/tcprules.txt」において， 迷惑メールの発信元になっているホストの IP アドレスを「deny」と指定すれば， そのホストからの接続は一切受け付けなくなり， 迷惑メールを受け取らずに済む。 ダイレクト・メール業者など， 迷惑メールの送信を本業にしているようなサイトは「deny」 を指定して， 一切無視するに限る。
しかし， 迷惑メールの送信元はダイレクト・メール業者だけではない。 侵入されたホストや， 不特定多数からのメールの中継を許可している SMTP サーバーから送られてくる迷惑メールの方が数としては多い。 こうした悪用されて送信元になってしまったホストの数は極めて多く， 迷惑メールを受け取る数を実質的に減らそうと思うと， かなりの数のホストを登録しなければならない。 これでは大変なので登場したのが MAPS (Mail Abuse Prevention System, メール濫用予防システム) RBL (Realtime Blackhole List) である。
MAPS RBL は， 迷惑メールを大量にばらまくホストのデータベースである。 SMTP 接続を受付ける際に MAPS RBL へ問い合わせて， もし送信元ホストが登録されていたら， メールの受け取りを拒否すれば良い (図 6)。 MAPS RBL への問い合わせには DNS を使う。 つまり， 送信元ホストの IP アドレスが a.b.c.d ならば， DNS で「d.c.b.a.rbl.maps.vix.com」 を検索する。 もし TXT レコードが登録されていたら， そのホストはデータベースに登録されている。
|
| 図 6 MAPS RBL に問い合わせることでダイレクト・メールの受信を拒否 |
qmail で MAPS RBL を使うためのプログラムが， rblsmtpd である。 使い方は tcpserver と qmail-smtpd の間に挟む形になる。
tcpserver -x/var/qmail/control/tcprules.dat toyokawa.gcd.org smtp \ /var/qmail/bin/rblsmtpd /var/qmail/bin/qmail-smtpd &
送信元ホストの IP アドレスが MAPS RBL に登録されている場合， rblsmtpd は送信元ホストに対し， 一時的エラー 451 を返して SMTP 接続を切断する。 登録されていない場合は， tcpserver から引き継いだ SMTP 接続をそのまま qmail-smtpd へ引き継ぐ。
MAPS RBL 以外にも同様のデータベースがいくつかある。 用途に合わせて使い分けると良いだろう。 有名なものを表 4 に示す。
| 表 4 迷惑メール送信元ホストを登録しているデータベース | ||||||||||||||||||||||||
| 名称 | DNS で検索するドメイン | 登録されているホスト | 略称 | Web ページ |
| MAPS Realtime Blackhole List | rbl.maps.vix.com | 迷惑メールの大量送付で有名なホストを登録。 MAPS RBL に登録されているようなホストからのメールは 大抵のサイトが拒否するため，最近は大量送付に使われる頻度は減っている。 したがって受け取る迷惑メールの数は， あまり減らせないかも知れない | MAPS RBL | http://mail- abuse.org/rbl/ |
| MAPS Relay Spam Stopper | relays.mail-abuse.org | 不特定多数に対して中継を許可していて， かつ実際に迷惑メールの転送に悪用されたことがあるホストを登録。 RBL と ORBS の中間的位置付け。 ただし， 迷惑メールの送信者は， 新規に見つけた中継サーバーを利用しようとする傾向があるため， 食い止められる迷惑メールはさほど多くはない | MAPS RSS | http://mail-abuse.org/rss/ |
| Open Relay Behaviour-modification System | relays.orbs.org | 不特定多数に対して中継を許可しているホストを登録。 迷惑メールのほとんどすべてを食い止められるが， 日本の多くのサイトのホストも登録されてしまっているので， 必要なメールを拒否してしまう危険がある | ORBS | http://www.orbs.org/ |
| MAPS Dialup User List | dul.maps.vix.com | ダイアルアップでインターネットに接続するパソコンのために割り当てられた IP アドレスを登録。 プロバイダの MTA を経由せず， 直接パソコンから迷惑メールを送りつけるケースが増えている。 このタイプの迷惑メールを拒否できる | MAPS DUL | http://mail- abuse.org/dul/ |
自分のサイトの SMTP サーバーが， きちんと中継を拒否する設定になっているか確認するのはもちろんのこと， 表中の MAPS RSS や ORBS に登録されてしまっていないか確認してほしい。 登録されている場合は， 中継対策を行なった上で， 表 4 に示した Web ページに書いてある方法で削除依頼をするとよい。 なお、 迷惑メール対策をまとめると図 7 のようになる。
|
| 図 7 迷惑メール対策は上記の4 段階に分類できる |
| なお，1 ，2 は受けとる迷惑メールの量という点では変わらない。 |
qmail が作られた背景には， 大規模メーリング・リストを運営するため， という目的もあった。 sendmail では 1000 人規模のメーリング・リストでさえ， 配送を完了するまで数時間かかることがある。 数万人規模のメーリン・グリストだと， まったく使いものにならない。
qmail は，外部への配送を担当するのは qmail-remote プログラムだけであり 極めて軽い。 デフォルトで 20 本の SMTP 接続を並行して行なうが， 一世代以上前の PC でさえ同時に 60 並列の SMTP 接続が可能である。 配送するメーリング・リストの規模に合わせて並列数を調節すると良い。 qmail は，1000 人規模のメーリング・リストならば， 数分程度で配送を完了する。 数万人規模のメーリング・リストでも使われているようである。
sendmail が動いているホストに， qmail をインストールして実行してみることが可能である。 したがって， sendmail を使いつつ徐々に qmail へ移行することができる。 ここでは， sendmail が SMTP サーバーとして動き， sendmail 用の POP サーバーが動いていたホスト toyokawa.gcd.org で qmail へ移行する例について説明する。
ただしこのホストはファイア・ウオールで守られた LAN 上にあるものとする。 インターネットから直接アクセス可能なホストの場合は， セキュリティを考慮する必要がある。 例えば， APOP でない普通の POP サーバーをインターネットからアクセスできるところに 置いてはいけない。
qmail をインストールし， 主要な設定ファイルを書いたら， まず qmail-start プログラムで起動する。 この段階では qmail-smtpd プログラムは動かないので， SMTP 接続を受け付けることはない。 したがって， 他のホストからのメールは sendmail が受信する。 もちろんパソコン上の MUA を使って送信したメールも， sendmail が受けとって送信する。 つまり今までのメールの配送は全く影響を受けない。
例： /var/qmail/bin/qmail-start ./Mailbox splogger qmail
この状態で， qmail-inject プログラムを使えば， qmail を使った送信のテストができる。 さまざまなあて先に対して配送が正しく行なわれるか確認する。 また， ローカル・ユーザーそれぞれに対し， 好みに応じて ~/.qmail を設定させた上で， ローカル・ユーザー宛に qmail-inject を使ってメールを送ってみる。
次に sendmail プログラムを， qmail に付属する sendmail ラッパーで置き換える。 ただしデーモン (SMTP サーバー) として走らせる sendmail は置き換えない。 置き換えるのは MUA として使われる sendmail だけである。 例えば次のようにすると良いだろう。 sendmail のパスを /usr/sbin/sendmail と仮定すると，
例： ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail
この段階で， /usr/sbin/sendmail を呼び出すタイプの MUA は， 送信に qmail を使うことになる。 もし UUCP を使っているならば， UUCP 経由で受信したメールも， qmail 経由になる。
次に， qmail-smtpd を 25 番ポート以外のポート (25 番ポートはデーモン・モードの sendmail が使っているため) 例えば10025 番ポートで立ち上げる。
例: /bin/tcpserver -x/var/qmail/control/tcprules.dat toyokawa.gcd.org 10025 \ /var/qmail/bin/rblsmtpd /var/qmail/bin/qmail-smtpd &
telnet コマンドを使って 10025 番ポートにつなぎ， 図 2 と同様にしてメールを送信してみる。
MUA の中には， 送信用 SMTP サーバーのポートを任意に設定できるものがある (例えば Mew+IM)。 そのような MUA を使っているユーザーは， SMTP サーバーのポートを 10025 番に変更することにより， qmail を使って送信できる。
あるいは， ML サーバーの中にも SMTP サーバーのポートを容易に変更可能なものがあるので， この段階で一部の ML を qmail 経由で配送するように変更しても良いだろう。
さらに， qmail 用の POP サーバーを 110 番ポート以外のポート， 例えば 10110 番ポートで立ち上げる。
例: /bin/tcpserver toyokawa.gcd.org 10110 \ /var/qmail/bin/qmail-popup toyokawa.gcd.org \ /bin/checkpassword /var/qmail/bin/qmail-pop3d Maildir &
telnet コマンドを使って 10110 番ポートにつなぎ， メールを読んでみる (図 8)。
ozenji:/home/sengoku % telnet toyokawa.gcd.org 10110 Trying 210.161.209.178... Connected to toyokawa.gcd.org. Escape character is '^]'. 1 +OK <2608.946652520@toyokawa.gcd.org> 2 USER sengoku 3 +OK Password required for sengoku 4 PASS ******** 5 +OK 6 LIST 7 +OK 8 1 566 9 . 10 RETR 1 11 +OK 12 Return-Path: <postmaster@gcd.org> 13 Delivered-To: sengoku@gcd.org 14 Received: (qmail 2541 invoked from network); 01 Jan 2000 00:01:02 +0900 15 Received: from ozenji.gcd.org (sengoku@192.168.1.4) 16 by toyokawa.gcd.org with SMTP; 01 Jan 2000 00:01:02 +0900 17 Subject: test 18 From: postmaster@gcd.org 19 To: sengoku@gcd.org 20 Date: Sat, 01 Jan 2000 00:01:02 +0900 21 22 仙石です。これは SMTP 説明用のテストメールです。 23 24 #5403. 仙石 浩明 25 http://www.gcd.org/sengoku/ Hiroaki Sengoku <sengoku@gcd.org> 26 27 . 28 QUIT 29 +OK Connection closed by foreign host.
図 8 POP でメールを読む
MUA の中には， 受信用の POP サーバーのポートを任意に設定できるものがある (例えば Mew+IM)。 そのような MUA を使っているユーザーは， POP サーバーのポートを 10110 番に変更することにより， qmail 経由で受信することができる。
以上， 十分に動作確認できたら， デーモン・モードで動いている sendmail および sendmail 用の POP サーバーを殺し (inetd から呼び出している場合は， inetd.conf の該当する行をコメントアウトする)， qmail-smtpd を 25 番ポートで， qmail 用のPOP サーバーを 110 番ポートで， それぞれ起動する。
これで qmail への移行が完了した。 setuid ビットが立ったままの /usr/sbin/sendmail.daemon を放置すると セキュリティ上の脅威となるので， 削除するか chmod 0 /usr/sbin/send-mail.daemon を実行しておく。
（仙石浩明）
(ライターから)
本稿は日経Linux 2000 年 3 月号に掲載された、 特集 2: 高性能メール配送エージェント qmail 徹底活用, Part 1「sendmail を捨て, qmail に乗り換える ---qmail の仕組みから設定管理, 迷惑メール対策まで---」を日経BP 社の許可を得て転載したものです。
Copyright(C)2000 by 仙石浩明 <sengoku@gcd.org>
無断転載を禁じます