今や電子メールは，全社員が共通して利用する，ビジネス手段である。システム・ダウンやウイルス感染などの事故は，可能な限り防がなくてはならない。加えて，円滑にメールを送受信するためには，利用する規模に見合ったシステム性能も必要である。
企業は現在，「ハードウエアのリプレースに合わせてメール・システムの設計を見直す時期にきている」（SIベンダーのアイアイジェイテクノロジー プロフェッショナルサービス部の染谷直マネージャ）。機器のリプレースに限らず，時代に合ったメール・システムに設計し直す企業もある。
サイジングとポリシー設計がカギ
メール・システムの設計と運用に関して企業が抱えている課題は，大きく3つある（図1[拡大表示]）。（1）ネットワーク設計の課題，（2）運用ルール設計の課題，（3）今後取り組むべき新たな運用ポリシー設計の課題，である。
ネットワーク設計では，これまで部署ごとに分散していたメール・サーバーを1カ所に集中させて管理コストを低減できる時代になった＊1。メール・サーバー群の中で特に管理が面倒なサーバーは，受信したメールをディスクに蓄える「スプール・サーバー」。現在では，このスプール・サーバーを集中管理するようになった。
日々の運用コストを低減させる試みでは，ディレクトリ・サービスのLDAP＊2サーバーを使ってユーザー情報を管理する企業が増えた。他のシステムからでも利用できる汎用性を確保するとともに，メール・サーバーのユーザー管理コストも削減できる。メール・アドレスの割り振りも，ルールを明確に定めて機械的に行い，人件費を減らす企業が多い。
例えばSIベンダーのNECソフトは，2000年にメール・サーバーの集中化を図った。それまで部署ごとに立てていたメール・サーバー群を1カ所に集約。LDAPサーバーを用いたユーザー情報の一元管理も実施し，入社以後は同一のメール・アドレスを使い続けられるようにした。
メール・システムを構成しているコンピュータ資源は数多い。メール・サーバー機だけでも，インターネット上に設置して社内あてのメールを最初に受け取るサーバー，ウイルス対策を施すサーバー，受信メールを蓄えるサーバー，に分かれる。
メール・システムが利用するネットワークの設定も重要である。メール・ソフトからインターネットに向けたSMTPリクエストとPOP3リクエストをファイアウォールでブロックするといった具合だ。社内LANからインターネット上のメール・サーバーに直接アクセスしてメールを送受信するのは，セキュリティ上好ましくない。
寺岡精工では，そもそもパケットの標準のアクセス先をインターネットに向けない工夫を施している。WebアクセスとFTPアクセスはプロキシ・サーバー経由で，メールはメール・サーバー経由で利用すれば，社員がファイアウォールに直接アクセスする必要はないからだ。
ほかに，社内LANのネットワーク・アドレス全体に対して中継を許可することをせず，POP before SMTP＊3を用いて個々のホストごとに中継を許可する企業も多い。社外の業者が社内LANにノートPCをつないで，社内LANのドメインからメールを出されると困るからである。
分散管理から集中管理に移行
メール・システムを構成するネットワークは，従来と現在とでは大きく様変わりした。従来は部門や事業所ごとに独立して構築・管理していたスプール・サーバーを，データセンターやアウトソーシング先に1カ所にまとめて管理するようになった（図2[拡大表示]）。背景には，通信回線コストが下がったという要因がある。
企業がスプール・サーバーを統合する上で問題になるのは，統合時点まで使ってきたメール・アドレスをどうするか，である。例外はあるが，分散していたスプール・サーバーごとにサブドメインを割り振っているのが一般的である。このサブドメインを残したまま，スプール・サーバー統合後も使い続けられるようにする企業と，新規にメール・アドレスを振り直す企業とに分かれる。
NECソフトは，2000年のLDAP導入を機にメール・アドレスを新規に振り直した。そもそも部署ごとにメール・サーバーを管理していた従来は，人事異動によってメール・アドレスが変わるのが当たり前だった。サブドメインが変わるだけでなく，すでに同じユーザー名を使っている他人がいた場合はユーザー名も変える必要があった。退社するまで変わることのないメール・アドレスを新規に割り振るニーズが強かった。
従来のメール・アドレスをそのまま使えるようにした企業の1社が大成建設である。同社は，古いメール・システムを残しつつ，新たなメール・システムを構築し，並行稼働させた。事業部ごとに13台あったスプール・サーバーとは別系統の，新たなサブドメイン「pub」を用意して，全社員が共通して使える新系統のスプール・サーバーとした。
新スプール・サーバーが稼働した後で，徐々に古いスプール・サーバーを撤去した。移行の際は，新スプール・サーバー上でも古いサブドメインを使えるように，マルチドメイン構成＊4を採用した。「メール・アドレスが変わってしまうとビジネス上好ましくない。古いメール・アドレスも使い続けられるように配慮した」（社長室情報企画部の北村達也次長）。
スプーラの設計に注力する
スプール・サーバーの性能は，しっかりと見積もる必要がある。理由の1つは，基本的にスプール・サーバーの性能は後から上げにくいことである。もう1つは，そもそもスプール・サーバーの処理負荷は高く，メール・システムのボトルネックとなるケースが多いことである。
まず，メールを格納する方式を決める必要がある（図3[拡大表示]）。古くから使われている方法がMbox形式であり，ユーザー1人に1つ用意したファイルに，そのユーザーあてに届いたメールをすべて格納するものだ。Mbox形式は，オープンソースのメール・サーバー・ソフト「Sendmail」が用意している標準のメール格納プログラム「mail.local」が用いる形式である。
最近，利用が増えているのがMailDir形式（ディレクトリ形式）で，これはユーザー1人に1つのディレクトリを用意し，個々のメールごとに1ファイルを生成する。オープンソースの「qmail」に含まれる「qmail-local」で選択可能であり，米SendmailのSendmail Switchなど，多くの商用メール・ソフトでも選択できる。
MailDir形式では，1メールを1ファイルで管理するため，個々のファイル・サイズを小さくできるほか，事故が起こってファイルが消えた場合の他のファイルへの影響も少ない。一方のMbox形式の場合，ユーザーのメール格納領域が1ファイルであるため，1ファイルの容量が100Mバイトに膨れ上がることも珍しくない。
管理負荷だけでなく，性能面でもMailDir形式が優れる。例えば，Mbox形式のメール・ボックスにPOP3サーバー・ソフトの「qpopper」でアクセスする場合，プログラムの2重起動を防ぐ手段としてロック・ファイルを生成する。この際，データ保護のためにメール・ボックスの全内容を含むロック・ファイルを生成する。メール・ボックスの容量が100Mバイトあった場合，100Mバイトのロック・ファイルを生成するので，ディスク・アクセスに時間がかかってしまう。
NFSという選択肢もある
メールを中継するだけのサーバーは，台数を増やすだけで安価に性能と可用性を高められる。これに対し，メールをディスクに格納するスプール・サーバーの性能と可用性を高めるには，コストがかかりがちである。
スプール・サーバーを冗長化構成にする方法は2通りある（図4[拡大表示]）。クラスタリングによる可用性の向上と，NFSマウントによるスケールアウトである。クラスタリング時に性能を上げる手段は唯一，より性能の高いサーバー機に置き換えることだけだ。
一方のNFSマウントは，スプール・サーバーの台数を増やすことでほぼリニアにCPU処理性能を上げられる。半面，NFSマウントしたディスクへのアクセスは，SCSI接続したディスク・アクセスと比べて遅くなるほか，障害が発生しやすい。NFS利用時は，メール・ソフトからファイルの排他制御ができるかどうか，メール配信処理性能の低下が少ないかどうか，に注意する必要がある。
新日鉄ソリューションズの古川浩氏（基盤ソリューション事業部コンサルティング&エンジニアリング部コンサルティンググループ グループリーダー）は，クラスタリングによる可用性の向上を薦める。NFSによる性能低下と信頼性の低下は，ミッション・クリティカルなスプール・サーバーには不向きと見ているからだ。
一方，大成建設では，NFSマウントを積極的に利用してスプール・サーバーの負荷を分散している。NFSサーバーには米Network Applianceのアプライアンス機を採用。同時稼働する4台のスプール・サーバーからNFSマウントして利用する。
同社のメール格納方式はMbox形式である。qpopperベースのPOP3サーバー製品を使っているため，ユーザーによっては数十Mバイトを超えるロック・ファイルを生成する。社員数は1万2000人，メール・アドレスは1万5000件に達する。同社にとってディスク性能は重要である。
NFSマウントで数十Mバイトのロック・ファイルを生成しても性能が悪化しない理由は何か。それは，NFSサーバーとスプール・サーバーとを，ギガビット・イーサネットで接続したためだ。従来は100Mビット/秒のイーサネットを使っていたが，性能が悪かったためギガビット・イーサネットに変更した。「劇的に性能が向上した」（大成情報システム ネットワークシステム事業部ネットワーク&サーバー運用グループの古口泰司氏）と評価している。
DNSか負荷分散装置か
クラスタリング型のスプール・サーバーを除き，メール・サーバーはいずれもスケールアウトによる処理負荷の分散と可用性の向上が可能である。スケールアウトの方法は2つある（図5[拡大表示]）。DNSサーバーのラウンドロビン機能＊5を利用する方法と，専用の負荷分散装置を使う方法である。
DNSラウンドロビンの利点は，仕組みが単純であるため，負荷分散のための追加コストがかからない点である。しかし，システム・ダウン時，タイムアウト待ちに時間がかかることが弱点となる。
一方，負荷分散装置を使えば，仮にサーバーがシステム・ダウンしても，そのサーバーにリクエストを振らない運用が可能だ。大成建設は，NFSマウント型の4台のスプール・サーバーに対し負荷分散装置を経由してアクセスしている。負荷分散装置の利用は可用性向上にもつながる。
MXで優先順位を付ける
DNSを用いたアクセスの制御方法として，特にメールの中継用途に適した仕組みがある。メール・アドレスに含まれるドメイン名と，メールを受信するメール・サーバー名を関連付ける「MXレコード」である。メール・サーバーごとに異なる優先順位を付けて運用できる。
MXレコードの構成要素は，(1)メール・アドレスを構成する文字列の一部，(2)優先度を表す数値，(3)中継先のホスト名，の3つである。優先度は数値が小さいほど高い。
例えば，文字列「nikkeibp.co.jp」のMXレコードは，優先度50のホストが「bpns1」，優先度70のホストが「bpns2」である。メール・アドレスの末尾が「nikkeibp.co.jp」の場合で，サブドメインとなるホストのMXレコードが登録されていない場合は，優先度の高い「bpns1」にメールが届く。
MXレコードは，メールを受信するサーバーをメール・アドレスのサブドメイン表記ごとに割り振る目的，あるいは，サブドメイン表記を無効にして同一のサーバーで常時受信する目的で使われる。特に，インターネットからメールを受信するゲートウエイ部分のメール・サーバーは，MXレコードを持つのが一般的である。
寺岡精工では，インターネットから社内LANへ向かうメールの中継経路と，社内からインターネットへ出て行くメールの中継経路を，MXレコードを用いて完全に分離している（図6[拡大表示]）。MXレコードの優先度の設定を，社内DNSサーバーと社外DNSサーバーとで正反対にしているのだ。負荷分散を兼ねるが，真の狙いは，内向きと外向きを分けることによる，管理の分かりやすさだ。
