新世代のMTAへ

Part I 新世代のMTAへ

電子メイル。なんと便利な道具だろう。どんなに離れた相手でも一瞬にしてメッ
セージが届き、その距離を忘れさせてくれる。このサービスは、インターネット
の創世記から存在する基本的なサービスのひとつである。そんな電子メイルを支
える技術に今大きな変革が起きようとしている。本特集では、これからの電子メ
イルを担うであろう新世代のMTAの代表格である Postfix と qmail を取り上げ、
安全で簡単で堅牢で便利なメイルサーバを構築するための第一歩を着実に踏み出
すための方法を説明したい。

■MTAとは?

電子メイルの送受信に関連するソフトウェアは多数あるが、そのなかでも電子メ
イルの配送を受け持つもっとも根幹にかかわる仕事をするのがMTA(Message
Transport Agent)である。MTAがどんな仕事をするものかという抽象的な説明よ
りも、sendmailという名を出した方がピンとくる読者の方が多いかもしれない。
つまるところ、MTAは
	* ローカルユーザまたはネットワークの先からメイルを受け取り
	* それをローカルユーザまたはネットワークの先に配送する

という基本的な処理を行なうものである(図い)。

--[図い]----------------------------------------------------------------------

 +------ LAN 1 ------------------------+
 | +-- client1--+ (smtp) +-mailserver+ |
 | |   [MUA] →→→→→→| MTA       | |
 | +------------+        |  ↓配送   | |  ←SMTP→
 | +-- client2--+ (smtp) | +mailbox+ |---/---/---/-  (The Internet)
 | |   [MUA] →→→→→→| |       | | |
 | +------------+        +-+-------+-+ |
 |                                     |
 +------------------------------------+

  ↑というLANが3〜4つくらいあって、相互に (The Internet) を中心に
    結ばれているような絵
------------------------------------------------------------------------------

利用者宛のメッセージの最終到着点はメイルサーバ上に存在するメイルボックス
である。かつて電子メイル利用者がUNIX利用者に限られていた時代は、各利用者
がメイルボックスを直接参照できるMUA(Mail User Agent)を利用していたので電
子メイルのやりとりはMUAとMTAだけで完結していたのだが、現在ではサーバに直
接ログインしてメイルを読むケースは少なくなり、代わりにメイルボックスから
MUAへのメイル取得の面倒を見るものとしてPOPサーバなどを同時にメイルサーバ
に導入する必要がある。

■定番MTA -- sendmail

まだインターネットが世界をつなぐ代表的ネットワークとなるはるか前、その前
身のARPAnetでのメイル配送を実現するプログラムとしてdelivermailが作られた。
Eric Allman によるそのプログラムは、のちにSMTPに対応してsendmailとして生
まれ変わることになった。当時のネットワーク事情を反映するように、sendmail 
はありとあらゆる種類のネットワークのメイルアドレスを理解し、異種ネットワー
クでのメイルのやりとりが可能なように相互にアドレスを変換する機能を備えて
いた。この、非常に柔軟な「アドレスの書き換え」こそがsendmailの真髄である。
利用者の属するネットワークを選ばないこの機能のおかげでsendmailは他の追随
を許さぬ業界標準のMTAとして強力に電子メイル文化を支えて来た。

アドレス書き換え機能だけでなく、ユーザによってメッセージの配送先を変更で
きる(~/.fowrad)機能は利用時の柔軟性をさらに高め、メイリングリストなどの
コミュニケーションツールを手軽に導入することを可能にした。sendmail自身の
すぐれた可用性もまたインターネットの爆発的普及の一つの原動力として働いた
のは言うまでもない。

