_ あー、やっちゃった。 MYCOM によると、
これまでDIONと旧サービスの「NEWEB」に申し込みをした顧客の全データと一致することが判明した。漏えいしたのは97年から03年12月18日までのデータで、とのことだが、97年に NeWeB はまだなかったので、さらにその前身の今は亡き日本高速通信がやってたテレウェイシリウスの時代のデータも含んでるってことだな。さすがに DION 統合前に解約した情報は入ってないとは思うけど。_ KDDI からのリリースによると、
※ ご契約のDIONメールアドレス、パスワード、口座番号等の信用情報、通信記録は流出していません。となってるけど、ほんとかなぁ？ 顧客管理システムで住所氏名が必要なのは課金を請求するためであって、そのためには契約情報やカード番号、口座番号といった情報は当然いっしょに管理されてるはず。恐喝犯が提示したのが住所氏名電話番号だけだったということであって、KDDI や警察は確認していないけど信用情報もいっしょに漏れたと考える方が妥当なんじゃないかなぁ。
_ これまで外とつながっていない隔離環境で実験してきたけど、ついにうちの本番機（といっても自宅サーバだが）を milter つき postfix に入れ替えてしまった。すっげーキケン。milter が動かないだけならいいけど、それ以外のところにも問題が出そうなのが怖い。もっとも、ちゃんとしたメールは1日数通しか届かないんだけど（spam は平均250通ぐらい）。
_ postfix 側の設定は要するに milter のソケットの場所を教えてあげるだけ（Sendmail でも同じだが）だからカンタンなんだけど、どの milter も sendmail で使うことしか考えてないから（あたりまえだ）、こっちの方がめんどくさい。sendmail.cf の設定と矛盾していないか起動時にチェックする clamav-milter は論外として、どれも milter が作ったソケットに postfix 権限では書き込みできなくてアクセスするとみなコケる。実験する場合はそんなのは手で修正してやればいいんだけど、本番機で稼働させるとなるとそのあたりをちゃんと調整しないといかん。
_ といっても、実は postfix 側の設定でもハマったんだけどな。ヘッダの正規表現でメッセージをブロックする制限を入れてあるんだが、ローカル(pickup, submission)からの送信ではこれにひっかからないように、これまでは master.cf で -o receive_override_options=no_header_body_checks を指定していた。が、これがあると milter も回避されてしまうようだ。なんで milter が無視されるのかかなーり悩んだぞ。愚直に -o header_checks= -o body_checks= とすれば、{header,body}_checks を無視させながらも milter は適用することができる。ちうわけで、現状の master.cf の該当部分。複雑怪奇。
なお、上では submission で smtpd ではなく submission という本来は存在しないデーモンを呼んでいるが、これは ln -s smtpd submission しただけ。こうしておくとログには postfix/submission と記録され、587 と 25 のどちらに接続してきたのか区別できるようになる。ただし、非推奨かつ、将来のバージョンでも同じ方法が使える保証はない（事実、2.3 から smtp と lmtp は同一のバイナリになり、どちらの名前で起動されるかによって動作が変わるようになったので、symlink を使うこのような手は smtp ではできない）。submission inet n - n - - submission -o smtpd_use_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,permit_tls_clientcerts,permit_sasl_authenticated,reject -o smtpd_data_restrictions= -o smtpd_end_of_data_restrictions= -o header_checks= -o mime_header_checks= -o nested_header_checks= -o body_checks= pickup fifo n - n 60 1 pickup -o header_checks= -o mime_header_checks= -o nested_header_checks= -o body_checks=_ まあそんなわけで、わしが飽きて気が変わったり設定ミスで消えたりしなければ、わしからのメールには DKIM-Signature: ヘッダがつきます。DKIM の verify ができる環境なんて、よほどの物好きでないとないと思いますが。つーか、 google で調べると日本語では本家 sendmail で dkim-milter を動かす情報すらほとんどないんだよな。
_ 音の減衰。距離以外の減衰要因としては、音を伝える媒質である空気自身がいちばんデカいです。
_ 音ってのは空気の振動なので、冗談みたいですが、空気抵抗を受けるです（粘性によりエネルギーの一部が熱にかわる）。なので、振動の激しい高周波音ほど減衰が大きい。近くの雷がピシャッと鳴って遠くの雷がゴロゴロと聞こえるのはこのため。ほかにも空気の非線形性によって波形が崩れて振幅が小さくなる（かわりに時間が長くなる）とか、まあ、いろいろ理由はあるんですけどね。
_ 細かい理屈を説明できるほど覚えてないので、詳しく知りたければそっち方面の専門の本をあたってくださいませ。
_ Apache の WebDAV でファイルが apache の権限になってしまう。よくある悩みですな。でも、Apache だからできないわけではないです。Apache のモジュールで WebDAV を実現しているからできないんです。
_ Apache にはリクエストメソッドに応じて指定された CGI を呼び出す Scriptというディレクティブがあります。つーわけで、mod_dav を使わずに、
てな感じで、WebDAV で使われるそれぞれのメソッドごとに CGI を用意してやって、それを suexec 起動してやれば、apache の権限ではなくユーザ hoge の権限でファイルを管理できるようになるです。パフォーマンスは落ちるだろうけど。<Location /~hoge/dav/> Script MKCOL /path/to/dav-mkcol.cgi Script COPY /path/to/dav-copy.cgi Script MOVE /path/to/dav-move.cgi .... </Location>_ あるいは、もっと単純に /~hoge/dav.cgi/filename のように、WebDAV のすべてのメソッドを実装した CGI が PATH_INFO から引数を受け取って処理する、みたいな形にしてもいいです。
_ CGI を使う方法の問題点は、そういう実装が存在していない、要するに自分で作れ、ということ。がんばって作ってくださいまし。わしはそもそも こういう用途に HTTP を使うのが嫌いなのでその気はまったくなし。
_ ちなみに、Script というディレクティブは最近実装された新しいものではなく、NCSA HTTPD の時代からひっそりと存在してるのにだれにも使ってもらえない不遇な機能であります。
_ またか……。いいかげんなんとかならんかなぁ。
_ えーと、8BITMIME をサポートしてない MTA に送るときの 7bit 変換でコケるわけね。でも、今どき 8BITMIME をサポートしてない MTA なんてないよね。ESMTP の各種拡張機能の実装がはなはだしく遅れている qmail でさえ、8BITMIME だけはパッチなしでサポートしてるんだから。だったら穴を突くメッセージが送られてきても 7bit への変換ルーチンは使われずにそのまま出ていくから DoS が成立しないよ。うん、そんなに問題になることはないよ。
_ あ、そういえば docomo が 8BITMIME をサポートしてねぇ……。ダメだ、すぐ死ぬわ。
_ ところで、この件を FreeBSD SA という記事にするのは観点がおかしいと思う。ライターがそういう人なのは百も承知だが理由にはならん。てゆーか、 回避策はあるようなのに FreeBSD SAでは "No workaround is available" となってるのはなぜ？
_ えー、わたくし、嘘をついておりました。
_ このまえの設定サンプル。正しくは、こう。
長いので書かないけど、submission の方も pickup と同様に -o xxx_checks= の部分を -o cleanup_service_name=... と修正。xxx_checks は cleanup が受け持つので、smtpd や pickup のオプションで指定したって効くはずがない。ちゃんとテストしないで書いてるのがバレバレ。pickup fifo n - n 60 1 pickup -o cleanup_service_name=cleanup_without_filter cleanup_without_filter unix n - n - 0 cleanup -o header_checks= -o mime_header_checks= -o nested_header_checks= -o body_checks=_ で、こういうめんどくさいやりかたをしなくても可能なようにしたのが、2.1 から登場した receive_override_options というパラメータなわけだ。
_ ここ数日でそっち関係の記事がたてつづけに出てるのでちょいとメモ。
_ 1ヶ月前の記事だけど、一方の著作権管理団体の側は。
JASRAC を一方的に悪者呼ばわりするつもりはないんだけど、これにはさすがに溜息。「保護期間の延長に反対する」のと「保護期間を短縮する」のとでは議論の内容がまったく異なるんだけど、なんでごっちゃになってるんだろ。_ あたりまえのことをあらためて書いたってしかたないんだけど、まず第一に文化の発展という大きな目的があって、著作権の保護はその目的のための単なる手段でしかないことを思い出してもいいんじゃないかな（ 著作権法第1条）。手段と目的を取り違えちゃいかんでよ。
_ WIDEプロジェクトなどがDNSサーバ「BIND9」を高性能化--応答速度が最大2.1倍にだそうで。噂に聞いてたけど、そんなに変わりますか。まあ、数百万レコードをマルチプロセッサのマシンで扱うような場合だから庶民には関係ない話ですが。シングルでも1割〜2割程度は速くなると聞いたような気はするけど、数ゾーン数十レコードを管理するだけの庶民には DNS のパフォーマンスが問題になるようなことはございませんよ、ええ。
_ えーと、9.4.0a6 の CHANGES によると、これかな？
architecture dependent ですか。SPARC Solaris じゃダメだよ、と。--- 9.4.0a1 released --- 1813. [func] Restructured the data locking framework using architecture dependent atomic operations (when available), improving response performance on multi-processor machines significantly. x86, x86_64, alpha, powerpc, and mips are currently supported._ このへんの資料と見比べるに、2倍というと BIND8 に肩を並べるぐらいになったってことなのかなぁ？ 条件にもよるからなんともいえんけど。なお、これまでさんさん遅い遅いといじめられてきた BIND9 だけど、これらの資料を見るかぎりではすでに djbdns よりは速いみたい。
_ 今日は疲れたよ。精神的に。
_ なんか書くネタがあったような気がしたんだが、忘れた。まあ、思い出せなくても困らないようなことだと思うけどな。
_ なかなか興味深い。
_ 衝撃的なのはページビューだな。3000PV/月以上あるブログは全体の1割もない、と。4割は1日あたり 10PV にも満たない、と。えー。ブログが流行してるわりには、ちっとも読まれてないんじゃないの。この調査によると、うちのところはどこかに宣伝したわけでもないのに上位5%に入っちゃうよ（昔ながらの Web 日記だから直接比較はできんだろうけど）。「自分の声の大きさを知れ」という格言があるけど、なーに、誰も聞いてないってことか。
_ モノをくれるなら提灯記事を書いてもいい、が3割弱。モノをくれて提灯を強要されなければ書いてもいい、が7割弱。ふーん。まあそんなもんだろうなぁ。
_ って、 有効回答103名かよ。統計的にはさほど問題ないのかもしれんが、でももう少し大規模に調査してくれるとうれしいなぁ。
_ 各所より古川享氏による 720p への圧力。ほほう。なんで NHK が 720p を潰したがったのかよくわからんけど（1080i の優位性だけアピールすりゃいいじゃん）、まあそれが技術とは関係ないところにある政治の世界なんだろうな。
_ 関係ないが、
某放送局のEB沢さんから直接日テレ社長のUJ家氏にこういう無意味な伏せ字はどうにかならんのか（EB や UJ もそうだが、何より「某放送局」）。伏せるつもりなら特定できないようにしろ。伏せるつもりがないなら堂々と書け。若い人でこういうアホな伏せ字をする人は多いけど、古川さんほどのいい歳こいたおっさんでもこんなことするのか。
_ 季刊化されたユニマガを本屋で見た。……なんだこれは。月刊だったころとはまったく別モノというのはまあしかたないだろうが、IPv6 の話ばっかりで UNIX の話がそもそもないじゃないか。UNIX 以外の記事を載せるなと言うつもりはないが、さすがに UNIX の記事が皆無というのは問題ありだろう。
_ 記事を書いてるのが IIJ の社長に副社長に研究員に元社員。なにこれ？ IIJ の広報誌ですか？
_ この前の BIND9 高速化の件。WIDE から プレスリリースが出てた。スレッド数に対してほぼリニアにスケールしてますな。すばらしい。