大橋のページ

「メールサーバ」あれやこれや


普段ぼんやり思っていた「メール」に関することをメモ程度にまとめたものです。誤りがあるかもしれません。そのさいは、ご連絡を............oohashi@hyperdyne.co.jp

■SMTPとPOPについて

インターネットメールシステムの解説というと「MTA」「MTU」という用語の解説から始まる場合が多い。「MTA」は「Mail Transfer Agent」、「MUA」は「Mail User Agent」の略で、「Tarnsfer」というだけあってMTAはメールを配送するもの、「User」というだけあってMUAはユーザがメールを読み書きするためのものだが、MTAやMUAという耳慣れない用語にとらわれすぎるとメールシステムをかえって理解しずらくなってしまう。

インターネットのメールシステムは、そのほかのサービス同様、UNIXのネットワークを土台にして発展してきたものだ。マルチユーザ(複数のユーザが同じマシンを利用する)システムであるUNIXでは、たとえばsendmailのようなメール配送プログラムが使われ、メール送信先のアカウントを持ったホストにメールが届けられる。ユーザはそのホストにログインしてから、メールを読み書きするプログラムを使って、メールを読んでいた。こう考えるとMTAとは、sendmail(あるいはqmail)のようなメール配送プログラム、MUAはmailやmail.local(procmailはMUAというよりメール振り分けプログラム?)のようなメール読み書きプログラムのことで、MTA、MUAとも機能上は明確に分かれていた。

しかし、インターネットが普及するにつれてメールシステムにも変化がおとづれた。大きな変化はダイヤルアップ接続クライアントやWindowsクライアント、Macintoshクライアントの登場だろう。ダイヤルアップ接続クライアントの場合、そのクライアントが接続していなければメールを配送することができない。同じようにLAN上に多いWindowsクライアントやMacintoshクライアントは、つねに起動しているとはかぎらない。

自分がログインするホストまでメールが届けられている場合、その読み書きには通信の必要がなく、プロトコルも必要なかった。どのディレクトリにメールがスプールされているかが重要で、メールを読み書きするプログラムが正しくその位置を理解していれば、あとはスプールされたメールのデータをディスク上から読み出し、あるいはその逆に書き込むだけだった。ところが、ダイヤルアップ接続クライアントやWindows/Macintoshクライアントがインターネットに参加するようになってきたことで、MUAはMTAと送受信する機能が必要になり、そのためのプロトコルも必要になった。

現在、Windowsクライアントで一般的なMUAは、OutlookExpressだろう。OutlookExpressにかぎらず、MUAというような専門的な呼び方はされず、メールソフトやメーラーと呼ばれている。PostPetなども見た目はともかくりっぱなMUAだ。また、sendmailのようなMTAをメールサーバと呼ぶのに対してメールクライアントとも呼ばれている。

メールソフト(MUA)がメールサーバ(MTA)とメールを送受信するとき、メールの送信時にはSMTPというプロトコルが使われ、受信時にはPOP3というプロトコルが使われている。送信時と受信時とでプロトコルが異なっていることに注意する必要がある。

SMTPは「Simple Mail Transfer Protocol」の略で、その名のとおり「Simple」なメール配送用プロトコルだ。Simpleすぎて問題が多いくらいだ。POP3は「Post Office Protocol 3」の略で、メールを保管したサーバをポストオフィス(郵便局)に見立てている。実際の郵便は自宅まで配送されるのが一般的だから、イメージ的には「私書箱」に近いように思う。POP3の「3」は「バージョン3」の意味で、POPプロトコルが、POP、POP2、POP3とバージョンアップしてきたことによる。

Windows上のメールサーバでは、SMTPとPOP3の両方のプロトコルに対応していることが多いが、UNIX上のメールサーバは、SMTPをサポートしているSMTPサーバと、POP3をサポートしているPOP3サーバの2つを組み合わせて「メールサーバ」とすることが多い。また、メールを中継するだけのSMTPサーバと違って、ユーザのアカウントを持っていて、届けられたメールをスプールするユーザにもっとも近いSMTPサーバは、mail.localなどのMUAも必要であることにも注意。

SMTPとSPAMメール

インターネットメールの基本的な流れは、

メーラーA  -->  メールサーバA  -->  メールサーバB  -->  メーラーB
       SMTP         SMTP           POP3

というようになっている。まず、送信者側は、手元にあるメールサーバAに自分のメールを預けるだけで、そのあとそのメールがどう配送されるかに関しては感知していないことに注意したい。これはゆっくり考えれば当たり前のことなのだが、なんとなくクライアント(メーラーA)と相手のメールサーバBとが直接SMTPで接続できないとメールが届けられないかのような気になってしまうが、そんな必要はないということだ。このことはとくにファイアウォールを構築したときにポイントになる。メールに関しては、メールサーバはクライアントにとってプロキシのような位置付けになる。