電子メイルサービス、電子ニュースサービス、FTPによるファイル転送、、とい
う基本的なサービスだけでも、境目のないインターネットの魅力は徐々に認めら
れていって、少しずつ広がりを見せていった。そしてWWWの台頭、Windows95での
TCP/IP標準対応によってインターネットの普及はさらに拍車がかかった。その結
果もはや「電子メイル」といえばインターネットのそれだけを考えれば良くなっ
た。皮肉にも、インターネット成長の一助をなしたsendmailは、その柔軟性をメ
リットとしてだけは受け入れられないものにしてしまった。

■sendmailでいいの?

sendmailの持つ柔軟性は、単に「柔軟性」という言葉では片付けられない程無限
の可能性を持ったものである。現在でこそメイルアドレスは

	ユーザ名@ドメイン名

という形式で表すものという認識が広まっているが、sendmailではそれだけでは
なくUUCP形式、BITNET形式、JUNET形式などありとあらゆる形式のアドレスを処
理できるようになっている。もっと言えば、「○×形式に(も)対応している」と
いう表現自体が的確ではない。そもそもsendmail自体にはメイルアドレスの形式
上のルールは一切実装されておらず、どのような表現形式をどう解釈するかとい
うルールセットを定義ファイル(sendmail.cf)で全て与えるようにプログラムさ
れている。このため、sendmailを利用している限り、将来どのようなメイルアド
レス表現形式が現れたとしても絶対に対応できる。

このように説明すると、sendmailのおそろしい程の万能性に感心するかもしれな
いが、万能であるということは裏を返せば気の利いたことは何もしてくれないと
いうことである。コンピュータ言語にたとえるなら、どんな高水準言語もコンパ
イルすると機械語に変換され、それが実行される。「よって、機械語があれば全
てのことができます。なのでこのシステムにはアセンブラだけ用意しますのでそ
の *柔軟性* を存分に利用してください」と言われても困るように、sendmailだ
けを渡されても途方に暮れてしまう。現実的には一般的に利用するであろう利用
形態のみのルールセットを生成するようなツールを利用してsendmail.cfを作成
している。そのツールの代表的なものとしてCFなどが挙げられる。

結局のところ、インターネットが絶対的な存在になってしまった現在では、
sendmailに備えられた「アセンブラ並の」柔軟性は無用の長物と化してしまった。
柔軟性があることは、たとえそれが使われなくともソフトウェアの持つ良い性質
として捉えられるべきものであるという考えもあるが、実際には現在ではそのよ
うにはなっていない。ソフトウェアの信頼性の問題である。

sendmailでは全てのMTAとしての動作をsendmailプログラムが行なう。一つのプ
ログラムだけが全てやってくれるということは、管理者がそれをインストールす
る時の作業量が少ないというメリットはある。しかし、プログラムを作成する場
合、プログラムの複雑性はプログラムの規模に比例する部分があるため、大きな
プログラムはその分バグが発生しやすくなり、バグの除去も難しくなる。そのよ
うな一般論はさて置くとしても、現実的にsendmailにバグ(とくにセキュリティ
ホール)が多いことは歴史が証明している。先に述べたsendmailの柔軟性も、今
となってはコード自体の複雑性を高めることにしか役立っていないといったらい
いすぎだろうか。

また、sendmailの生まれた時代背景が現在とはかけ離れているのもセキュリティ
ホールの一因となっている。生まれた当時は古き良き時代そのもので、電子メイ
ルを利用して悪事を働こうという人間も皆無だった。sendmailの目標自体がそう
であったようにどんなネットワークに属するものでも平等な仲間と信じて自由に
メイルのやりとりをしようという考え方が一般的であった。そのため、ネットワー
ク経由でメイル送信をするときにはとくに認証を必要とせず自由に利用できる
(Open Relay)のが当たり前であったが、現在はそうではない。部外者が自由にメ
イルサーバを利用できないようにするための機能をあとから追加したりするなど、
初期設計時には想定していないものを実装することを繰り返してきているため、
それに伴いさらにsendmailは複雑化していった。既に20年以上の歴史を持ち、異
なる文化背景をつなごうとしているsendmail。それに手を加える人に、新たなバ
グを仕込まないことを期待するのは「神になれ」と言うのと同じくらい酷なこと
だろう。

