_ やっとこさ新しい自転車に乗れた。これに乗って仕事に行ってもいいんだけど、昼間どこに置いておくか悩むんだよなぁ。
_ きのう。旧江戸川と江戸川放水路が分流するあたり、要するに行徳橋まで往復。セイタカアワダチソウが満開ですな。世間的にはあまり印象のよくない雑草だけど、これだけ群生して一斉に花を咲かせているとなんだかんだいってやっぱ見事だわ。40km を2時間で。
_ 今日。江戸川と R16 が交差する金野井橋まで往復 + 利根運河往復。上流の方はまさに田舎の田園地帯で走ってて気持ちがいい。途中、昼飯を食いに野田の市街地に入りこんでいったら超大盛りで有名なやよい食堂の前はすげー行列だった。おまえらそんなに怖いものが見たいのか。結局、70km を3時間半で。帰りは向かい風で泣きそうになった。
_ 気になっていたハンドルの遠さだが、うん、慣れた。まったく問題ない。むしろクランクがもっと長くていいかも？
_ うーん。
HTTPの世界と違って、SMTPではTLSを必須にできるほど普及していないし、外の世界とやりとりするMTAでTLSを必須にすることは、相互接続性の観点から推奨されていない。TLSが使えなかったらplain textにfallbackするのが普通なプロトコルでは、TLSは「ないよりまし」な機能でしかない。うちのサーバを TLS に対応させようかどうしようか、というレベルでの議論においてはこれは正しいと思う。現状は TLS が使えないサーバの方が大多数なわけで、特定の MTA 間だけ TLS 化されたところで、end-to-end でずっと TLS というのは期待できないわけだし。しかし、それでも TLS をやる、と決めたのならば広く検証できる証明書を使うべきであって、オレオレ証明というのはやっぱりおかしい。「自分はニセモノかもしれません」なんて公言することにいったい何のメリットがあるのか。正しく運用しても「ないよりまし」程度でしかないのに、それができないのならば「ない方がまし」だと思う。_ ほとんどの MTA 間は平文で通信されてるから、相手サーバが正しいかどうか検証できない。それができるのが TLS のはずなのに、そこでオレオレ証明書を使うのでは意味がない。これでも暗号化されてはいるが、通信相手が正しいかどうか検証できない暗号に意味はない。人違いと気がつかずに赤の他人とやりとりしてどうすんの。
もしかすると、sourceforge.jpにはすべての経路でTLSを保証したいルートがあって、そこはオレオレ証明書でもいいので安全にしたい、けど外部とのやりとりはどうでもいい、ということなのかもしれない。もしそうならば、その特定ルートからの接続があったときだけ STARTTLS が使えるよという応答をすべきだと思う。Sendmail ならば Srv_Features、Postfix ならば smtpd_discard_ehlo_keyword_address_maps。もしくは単純に別ホスト/別ポートでプロセスをもうひとつ動かしてクライアントにスタティックな配送経路を設定してもらう。オレオレ証明でも、特定少数に対して使うのならば非常に有効かつ安全に運用できるのは事実だ。クライアント証明と組み合わせれば SMTP AUTH はいらなくなるわけだし。が、不特定多数に対してオレオレ証明書で運用する意味は、ない。
_ 佐川が荷物を配達してくれません。
_ 週末はしゃぎすぎた。足が上がらん。今日は雨が降ったが、水たまりをまたぎ越えようと足を上げるも意思に体がついていかずボチャン。意外なことに腕も筋肉痛。とはいっても、あれだけ走りまわったのにあの程度で済んでるんだから、たいしたもんだといえるような気もする。
_ えーと、sh/bash の場合。
これがふつーの動作だと思ってた。が、zsh の場合。$ hoge="uname -srm" $ $hoge FreeBSD 6.1-STABLE i386 $ set -- $hoge $ echo $# 2なんだこりゃ。zsh では $hoge と "$hoge" が同じ意味になるらしい。ムチャクチャだな。どーせ zsh のことだから、何かのオプションをいじればこのあたりの挙動は変えられるんだろうけど（調べてはいないので実際は知らない）、一般的な変数展開のルールと大きく違うやりかたがデフォルトというのは解せない。キモい。% hoge="uname -srm" % $hoge zsh: command not found: uname -srm % set -- $hoge % echo $# 1_ そこで思いだした。かなり前になるけど、ウノウの ベンチャー流サーバ構築のススメ(同期ツール編)というエントリ。ここで挙げられているスクリプトには root で ssh する危険なコマンドがてんこもり。たとえばそのエントリの dir_diff.sh というスクリプトを起動するときの2番目の引数を "localhost rm -rf /;" してやれば、
という部分の $2 が展開されて ssh 部分がdiff -u <(ssh root@$2 find $source|sort) <(sudo find $source|sort)|grep '^\(+\|-\)'という即死コマンドに化けてしまう、という極めて危険なセキュリティホールをはらんでいる。……はずだった。ssh root@localhost rm -rf /; find ..._ 実はこいつは zsh スクリプトなんだな。上述のとおり、"$hoge" ではなく $hoge としても空白入り文字列が分割されないから、$host が "localhost rm -rf /;" だったとしても、
となって、そんなホストは存在しないというエラーになるだけで危険なことは起きない。最初にこのエントリを見たときにこれは巨大な穴つきスクリプトだと思っていたのだが、なるほど、zsh の妙な仕様に救われてそういう穴はなかったのか。ssh root@"localhost rm -rf;" find ..._ こういう悪例のように、sh では "" で括らなかったばかりに空白入りの文字列で事故が起きることはないことじゃないから、zsh の動作というのはたぶん安全側に倒してわざとそうしたんじゃないかと思う。が、こういう基本的な常識だと思ってた部分の動作が覆されるのはどんなもんかなぁ。zsh でも "$hoge" のようにちゃんと括るクセをつけておくべきだと思う。
_ つーか、ssh root@... とか sudo とかよく平気で書けるな。コメントで別の穴が指摘されているけど、もともと root を持ってる人が実行するものだから大丈夫というのもなんだか。スクリプトの中身よりも、こういう考えかた自体を矯正した方がいいのかもしれない。
_ 思わず吹いてしまったわしはこちらの峰の元住人。農学部もやってくるのか。ゴルフ場のあたり？（というかあの問題解決したんか？）
_ うほ大なんて表記、久しぶりに見たぞ。
_ Postfix で SQLite を使えるようにするパッチだって。RDB は便利だけど、MySQL とか PostgreSQL とかはちょっとおおげさだな、というときにはいいかも。
_ たとえばこういうスクリプトを書く。すげー手抜き。
んで、このスクリプトを postfix の master.cf で以下のように指定する。いや、別に inetd.conf でもいいけど。#!/bin/sh postmap="postmap" case "$1" in -a) postmap="postalias" shift ;; esac case "$1" in "") echo "400 usage: $0 [-a] type:file" exit 1 ;; esac map="$1" while read method key; do case "$method" in get) case "$key" in "") echo "500 null key";; *%*) echo "500 invalid char";; *) s=`$postmap -q "$key" "$map"` case "$?" in 0) echo "200 $s";; *) echo "500 not found";; esac ;; esac ;; *) echo "500 not implemented" ;; esac donepostfix reload して変更を反映してから以下を実行。127.0.0.1:9999 inet n n n - - spawn user=nobody argv=/path/to/script -a hash:/etc/mail/aliases% postalias -q postmaster tcp:127.0.0.1:9999 root_ ちうわけで、aliases の内容をネットワーク経由で参照できるようになりましたとさ。この例は 127.0.0.1 を使ってるからダメだけど、複数台のホストで構成されるような大きなメールシステムでも、各種テーブルをそれぞれのサーバに配布するのではなくひとつのホストで集中管理してネットワーク経由で参照させることも可能。まあ、ふつうは RDBMS や LDAP だろうけどね。
_ この機能、postfix 2.1 snapshot のころからあるんだけど、正式リリース版には 2.3 になった今でも採用されていない。使えない。不憫。コードの質が低いというより、プロトコルがいいかげんすぎて改良の余地あり、ってことで正式採用されてないんだと思う。そういうわけで、便利に見えるかもしれないけどあまりオススメはできない。
_ ちなみに、sendmail では socketmap という機能で似たようなことができる（プロトコルは違うので流用できない）。
_ ここのところずっと帰宅が遅かったりしたものだから、頼まれものの作文がちっとも進んでない。週末にがんばらねばならんところなのだが、うちにいると誘惑が多すぎてダメ。つーことで、自転車に乗って 10km 先の馬車道まで。
_ ……馬車道にすみれ女史がいなくてどーする。
_ ケーキを食べながらノート PC のキーボードを叩いてたらあっとゆーまにバッテリーがなくなった。うーん、そろそろ寿命かなぁ。ちうわけで作文はちっとも進まず。あした中に8割程度までは終わらせないとマズいな。
_ 携帯電話の番号持ち運び制度がはじまった。電話番号は変わらないけどメールアドレスは変わる。
_ ということは、携帯キャリア宛の不達メールが今後増えるんだろうか。増えるんだろうな。関係ないやとまったく考慮してなかったけど、実はちょっと影響ありなのか。めんどくせー。
_ ところで、MNP に合わせてソフトバンクが滑稽な料金体系を発表したけど、情報漏れを防ぐために事前に知っていたのはごく一部の幹部だけ、ってのはほんとなんだろうか。っていうか、ウソだな。いくら常識はずれのポイントに損益分岐点をおくソフトバンクといえども、収支にどれだけインパクトを与えるかの見積もりをせずに料金体系を変えるなんてことするわけないだろうし、それをごく一部の幹部だけでその予測を立てたとは到底思えないんだが。ああいう大規模な料金体系の変更では課金システムの修正も必須だし。末端販売店にナイショにしてただけで、店頭に立たない社員はきっとみんな知ってたに違いない。
_ MNP がはじまって最初の週末の結果は KDDI が一歩リードだそうな。au は8万増、ドコモは6万減、ソフトバンクは非公開だけど差し引きすれば2万減。ただし、ドコモは産経の記事では公開された数字ということになっているが、産経以外では非公開ということになってる。謎。
_ で、今回のソフトバンク騒動はこういうことだったのかな。
……というのがソフトバンクの当初の目論見。
- よーく考えれば高いんだけど、よーく考えないと高いとは気づきにくい料金プランをひねりだす。
- そいつを番号ポータビリティ開始直前に発表する。
- よーく考えるヒマを与えられていない消費者が表面上の安さに釣られて飛びついてくるのを待つ。
- 高いことに気がついても、2年縛りでやめるにやめられず後の祭。囲いこみ成功。
_ 現実。
障害が起きてなかったらどうなってたか知らんけど。そもそも流出過多というのがほんとなのかもよくわからんし。
- 表面上の安さに釣られた消費者は意外と少なく、他社に逃げるユーザの方が多かった。
- システム障害が起きて移行できなくなった。
- 結果として他社に流出するユーザが減ってソフトバンクは助かった？
_ 障害のせいでソフトバンクの流出数が少なく抑えられたというのが仮に真だとすれば、au への流出分をソフトバンクから流入で補うはずだったドコモがいちばん痛かったということか。まさか意図的に障害を起こしてユーザの流出を止めた、なんてことはないよな。
_ まあ、MNP ってのは先週末で終わりの制度じゃなくて、これからも流動していくものだけどね。ただ、固定電話のマイラインも今だって続いてる制度だけど、獲得競争をやってたのは導入当初だけで、今になって電話会社を変えようなんてしてる人はめったにいないわけだから、スタートダッシュはやっぱり重要。