逆引き論争

　reject_unknown_clientはスパム対策として有害だという主張がある。そのとおり。ログも確認せず、逆引きできない送信元ホストを蹴りっぱなしにする運用は有害である。しかし、ログを見て、逆引きできないホストからのリトライアクセスを見つけてホワイトリストで救済するならば、reject_unknown_clientは有害ではない。
　対して仙石さんは、「（送信元の）素性を調べる手段としてDNS逆引きは、ある程度の合理性を持つ」と主張しておられる。まったく同感である。ただ…
　「逆に言うと、弊害をきちんと理解していれば、DNS逆引きの結果を迷惑メール判定に用いることは受信側の判断だろう。DNS逆引きができないホストからメールを送らざるを得ないサイトにとっては釈然としないところもあるとは思うが、受け取らない権利があるのもインターネットである。」――いや、受信側は、正当なメールを受信するために最善の努力をすべきである（「逆引きできないホストからの正当なメールを受け取らないのも受信側のポリシーとして認められる」という解釈は仙石さんの本意ではないと信じるが）。
　「「まともに管理されているホストに逆引きがないというのもふつうに存在する」のは事実だと思うが、「まともに管理している」ということを通信相手に伝える努力はすべきではないだろうか？通信はお互いの協力があって初めて成り立つものであるから、spammerと区別してもらうための努力もせずに、spammerと一緒にするなと叫んでいるだけでは解決にならない。もちろん、spammerと区別してもらう方法がDNS逆引きの設定だけであると主張するつもりはない。」――確かに、まともに管理していることを送信側が逆引きによって伝えてくれれば、スパム対策をする受信側としてはうれしい。しかし、努力というほどのことを受信側が送信側に求める必要はない。送信側はただ、まともなMTAを使っていてくれればよい。それで、逆引きできなくてもリトライの検出によって、まともなメールサーバであることがわかるから。
　S25R方式のコンセプトは、逆引きできない正当なメールサーバがあるという現実を認めている。逆引き名からアクセス元をエンドユーザー回線と推定するルールを定めているが、それに引っかかる正当なメールサーバがあることも承知している。正当なメールサーバを蹴るリスクがあるから、蹴る時に返す応答コードは「450」である。送信をある程度遅延させることは送信側に受忍していただくが、リトライを検出して正当なメールを救済するのは受信側の努力で行う。
　送信側に対して「逆引きを設定してくれ」などとは要求しない。まして「S25Rの拒否条件に引っかからない逆引き名にしてくれ」などという傲慢なことは言わない。そんなことを他人に要求して対処を待つよりも、自分が選んだ対策方法に伴う副作用の問題はさっさと自分の手で解決する方が早い。その覚悟があれば、すぐにも非常に効果的にスパムを排除できるのである。
　S25R方式は、逆引き検査によるスパム対策は是か非かという論争をとっくにアウフヘーベンしてしまっていると思うんだけどなあ。

（関連記事）
DNS逆引きチェックは有効なスパム（迷惑メール）対策