エラーリターンを受け損ねた

　私が運用しているメーリングリストのメンバーの誰かがソフトバンクの携帯電話へメールを自動転送して、そこで何かのエラーになったらしい。エラーリターンの送信アクセスがあった。
　softbank.ne.jpのサーバがルール1に引っかかるということは協力者から報告されていて、ホワイトリスト情報に掲載しているのだが、自分のホワイトリストに登録し忘れていた。

Jul 20 10:50:50 mmrts020p01c.softbank.ne.jp [210.228.189.186]
Jul 20 11:10:42 mmrts020p01c.softbank.ne.jp [210.228.189.186]
Jul 20 11:50:41 mmrts020p01c.softbank.ne.jp [210.228.189.186]

　1時間、3回のトライで止まってしまい、ホワイトリスト登録が間に合わなかった。「4xx」の応答に対してエラーリターンの送信を長時間リトライしないのは、携帯電話メールサービスではメールトラフィックが多いので、リソース負荷の増大を避けるためだろう。もっとも、メーリングリストの一時的なエラーリターンと推測できたので、受け損なったところで大した損失ではなかった。むしろ、こういうケースがあると知ったことは怪我の功名だった。
　Rgreyならば受け損なわずに済んだだろうが、素のS25R方式だと、リトライするスパムに強い代わりに、こういう時に受け損なう。メールマガジンのリトライが1時間余りで止まったケースもあった。素のS25R方式を使っている人がこういう受信失敗を避けるためには、なるべく私の公開ホワイトリスト情報を利用するのがよいだろう。
　組織サイトのメールシステム管理者は、再送が短時間で止まってしまった拒絶ログを見つけた時には、受信者に照会をかけるのがよいだろう。受信者は、心当たりがあればそれで何らかの判断ができるだろう。
　S25R方式にはこういうリスクがある。しかし一方、スパム対策をしなければ、安いサーバを使っていてユーザー数の割にディスク容量が大きくない場合、突発的に大量のスパムが押し寄せた時にスプールあふれを起こすリスクがある。受けてからフィルタリングするSpamAssassinなどのスパム対策方式でも、偽陽性判定に備えてスパムを全部ディスクに蓄積しておかなければならないので、やはり同じである。そのリスクを低減するためには、サーバのリソースの増強にコストがかかる。S25R方式を使えば、ディスクに蓄積されるスパムは少なく抑えられるので、サーバにかけるコストを増やさずにすむ。受け損なってもさほど損失が大きくないメールを受け損なうリスクに比べて、利益の方が大きいと思う。
　S25R方式を正しく運用して効果を喜んでいる人たちは、正当なメールの救済が間に合わないリスクをゼロにできないとわかっても、S25R方式を放棄しようなどとは思わないだろう。