電子メールのしくみについて

電子メールはインターネットサービスの中でも、最も仕組みが複雑なものの一つです。

例えば、 FTPサーバー には FTPクライアント 、 Webサーバー には Webブラウザ 、という具合に、他の多くの サーバー アプリケーション は基本的に クライアント と１対１で利用されます。

しかし、 メールサーバー では最低「送信」と「受信」の二つのサーバーが必要ですし、クライアントの種類や利用方法によってはメールサーバーの種類や設定を変更しなければならないこともあります。

更に セキュリティ 確保のために別のアプリケーションとの連携が必要になることがあり、ただでさえ複雑なメールサーバーは、なお一層複雑なシステムになってしまいがちな傾向にあります。

なぜメールシステムがこのように複雑なのかというと、原因のひとつはその生い立ちにあります。

元々電子メールは、 UNIX のワークステーションで利用されてきたスタイルが起源になっています。下の模式図をご覧ください。

初期のデータ集中型メールシステム

世の中で初めての実用的なメールシステムには、現在のように「メールデータは クライアント機 で受信して保存する」という概念がなく、全て サーバー 上に「置きっぱなし」でした。

つまり、クライアントがメールを読むためには必ず LAN でサーバーとの接続を維持しておく必要があったわけです。

またメールの送信は、サーバーに ログイン しているユーザーが、同じサーバー内の別の ユーザーアカウント のメールボックスに対して「メールデータを書き込む」という単純な方法でのみ行われていました。

メールの送信はすべてサーバー内で完結する

つまりこの方法には、「メールを読んだり送信したりするだけでなく、メールを作成するときもサーバーにログインしておかなければならない。」という条件が必要となります。

ただ、接続してログインできていれば、その方法がLANであろうと電話回線であろうと何でも構わなかったはずですが、実際にクライアントからサーバーに電話回線で接続してメールを運用するには問題がありました。

高速で安価な常時接続の通信環境が当たり前の現在と違って、当時の通信は極めて低速で非常に高価でしたから、クライアント一人一人がそれぞれの通信回線で遠隔地からサーバーに接続することは通常考えられなかったわけです。

そこで、

サーバー同士でメールをリレーする

のように、サーバー同士のみを定期的に通信回線で接続させることで、間接的に遠隔地同士のメールデータのやりとりを行う仕組みが付け加えられたわけです。

その後、パソコンの普及による通信機器の低価格化が始まり、時を同じくして通信の品質向上と価格の下落が起こり、クライアントから遠隔地のサーバーへの接続が、コスト的に可能な時代になってきました。

