いなばにっき

とある大学助手のだらだら日記

スポンサーサイト

いなばにっきはblog.1783.orgに引っ越しました。

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

メール環境どーするよ? ~POP と IMAP~

いなばにっきはblog.1783.orgに引っ越しました。

今日は実家にて次女のお食い初め。
行きがかり上、生まれて初めて魚をおろしました。結構楽しいかも。
長女のお食い初めのときのビデオがあって父が見せてくれたんだけど、色々思うところあり。

それはそうと、今日も今日とて次期メールシステムを脳内検討。
本日のお題は IMAP でいくのか POP でいくのか。

おおまかに言っちゃえば、
POP = メールはクライアントが受信した時点でサーバから削除。メールの管理はクライアントまかせ。
IMAP = メールは受信してもメールサーバに置いておく。クライアント側でフォルダ間移動があれば、それに対応してサーバ側でファイル移動。
ということなんだけど、ウチの現行システムのように、Web メール前提だと、POP を使っていても運用的にはかなり IMAP に近い。

Web メール前提で今後もいくのかどうかについてはまた後日検討するとして、とりあえずここでは、Web メール前提でいくとする。

そーすると、POP の場合には、受信時の動きは
・メールサーバにメールが届く
・Web メールサーバがクライアントとして受信する
・Web メールサーバ上の、各ユーザに割り当てられた領域に、メールを保存
という流れになる。
IMAP の場合には
・メールサーバにメールが届く
・Web メールサーバがクライアントとしてメールサーバ上のメールを読む
・メールサーバ上の、各ユーザに割り当てられた領域にメールを保存
となる。

ウチの現行システムの場合、Web メールで受信したメールは実際にはメールサーバから NFS で提供されたリソースに対して書き込むので、ディスク I/O の問題だけ考えれば、IMAP に移行した方が効率的な気がする。現状だと
・メールサーバにメール到着(メールサーバのディスクにローカルに書き込み)
・Web メールサーバでメールを受信(メールサーバのディスクからローカルに読み込み AND メールサーバのディスクに NFS 経由で書き込み)
となるので、ディスク回りの効率がワルゲ。

ただし、前の職場での実績を考えると、IMAP サーバのプロセスは POP サーバのそれに比べて重め。特に、検索をしたときなんかは、かなり CPU 使用率を奪われることになる。

このあたり、どちらがよいのか非常に微妙だけど、現行の方法だと検索時には
・実際の検索をするのは Web メールサーバ
・検索に使うデータは、別サーバ(メールサーバ)から NFS で提供されたリソース
ということなので、ある意味で微妙に処理が分散できていると言えなくもない。

んー、これ微妙だな。

IMAP サーバの処理を別のサーバに分けるとすると、また例によって NFS なりなんなりでリモートのディスクをごにょごにょしなきゃいけないから、それはそれでパフォーマンス出なそうだしなぁ。

あと、一般論で言えば IMAP の場合メールを全てサーバ側に置いておくので、ディスク容量が圧迫される、という傾向はある訳だけど、今の運用のパターンなんかをみていると、POP でも基本的にはメールは「サーバから削除しない」設定なので、その意味ではあんまり変わらないはず。




スポンサーサイト

メール環境どーするよ? ~mbox と maildir~

いなばにっきはblog.1783.orgに引っ越しました。

職場のメール環境をどうしようかいろいろ考えていて、なんか頭んなかがとっちらかってきたので数日に分けてちょっとまとめてみようと思います。

さしあたって考えなきゃいけないこと

・メールの保存形式 [mbox or maildir]
・メールの取得形式 [IMAP or POP]
・メールの運用方法 [Webメール or 通常のクライアント]
・SPAM 対策どーするよ
・切り替えとかどーする

つーことで今日はとりあえずメールの保存形式についてちょっと考えてみます。個人的なメモつーことで。

まずは、mbox と maildir のまとめ。

mbox/maildir は、狭義には「届いたメールをどこに保存するか」の違いであり、広義には「届いたメールをどんな形式で保存するか」の違いです。

まずは狭義の方。

メールがメールサーバに届いたとき、メールをどこに置くかでふたつの考えかたがあります。

まず、届いたメールを /var/spool/mail/[ユーザ名]などに置く、つまり、同一ディレクトリに複数のユーザのメールを置くという方法があります。

一方、届いたメールを /home/[ユーザ名]/Maildir などに置く、つまり、ユーザごとに異なるディレクトリにメールを置くという方法もあります。

mbox / maildir を狭義に用いる場合、この手の「メールをどこに置くか」を含む場合があります。前者が mbox で後者が maildir です。


次に広義の方。

メールを「どんな形式で保存するか」にも二つのの考え方があります。

まず、あるユーザ宛に届いたメールをひとつにまとめて管理するという方法があります。
一方、あるユーザ宛に届いたメールを1通ごとに別ファイルとして管理するという方法もあります。

前者が mbox の形式で後者が maildir の形式です。


ただ、「届いたメールを mbox 形式で(単一のファイルにまとめて)ユーザごとのディレクトリに置く」という運用も考えられるので、
・どこに置くのか
・どう置くのか
は別の問題として切り分けた方が良いように思います。


[どこに置くのか]
個人的には、大学などの環境で運用する場合、届いたメールは各ユーザごとのディレクトリに置くべきだろうと考えます。
quota(容量制限)のかけやすさ、ということもありますし、例えばホームディレクトリを置くディスクを教職員と学生とで分割したりすると、多少ディスクI/Oの負荷が分散できます。○○年度入学、みたいな形で分割してもいいかも。ただし、ホームディレクトリを置くディスクを入学年度で分けるのは、運用としてはちょっと面倒ですが。教職員と学生、という分割が妥当かな。


[どう置くのか]
これも個人的見解ですが、maildir にすることのデメリットは非常に少ないと思います。

mbox の場合、同一ファイルに全てのメールが書き込まれるので、不運にも mbox のファイルになんらかの障害が発生すると全てのメールが読めなくなってしまいます。また、同じファイルにどんどん追記していくため、ファイルサイズが大きくなり、パフォーマンスがリニアに低下します。

maildir の場合、読めないのは個別のメールになるので、被害は少なくなります。また、トータルでディレクトリのサイズが大きくなっても、パフォーマンスの低下はさほど大きくありません(少なくともmboxよりは)。

もうひとつ、現在のうちの環境なんかもそうなんですが、メールを保存する領域を NFS などでマウントしている場合、排他制御がうまくいかないと mbox の場合ファイル破損のリスクが高まります。
maildir の場合、新しいメールが届いた場合には別のファイルを生成するし、既読未読のようなフラグもファイル名として持たせるので、基本的に「すでに届いたメール(のファイル)に後から何かを追記する」というアクションがありません。なので、排他制御がうまくいかなくてファイルが破損する、というリスクは極めて低いと思います。

なお、経験的には、pop 受信時、maildir 形式でも、おかしなメールが届いた場合、一部の環境で受信できなくなることもあるようです。


[まとめ]
つーことで、maildir を避ける積極的な理由は無いように思います。
あー、あるとすれば、IMAP や POP が maildir に対応していないというケースかな。
既に貯まっているメールについては、mbox から maildir に変換するスクリプトなんかもあるし。

Top

HOME

いなば

Author:いなば
とある私立大学のダラダラ助手。
機械には人格があると信じて疑わない。
最近、体脂肪率がすこ~し下がってとってもうれしい。

あわせて読みたい

にほんブログ村 教育ブログ 大学教育へ

ネットショップチャットレディSEO対策SEO誕生日プレゼントパワーストーン自動車

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。