そして残念なことに、sendmailはアドレス書き換え処理が万能である反面、メイ
ルボックスの処理はきわめて貧弱である。詳細はPart2, Part3での特長説明に譲
るが、たとえば原則としてメイルボックスを一人につき一個しか持てない[註ろ]
ので、現在では当たり前になった「メイルアドレスの使い分け」などのことも一
つのsendmailサーバではできない。

--[註ろ]----------------------------------------------------------------------
 これもsendmail.cfの書き方次第でどうにでもできるのだが、それはつまり統一
 的な方法がないということで、複数のメイルボックスを判別して配送するロー
 カルメイラとPOPサーバなどが一般的に用意されているわけではなく、自前で用
 意しなければならない。ということで、普通の管理者にとってそれは「不可
 能」であるのとあまり差がない。
------------------------------------------------------------------------------

■それでもsendmailにこだわる理由

現在では色々な欠点を全て克服する形で新しいMTAが登場している。にもかかわ
らず、多くのサイトでいまだにsendmailが使われている。それは新しいMTAが、
移行するに値しないものかという疑問を感ずるかもしれないが、そのようなこと
はない。sendmailを使い続けるのは、ソフトウェアの性能以外の要素によるいく
つかの理由がある。

* 移行作業のコスト

新しいMTAがどんなに魅力的で簡単だとしても、それに移行するためには新しい
ことを覚えなければならないし、既存のメイル利用環境を損なわないように気を
つける必要がある。たとえ定期的にトラブルに見舞われる可能性をはらんでいた
としても、勝手知ったるMTAの方が安心できるという精神的要素の影響は大きい。
本特集の一番大きな目的は、この大きな壁をできるだけ低くすることである。

* 過去の苦労を捨てることへの抵抗感

sendmailの設定は難しい。覚えることもたくさんある。しっかりと管理できるよ
うになるまでには多大な努力が必要である。その努力を乗り越えてある程度思い
通りにコントロールできるようになることは、それ自体に充実感を感じるに値す
る功労である。別のMTAに変えることは、その労力の全てを無に帰してしまうこ
とのように感じるのも無理はない。しかし実際にはsendmailとは全くポリシーの
違うMTAに触れることでSMTPというものの本来の姿を深く理解できるようになる
ので、けっして過去の努力は無駄にならないといえよう。

* ブランドイメージ

その歴史の長さから「メイルサーバといえばsendmail」というイメージは揺るぎ
ないものになっている。UNIXの歴史とともに歩んで来たという実績からも、「正
統派」というイメージを持つ人も少なくない。感性に由来する理由だけに、これ
は理屈ではいかんともしがたい。しかし、人間の選択はえてして感性がもっとも
重い位置付けにある。

* 無欲性と束縛指向

続くPartで紹介する Postfix, qmail ともに、管理が飛躍的に楽になったり、一
般利用者が拡張アドレスを限りなく持てたりするなどのメリットがある。しかし、
どんなメリットも、それを欲しいと思わなければ価値がない。管理者の立場とし
て新たな利便性が得られることに興味を示さないケースも多い。

またたとえば、拡張アドレスが使える機能は利用者全員が受けられる恩恵である
が、古くからの管理者は、このような無限の可能性を利用者に与えることにたい
してすべからく否定的に考える傾向が強い。複数のアドレスを使えるようにする
と他人に譲渡するなどの権利外利用を誘発するのではないかと懸念する。しかし
実際のところ、利用者が悪用を考えるかどうかはシステムの利便性とはあまり関
係ない。とくに現在ではメイルアドレスなどはいくらでも無料で手に入れられる
時代なので、それを無限に与えること自体が権利外利用を誘発することにはなら
ない。またLANでの利用の場合、制限の強いメイルサーバの束縛から逃れるため
に個人PCなどを利用して勝手にメイルサーバを立ち上げてしまうことも考えられ
る。不十分な管理状態で放置されるよりは、最初から主メイルサーバに大きな利
便性を与えて、十分な教育とともにそれを利用させる方が賢明である。

