2004年度 情報システム構成論 第9回 メイルシステム 2004年度 情報システム構成論 第9回 メイルシステム 西尾 信彦 nishio@cs.ritsumei.ac.jp 立命館大学 情報理工学部 情報システム学科 ユビキタス環境研究室

MTAとMUA Mail Transfer Agent Mail Server Mail User Agent Mail Client

メイルBox サーバ上のメイルを貯めておく場所 構築するシステムに沿ったものにする必要がある （特にNFSを利用する場合は注意が必要） 古くからさまざまな種類がある 古株（というより絶滅危惧種） MMDF おそらく一番単純なメイルBox形式 現存しているかどうか不明・子孫がSCO システムで使われている？ BABYL MIT の昔のメイルシステムが起源 Emacs のメイルリーダモードで使われている場合があります （Emacsの仕様変更によっては使われていないかも）

MH形式 古くからあるメイルBox形式 MH系ソフトが利用している メイルが一つ一つ別々のファイルに保管される ファイル名は連番で記述される 管理用のファイルを編集する必要がある 管理用ファイル編集を同時に行うなどするとメイルが正しく管理されなくなる場合がある NFSの場合、正常に書き込まれない場合がある

mbox形式 比較的古くからあるメイルBox形式 UnixのメイルBox形式としては一般的 全メイルがひとつのファイルに凝縮 メイルとメイルの基本的な区切りはFromで始まる行があるかどうかで判断する （メイルの途中でFromから始まる行があると>が頭に付く） 未対応のメイルソフトが少ないので導入が比較的楽

mbox形式（問題点） 配送途中で（つまりファイル編集中に）サーバが落ちる、他のソフトが同時に書き込む、NFSのマウントが切れるなどするとメイル消失の危険性がある。 ファイル中でFrom行が消失すると、複数のメイルがひとつに融合してしまう可能性がある さまざまな亜種が存在するが、その亜種間での互換性は保障されていない NFSを利用している場合、ファイルロックを別々のホストで実行すると無意味

Maildir形式 別名, qmail-maildir形式 比較的新しいメイルBox形式 メイルが一つ一つ別々のファイルに保管される NFSを意識してNFS上で利用した場合にも、正常に処理されるようにしている 中央制御ファイルを置かないためファイルロックを行う必要がなく、複数のプロセスで利用した場合においても安全

Maildir形式が安全な理由 下記のアルゴリズムを利用しているため maildir ディレクトリに 移動する 名前 tmp/time.pid.host の存在をチェック time は GMT で1970年の開始からの秒数 pid はプログラムのプロセスID host はMTAのホスト名 すでに同名ファイルがあった場合は、数秒待ち再試行する、これを、回数の上限まで繰り返す tmp/time.pid.host を生成 ファイルを NFS 書き込み(NFS-writing)する ファイルを new/time.pid.host に linkする この瞬間、メッセージは正常に配送される

Maildir形式が安全な理由（2） NFS 書き込み(NFS-writing) とは などを意味します。 いつものように、各 write() コールから返されたバイト数をチェックする fsync() を呼び出し、戻り値をチェックする close() を呼び出し、戻り値をチェックする などを意味します。 標準的な NFS の実装では、fsync() を誤って処理するが、 close() して書き込みを強要している（qmail実装） 実際のアルゴリズムは実装による

受信用プロトコル POP3 サーバ上のメイルBoxから受信 サーバ上のメイルBoxからメイルを削除する 単一のマシンでしか同一のメイルを扱うことができない

