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からメイルを削除する • サーバ上からメイルを削除するため、メイルBoxの容量が少ない場合などに有効 • 単一のマシンでしか同一のメイルを扱うことができない

APOP（Authenticated POP) • 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が抱える問題点 • 古くに作られたプロトコルであり, 性善説にのっとって作られたプロトコル • 送り元の判定をしていない • どのSMTPサーバにメイル送信を頼んでも, 目的地に届く • この特性をSPAMなどに利用され、踏み台にされているサーバが多数存在する • 暗号化されていないため、内容は丸見えである

ユーザ認証機構を付加したSMTP • POP before SMTP • SMTP送信を行う前にPOPにて認証を行う • SMTPサーバはPOP認証を行ったホストに対して認証後、規定時間以内のメイル送信を許可する POP認証規定時間以内にメイルを送信 POP認証をしていない（正規の権限がない）ホスト）

POP before SMTPの問題点 • 毎回POP認証を行うため、ネットワークトラフィックの増加と、スループットの低下を招く • 送信元を偽ってメイルを出すことによって、誰かが行ったPOP認証にまぎれて、メイルを飛ばすことが可能である POP認証ホストA 私はA 規定時間以内にメイルを送信送信元偽装メイルは送信可能ホストB

ユーザ認証機構を付加したSMTP • SMTP Authentication（SMTP AUTH） • 文字通り、SMTP接続時に認証機構を組み込んだもの • 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) • Netscape Communications社が開発した通信経路暗号化プロトコル • はじめに公開鍵暗号化方式で共有鍵を交換し高速な暗号化経路を実現している • 第三者認証機関が発行した開鍵（電子証明書）を利用することで、サーバ・クライアントが公的に正規のものであることを証明することができる • TLS (Transport Layer Security) • SSL3.0に若干の拡張と改良を加えたもの • RFC 2246としてIETFで標準化されている

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

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

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 • ミラーリングし、それをさらにストライピングしたもの • 最低4台以上での構成となる • RAID6 • RAID5に独立パリティを追加し、複数台異常のディスクが同時に壊れた場合で、修復可能にしたもの

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

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

2004 年度情報システム構成論第 9 回メイルシステム