また、メールの配送に関して、メールサーバを中継してメールが届けられるというような説明が多い。実際にそのとおりにメールサーバを転々としながらメールは届けられていることが多いが、上の図のように2台のメールサーバ間で配送されていると基本的には考えていい。どこかにあるメールサーバで転々と中継されて相手のメールサーバに届くわけではない。ただ、インターネットプロバイダや大中規模ネットワークではメールサーバの負荷やネットワークの構成上の問題など、さまざまな理由から、ネットワークをサブドメインとして分割し、サブドメインごとにメールサーバを設け、その間でメールを中継していることが多い。

さて問題となるのがメールサーバAがSMTPによってメールが届き、それを同じSMTPによって別のメールサーバに届けるということだ。この行為は、その一部分だけを見るとメールを中継しているにすぎない。そういう意味では、プロバイダのネットワークや大中規模ネットワークで複数台のメールサーバがメールを配送しあっていることと大差がない。

メールの中継ということを考えたとき、中継しているメールサーバにはメールユーザのアカウントがないことに注意してほしい。あるのは、送信先のメールアドレスからサブドメインを識別し、担当しているメールサーバあてに中継するためのルールだ。実際にそのメールアカウントが有効かどうかを中継しているメールサーバは知らない。逆に言うと、中継しているメールサーバもユーザのアカウント情報を持って、そのアカウントが有効かどうかを判断しながら中継するとなると、複数のメールサーバでつねにユーザアカウント情報を同期をとりながら持っていなければならず、大規模ネットワークではむずかしい。まして無限と言ってもいいほどのメールアカウントがあり、それが時々刻々変化しているようなインターネットでは、不可能だ。

結果的に、SMTPサーバはユーザのアカウント情報を持っていないし、接続してくるものが内部ネットワークに存在するクライアントなのか、それともインターネット上に存在するメールサーバなのかも識別することができない。

一般のユーザが誤解しやすい第一のポイントがここにある。メールソフトに「ユーザ名」と「パスワード」を設定して使っているため、メールの送受信のときに「ユーザ名」「パスワード」で識別しているのではないかというわけだ。

しかし、メールソフトの設定画面をよく見てみよう。たとえばOutlookExpressでは、「ツール」−「アカウント」−「メール」タブ−「プロパティ」でアカウントごとに設定するが、「サーバー」タブで「ユーザ名」と「パスワード」を設定しているのは「受信メールサーバー」であって、たんなる「メールサーバー」ではない。つまり設定するユーザ名とパスワードは受信のときにしか使われていない。プロトコルで言うと、POP3ではユーザ認証が行なわれるが、メール送信のSMTPではユーザ認証は行なわれていないのである。

SMTPのこうしたSimpleな仕組みは、悪用するユーザがいなかったころはなにも問題なかったが、これを悪用するものが出始めたことから事態は複雑になってくる。ユーザ認証もなく(中継するためのメールサーバの存在を考えるとできない)、SMTPで接続してくるものはすべて受け取ってしまうとなると、メールサーバが置かれているドメインとはまったく無関係なユーザが、まったく無関係なユーザあてにメールを送信するようなときもメールサーバは動作しないわけにいかなくなる。これがSPAMメールだ。

「SPAMメール」は、2つの意味合いを込めて使われている言葉のようで、1つはDMメールそのもので、もう1つがそういったDMメール送信のメールサーバとして(踏み台として)第三者に利用される被害行為そのものだ。第三者に踏み台として利用されるとは、たとえば「hyperdyne.co.jp」というドメインがあったとき、「somebody@xxxxxx.com」というユーザから「somebody@yyyyyyyy.com」というユーザあてのメールの送信のときにhyperdyne.co.jpのメールサーバが使われるということだ。

人のいい方は「そのくらいいいじゃないか」と思うかもしれない。しかし、いったんSPAMメールの踏み台にされると、加害者同士で連絡を取り合っているのか、複数のサイトから集中攻撃にあうことになり、まったく関係のないメールの送信でメールサーバはアップアップになって、自分のドメインあてのメールの受信やドメインユーザからのメールの送信がままならなくなる。さらにSPAMメールの送信先のアドレスに間違いが多く、その結果、メールサーバは何度も送信をリトライすることになり、その負荷は非常に高い。ときにはサーバそのものをダウンさせることすらある。回線そのものも無関係なメールの送信におわれてしまい、帯域のほとんどが使われてしまう。

SPAMメール対策をしているサイトも多く、そういったサイトではSPAMメールを送信しているメールサーバだと認定すると、そのメールサーバからはいっさい受信しなくなるため、さらに送信リトライが多くなる。SPAMメールの被害にあっていても、外部からはセキュリティの甘いネットワークだとしか思われないため、ひどいめにあっていても被害者として同情されるようなことはいっさいなく、加害者に荷担するものとしか見られない。SPAMメールに関しては、いいことはまったくなく、踏んだりけったりというのが現実だ。

さらに具合の悪いことには、インターネット側とのメールの送受信を停止してしまうわけにいかない場合が多いことだ。ドメイン内のユーザからのメールや、ユーザあてのメールの送受信をそのまま継続しながら、ダウン寸前のメールサーバでSPAMメール対策をするのは、慣れていてもむずかしい。

