エラーメールの処理の設定について
お世話になります。おすすめプランで約1年使わせていただいております。
今まで特に問題なく使用しておりましたが今月に入り、配信エラーの戻り先アドレスからの送信キューが蓄積し、サーバのリソースを圧迫している旨の連絡がサーバ管理者からありました。
送信キューの内容を確認したところ、hotmail やyahoo、msn 等のウェブメール宛のエラーメールの処理（迷惑メールフィルタによる？）を行っているようなのですが、圧迫しない程度の処理にするにはどのような設定をすれば良いでしょうか？
関係しているかは不明ですが、12月3日にバージョンを1.44から1.52へアップデートしました。
平素はMilkyStepをご利用いただきまして誠にありがとうございます。
お客様の方で、エラーメールのアドレスをきちんと設定し、運用なさっているという仮定でお話しさせていただきます。
まず、ご存知かもしれませんが、現在のMilkyStepのエラーメールの処理は、相手先に何らかの理由でメールが送れなかった時に、相手先メールサーバからのエラーメールが、エラーメール受信用メールボックスに返されるという前提のもと処理を行っております。
つまり、エラーメール専用の受信BOXに届いたエラーメールに関しては、処理時に完全に消去しますので、エラーメール専用の受信BOXの容量が圧迫されているということはまず考えにくいと思います。
現在世の中に存在するメールサーバは、ほとんどの場合何かしらの配信エラーが発生した時には送信元のエンベロープアドレス（＝エラーメール受信用アドレス）にメールを返してくれる設定になっています。
しかし、相手先メールサーバの設定やエラーの原因（Connection Time Outなど）によっては、一定回数メールの再送を試み、メールキューがメールサーバ間を往復し、一定回数再送が失敗した時点でエラーメールを返却する仕様になっているものや、エラーメール自体を配信せず、上記の再送の繰り返しによってメールキューが一定期間で自然消滅するまで特に対処を行わないもの、ホスト・メールアカウント自体が存在しないのにもかかわらず、恒久的エラーコードを返さないもの、またごくわずかではありますが最初から応答コードやエラーメールを返さないものも存在します。
このような再送処理を繰り返し行っているために、メールスプール（配信処理中のメールキューが蓄積するフォルダ）に存在し続けているものが、お客様のサーバを圧迫している実体かと思われます。
しかも、配信エラー時の再送間隔は、一般的には徐々に長くなる仕様になっています。
例えば、１回目に失敗したら１０分後に再送、２回目に失敗したら３０分後、３回目は１時間後、など。
したがって、定期的にメルマガを配信した場合、毎回一定数以上の上記のような再送処理が行われるメールアドレスがリストに含まれていれば、必然的にメールスプールに溜まるキューはどんどん増加していくことになります。
ただ、当方も、毎日12000件以上のメールアドレスに１日２回～３回、実験的にメルマガを配信していますが、約半年メールキューのクリーニングを行わず放置した状態でも、エラーによりスプールに溜まっているキューは実績として約200件ほど（容量は約1.5MB）です。
（全配信数の0.045％）
これに関しては、お客様のリストの質と当方のリストの質が違うので、一概に比較はできませんが、スプールにキューが溜まり続けるというのは、どちらにしろ好ましい状況でないことは確かです。
現在のお客様の環境で、約１年でスプールを圧迫するということは、最低でも半年に１回は、スプールのクリーニングを行うことをお勧めいたします。
クリーニングの仕方などは、サーバのサポートに対応してもらえると思います。
この溜まったキューを一括で削除してしまうという方法もありますが、理想としては、一件一件エラーになった宛先を確認し、メルマガのリストにまだ残っていれば、それを手動で削除（もしくは削除してブラックリストに登録）していくのが、長期的に考えると望ましいかと思います。
このようなエラーメールがスプールに溜まってしまう現象は回避できないのか？というと、技術的にはできなくはありません。
定期的にスプールの中身を見に行き、エラーと思われる文字列とその宛先をパースし、キューは削除し、メルマガのデータベースに接続して、その中にこのリストがあれば削除する、というようなプログラムを組むことで実現可能です。
もしくは、このような処理をデーモンレベルで行ってくれるMTA（メール配信エンジン）を開発、または既存のMTAをチューニングすれば可能です。
（実際にそうやってシステムを納めている会社やASPサービスを展開している会社はたくさんあります）
しかし、これを実現するためには、プラットフォーム（OS）やそのバージョン、MTA、コマンド名などがある程度固定されている必要がほか、管理者権限を持っていなくてはいけない場合もあります。
当ソフトや他の売り切り型CGIの大きな主旨の１つである「様々なサーバ環境でより多くの人により安価に」メールマガジン配信システムをご提供することは非常に難しくなります。
サーバ環境によって組むプログラムが変わってきますから、それこそお客様１人１人に対する受注開発、またはASP型サービスとして提供しなくてはならなくなります。
もしそうなれば、現行のこの価格で、しかも１回きりの買い取り式では、間違いなくご提供はできなくなってしまいます。
MilkyStepが、大学から予算のついている研究室の開発案件であれば話は別ですが、経済的観念から言うと、これがCGI買い取り型ソフトとしての限界ということになります。
もしかしたら、将来的には、OSやMTAの種類を自動判別してそれぞれにあったスプール処理を実装したCGIが登場するかもしれませんが、現在までの実績やサポート面でのリスクやを考えると、当面は望めないのではないかと思っております。
結論としては、MilkyStepだけでは対応できないということことになってしまい申し訳ありませんが、以上のことをご考慮いただき、今後もメルマガ運用にあたっていただければ幸いです。
詳細なご説明ありがとうございます。
定期的なメールキューのクリーニングで対応していこうと思います。
今後ともよろしくお願い致します。
kou 様
「エラーメールを返さないMTAもある」と書きましたが、これは本当にごく一部であり、ほとんどの場合はスプールに滞在し続けたとしても、所定の滞在時間を超えた場合、最終的に送信者にエラーメールを返すものと考えていいと思います。
もしkou様の環境が、VPSや専用サーバであり、root権限が使用できる場合は、MTAのキューがスプールに滞在（生存）できる最大時間を短くすることで、このようなスプールの圧迫を解消できると思います。
この設定は、MTAによって変わってきますので、ここですべて詳細を書くことはできませんが、sendmailだったら基本設定ファイルを変更することで割と簡単にできます。
http://www.kkoba.com/linux/mail.shtml#14
qmailの場合はqueuelifetimeという項目で設定できます。
http://www.ayamizu.com/mail_retry.htm
以上、ご参考になりましたら幸いです。