災害時の職員招集/安否確認を、eメール（携帯電話のメール機能？）で行うアプリケーションの開発が佳境に入ってきた。現在運用テストを行っている状況だが、なかなかの出来で、上機嫌なのである。
送信前にリスト生成、送信キュー生成をするのだが、この際、定義されている複数のメールサーバーに分散する。また受信メールボックスを複数に分散することで、受信時の負荷分散も考慮されている。
送信前に宛先ユーザーに対して、送って良いのか悪いのかを判断（すでに返答を受信していればスキップ・・など）して1通送ったごとに送信状況をDB書き込みする。
受信は、定義した分のメールボックスを指定した巡回時間で自動受信。スパム判定語句リストでスパムかどうかを判定した上で、件名、本文から値を読み取りDB書き込み。
送信メッセージと受信メッセージの対応を取りながら、招集応答、安否確認応答を判定する仕組み。
結果は、1000通のメッセージを1台のメールサーバーで送信した場合に、所要時間が5分。送信サーバーが増えればその分、時間が短縮される。
受信は、1000通のDB格納が12分。こちらも定義するPOPアカウント（メールボックス）が増えれば時間が短縮できる。
1万通なら計算値としては、1時間程度、受信は2時間。10万通レベルになると複数サーバーを考慮する必要があるが、仮に2台のメールサーバーを準備すれば、送信で5時間、受信で10時間で完了する。
つまり、災害が発生して、10万人の市民全員に確認メールを送信し終わるまでに5時間。受信も送信完了から半日あれば処理できることになる。（送受信待機時間を考慮しない場合）
Webの場合は、リアルタイム処理なので負荷の予想や負荷分散構成が難しいが、メールなら非同期アプリケーションなので、送受信タイミングをコントロールできる。しかも、メールサーバーがバッファとなり、再送処理が行われるし、メッセージがロスする可能性もかなり低い。（Webなら待ち時間が発生したり、タイムアウトが起こる）
さぁ、今度は1万件や携帯メールへの送信テストだー。（かなり上機嫌）
