週末の受信失敗はあきらめてもよい

　前回、休日にもログを監視した方がよいと述べた。しかし、別の考え方が浮かんだので、今回はあえて逆説的なことを言う。オンラインショッピングの確認メールが2日でリトライアウトし、週末の間に救済できなかったからといって、それが取り返しのつかないほどの問題だろうか。
　週明けにスタッフがログを確認し、リトライアウトしているアクセスを見つけたらユーザーに知らせる。ユーザーは、どうしても受けたかった確認メールだったならばオンラインショッピング会社に問い合わせればよい。
　メールサーバの運用者は、正当なメールを受信するために最善の努力をすべきであるが、最善の努力としてどこまでできるかはサイトの事情による。スタッフが自発的に休日にもリモートでログを監視してくれればそれに越したことはないが、スタッフの少ない組織サイトでは、週末にレジャーにも行けないような働きをスタッフに命令するわけにはいかない。金曜の夕方にログを確認して、必要なホワイトリスト登録をしてから帰り、月曜（3連休の場合は火曜）の朝にまたログを確認して、必要なホワイトリスト登録をする。これによって、Postfixやsendmailのデフォルト設定で5日間リトライするメールの受信は十分保証できる。そこまでが精一杯であれば、それがそのサイトの最善の努力である。スパムを受信することによるリソース消費のリスクと、リトライ期間の短い正当なメールを受け損なうリスクとのバランスや、スタッフの負担を勘案して、それでよいと判断するなら、それがそのサイトのポリシーである。
　5日よりも長くリトライするメールサーバはまずないと思われるので、長期休暇中に5日間のリトライを放置するようなことはしないでほしいが、2日以下しかリトライしないメールを運悪く週末の間にリトライアウトさせてしまったからといって、送信側に迷惑をかけたと思う必要はないだろう。リトライ期間を短く設定している送信側サイトは、受信側サーバが故障した場合に、復旧までもう少し長く待ってあげるよりも送達失敗の確率が増えるというリスクを当然承知しているはずである。送達失敗のリスクは、どうしても届けたいメールならば送信者が再送するか、受信者が知ったら送信者に再送を依頼するか、あるいは別の連絡手段をとるなどして、人手でカバーすればよいのである。
　リトライ期間の短いメールをリトライアウトさせてしまうリスクをS25R方式の問題点として批判する向きもあるかもしれないが、Postfixのオペレーションがどうにかできるくらいのスタッフしかいない、お金もないというサイトが使えるスパム対策がほかにあれば示してもらいたいものである。増える一方のスパムからネットワークリソースやユーザーの業務を守ることは多くのサイトにとって緊急課題である。応答コード「4xx」を返して送信を待ってもらうこと（言わば、一時的トラブルのふりをすること）は、リソースを守るための自衛権の範囲内である。
　S25R方式を批判することは自由だが、スパムの被害にやむにやまれずS25R方式を採用するサイトのポリシーを批判する権利など誰にもない。そのサイトが、正当なメールを受け入れるために最善の努力をしている限りは。