_ もう12月なのかっ。
_ えーと、今までに何度も書いてることだけど（いちばん最近は これ）、DNSBL ってのは spam をやっつけてくれる便利な魔法じゃないんだから、どういうものなのかちゃんと理解して使わなくちゃダメだよね。
RBLを利用する側に対しては、「RBLだけを参照して接続拒否せずに、あくまでRBLをスコアリングの材料として使い、ホワイトリストを併用して欲しい」「利用するRBLがどのようなポリシーで運用されているのかを理解し、導入することのリスクを理解した上でRBLを利用して欲しい」との希望を述べた。非常に正しい。まったく異論はない。異論はないのだが、それでも困ることがある。_ 「どういうポリシーで運用されているのかを理解し」ってのが極めて重要なんだよね。でも、どういうポリシーなのか調べるのって、設定する最初の1回だけでしょ。DNSBL を設定して半年後にポリシーが大きく変わったなんてことがあっても、ふつー気がつかないでしょ。ポリシー変えるよ、なんてアナウンスがあるかどうか毎日見にいくのは手間だし、変えるときにそういうアナウンスが出るかどうかもそもそもわからんのに。
_ 要するに、DNSBL を運用している方は、いったん稼働をはじめたらポリシーを変えないでくれ。変えるのではなく、新しいゾーンを作ってそっちでやってくれ。それをお願いしたい。
Spamhaus側が「KDDIはスパマーを支持している」と判断し、「報復」（Spamhausは「エスカレーション」と表現）処置として全く関係のないアドレスを含むブロック単位でRBLに登録したものもあったとしている。spamhaus は昔はこんなことやってなかったはず。 spamhaus に関して、今年になってからこういう話題がよく出るようになったけど、つまり最近になってから spamhaus の登録ポリシーが変わってるんだよね。ヤメテ。_ いろんなポリシーの DNSBL があっていいと思う。ほんとに spam しか送信されていないと確認したところだけリストした DNSBL も、確認はされていないけどあやしいグレーなところも登録しちゃう DNSBL もあっていい。問題はそれをどう使うかであって、どんな DNSBL もポリシーを同じにしなくちゃいけないなんてことはない。真っ黒なところしかリストしない DNSBL にひっかかったなら即座に蹴ればいいし、グレーなところもリストする DNSBL にひっかかったら別の方法でもっと精査すればいい。DNSBL の運用ポリシーにあわせて、それを利用する側の運用ポリシーも変えてやるだけのこと。ただ、そういうふうに使い分けるのは、その DNSBL の運用ポリシーが一貫していることが大前提。こっちのポリシーが変わってないのにあっちのポリシーだけ一方的に変わったりしたら、そりゃ混乱が起きるに決まってる。DNSBL がいったん動きだしたらポリシーを変えるのは、やめて。ほんとおねがい。
_ 少し前だけど 朝日の記事。自転車の歩道走行を認める方向へ、という内容だが、 自転車対歩行者の事故件数が急増しているから自転車を歩道に上げようという矛盾した記事。
_ まあ、要は現状の追認なんだけど、このまま自転車は歩道を走るものという常識ができてしまうと（もうそれが常識になってる？）、そのうちに今度は車道走行禁止になる将来がやってきそうで、これは非常に困る。路側帯が狭くて車の流れが速いと自転車じゃ車道を恐くて走れないことも多いのは事実だけど、これはむしろ、車道を走るのは自動車だけではないのに自動車で走ることしか考慮してない道路設計になっていること、自動車の側にも自転車が車道を走っているという意識が低いことがまずいわけで、それを放置して現状を追認したらいかん。自転車対歩行者の事故が多いのならば自転車は歩道を走るべきではないし、自転車が安全に車道を走れるように道路の方も作りかえなきゃならん。自転車は車道を走るもの（歩道を走れるのは一部の例外だけ）という教育をもっとせにゃならん。道路行政やわしらの意識として、道路は自動車だけのものじゃない、 SHARE THE ROADという考え方を広め、そういう努力をした上でなお車道を走ると危険な場合に関してのみ歩道を徐行するのを認めるというのならば、こういう方向の施策も歓迎するがとてもそんなことを考えているようには思えない。
_ よく知られていることだけど、世界的に見て歩道を自転車が堂々と走っている国は日本ぐらいなもの。自転車ってのはまぎれもなく車両であって、あんなものが歩道上を歩行者を蹴散らして走るという状況はどう考えてもおかしい。傘をさして走ったり、携帯を操作しながら走ったり、無灯火で走ったりするアホがのさばってるのは、自転車を歩道で甘やかしたからこそ。ああいうのはどんどん違反キップを切るようにした方がいいと思う（自転車はいきなり赤切符しかないので青切符で許してやる制度も作ってくれ）。ママチャリ程度でもふつーの人が全力疾走するのと同じぐらいのスピードがかんたんに出るのに、そんな凶器が歩道に上がるのはできるだけ避けるべきだ。
_ 前も思ったけど、丸2日以上サービスを止めるとは大した度胸だよな。実作業に携わる人だけでなくサポート部隊にもかなりの負荷がかかるだろうし、しかも タイミング的に東証上場と重なってるから、もし作業に失敗してロールバックなんてことが起きたりしたら、上場直後の株価にひどい影響を与えてエラい人のクビが飛びかねない。せめて日程をずらすとか考えなかったのかなぁ？
_ 何をやるかというと、
◇メンテナンス目的だそうで。あー、やっぱり。 前回の作業時に内部構成をある程度推測してみたけど、実際その推測どおり全ユーザがひとつの DB に収容されていたってことか。なので、契約品目ごとに DB を分割してひとつあたりの収容ユーザを減らして負荷を下げる、と。ベーシック/プラス/プロの品目ごとに DB を3つ作るってことなのかな？ それとも、同じ品目であっても必要に応じて複数の DB に分割できるような構成になるのか？ 後者ならばいいんだけど、前者ならまたそのうち数十時間規模のメンテが必要になるだろう。そのへんのことを考えてないわけではないと思うんだけど、どうなんだべ？
ココログデータベース分割
ココログベーシック／プラス／プロのバージョンアップ
_ あれ？
docomo がいつのまにか ESMTP SIZE 拡張をサポートしたようだ。 以前は SIZE をサポートしていないどころか、どうしようもなくアホな挙動をしていたのだが、これでやっとふつーの MTA の動作になったようだ。ありがたいことで。% telnet mfsmax.docomo.ne.jp 25 Trying 203.138.181.240... Connected to mfsmax.docomo.ne.jp. Escape character is '^]'. 220 docomo.ne.jp ESMTP Service Ready ← 以前は ESMTP ではなく SMTP だった EHLO hoge 250-docomo.ne.jp 250 SIZE 5242880 ← SIZE に対応してる！ MAIL FROM:<> SIZE=5242880 250 Requested mail action okay, completed RSET 250 Requested mail action okay, completed MAIL FROM:<> SIZE=5242881 552 Message size exceeds maximum value ← 巨大なメールを送る前に拒否してくれた！ QUIT 221 docomo.ne.jp Service closing transmission channel Connection closed by foreign host.
_ 横浜なんて来るの何年ぶりだ。うちから遠いんだよ。
_ わしは L7 の人なので、L3 はよくわからんのだよ。しかも技術的なことよりもむしろ政治的なネタだし。へー、とか、ふーん、とか思えればまだマシ、わしの知らない言葉が飛びかってるよー、てなもんで。わしじゃなくてもっとよく知ってる人が行った方がよかったんじゃ。
_ きのう
もし作業に失敗してロールバックなんてことが起きたりしたら、上場直後の株価にひどい影響を与えてエラい人のクビが飛びかねない。と 書いたのだが、 ほんとに失敗して巻き戻してるし、今日上場された株も 公募価格を割ってる。誰かのクビが飛ぶかどうかは知らんが、わし何かよけいなこと書いたか？:-)_ ユーザからの容赦ないコメントがすげー。まあ憤る気持ちもわからんでもないが、わしもいつこういうことをやらかして責められる立場になるかもしれんので、わりと同情的になっちゃう。中の人がんばれー（でもやっぱりひとごと）。
_ 各所より amazon の ISBN（国際標準図書番号）規格改定に伴うアソシエイト・リンクの対応についてのご案内。あー、そうだ、ISBN が変わるんだっけ。そういえば、こっちではあんまり本のネタを書くことはないから使う機会はなかったんだけど、うちの日記スクリプトにもいちおう ISBN を書くだけで
こんな感じでよしなにリンクを張ってくれる機能があったりするので対応しておかなきゃいかんなぁとは思ってたんだよね。まだまだ先だと思って放置してたら、もう1ヶ月も猶予がないのか。_ amazon みたいに ISBN と ASIN が一致しなくなるよ、と表明してるところは切り捨てるか、てきとーなリンク先 URL を見つけるとして、それ以外のパターンはどうするか。 このへんの仕様を見ながら従来の10桁コードと新しい13桁コードを相互変換できるようにすればいいのかな。うーん、どうやって実装しよう。これまではスクリプト本体では専用の処理は一切してなくて、すべてマクロ展開で処理してたけど、チェックサムの計算をそれでやるのは荷が重そう。まあ、のんびりやるか。←また放置するつもりか
_ 実はこの記事が出る以前からうちで使ってたり。
おなじみ（？）のブルースクリーンを表示する。しかも丁寧にWindows XPで“再起動”するところまで再現しているのだ。このスクリーンセーバーの場合は「再現」という表現は正しくないような。インストールの説明を見ると、どうやら自前で青画面のイメージを持ってるのではなく、ntoskrnl.exe に入ってる本物の青画面、起動画面を抽出して表示してるっぽい。再現してるんじゃなくて本物そのもの。
_ このネタもいいかげん飽きてきたな。 迷惑メール送信者とのイタチごっこを終わらせるために (2)より。ただし、以下はメールではなく DNS の話。
他者と通信するホストは、基本的には DNS 逆引きできたほうがいいと思うのだが...なんで？ こう主張する人は少なくないけど、でも、なぜそうした方がいいのか、という納得できる理由は一度も見たことがない。わしが逆引きを設定するかしないかを聞かれたら、する、と即答する。しかし、それは IP アドレスだけだと「自分にとって」管理がめんどくさいからであって、無関係の他人のことなんか正直いって知ったことではない。/16 とか /24 とか大きな範囲ではなく、/29 とかの小さなネットワークしか管理しないのであれば、DNS なんか使わなくても hosts に書いておけば十分用は足りるだろう。じゃあ、その管理上の都合以上に、逆引きがあった方がいい理由って何があるんだろうか？_ 逆に、なぜ逆引きがないとマズいのか、については この前冗談めかして書いたけど、逆引き必須派にからまれたりアクセス拒否されたりするのを避けるため、という逆説的で後ろ向きな理由以上のものを見つけられない。
性善説が通用した牧歌的なインターネットの黎明期ならいざ知らず、通信相手はまず疑ってかからなければ手痛い目に会うのが (それがいいことかどうかはさておき) 現代のインターネットである。通信相手の素性は可能な限り収拾しておきたいし、できれば ssh や SSL認証のような認証を行なって、通信相手が間違いなく意図した通りの相手であることを確認したい。まさにそのとおりで 100% 同意する。が、そこで、
しかし残念ながらメール配送は、いまだ認証無しの通信が大多数を占める。通信は相手あってのものだし、特にメールは不特定多数からの通信を受付けなくては機能しない。一方的に、「認証無しの接続は受付けません」と主張したところで得るものはあまり無い。だから完全な認証は棚上げせざるを得ないが、不十分であっても通信相手の素性が分かる方法は総動員したいところだ。素性を調べる手段として DNS逆引きは、ある程度の合理性を持つ。となる理由がさっぱりわからない。逆引きを名乗るだけならば、kantei.go.jp でも whitehouse.gov でも好き放題できるのに、素性を調べるのに合理性があるなんてウソでしょ。逆引きと正引きが一致するところまでチェックするのならばまだわからなくもないんだけど、少なくとも逆引きだけに関していえば詐称し放題で、信じちゃいけない情報の筆頭のはず。「まともに管理されているホストに逆引きがないというのもふつうに存在する」のは事実だと思うが、「まともに管理している」ということを通信相手に伝える努力はすべきではないだろうか？そのとおりだろう。しかし、「逆引きが設定してある」⇒「まともに管理している」となる理屈がわからない。わしが書いた文が引用されてるけど、中韓あたりの国はそもそも逆引きを設定する習慣があまりないようだ（大手 ISP や企業などは設定してあることも多いが、中小になるとまずない）。つまり、これらの国では「まともに管理している」ことの条件に「逆引きを設定する」ことは含まれていないということだ（あるいは内部的には使っていても外には見せないのかもしれない）。あるいは日本国内でも、自分の経験ではなくて聞いた話だけど、金融系の会社から仕事を請け負った業者が親切に逆引きを設定したら「情報を漏らすなバカ」と怒られたことがあるらしい。つまり、ここでは「逆引きを設定しないこと」が「まともに管理すること」の条件のひとつになっている。そういうわけで、世の中には「逆引きなんかあってもなくてもどうでもいい」「逆引きを設定しちゃダメ」という認識がある人たちもいるわけで、統一したコンセンサスがあるわけではない。そこに「逆引きがなくちゃダメ」なんて異なった価値観を一方的に押しつけようとすることに無理はないのだろうか。通信はお互いの協力があって初めて成り立つものであるから、 spammer と区別してもらうための努力もせずに、 spammer と一緒にするなと叫んでいるだけでは解決にならない。通信はお互いの協力があって初めて成り立つものなのであれば、俺ルールを一方的に押しつけるのも解決にならないと思うのだがどうか。もちろん、spammer と区別してもらう方法が DNS逆引きの設定だけであると主張するつもりはない。送信側と受信側、双方にとって最も合理的な判別法を選択していくべきであろう。ならば送信ドメイン認証を。逆引きなんていいかげんな手段に頼らずに。_ 「これまで自分がそうしてきた」「自分の近所でもそうしてる人が多い」ということから、それが自分の中で常識になってしまったというのはあるだろう。しかし、なぜそうするのが常識なのか考え直してみるのも必要ではないのか。それが正しいからそうしてきたのではなく、ただ利便性のためにそうしてきたのが定着して常識になっただけのであれば、それは「便利な常識」であって「正しい常識」ではない。正しい常識ならば他人に押しつける正当性もあるだろうが、ただ便利なだけの常識ならば、それを便利と思わない人には理解されない。さて、DNS の逆引きはいったいどちらの常識に属するのか。
_ わしのまわりでは逆引きが設定されてないホストなんてひとつもないから、逆引きがないと蹴るサイトがあったとしても困ることはまったくなく、勝手にやってもらってかまわない。しかし、俺ルールを世界のルールかのように喧伝するのは、違うよ、と指摘しておかなければ。
_ 水元公園とか中川とかのあたりをうろうろしながら知らん道を開拓しつつ 55km を3時間半で。中川は下流から上流に向かって走るのはいいけど、逆はやめておいた方がいいな。両岸とも上流方向への一方通行になってる区間が多い。
_ 水元公園はひさしぶり。この前は蓮の花が咲いてたから初夏だったか。今日は葉がだいぶ落ちたけど紅葉の名残りがいい感じ。公園の中ということで意識してゆっくり（早足で歩くぐらいの速度）走るようにしてみたけど、木立ちの中をのんびり進んでいくのはきもちいい。天気もよかったし。
_ 壊れた MIME メッセージを送ったときに、MIME パーザの解釈の違いによってデコードされたりされなかったりするために製品によってウィルスがすりぬける。またか、って感じ。古くは Sircam も壊れ MIME ですりぬけた。また、qmail のバウンスは壊れてるとか壊れていないとかいう以前にそもそも MIME マルチパートじゃないからデコードなんてできやしないはずなんだが、そのバウンスメールの末尾にくっついてる元メールから無理矢理添付ファイルをデコードしちゃうものもあって、やっぱりウィルスがすり抜けてきたぞ問題が起きることがある。
_ これはもうどうにもならんわ。デコードする MUA の側ができるだけ規格に厳密に例外を認めないように、ウィルスをチェックする側は規格を逸脱したものでもできるだけルーズに解釈するようにすればまだ何とかなるんだけど、まあムリだわな。