休日にもログを監視した方がよい

　送信側メールサーバは、受信側メールサーバへのアクセスに対して応答なしの場合（ネットワークの不通や、サーバの故障か停止が考えられる）、コネクション拒否応答が返された場合（MTAデーモンが停止していることが考えられる）、応答コード「4xx」が返された場合（クライアントの逆引きや送信者ドメインのDNS検索に失敗した場合、メールボックスに一時的に書き込みができない場合、グレイリスティングにかけられた場合など）に、適度な時間間隔で送信をリトライする。リトライ期間は、古くから使われているsendmailのデフォルト設定では5日である。Postfixでも同じである。
　リトライ期間のデフォルトがなぜ5日なのか。かなり運悪く長時間にわたってメールサーバのトラブルが続いたというケースを想定してみよう。
　企業や学校などで、金曜の17時にスタッフが帰った後、運悪く18時にハードディスクが故障した。さらに運悪く、月曜は祝日だった。火曜の朝、スタッフが出勤して故障に気付き、サポート業者を呼んだ。午後になってサポート業者が到着。ディスクを交換して、システムを再構築し、バックアップからデータを復元して、動作試験。復旧したのは20時だった。ダウン時間は4日と2時間。送信側メールサーバが5日間リトライするようになっていれば、こういうケースでもメールは届く。
　ゴールデンウィーク、1週間の夏期休暇、または年末年始の期間中にサーバの監視をまったくしなかった場合は、ダウン時間が5日を超えることがありうる。しかし、リトライ期間をあまり長く設定すると、ついにメールが送達しなかった場合に送信者がそれを知るのが遅くなってしまう。5日間のリトライ期間は、デフォルト値としてちょうどよいだろう。
　リトライ期間は、Postfixではmaximal_queue_lifetimeパラメータ（バウンスメールについてはbounce_queue_lifetimeパラメータ）で設定できるが、通常のメールサーバでは、あえてデフォルトから変更している人は少ないだろうと思う。ただ、5日というデフォルト値が決められたのは、インターネットの黎明期。相手サーバは故障しているかもしれないから気長に待ってあげようという心が背景にあったと考えられる。インターネットを使ったビジネスが忙しくなった今は、そこまで悠長に待ってはいられないと考える人がいても不思議はない。
　S25Rのルールに引っかかる、オンラインショッピングの確認メール送信サーバが2日でリトライアウトするケースがあることがわかった。素のS25R方式を使っている組織サイトで、週末にスタッフが不在になる場合、金曜の夜に送信が開始されたメールは日曜の夜にリトライアウトしてしまう。オンラインショッピングの確認メールは、受信者にとって受け損なうと困る大事なメールである。
　私は毎日朝と夜には拒絶ログソーティングスクリプトでリトライアクセスの有無を確認している。旅行中にも（PHSの電波が届かない所へ行かない限りは）毎日モバイルで確認している。だから、1日以上リトライしてくれるメールは受信できる。しかし、素のS25R方式を使う組織サイトにとっては、3連休があることを考えればせめて4日はリトライしてほしいところだろう。
　とはいえ、インターネットの世界では、サイトのポリシーの自由がある。S25R方式を採用するのも自由なら、リトライ期間を2日に設定することも自由である。S25Rに引っかかるすべての他サイトに4日以上のリトライあるいは逆引き名の変更を要求することは非現実的である。自サイトのポリシーに伴う副作用の問題は、他サイトのポリシー変更を要求することによってでなく、自らの努力で解決すべきである。
　私が協力者からの情報も集めて公開しているホワイトリスト情報を利用すればめったなことはないとは思うが、それでも休日にも一日一度はリモートでログを監視した方がよいだろう。
　さもなければ、Rgreyなどでホワイトリスティングを自動化することを考えた方がよい。リトライするスパムがすり抜けてしまうおそれがあるが、私のサイトでの観測によれば、受け入れまでの遅延時間を25分に設定すればほぼ防げることがわかっている。また、正当なメールが25分未満でリトライアウトするケースは見つかっていない。
　なお、正当なメールが1時間ほどでリトライアウトするケース（メールマガジン、携帯電話サイトからのエラーリターン）があることがわかっているが、これは素のS25R方式では、あらかじめホワイトリスト情報を取り込んでおくことでしか救済しにくい。素のS25R方式を使う組織サイトでは、こういうリスクがあることをユーザーに説明しておいた方がよい。また、救済できなかったリトライアクセスを見つけたらユーザーに知らせるようにした方がよい。
　もっとも、送信側が1時間ほどでリトライアウトするということは、受信側サーバの故障あるいはメンテナンスにぶつかってもメールを届けたいという意思がないということだから、受け損なっても大して問題のないメールだと考えてよいと思うが。