佐藤さんから聞いた話。IPアドレスの割り当て1個の接続サービスを利用している会社から某大手ISPにメールを送ろうとしたら、リトライアウトでエラーリターンしたとのこと。先月（9月）のことである。そこに示されたエラーメッセージは、「may not be mail exchanger」という、私が作ったものだった。応答コードは「450」だった。
このメッセージ文で検索すると、困っている人の情報が得られると佐藤さんに言われて、検索してみた。そのISPへのメールのエラーリターンに「550」の応答コードが示されているのがさらされていた（日付はやはり9月だった）。これには驚いた。
裏を取ろうと、ダイヤルアップ接続で手動のSMTPアクセスをかけてみた。RCPT TOコマンドに対する応答コードは「250」。拒否していない。私がダイヤルアップ接続に使っているISPのダイヤルアップ用IPアドレスの逆引き名はルール5（逆引きFQDNが5階層以上で、下位2階層の名前がともに数字で終わる）に引っかかるが、もしかしたらルール5を入れていないのかもしれない。私は8個ブロックのIPアドレスをもらっていて逆引き権限の委譲を受けているので、予備サーバのIPアドレスの逆引き名を「219-163-213-19.rev.reto.jp」とS25Rに思い切り引っかかるものに変えて、予備サーバからアクセスしてみた。「450」で蹴られた。「550」を返していたという裏は取れなかった。
それにしても、正当なメールをリトライアウトさせてしまったとはどういうことだろう。通常のMTA（くだんの会社ではqmailを使っているとのこと）なら数日間リトライする。その間ずっと、ログを確認せずに放置していたのだろうか。
私は、善良な送信者や受信者をハッピーにするためにS25R方式を発表したのである。善良なユーザーを困らせてはいけない。正当なメールを「450」で蹴ってしまうというリスクをちゃんとコントロールしてくれなければ困る。正当なメールを救済することには真剣勝負の覚悟で取り組んでほしい。リトライのログを確認しやすくするために、私は拒絶ログソーティングスクリプトを提供している。まめにログを確認することができないなら、Rgreyなどでリトライアクセスの救済を自動化することを考えてほしい。それさえしないなら、S25R方式は使わないでほしい。
大手ISPでもS25R方式が導入されたとは光栄なことではあるが、正しく運用してくれているのだろうか。導入初期に失敗はあったけれども今はうまくやっていると信じたいが。
そのISPはS25R方式の導入を公表していないので、私がここで社名を公表するのは差し控える。もっとも、私が作ったメッセージ文で検索すればわかってしまうけれども。
2 件のコメント:
なんというか、想定していない使われ方をして、それに対して文句を言われたりすると、ちょっとげんなりしますよね。
自分は、多少false negative増えても、なにもしなくてもよりfalse positiveが少なくなる方向で、SMTPセッションでのフィルタについてはログ見なくても済むようなものを目指すようにしてます。
結局、意識が下のほうの人は、ログなんて全く確認しないんですから…
stealthinuさん：
まったくです。Postfixのオペレーションができれば簡単に導入できるという利点があだになって、意識が低い人が安易に導入して正当なメールをエラーリターンさせ、それで被害者から「逆引きでスパムと決め付けるS25Rが悪い」と言われた日には、たまったもんじゃありません。
S25Rのトップページに警告を掲載することを考えます。
コメントを投稿