そこで導入されたのが、「クライアント上で作成したメールをサーバーに送信( アップロード )する」という仕組みと「サーバーからクライアントにメールを受信( ダウンロード する」という仕組みです。

サーバーとクライアント間でメールを送受信する

このように、基本的な動作を担うシステムに、後から必要な機能を継ぎ足していったものが現在のメールシステムの一般的な環境ということになります。

さて、このようにして一応の運用形態が確立した電子メールシステムですが、既に古い仕組みがワークステーションのシステムの一部として大学や会社、官公庁などに深く根付いてしまっていたため、その古い運用形態と現在のメール環境を共存させなければならないという現実的な問題に直面してしまいました。

また、そもそもはメールの運用形態が 「お互いに信頼できるメンバーが一つのサーバーにログインしてメールの送受信を行う。」 というものであったため、メールの送信について認証を行うという、今では当然必要とされる仕組みすら存在しませんでした。

その結果、このセクションの ”ユーザー認証によるメール送信” で説明するようなユーザー認証によるセキュリティ対策は、従来からあったメールサーバーシステムに後から組み込まざるを得なかったという現実もあります。

つまり、「古いシステムを切り捨てる思い切ったシステム改革」をとることもできず、「古いシステムを生かしたままでの機能拡張の継ぎ足し」を行わなければならなくなった結果、メールサーバーは現在のような複雑な構造になってしまった、というわけです。

関連セクション・ Sendmailの設定

関連セクション・ Postfixの設定

現在のメールシステム色々

基本的に現在のメールシステムは、 クライアント から サーバー 、及びサーバーからサーバーへのメールの送信を担う MTA (メール転送エージェント、または送信メールサーバーとも呼ばれます。)という アプリケーション が中心となって動作します。

MTAの最も重要な仕事は世界中の他のMTAとの連携にあります。従ってできるだけ特別な振る舞いをしないことが望ましいので、 UNIX 系の OS 上では、安定性と動作実績のある Sendmail 、 Postfix 、 qmail のいずれかの アプリケーション が利用の大部分を占めます。

MTAによって最寄りのサーバーまで転送されたメールは、サーバー内で MDA (メール配送エージェント。)によって適切な場所(メールボックス)に保存され、サーバーはクライアントからの受信要求を待ちます。

サーバーに蓄えられたメールは、 MUA (クライアントのメール送受信アプリケーション)からの要求に答えて、 MRA (メール取得エージェント、または受信メールサーバーとも呼ばれます。)によってMUAの元に届けられることになります。

MRAは、サーバーに蓄えられたメールをクライアントのMUAとを結びつけるもので、MUAへのメールの ダウンロード が基本動作になる POPサーバーと、 MUAとサーバー間でメールデータの同期を行う動作を基本とした IMAPサーバー の二種類があります。

メールシステムはこのように複数のサブシステムが組み合わされる形になっていますから、 Webサーバー のように「とりあえず Apache だけ設定すればOK」。というわけにはいかないのが面倒なところではあります。

ただ、それぞれのサブシステムは複雑に絡み合っているわけではなく、メールの送信から受信までの流れは、

と一直線になっています。

特に、送信メールサーバーと受信メールサーバーとの間にはLinuxOSのシステム自身が入っていますので、送信メールサーバーと受信メールサーバーは別々のものとして考えても差し支えなく、相性や連携といった部分にはあまり注意を払わなくてもかまいません。

従って、送信メールサーバーをSendmailからPostfixに変更したからといって、受信メールサーバーを別の種類に変更する必要はありませんし、受信メールサーバーの種類を変更するときに、原則としては送信メールサーバーの設定を変更する必要もないということです。

この点を踏まえておくだけで、難解なメールシステムも容易に理解できるようになると思います。

以下に、現在一般に利用されているメールシステムの例を示します。

メールをMUAにダウンロードする(POPサーバー方式)

メールデータを MUA が ダウンロード することを前提とした一般的なシステムです。

MTA+POPサーバーによるメールシステム

MTA には任意の アプリケーション を使用し、 MRA に POPサーバー を使うパターンです。

この方式では、メールデータは基本的にサーバーからMUAにダウンロードされ、 クライアント機 で保管、管理さることになります。

一方で、サーバー上のメールボックスは「MUAにダウンロードされるまでの一時保管場所」という位置づけになりますから、基本的にはダウンロードのときにサーバー上のメールデータを削除してしまうことが前提とした運用になります。

一般的なインターネット接続契約で、 ISP からサービスで提供されるメールアドレスの受信メールサーバーは、ほぼ例外なくこの方式になっています。

メールをサーバーとMUAで同期する(IMAPサーバー方式)

メールデータを サーバー と MUA で同期、共有することを前提としたシステムです。

MTA+IMAPサーバーによるメールシステム

POPサーバーを利用する場合は、メールデータをMUAに ダウンロード するときに、サーバー上のメールデータを削除してしまうのが普通です。

一方IMAPサーバーを MRA に使う場合には、メールデータは基本的にサーバー上に置きっぱなしにしておきます。

この場合MUAの役割は、 クライアント機 上のメールデータの管理ではなく、 サーバー機 上のメールデータのリモート管理ということになります。

MRAにIMAPサーバーを用いる場合、過去に送受信されたメールデータは常にサーバー上に保管されていますから、クライアント機が壊れてしまってもメールデータが失われてしまうということはありません。

従ってこういう「ホスト機の故障」のような不測の事態に遭遇しても、新しいクライアント機とMUAを準備して、ユーザー名とパスワードを設定してIMAPサーバーと接続すれば、完全に元の管理状態が再現されることになります。

また、同じ理由から、複数のクライアント機で一つのメールボックスを操作することも問題なく行えるようになります。

例えばパソコン"A"から送信したメールの内容は、POPサーバー方式の場合はパソコン"A"の中にしか残りませんから、他のパソコン"B"からは、パソコン"A"で送信されたメールの内容を参照することはできません。

一方、サーバー上で全ての送受信メールを管理するIMAPサーバー方式では、パソコン"A"とパソコン"B"のMUAの状態は、常にサーバーのメールボックスを通じて同期されますから、「パソコン"A"から送ったはず」あるいは「パソコン"B"にダウンロードしたはず」のようなことを考える必要はないというわけです。

また、サーバー上のメールデータをダウンロードしてしまうPOPサーバー方式では、クライアント機が壊れてしまうとそれまで送受信してきたメールデータは消失してしまいます。

しかしIMAPサーバーを利用すれば、サーバー機とクライアント機の両方が一度に壊れてしまわない限り、過去のメールデータが失われることはないといえます。

と、いいこと尽くめのようなIMAPサーバー方式ですが、欠点はあります。

まず、「メールデータをサーバーに置きっぱなし」にするわけですから、それなりにサーバー上の ハードディスク スペースを必要とします。

POPサーバー方式の場合は、メールデータをダウンロードするとサーバー上のメールボックスを空っぽにできますから、通常50〜100 MB あれば充分です。しかし、IMAPサーバー方式の場合で、写真データなどを頻繁に送受信するような使い方をすると、少なくとも500MB〜1GB程度は必要になるでしょう。

つまり単純計算で、 構築中のLinuxサーバー 上に全部で50GB程度のハードディスクスペースをメールボックス用に割り当て可能だとすると、POPサーバー方式で500〜1000人分のメールボックスを確保できるのに対し、IMAPサーバー方式では50〜100人分しか確保できないことになります。

また、IMAPサーバー方式では、「常にサーバーとMUAが同期」という振る舞いをしますから、サーバーの動作負荷、通信負荷もかなり大きいものになります。

従って、IMAPサーバー方式で メールサーバー を運用する場合には、できるだけ利用人数を絞り、なおかつ LAN や FTTH 、及び高速な ADSL でクライアントとサーバーが接続できる環境でなければ、快適な運用は難しいでしょう。

MUAにWebブラウザを利用する(IMAPサーバー+Webサーバー)

クライアント機 に インストール した MUA アプリケーション を使うのではなく、 Webサーバー から提供されるMUA機能を利用する方法です。

通称 「Webメール」 と呼ばれます。

この場合受信システムはIMAPサーバーの仕組みが利用されることになります。

MTA+IMAPサーバー+Webサーバーによるメールシステム

このシステムを用いると、おなじみの "Outlook" や "Outlook Express" などのメーラー(MUA)の代わりに、 Webブラウザ でメールの送受信や整理を行うことになります。

Webメールの利用例(SquirrelMail)

Webメールを利用する場合は、メールデータの管理やMUAの設定などは原則としてすべて サーバー 上で行われることになります。

つまり、クライアント機にメールデータを ダウンロード せず、すべてサーバー上でメールデータを取り扱うわけですから、運用方式としてはワークステーションの時代に戻っているように思えるかもしれません。

ところがこれは、比較的最近になって無料のメールアドレス配布システムとして多用されるようになってきているサービスです。

こういうシステムが復活してきた理由はいうまでもなく、インターネット接続ユーザーの WAN 空間へのアクセス速度が非常に速くなったためです。

実際、20年前の LAN のスピードよりも現在の FTTH や ADSL 速度のほうが高速なケースが増えてきましたから、 アナログ通信 や ISDN が主流の頃に、 「低速回線でもメールが利用できるように」という目的で利用が始まったPOPサーバーに頼る必要がなくなってきた、ということです。

Webメールはクライアント機上でMUAを用いる普通のIMAPサーバー方式と比べると、「同期してクライアント機にもメールデータをダウンロード」という作業を行わない分、動作負荷、通信負荷は小さくなります。

またWebメールはMUAアプリケーションを使わず、設定もサーバー上で行うわけですから、自分専用のパソコンは必要ありません。

例えば、インターネットカフェや学校、会社などで比較的自由に扱えるパソコンさえあれば誰でも利用できるという利点もあります。

欠点はいうまでもなく、 「インターネットに接続していなければ何もできない」 という点に尽きるでしょう。

関連セクション・ Sendmailの設定

関連セクション・ Postfixの設定

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

メールサーバーを運用するための条件

電子メールで今一番問題になっているのは、無差別に配信されるダイレクトメール、いわゆる スパムメール でしょう。

電子メールは普通の郵便物と違って基本的に印刷代も配達料金もかかりませんから、個人宛てに大量に情報を配信するには格好の媒体といえるでしょう。

ということは、いままさにここで解説している「自宅 メールサーバー 」を利用すれば、そしてあなたがその気になれば、自分自身でスパムメールを配信できる スパマー になれるということを意味します。

ただ現在のメールシステムには、自分で所有しているメールサーバーをスパムメールの発信媒体にできないような、というより 「そういう行為に及び難くするような」 抑制の仕組みがあります。

それは、メールサーバーの多くが

「 FQDN へ名前解決できないメールサーバーからのメールの転送を拒否する。」

というリレー制御を行うからです。

FQDNを持たないメールサーバーからの転送を拒否

上の図をみればお解かりと思いますが、他のメールサーバーからメールデータの転送を受け付けようとするメールサーバーは、転送元のメールサーバーのFQDNを DNSサーバー に問い合わせ、正しく名前解決されない場合は転送を拒否するように設定するのが普通です。

メールサーバーにFQDNを設定するには、当然FQDNの元になる ドメイン名 が必要になりますが、ドメイン名の使用には必ず登録が必要となります。

また、そのドメイン名を DNS で利用するには、ルートサーバー に所在地が登録されているDNSサーバーで管理する必要があります。

つまり、自分のメールサーバーから他のメールサーバーにメールを転送するためには、「正式に申請、登録されたドメイン名とDNS情報」が必要になるわけですから、 「自分のメールサーバーから匿名でスパムメールを配信する」 という行為は事実上できないというわけです。

例えば Webサーバー や FTPサーバー などは、不便さにさえ目をつぶればFQDNは必要というわけではありません。 グローバルIPアドレス だけでも運用可能です。

しかしメールサーバーについては、他のメールサーバーにメールデータを転送できなければ実際のところほとんど利用価値はありませんから、どうしてもFQDNは最低限必要になるというわけです。

関連セクション・ Sendmailの設定

関連セクション・ Postfixの設定

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト