Web屋のネタ帳

前の記事で書いた内容の筆者の認識は大間違いであることが発覚。

（どさにっきより抜粋。）

さて、上のリンク先の記事曰く、

  reject_unknown_hostname は上とはちょっと違って、詳細は省くけどそれほど弊害の大きい設定じゃないと思う。

省かれてしまったので詳細を書くと、reject_unknown_hostname （2.3 からは reject_unknown_helo_hostname）は逆引きとはまったく無関係で、HELO/EHLO で名乗った名前が DNS で正引きできない場合に拒否するというもの。が、「それほど弊害の大きい設定じゃないと思う」だって？ 馬鹿いっちゃいけない。逆引きできないホストを蹴る以上にやっちゃいけない危険な設定だ。

具体例をあげると、MTA がプライベートアドレスを持ったホストで、外とのやりとりでは NAT でアドレス変換されているようなネットワーク構成の場合。プライベートアドレスだからホスト名が組織内部の DNS にしか登録されておらず外部からは参照できないなんてことは、spammer ではないまともな企業のネットワークでもちっとも珍しくない。この場合 MTA が正直に自分のホスト名を名乗っても、それは外部から見える DNS には登録されていないので、意図せずとも偽造ホスト名に見えてしまう。よって、HELO の正引きチェックをされると見事にひっかかって拒否されてしまう。

こういう場合、MTA はイントラネット上の自分のホスト名ではなく、インターネットから解決できるてきとーな名前を名乗るか、あるいは、イントラ用のホスト名を外からも名前解決できるように DNS に登録するなどしないと回避できない。が、どうすれば回避できるか以前に、そのような問題があることを認識していないサイトが非常に多い。また、その問題を仮に認識して直そうとしても、MTA によっては設定するのがえらくめんどくさいものがある。

わりと管理がしっかりしている spam なんか出さない組織であってもこういう問題を抱えているところはかなりの数存在する。そういうところからのメールを捨てたくなければ HELO の正引きチェックをしてはならない。そういう事情を認識した上でなお「外から解決できる正しい名前を名乗りやがれ」という主張をする、誤爆を気にしないパラノイドな人が設定するパラメータが reject_unknown_helo_hostname である。

ぐぉっ。やばい。 企業内LANでプライベートアドレス／ドメインを持ってるホストからのNATを介した通信というパターンは確かに大いにありうる。っていうか普通にある。 お詫びして訂正いたします。