もちろん利用者に利便を与えることが目的でないサーバに関してはこの限りでな
い。

* 定期的に発生するトラブルが必要

冗談のような話だが、UNIXを利用したネットワーク環境のメインテナンス&サポー
トを売りにしている仕事では、ある程度、導入ソフトウェアにバグ修正や機能追
加によるバージョンアップが頻繁にあった方が望ましい。なぜならそうでないと
サービス料が請求しづらいからだ。たとえばqmailなどは現在のバージョン1.03 
が1998年に出てから全く修正の必要がないため、一回もバージョンアップがない。
これでは導入後の定期サポート作業が発生しない。そうした下心から顧客先に導
入するMTAとしてsendmailを選択することが誠実かどうかという議論は置いてお
くとして、実際にサポートを売るとしたら

・知名度が高く
・管理に必要な技術レベルの高さを誇示でき
・定期的にサポート作業が必要になる

などの性質を満たすソフトウェアを選んだ方が有利であると判断することは利益
追求者の(短期的に)正しい判断である。

顧客の立場なら、もちろん事後メインテナンスの発生可能性の一番低いものを入
れてくれ、と頼むだろう。

■次世代MTAには何があるか

sendmailの代わりとなりえる次世代MTAがいくつか発表されている。このうち、
完全なsendmailの置き換えとして送受信両方に利用できるものとして
ZMailer[※1], qmail[※2], Exim[※3], Postfix[※4] が代表的である。
--[※1〜※4]---------------------------------------------------------------
1. Copyright 1992 by Rayan S. Zachariassen,
   Copyright 1992-1997 by Matti Aarnio
2. qmail 1.03 Copyright 1998 D. J. Bernstein
3. Copyright (c) 1998 Nigel Metheringham
4. Copyright (c) 1997,1998,1999, IBM Corp..(作者はWietse Venema)
---------------------------------------------------------------------------

どれも難解な sendmail.cf を反面教師として設計されているため、より人間向
けの設定方式を採用している。これらのうち最初に注目されたのは、sendmailの
悪しき慣習を捨て、高性能と高信頼性と高利便性でアピールしたqmailだろう。
ちょうどその時期はUBE(いわゆるSPAM)などのSMTPサーバの悪用が顕著に出てき
た時代で、同時にsendmailの持っていたセキュリティホールやデフォルト設定の
不備などがどんどん見付かった。これに嫌気をさす管理者も増えて来ているとき
にセキュリティとパフォーマンスを重視して登場したqmailは一部の管理者に積
極的に受け入れられていった。実はほぼ同時期にPostfixが公開されたのだが、
当時の名称である "Vmailer" が、商標的問題を起こす恐れがあり初期公開でつ
まずいてしまった経緯がある。実際、筆者がsendmailを捨てようと決心したのは
1997年で、このときに試してみようと思ったのがqmailと Vmailer(当時)だった。
しかし先述の問題からか、どうしても Vmailer のパッケージを手に入れること
ができず、試すのを断念した記憶がある。

その後改名したPostfixは、Maildir形式などqmailのすぐれた機能などを取り込
んで次第にユーザを増やして来た。一つの転機としてはNetBSDでsendmailの代替
MTAとしてPostfixが標準装備された点が挙げられよう(ただしデフォルトで動く
のはsendmail)。

