E-PostのSMTPから他のサーバへSMTP送信しているときに、他のサーバが停止するときの運用はどうすべきか

E-PostのSMTPから他のサーバへSMTP送信しているときに、他のサーバがメンテナンスなどのため丸１日や丸２日停止する場合、E-PostのSMTPはそのまま稼働させておくか、サービスを止めるべきかという運用上の課題があります。たとえば、SMTPゲートウェイの位置に立てた E-Post SMTP Server ないしは E-Post Mail Server から、内側にあるメールサーバに振り分け送信をしているような状況下で内側のメールサーバを停止せざるを得ないようなケースはそうした典型例です。ここで考えられる選択肢として下記 A.〜 C.の３通りあげます。それぞれのメリット・注意点について記します。
  1. epstdd サービスのみ停止しておく方法
    2.  epstrd（SMTP受信サービス）は稼働させておいて、epstdd（SMTP配信サービス）はサービスを停止しておく方法です。送信先サーバが稼働開始した時点で、epstdd サービスを再開します。
    （メリット）
    epstrdが稼働しているため、受領だけは行われます。メールクライアントを操作しているユーザーは、「送信」ボタンを押しても、拒絶されたりエラーになりません。
    さらに、E-Postが受領した後のメールは、メールボックスへの格納、および配送はいっさい実行されません。また配送のリトライも行われません。配送待ちのメールデータは、incoming フォルダにどんどん蓄積されていきます。
    配送のリトライが試みられないため、送信先サーバが２日間停止していたとしても、無駄なリトライは行われず、epstdd サービス再開後に、確実に配送することができます。
    （注意点）
    epstdd サービス停止期間中のみ配送しないでおくために、epstdd サービスを停止させる前には、incoming フォルダ、holding・domains フォルダにメールデータがたまっていない状態を確認した上で実施してください。 また、epstdd サービス停止期間中には、incoming フォルダ内にメールデータ（拡張子.RCPと.MSGの２個１組のファイル）がどんどん蓄積されていくことになります。
    このとき、蓄積されるファイル数が膨大にならないように注意してください。あらかじめ通常運用の中で、受領件数がどのくらいかを見積もっておき、ファイル数が数千を超えないように計画してください。
    仮に、incoming フォルダ内に膨大なファイルが蓄積された場合、配送そのものは何とか実行されますが、ファイル数が膨大になると、ファイルシステムに起因して、パフォーマンスが低下するおそれがあります。ファイル数が減っていけば、パフォーマンスは自然と回復します。

  2. epstrd・epstdd サービスの両方を停止しておく方法
    3.  epstrd・epstdd サービスの両方を停止しておく方法です。メールクライアントからの接続はエラー応答となり、すべて拒絶されます。配送そのものも当然されません。
    （メリット）
    メールクライアントにエラーが即表示されるはずですので、ユーザーがわかりやすいという点がメリットです。
    （注意点）
    epstdd サービスを停止する前には、incoming フォルダ、holding・domains フォルダにメールデータがたまっていない状態を確認した上で行ってください。

  3. epstrd・epstdd サービスを稼働させておく方法
    4.  epstrd・epstdd サービスの両方をそのまま稼働させておく方法です。メールクライアントからの接続はエラーとなりませんが、送信先サーバが停止しているのであれば、「サーバ無応答」と判断し、epstdd サービスは、既定値の設定で24時間は配送リトライを試みます。
    〔※E-POSTコントロールセンターのメールサーバ管理から［システム管理メニュー］をクリック、［SMTP送信詳細］を開いて設定を確認できます。〕
    （メリット）
    考えられるメリットは、E-Post側で行う特別な操作が特に必要ないことです。「サーバ無応答」設定時間内はリトライが続けられ、時間内であれば相手側が回復した時点で自動的に配送が成功することになります。設定時間内のリトライであれば、メールクライアントにエラーを返しません。ちなみに「サーバ無応答」設定を変えることで配送リトライを必要な時間だけ伸ばすことは可能です。
    （注意点）
    既定値「サーバ無応答」24時間の場合は、その時間は配送リトライを続けますが、それ以上応答がない場合は、配送をあきらめ、最終的に送信者に配送エラーのエラーメールを返します。
    もし、送信先サーバの停止期間が２日間の間、配送リトライを継続させるのであれば、既定値の設定を変え、48時間に変更する必要があります。
    ただし、「サーバ無応答」に応じたその時間は、配送リトライを試みるとはいっても、あくまで理論的なものであり、正確な時間ぴったりと配送リトライを試みる保証はありません。少し短くなるおそれもあります。そのため、最終的に配送エラーとなり、送信者に対して「配送ができなかった」旨のエラーメールが返ってくる可能性は十分考えられます。
    なお、設定時間内は、リトライデータが holding・domains フォルダにメールデータが蓄積され続けます。1フォルダに格納されるメールデータが数千を超えるとパフォーマンスが落ちていき、万を超えると極端なパフォーマンス低下となって現れます。リトライ関係フォルダのようすを目視で確認しながら、リトライするメールデータが万を超えないように注意してください。
以上、それぞれの注意点をふまえてどのように運用するか十分に検討してください。