_ v6 の逆引き設定したくねーよなー、みんなどんだけマジメに逆引き書いてんだろ、ということで、実際に v6 足を持ってるホストにアクセスしてきたクライアントを逆引きしてみた。結果。逆引きは半分弱しか設定されてませんでした。国内のサーバなのでとーぜん日本のものが多いんだけど、それ以外だと .de や .fr、.edu が多い印象。ちうか、.jp よりも .de の方が多い。.com や .net な国内 ISP を jp に繰り入れると日本の方が多くなるという程度。ただ、ドイツやフランスが逆引きを書くのがあたりまえな風潮があるかというとそうではなくて、単に v6 の普及度が高いだけという可能性もあるのでなんともいえない。逆引きができなかったアドレスがどこの国で使われてるのかを調べないと実際どうなのかはわからんが、調べてない。
_ そんなことよりも妙なことに気がついた。この調査をしたホストというのは、コンテンツ用の DNS サーバ。つまり、ここにアクセスしてくるのはリカーシブな DNS サーバであって、一般的なエンドユーザではない。ぶっちゃけ、一般的なクライアントではなくサーバ用に使われている IP アドレスですらこの程度しか逆引きが設定されてないんだから v6 の逆引きなんていらねーよな、と言う根拠を見つけるためにわざとサーバにしか使われなさそうなホストを選んで調べはじめたわけ。
_ が、v4 でアクセスしてきたクライアントを同じように逆引きしてみると、*.ap.yournet.ne.jp だの *marunouchi.tokyo.ocn.ne.jp だのといった、よく見かけるエンドユーザに割り当てられた逆引きが大量に見つかる。逆引きできないものも大量。いくつか pbl.spamhaus.org (spam 送信元ではなく、エンドユーザ回線な IP アドレスをリストした RBL) に聞いてみたところ、1/3 ほどが登録されていた。PBL がどの程度網羅してるのか知らないけど、本来はかぎりなくゼロに近い値のはずのものが 1/3 なんて高い割合になるのは異常。なんでお前らがここにアクセスしてくんの？ ふつーのユーザならば ISP から提供されているキャッシュ DNS に問い合わせる以外で DNS のクエリーを投げることはないはずなんだけど。
_ こいつらが具体的にどんな名前を解決しにきてんのかをさらに調べてみたら、案の定ほとんどが MX → A のコンボだった。spam 送信用ボット確定。ふつーのエンドユーザなら ISP から指定された submission 用サーバを使ってメールを送るので、MX を聞く必要はない。MX に対して直接 spam を投げ込まなければならないボットの挙動だ。もちろん、ボットでなくても自前でキャッシュ DNS と MTA を動かしている自宅サーバな人も同じ挙動になるけど、しかしそんなことをやってる人がこんなに多いはずがない。
_ が、謎もある。なんで、たかが bot のくせにフルリソルバを実装してんの？ わざわざルートから権威サーバを辿って名前解決しなくても、ISP に指定された DNS に問い合わせた方が速いし実装も簡単なのに。ボットの DNS 検索はプライマリ MX の選択がおかしいとかラウンドロビンの扱いがおかしいとか、いろいろ妙な挙動をするものが多いんだけど、なんで Windows 標準の API を使わずにわざわざ壊れた車輪を再発明するんだろうか。もちろんすべてのボットが同じようにおかしいわけではないだろうけどさ。
_ そういえば再帰検索を受け付けないはずの権威 DNS に再帰フラグの立った問い合わせが大量に来てるのも確認してるんだけど、もしかしてこれもおかしなボットなんだろうか。たぶんそうなんだろうなー。……はて、再帰フラグの立ったクエリーが来てるって、わしどうやって見つけたんだっけ？ BIND の querylog にはそんな情報載らんし。
_ この前の調べものの続き。v4 で逆引きしたものの中から *.compute-1.amazonaws.com のものを抽出。この IP アドレスを spamhaus に問い合わせる。結果。ほとんど PBL に登録されてた。いくつかあるセグメントのうち 75.101.128.0/17 だけ未登録で、あとは全滅。zen.spamhaus.org には PBL も含まれるし、またこの逆引きホスト名は S25R のルールにもひっかかるので、つまり Amazon EC2 を使っているというだけで受信元から spam 判定される可能性が高くなる。
_ amazon に非はまったくないんだけど、利用者の側では回避しようがないので、確実に届けたいメールであれば Amazon EC2 からの送信はしない方がいい。あるいは運よく 75.101.128/17 に収容されるのを祈るか。こういうサービスを使ってメールを送るのはわしゃ何ら問題ないと思うし、メルマガ配送用のサーバを構築したりするにはいいサービスなんじゃないかと思ってたんだけど、こういう似非ブラックリストの存在で使いにくくなるのは非常に残念。
_ なんだこりゃ。
なんで gmail？ というわけで、Gmail や Google Apps を使えば誰でもはてなからのお知らせメールを詐称できます☆% dig +short txt hatena.ne.jp "v=spf1 +ip4:59.106.108.64/26 include:gmail.com include:aspmx.googlemail.com ~all"_ ……って、gmail にしろ google apps にしろ、envelope sender を詐称ってできたっけ？ From: のヘッダは設定で自由に変えられるけど、envelope sender や Sender: ヘッダは gmail/google apps のもので固定だよな。ということで、実際は詐称することはできないので、その点は安心していいようだ。もっとも、それははてなの中の人ですら gmail から hatena.ne.jp のメールを送るのは無理ってことなんだが。
_ ん？ もしかして。
というわけで、google apps のホストに hatena.ne.jp 宛で投げようとしても不正中継の拒否はされませんでした。つまり、はてなは google apps を使ってるようです。そういうわけで、SPF の include:aspmx.googlemail.com についてはどうやらほんとにありうるらしい。% telnet aspmx.l.google.com. 25 Trying 209.85.222.86... Connected to aspmx.l.google.com. Escape character is '^]'. 220 mx.google.com ESMTP 26si9701932pzk.57 ehlo hoge 250-mx.google.com at your service, [219.111.8.132] 250-SIZE 35651584 250-8BITMIME 250-ENHANCEDSTATUSCODES 250 PIPELINING mail from:<> 250 2.1.0 OK 26si9701932pzk.57 rcpt to:<postmaster@hatena.ne.jp> 250 2.1.5 OK 26si9701932pzk.57 quit 221 2.0.0 closing connection 26si9701932pzk.57 Connection closed by foreign host._ が、include:gmail.com はやっぱり謎。
_spf.google.com には all が含まれているから、必ずこの項でマッチする。include ではなく redirect なので、pass じゃなくても all でマッチした時点で終了。評価は include:gmail.com で必ず終わるので、はてなの SPF でそれよりも後に書いてある include:aspmx.googlemail.com には決して到達しない。つまり、書くだけムダ。はてなが google apps のホストからメールを出しても、google apps 用の SPF の記述でマッチすることはない。% dig +short txt gmail.com "v=spf1 redirect=_spf.google.com" % dig +short txt _spf.google.com "v=spf1 (長いので途中略) ?all"_ ……って、あれ。redirect の ?all ってどういう扱いになんの？ もしかして「neutral としてマッチした」じゃなくて「なんにもマッチしなかった」扱い？ だとしたら後の記述に続くなぁ。どっちだろ。
_ まあ include:gmail.com で評価が終わったとしても、実際のところ gmail.com も aspmx.googlemail.com も、SPF が指してる内容は同じ(=gmail.com も google apps も出口ホストは同じ)なので、たまたま運よく pass しちゃって実害はないんだけど。