さて、現時点でsendmailの乗り換え先として選ぶのは何がいいだろうか。結論か
らいうと好みのものが一番である。なぜなら管理者の嗜好に合うものが一番管理
の手がゆきとどくからである。そうした好みがない場合、選択の基準となるのは
管理上の情報の得やすさと利便性の高さだろう。その他の選択要素として、設定
の簡単さと、配送性能の高さ、などがあるが、いずれのMTAもsendmailを基準に
考えると、十分な優位性を持っているので決定的比較材料になりにくい。情報の
得やすさ、利便性の高さ、という面で一歩リードしているのがやはり現在大きく
利用者数を伸ばしているqmailとPostfixである。どちらも、導入、設定、UBE対
策などの基本的作業がやりやすく、いざというときに同じ悩みを持つ人とともに
問題を解決できる可能性が高いといえよう。

■Postfixとqmailに関する疑問点について

Webで見掛ける文書などでも、qmailとPostfixに関するものが多くなってきてい
る。そうした中でどちらを選ぶのがいいかの議論として、既に片方を選択した人
がもう片方に感じた欠点を挙げていることが多いが、その多くは経験不足による
本質的でない指摘であることが多い。そのいくつかに関して考察してみたい。

    * 共有スプール(/var/mail/USER)を利用する危険性

      Postfixでは確かにデフォルトで利用するようになっているが、安全性の
      高いMaildir 形式も完璧に利用できる。どちらを選ぶかが管理者の判断に
      委ねられているというだけである。むしろPostfixの方がユーザのMaildir 
      が存在しない場合にも自動的に作成してくれる分、Maildirをシステムの
      デフォルトメイルボックスにするという設定を選択しやすい。

    * 設定ファイルの容易性

      少なくともいえることは、どちらもsendmail.cfよりは圧倒的に簡単とい
      うことだ。どちらを「容易」と感じるかは主観であり実際に両方体験して
      両方理解してみないと判定できない。定量的に見ればqmailの設定ファイ
      ルは1,2行のファイルを4〜5個書くだけで良く、そのうち手動で定義すべ
      きものが2行程度なのでqmailの方が「少ない」というのは間違いない。と
      ころが、設定すべきことが少なすぎることはしばしば管理者に不安を与え
      ることにつながり、それ以上のことを設定しなくて良いという情報が得ら
      れるまではあれこれ調べ回る苦労を負わせることもある。逆にPostfixの
      設定ファイルにはあらかじめ設定しそうな項目がコメントとともに書かれ
      ている。これを見て必要すべき項目だけをすらすらと探せるか、それとも
      全部設定すべきなのかと感じて圧倒されるかは、その人の性格次第だ。ど
      ちらの定義ファイル形式にせよ、最少設定項目を理解していれば非常に簡
      単である。

    * Virtual domain の設定可能性

      MTAのもつ virtual domain と一言でいっても、二つの性質がある。第一
      種のものは、アドレス(alias)テーブルをドメイン名の数だけ独立して持
      てるという意味合いのもの。そして第二種は第一種に加えてメイルボック
      スも各ドメインの各アドレス毎に独立して持てるもの。qmailでは最初か
      ら第二種の virtual domain が簡単に設定できるようになっている。実際
      この点がqmailの大きな魅力であることは確かだが、qmailだけでその恩恵
      を受けられるわけではない。Postfixではデフォルトで第二種の機構が用
      意されていないだけで、正規表現マップを利用すれば簡単に実現できる。
      ただし、Postfix FAQには第二種の機構を利用したいと思うことを愚かと
      考えるべきだと思わせる節がある。何を問題視してこのように書いている
      のか真相を知ることはできなかったが、個人的には第二種のvirtual
      domainこそが新世代のMTAの最も有効な利用法だと思うのでぜひ多くの人
      に体験して欲しいと考える。

これらを踏まえて考えるに、細かい項目での得手不得手はあるものの、MTAとし
ての総合的性能および管理者と利用者に与える幸福度の大きさとしてはどちらも
完全に互角だといえる。それでもまだ選択の理由を求めたい読者のために強いて
違いを挙げるとすれば作者のソフトウェアに対するポリシーの違いである。これ
はドキュメントを読めば自ずと分かるものなので、共感できるほうを使うと良か
ろう。

では新世代のMTAの世界を体験してみよう。

yuuji@