FAQ19-97

IMAP4サーバの高負荷原因を調べるため、特定クライアントからのアクセスを一時的に拒否するには new!

【回答】
プログラムインストールフォルダにrejectimapip.datを作成し、接続拒否対象のIPアドレスを記述することで、そのIPアドレスからのIMAP4接続を拒否できます。IMAP4認証ロックアウト・IPロックアウト機能の有効化設定を行わなくても、このファイルの記述だけで接続を拒否できます。

高負荷の原因を切り分けるため、疑わしいクライアントを一時的に接続拒否し、CPU使用率や同期処理の変化を確認します。逆に、調査対象の1台だけを接続させ、他のクライアントを拒否して動作を確認する方法もあります。

【事前準備】
調査時間と影響範囲を決め、対象利用者へIMAP接続が一時的に利用できなくなることを周知します。IMAP4ログからサーバが認識している接続元IPアドレスを確認し、対象端末と対応付けてください。同じ接続元IPを複数端末・アカウントが共有する場合、そのIPからの接続全体に影響する点に注意してください。
rejectimapip.datが既に存在する場合は、変更前に内容をバックアップします。既存の拒否設定を上書きしないようにしてください。

【IMAP4詳細ログを取得する】
FAQ05-14に従い、IMAP4詳細ログ（receiveimap4）の取得に必要なレジストリ設定とフォルダ作成を行い、IMAP4サービスを再起動します。この再起動は接続拒否ファイルの準備後にまとめて実施してもかまいません。サービス再起動は他の利用者にも影響するため、調査時間内に実施してください。

【接続拒否ファイルの作成場所】
プログラムインストールフォルダに、テキストファイルとしてrejectimapip.datを用意します。インストール先を変更している場合は、実際のプログラムインストールフォルダに合わせてください。

C:\Program Files\EPOST\MS\rejectimapip.dat

【ファイルの記述方法】
拒否する接続元IPアドレスを1行に1件記述し、その直後にTAB文字を入力します。TABで区切られた2番目の接続時間情報以降は記述しません。

192.0.2.10[TAB]
192.0.2.11[TAB]
192.0.2.12[TAB]

上記IPアドレスは説明用の例です。実際の接続元IPアドレスへ置き換えてください。[TAB]という文字列を入力するのではなく、TAB文字を入れて保存します。ファイル名がrejectimapip.dat.txtにならないよう、拡張子も確認してください。

通常の記録形式は「接続元IPアドレス[TAB]接続時間情報（シリアル値）[TAB]iplock」ですが、今回の調査用設定では接続時間情報以降を省略します。この形式は永続的ロックアウトとなり、時間経過では自動解除されません。「一時的な拒否」とするには、調査終了後に手動で解除する必要があります。

【拒否の適用と動作確認】
ファイルを配置し、詳細ログ取得設定に必要なサービス再起動を実施した後、対象IPから新たなIMAP接続を試します。拒否IPであることを理由に接続が拒否された場合、その理由はreceiveimap4に記録されます。対象以外の端末から接続できることも確認してください。
この設定は接続拒否のためのものです。接続拒否後も負荷がすぐに下がらない場合は、既存処理の継続状況をログで確認してください。

【負荷原因の切り分け】
拒否前後のCPU使用率、接続数、同期の進み方、ログの時刻を記録します。調査対象を段階的に変更し、一度に複数の条件を変更しないようにすると比較しやすくなります。1台だけを接続させる調査では、他のクライアントが実際に接続していないことをログで確認してください。

同じPCに別のメールソフトがある場合は、同じアカウント・同じ接続条件でフォルダ同期を比較することも切り分けの参考になります。接続拒否によって負荷が下がった場合でも、その端末だけが根本原因であると確定したわけではありません。メールボックスの状態や要求内容も併せて調べます。

【調査終了後の解除】
rejectimapip.datを任意の別名へリネームすれば、同ファイルに記述されたIPアドレスに対するロックアウトは無効になります。リネームはファイル全体の拒否設定を無効にするため、調査前から必要な拒否設定があった場合は、バックアップした元の内容へ戻し、既存設定を維持してください。
解除後は、接続を拒否していた対象端末から新たに接続し、IMAP接続と同期が再開できることを確認します。変更前後のファイルと調査記録を保管し、永続的ロックアウトの解除漏れがないことを確認してください。

【改善しない場合】
対象クライアントを絞っても高負荷が続く場合は、receiveimap4とIMAP4ログ、CPU使用率の推移、Windowsイベントログを採取してサポートへ提示してください。サポート回答では、サーバ再起動による確認も挙げられていますが、ファイルシステムの不調やデッドロックが確定したものではありません。再起動は業務への影響を考慮し、事前に必要なログを保存してから検討してください。

（関連FAQ）
●IMAP4の詳細ログ（receiveimap4）について
●IMAP4接続時の「IPロックアウト機能」について
●IMAP4認証時の「認証接続ロックアウト機能」について
●IMAPでFETCH要求後にログアウトしても、サーバ側の処理が続くことがある