メールがループしたときの動きについて
アカウントの自動転送設定で、転送先にメーリングリストアドレスを設定し、一方メーリングリストの設定でメーリングリストメンバーとして自動転送元のアカウントを設定した場合、いわゆる“メールのループ”が発生します。
さらに互いに転送先のアドレスとして自動転送を設定したような場合なども“メールのループ”が発生してしまいます。
その際、E-Postシリーズには無限ループにならない防止策が取られています。では、どのような仕組みと動きでこのループが最終的に止められることになるのでしょうか。
自動転送やメーリングリストの設定などによって、メールのループが発生した場合、無限ループにならないように、防止策になっているのが Received:ヘッダのループ数制限です。その設定値がデフォルトで "20" に設定されています。
ループが発生した場合の動きを順番に追ってみます。
自動転送・メーリングリストによって、内部ドメインのアドレスが指定された場合、配送サービスの epstdd が送信する相手は、SMTP受信サービスである epstrd になります。
これは制限に引っかからない限り続きます。
20回を越えようとした時点で、上記のReceived:ヘッダのループ数制限に引っかかり、epstrdは、"554 5.4.6 too many Received: headers." の応答コードと理由で、相手側、この場合は epstdd に対して拒絶します。
送ったepstddは、永続的エラーである500番台の拒絶応答を受けますので、epstddの「配送詳細」設定ダイアログにある「リトライ回数（受信拒否）」の設定された回数まで、送信リトライを継続します。送信リトライされる総時間や間隔は、その設定回数と「リトライ間隔」「リトライ間隔のまま」の設定内容によって変わってきます。
この間、epstrd は "554 5.4.6 too many Received: headers." の応答コードと理由で拒絶を続けます。そしてその間、epstdd は、メールキューの incoming フォルダから、リトライ関係のフォルダである domains フォルダと holding フォルダに待避させながら、規定された分だけ、リトライを試みます。
この時点で incoming フォルダを表示してみると、メールデータがあることが確認されるはずで、リトライを試みている最中であることが確認できます。
規定の送信リトライが終わると、リトライをやめ、配送失敗として処理されます。配送失敗された記録は、faillog に記録されるほか、エラーメールを送信元アドレスに送れるときや、管理者アドレスにもエラーメールを送信する設定になっているときは、エラーメールを送信します。
（関連FAQ）
●Received:ヘッダのループ数制限＝SMTPホップ数の制限を緩和するには
●リトライ回数やリトライ期間の設定について
●「リトライ間隔のまま」チェックボックスの意味について
●リトライ処理が行われるときの情報とフォルダについて