APOP（Authenticated POP) APOPはPOPのパスワードを暗号化して通信する 多くのメイルクライアントが対応済み Outlook, Outlook Express, Becky!, Sylpheed, Wanderust, etc 問題 多くの場合, サーバ上のアカウントとは別にパスワードを保存するため, 別途パスワードが必要になる パスワードのみ暗号化できるが、メイル本文は暗号化しないため、通信内容は丸見えである(SSL利用に）

受信用プロトコル IMAP４ サーバ上のメイルBoxを閲覧 サーバ上のメイルBoxからメイルを削除せず、 手元にはキャッシュのみを残す 携帯電話・Webメイルなどで利用されている 複数のマシンで同一のメイルを扱うことができる

IMAPのユーザ認証 IMAP標準のユーザ認証は暗号化したパスワードを利用しない 暗号化したパスワードを利用する方法として、CRAM-MD5などが用意されている APOPと同様に、暗号化したパスワードを利用する場合はアカウント用パスワードとは別にパスワードが必要になる場合が多い

メイル配送 SMTPプロトコル DNSのMXレコードを参照して、リレー形式であて先まで配送する MXレコード A宛はAまで B宛はBまで C宛はCまで D宛はBまで B A C D

MTAとMUA Mail Transfer Agent Mail Server Mail User Agent Mail Client

SMTPが抱える問題点 古くに作られたプロトコルであり, 性善説にのっとって作られたプロトコル 送り元の判定をしていない この特性をSPAMなどに利用され、踏み台にされているサーバが多数存在する 暗号化されていないため、内容は丸見えである

ユーザ認証機構を付加したSMTP POP before SMTP SMTP送信を行う前にPOPにて認証を行う 規定時間以内にメイルを送信 POP認証をしていない （正規の権限がない）ホスト）

POP before SMTPの問題点 毎回POP認証を行うため、ネットワークトラフィックの増加と、スループットの低下を招く ホストA 私はA 規定時間以内にメイルを送信 送信元偽装メイルは送信可能 ホストB

ユーザ認証機構を付加したSMTP SMTP Authentication（SMTP AUTH） SMTP接続時に認証を実行する （暗号化 or plain） ホストA 認証　＋　メイル送信 ホストB 認証されない限り、 メイル送信は不可能

SMTP Authの問題点 パスワード認証を提供するが、パスワードが暗号化されて利用されるとは限らない 暗号化する場合はチャレンジ-レスポンス認証でCRAM-MD5を利用することになる 暗号化したパスワードを利用する場合、アカウント用パスワードとは別にパスワードが必要になる たとえ、暗号化したパスワードを利用したとしても、通信内容は暗号化されず、内容は丸見えである

チャレンジ-レスポンス認証 APOPやSMTP/IMAPの暗号化パスワード利用時に使われる認証方法（CRAM-MD5） パスワードを直接暗号化したものは利用しない パスワードを特定方法で符号化（MD5などと同様）し、符号化後のものと符号化の鍵を送信する サーバ側では、クライアント側と同様に保存してある生のパスワードを送られてきた符号化の鍵を使って符号化し、値を比較して成否を判定する APOP/SMTP/IMAPなどで暗号化パスワードを利用する場合に別途パスワードが必要になるのはこのためである

チャレンジ-レスポンス認証図解 生パスワード ②不可逆変換 生パスワード ③不可逆変換 ランダム鍵 ④比較して成否判定 ①乱数発生

チャレンジ-レスポンス認証 利点・欠点 利点 欠点 パスワードそのものを暗号化して送らないため、途中で盗聴されたとしても、復号してパスワードを取得することはできない 鍵をランダムに決めることにより毎回異なる文字列が生成できる 欠点 双方が生のパスワードを保管しておく必要がある 保管されているパスワードの管理に注意が必要 サーバ側がクラックされた場合は、すべてのパスワードが流出する サーバ・クライアント双方であらかじめ利用する符号化方式をあわせておく必要がある

SSL/TLSの利用 通信経路すべてを暗号化する 暗号化された通信経路内で、生のパスワードを利用しても問題ない 通信経路すべてが暗号化されるため、パスワードのみではなくメイルの内容自体も暗号化することができる SSL/TLS証明書により接続先の安全性を検証することができる

SSL/TLSとは SSL (Secure Sockets Layer) TLS (Transport Layer Security) Netscape Communications社が開発した通信経路暗号化プロトコル はじめに公開鍵暗号化方式で共有鍵を交換し高速な暗号化経路を実現している 第三者認証機関が発行した開鍵（電子証明書）を利用することで、サーバ・クライアントが公的に正規のものであることを証明することができる TLS (Transport Layer Security) SSL3.0に若干の拡張と改良を加えたもの RFC 2246としてIETFで標準化されている

暗号化非対応クライアントとの共存 SMTPにSSLのみを組み込むと、SSL未対応のSMTPサーバからのメイルを受け取ることができない SSL対応SMTPサーバ間の通信はセキュアに、SSL未対応のSMTPサーバからの通信は今までどおり行うことができる SSL対応・SSL未対応クライアント双方を同一サーバで利用することができる

メイルまとめ メイルBoxの信頼性確保のためにシステムにあったメイルBox形式を選ぶ POPはサーバ容量が少なくても利用可能 IMAPは複数のマシンで同一メイルが利用可能だが、多くのサーバ容量が必要 SMTPメイルのスパム対策は必須 パスワードなどセキュリティ項目の検討 （利用者のクライアントソフト・ネットワーク構成上利用できない場合など）

2004年度 情報システム構成論 第10回 多重化とバックアップ 2004年度 情報システム構成論 第10回 多重化とバックアップ 西尾 信彦 nishio@cs.ritsumei.ac.jp 立命館大学 情報理工学部 情報システム学科 ユビキタス環境研究室

メイルサーバの多重化 メイルサーバはリアルタイムで情報が届くため、一度稼動させると停止させることが難しい メンテナンスや故障時など 二重化し、一方が停止している場合、バックアップ用のサーバが稼動するように設計することが必要になる

メイルサーバの多重化 MXレコードを利用して転送先を制御する 実際のMXレコードの例 優先順位により、転送先が自動的に変更される 実際のMXレコードの例 （***.ubi.is.ritsumei.ac.jp宛のメイル配送先） ubi.is.ritsumei.ac.jp IN MX 50 mail1.ubi.is.ritsumei.ac.jp. IN MX 90 mail2.ubi.is.ritsumei.ac.jp.

メイルサーバ多重化時の注意点 メイルサーバごとにメイルBoxが異なると障害時やメンテナンス時にメイルが分散する NFSを利用して同一のメイルBoxを利用する NFSを利用するため、メイルBox形式はMaildirが望ましい 双方で同一アカウントを利用する必要がある NIS/LDAPなどで同一アカウントが存在する状態にしておく 導入してあるソフトを同一のものにしておく必要がある

メイルサーバ多重化時の構成例 ①メイル配送 上流 メイル メイル サーバ サーバ ①’メイル配送 ②共通のメイルボックスに追加 メイルサーバダウン時 ②共通のメイルボックスに追加 メイル サーバ バックアップ NFS NIS

ファイルシステムの多重化 ファイルシステムがクラッシュすると全データが消滅する可能性がある 定期的にバックアップを取ることである程度防ぐことが可能 ロールバックはどうしても発生する ファイルシステムを多重化する利点 ひとつが壊れた場合でも、正常にサービスを提供し続けることができる サービスを提供しながら、壊れているものを途中で取り替えるなどして、再度多重化状態を構築することができる

RAID （Redundant Arrays of Independent Disks） 高速かつ大容量・高信頼性ディスクを構築する方法 1987年にカリフォルニア州バークレー大学で発表された 「A Case for Redundant Arrays of Inexpensive Disks」 という論文が基礎となっている 上記のように、もともとは安価（Inexpensive）なディスクを 利用することを前提にしていたものであるが、現在は個別（Independent）のディスクを用いてという意味になっている 専用ハードウェアを利用する方法 効果、高速、高信頼性 ソフト上でエミュレートする方法 安価、オーバーヘッドが大きい、信頼性はソフトと実行環境依存

RAID0 2台以上のディスクをひとつのディスクとして扱う 書き込み、読み込み時は複数のディスクにひとつのファイルを分散し、並列アクセスすることにより高速アクセスを可能にする (striping) 理論上、おおよそ接続台数倍のアクセス速度向上が見込まれる 分散して書き込むため、ひとつのディスクが壊れた時点で全ファイルが読み出せなくなる 信頼性という面では期待できず、信頼性は接続台数が多いほど低下する

RAID1 2台以上のディスクをひとつのディスクとして扱う ミラーリングを行い、複数のディスクに同一の情報を書き込む 最悪一台のディスクが生き残っていれば、処理を続行することができる 信頼性は接続台数を増やすほど向上する ディスク利用効率は接続台数に反比例する 2台同時に利用すれば1/2、3台同時に利用すれば1/3となる

RAID5 データに対してパリティを作成する 作成したパリティとデータを分散して配置する ディスクが壊れた場合でも、他のディスク上のパリティから壊れたデータを復旧することが可能 専用機器の場合、ディスク故障を自動検出し、自動的に修復するものもある 書き込み速度はパリティ計算のため多少低下する 読み込み速度は並列アクセス可能なため向上する ディスク利用効率は、ディスク一台分がパリティで利用されるが、 ストライピングされるためほぼ接続台数に比例する

その他のRAID RAID2,3,4が存在するがほとんど使われていない RAID0+1 RAID6 ミラーリングし、それをさらにストライピングしたもの 最低4台以上での構成となる RAID6 RAID5に独立パリティを追加し、複数台異常のディスクが同時に壊れた場合で、修復可能にしたもの

クラスタリングシステム 複数のマシンを相互に接続し、ひとつのマシンのように見せる ひとつのサービスに対してサーバを複数用意することにより、一部のマシンが故障しても、全体としてはパフォーマンスが落ちたように見える （サービスそのものは停止しない） パフォーマンスや信頼性の向上は単に接続台数を増やすことによって実現できる ネットワークトラフィックには注意が必要

クラスタリングシステム図解 一つのシステムとして利用 一部ホストが故障中でも全サービスが利用可能