ちなみに「SPAM」の語源がSPAMという名前の缶詰にあるという説がある。SPAM缶詰のコマーシャルで、「SPAM!! SPAM!!」と連発していたことから、うるさいDMメールをSPAMメールと呼ぶようになったという説だ。真偽のほどはわからないが、SPAM缶詰は日本でも手に入る。筆者の勤める会社の近くのコンビニに置いてあるが、筆者はまだ食べたことはない。

http://www.spam.com/

SPAMメール対策の考え方

無関係な第三者同士のメールのやりとりにメールサーバが使われてしまうSPAMメールを防ぐとはどういうことだろうか。インターネットに公開しているメールサーバに期待している役割は次の3点になるだろう。

  • 自ドメインのユーザから他ドメイン宛てのユーザ宛てのメールの中継
  • 他ドメインのユーザから自ドメイン宛てのユーザ宛てのメールの中継
  • 自ドメインのユーザから自ドメイン宛てのユーザ宛てのメールの中継

 受信
自ドメインユーザ他ドメインユーザ
送信自ドメインユーザ
他ドメインユーザ×

さて、SPAMメールを防ぐにはいったいどうしたらいいだろうか。直感的に思い浮かぶのがIPアドレスによる制限だ。ルータのフィルタリングやLinuxのTCP WrapperなどIPアドレスから接続を制限する手法はよく使われている。

だが、IPアドレスからメールサーバに対する接続を制限するのはゆっくり考えるとかなりむずかしいことがわかる。内部ネットワークは、たとえばプライベートIPアドレスを導入していれば、そのIPアドレスからの接続だけに限定すればいいのだが、公開しているメールサーバの場合、インターネット側からはどこからメールが届くかわからないため、制限のしようがない。接続してくる可能性のあるドメインのIPアドレスをひとつひとつ調べ上げて登録してゆくというのは非現実的だし、未知のユーザから届けられるメールはインターネットを通じての貴重な出会いでもある。そんな出会いをすべてあきらめなければならない。

結局、どうするかというと、ここで普段は見ることのないメールのヘッダ部分(エンベロープ)の仕組みを知る必要が出てくる。

メールのエンベロープ

メールソフトを使っているかぎりでは、メールの送信者、メールの宛先、そして件名と本文、それと受信日時くらいしかメールには書き込まれていないように思えるが、実際にはさまざまなデータが書き込まれている。メールの本文以外のものはエンベロープと呼ばれている。つまり「封筒」だ。ちょうど封筒に宛先や差出人、そして郵便局の日付時刻のスタンプが書き込まれているように、メールのエンベロープ部分にはさまざまな情報が書き込まれている。

たとえば次のようになっている。

<From bin  Thu Jul 26 19:16:06 2001
Received: from xxx.xxxxxxx.or.jp (xxx.xxxxx.or.jp [203.xxx.xxx.xxx])
	by mail.hyperdyne.co.jp (8.9.3/3.7W/00082418) with ESMTP id TAA18752
	for >oohashi@mail.hyperdyne.co.jp<; Thu, 26 Jul 2001 19:16:06 +0900
Received: from yyy (yy.yyyyyyyy.ne.jp [203.xxx.xxx.xxx])
	by xxx.xxxxxxx.or.jp (8.9.3/3.7W) with SMTP id TAA23464
	for >oohashi@mail.hyperdyne.co.jp<; Thu, 26 Jul 2001 19:15:11 +0900
Date: Thu, 26 Jul 2001 19:16:00  +0900
From: =?iso-2022-jp?B?GyRCQGokJCVRJVQlaiUqJXMbKEo=?= >zzzzzz@zzzzzzz.co.jp<
X-Mailer: VB_SendForm 2.0
MIME-Version: 1.0
To: oohashi@mail.hyperdyne.co.jp
Cc: 
Subject: =?iso-2022-jp?B?GyRCRUU7UjtUPmwbKEotGyRCQGokJCVRJVMlaiUqJXMbKEot?=
Message-ID: >0726101191600.0.191919@xxx.xxxxxxx.or.jp<
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
X-UIDL: h&W"!lo<!!lFV"!+1k"!

星が囁く今日のあなたの運勢は・・・・?

Received: from xxx.xxxxxxx.or.jp (xxx.xxxxx.or.jp [203.xxx.xxx.xxx])
	by mail.hyperdyne.co.jp (8.9.3/3.7W/00082418) with ESMTP id TAA18752
	for >oohashi@mail.hyperdyne.co.jp<; Thu, 26 Jul 2001 19:16:06 +0900
Received: from yyy (yy.yyyyyyyy.ne.jp [203.xxx.xxx.xxx])
	by xxx.xxxxxxx.or.jp (8.9.3/3.7W) with SMTP id TAA23464
	for >oohashi@mail.hyperdyne.co.jp<; Thu, 26 Jul 2001 19:15:11 +0900

の部分はメールサーバが書き加えた部分で、下に行くほど古く(発信人に近く)なっている。

以下、まだ書いてる途中なのね(^^ゞ

著作権、商標等について (C) 2001 HyperDyne Inc.