_ まさかそんなことができるはずないだろうと思ったけど、まあ試すだけならタダだから、とやってみた。
_ ……できちゃった。えー。
_ えーと、ニコニコ動画は、プレミアム会員にならなくても混雑時間帯にエコノミーモードで画質を落とされずに閲覧できます。アカウントを取得したばかりのそもそもその時間帯にログインできないような人はさすがに無理だけど。
_ さすがに影響がデカいと思うのでその方法をバラすのはやめとくけど、そんなに難しいことはしない。 この前のスクリプトの場合だと1行修正するだけ。っていうか、ぱっと見てすぐに思いついたけどまさかほんとにそれでできるとは思わず、1週間ほど試さず放置してたわけで。あまりにカンタンすぎる方法なんだけど、greasemonkey や proxomitron のフィルタを公開しているサイトを探しても見つからないね。ニコ動の運営元はこんなしょぼい方法で十分だと思ってたのかなー？
_ あ、この前のスクリプトでうまくニコ動にログインできない場合は、wget の引数に --no-check-certificate を追加するとうまくいくかもです。
比内地鶏ではないニワトリを使った薫製商品を比内地鶏と偽装していた問題で特産「比内地鶏」を偽装した薫製加工品を製造していた問題で_ 薫製という言葉にしばらく考えこんだ。「薫陶を受ける」の薫だから「くんせい」だろうということは想像がついたのだが、それなら「燻製」じゃないか？ なんで大手2紙が揃って誤字やってんの？
_ ……と思って調べてみたら 薫製という表記もありらしい。知らねー。燻が表外字だから代用したのか。
_ ぐーぐる様にお伺いを立てると燻製が133万件、薫製が16.2万件。知らんはずだ。こんなに普及していない代用字もほかにないような気がするなー。なんかあったっけ？
_ 毒キノコが交ざっていた可能性がの記事にすげー違和感があったので（間違いじゃないだろうけど自分なら交じゃなくて混の字を使う）、ちょっと過敏になってるのかも。
_ 例によってアカウントによってできたりできなかったりするようだけど、わしのは当たりだった。素の gmail だけでなく、独自ドメインが使える google apps の方でも imap が使えてる人がいるようだけど、こっちの方はハズレ。
_ で、実際に imap でアクセスしてみたけど、spam フォルダに溜まった12000通以上のゴミメールのヘッダ読み出しに膨大な時間がかかって泣けてきた。これだけ溜めこめば gmail じゃなくても時間はかかるけどさ、こんなゴミのために回線とマシンパワーと時間を費してると思うとねぇ。たった1ヶ月でこれだけ溜まるんだからやってられん。
_ まあ、でも実際のところ gmail はバックアップにしか使ってないし、これまでどおり自分のうちで動いてる imap サーバの方をメインに使うんだけどな。
_ って、11/1 からかよ。来週じゃねーか。アナウンス遅いよ。旧アドレスとの併用期間が半年というのも短かすぎないか。まあ、実際は数年ぐらいは動かしてくれると思うんだけれども。
_ そういえば、BIND でヒントファイルを読み直すのってどうやるんだっけ？ zone "." だから、ふつーのゾーンのリロードと同じように
でいいの？# rndc reload .
_ l.root-servers.net の11月からの新アドレスの方がすでに使える状態になっているようなので、リハーサルを兼ねてうちで動いている BIND の設定をためしに変えてみたんだけど、 この前書いたような "." だけ reload するような方法ではそんなゾーン知らんとエラーになった。全ゾーンリロードはエラーにはならないけど変更は反映されない。reconfig や refresh ももちろん不可。しかたねーなー、プロセス再起動しか方法ないのかー。
_ ……再起動しても変わってねぇ！ もしかして BIND って、ソースにハードコードされたルートサーバが優先されて、named.conf の zone "." { type hint; ... }; の設定は無視されるの？ それじゃいったい何のための設定だよ？ the Internet と切り離された実験室環境で独自のルートサーバを動かすときには BIND にパッチを当てなきゃ使えないってこと？
_ いや、違うな。パケットキャプチャしてみると、ちゃんと新しい L に聞きにいってる。dig . ns とか dig l.root-servers.net とかしてもヒントファイルにあるアドレスを答えるのではなく、ふつーに再帰検索した結果を返すので、世間的にはまだ変更されていないから反映されていないように見えるだけみたい。
_ ただ、IP アドレスを古いのに戻したり新しくしたりを何回か繰り返してみたけど、変更を確実に反映させるにはプロセスを再起動させるのが安全のようだ。rndc reload ではうまくいくときといかないときがある。ちょと謎。reload でうまくいかない場合でも rndc flushname l.root-servers.net でキャッシュを消してやると新しい方に聞きにいくように変わったりしてなんかよくわからん。
_ つーか、recursive yes（キャッシュ用 DNS）の場合は設定がちゃんと変更されたかどうか確認する方法ってパケットキャプチャしかないのか？ 再帰検索させないように dig +norecurs で問い合わせてもヒントファイルの内容が返ってくるわけじゃないし。recursive no（コンテンツ用 DNS）では、自分が管理していないゾーンを問い合わせたときに返ってくるルートサーバへの referral がヒントファイルそのままなのですぐ確認できるんだけど。もっとも、わしが設定する場合コンテンツサーバではヒントファイルは /dev/null にしちゃうことが多いので、そもそも変更の必要がないわけだが。
_ 11月から変わるものといえば、そういえば docomo もそうだったね。 送信ドメイン認証（Sender ID/SPF）なるものをやるそうな。
_ しかし、なんだ、その、これは、あれだ、ダメだな。
_ まずはじめに褒めておこう。影響力の大きい docomo がこれを採用することにしたのは歓迎すべきことだ。docomo に蹴られちゃかなわん、とあわてて設定するドメインは多いだろうから、今後数ヶ月で 普及率が一気に上がると思う。世に普及させるという意味では非常に大きな貢献となることは間違いない。
_ でもねぇ。実装がうんこだよ、これ。問題点はふたつ。
_ うんこその1。ヘッダ From で判定する。
_ いや、SenderID (PRA) ならば、ヘッダによる判定で正しいんだ。実際ドコモの記述は SPF ではなく SenderID/SPF と併記してるわけだし、正しく PRA のルールどおりに判定してくれるのであれば文句を言う筋合いはない。ヘッダ From がなかった場合のみエンベロープで判定する、という記述も、PRA でコケたときだけ SPF を見る、と読めなくもない。
_ が、どうやらそうではなさそうなんだよね。例に上げられている TXT レコードが v=spf1 になってる。PRA ならば spf2.0/pra だろうが。また、PRA ならば、From: だけでなく Sender: などのヘッダも判定対象になるんだけど、これに関する言及がまったくない。これから推測されるに、正しい SenderID (PRA) ではなく、ヘッダ From を SPF に適用するという、この世のどこにも存在しなかった勝手規格をはじめるんだろうということ。なんでそんなことするの？
_ これによっていちばん大きな影響を受けるのは各地のメーリングリスト。まともな ML はエンベロープ From を書き換えて Sender: を追加するが、ヘッダ From は書き換えない。まともな SenderID/SPF 実装ならば、書き換えた後のエンベロープ From に対応する SPF レコード、ないしは Sender: に対応する PRA のレコードをを登録しておけば詐称判定されることはない。が、docomo が SenderID/SPF と称するものではすべて詐称とみなされて受信を拒否されることになるだろう。11月になったら ML サーバ管理者はメールが届かなくなったという問い合わせの対応に追われることを覚悟すべし。
_ うんこその2。pass 以外全部拒否。
_ 判定結果が pass と fail のどちらかしかないのであればいいのだけれど、そんな単純にはできていない。docomo の記述を素直に解釈すると、認証に通らなかったけれど、さりとて失敗したともいえない neutral とか none とかも蹴るように読める。ふつーの SPF でもメールを転送する場合などにそなえて、pass しなかった場合でも fail ではなく neutral を返すように SPF を設定することは珍しくない。しかし、無情にも docomo はそれを蹴る。ヘッダ From による ML 誤判定もこの方法で回避できない。
_ もしかしたら error や temperror も蹴るかもしれない。SPF がちゃんと設定されていて、かつ SPF 的に正しい IP アドレスから送信しているのに、DNS サーバやそこまでの経路が一時的にコケていて SPF レコードの参照に失敗してしまうことはありうる。このような、実際には詐称していないのに、たまたまほんとかどうかわからなかっただけの場合も、docomo は蹴ってしまいそうな気配だ。
_ 最初に褒めたように、普及に弾みをつける意味では docomo で SPF による受信拒否を選択できるようになったのは喜ばしいことだ。が、どうせやるのならば正しく実装してくれ。このような影響力の大きいところがルール破りをやると、「正しくないけど通らないと困るから」とばかりにおかしな workaround が広まってしまうかもしれない。道理をひっこめて無理を通すな。
_ docomo の Web ページに書いてある SenderID/SPF なるものは、どうやらわしが知っている SenderID や SPF とはまったく別モノのように思えるのだけど、もしかしたら Web ページの記述がおかしいだけで、実はひじょーにふつーの実装なのかもしれない。そういう可能性もないではないし、実際にはじまってみないことにはわからん部分もあるのだけれども、はてしなくゼロに近い可能性に期待するのはアホのすることだ。
_ そして spammer は "v=spf1 +all" な TXT レコードを書いて無力化するのであった。
_ そういえば送信ドメイン認証といえば、DKIM の SSP (*1)に関する部分も先月 RFC になったです。これまで SSP なしの RFC 4871だけの中途半端な状態だったけど、これでめでたく完全な状態で運用できるわけだ。
(*1): 以前は site siging policy の略だったはずなんだけど、いつのまにか sender siging practices の略ということに変わってるぞ。
_ DVD 4枚にうにまがの創刊号からの記事が詰まった アレ、職場で買ったので見てたんだけどさ、使いづらい。総目次がないのな。各号ごとに PDF ファイルが並んでるだけ。どの記事がどの号に収録されているかさっぱりわからん。紙の雑誌だったころにバックナンバーから記事を探すのは毎年の4月号に載っている年間総目次を手がかりにしてたけど、電子化されても同じことをするハメに。安いモノじゃないんだから20年分の総目次を掲載したファイルぐらい置いてほしかったなー。いや、自分で買ったわけじゃないけど。
_ いちおう紙の冊子に全体のダイジェスト的な記事もあるけど、すべてを網羅してるわけじゃないし、そもそも紙の冊子を片手に電子化された記事を探すのもナンセンスだし。なんかのツールで全文検索用インデックスを作るってのもアリだけど、目次と索引はやっぱ違うわけよ。
_ で、中身。ほかの雑誌にくらべて unix magazine はそんなに古びない記事が多いかな、という印象だったけど、さすがに今見返すと使いものにならんものがほとんどだな。むしろ、ごくわずかとはいえいまだに使える記事が存在していることの方をむしろ驚くべきか。