_ よそのメールサーバに溜まったメールを Gmail が POP で読み出してくれる機能ができたっていう 記事。
_ が、これができて「完璧になった」だって。これまで実装されてなかったことを批判してきただって。えー。なんで？
_ Gmail がよその POP サーバからメールを拾ってくるには、その POP サーバに自分のアカウントでログインするための情報を google に教える必要がある。Gmail のメールボックスに溜まったメールにアクセスするための情報を google が知ってるというのはおかしなことではない。でも、google とは無関係なサーバに溜まったメールを読み出すための情報を google が知ってるってのは話が違う。google だからどこの馬の骨とも知れない業者ではないだろうけど、それでもれっきとした他人だよ。その赤の他人に自分のユーザ名/パスワードを教えちゃって平気なの？ そんなに google を信じていいの？ もし万が一 YahooBB や DION がやったような大規模な情報漏れを google がやらかしたとしたら、Gmail に溜まったメールだけでなく、よそのサーバに溜まったメールまで第三者の手に渡っちゃうかもしれないというのに。google がそういうのをぜったいにやらないと信じるだけの根拠はどこに？
_ ちなみに、この手のログイン情報を他人に教えることを約款で禁じてる ISP も少なくない。この機能を使うために Gmail に教えちゃったら、それ契約違反だよね。
_ ついでにいうと、POP ができるということは POP before SMTP もスカスカになるし、POP ログインと SMTP AUTH で同じユーザ/パスワードになってることが多い。つまり、この機能を使うユーザから google は膨大な数の open relay のメールサーバを手にできるわけだ。もちろん、実際にそれを悪用してメールを出すようなことはしないだろうけどさ。
_ Gmail に実装されたということでとりあえず Gmail を槍玉に挙げてみたけど、Gmail が最初ってわけじゃなく、記事にあるとおり同じ機能はだいぶ前から Yahoo にはあったし (*1)、記事にはないけどライブドアのギガメーラーでもサポートされてる。まったく同じ懸念がこれらのサービスにもあてはまる。みんなわかってんのかなぁ。
_ つーか、こういう POP アクセスの機能なんか使わずに、ふつーに Gmail の自分のアドレスにメールを転送すりゃいいのに。
_ これはたしかに便利な機能かもしれないけどさ、その利益を得るために差し出さなきゃいけないものの大きさってのも考えなくちゃいかんと思う。いつも言ってるけどさ、「できる」ということと、それを実際に「やる」ということはまったく異なる次元にあるんだよ。「できる」からといって何も考えずに「やる」にステップしちゃいかんと思うんだけどなぁ。
(*1): yahoo のこの機能はサーバに溜まったメールの未読/既読を判定するのに UIDL ではなく大昔に RFC から削除された LAST コマンドを使う。で、 qmail の POP サーバは LAST の実装がぶっこわれてるので、両者を組み合わせると同じメールを何度も何度も取得してしまうというおかしな現象が発生する。
_ yahoo が SPF 対応だって。少し前からその気配は見せてはいたんだけどね。DomainKeys を進めてる立場だから SPF は政治的にアレかな、と思ってたんだけど、とうとう正式にやってくれた。ふと思いついて ybb.ne.jp を調べてみたら、こっちも SPF レコードがついてた。SOA レコードを見ると、yahoo.co.jp のシリアル番号は 2006121208、ybb.ne.jp が 2006112702。これが日付だとすれば、ybb.ne.jp の方はすでに半月前から対応してたってことか。
_ ちなみに、yahoo.com や yahoo.co.kr、yahoo.com.cn はなし。
「まともに管理されているホストに逆引きがないというのもふつうに存在する」のは事実だと思うが、「まともに管理している」ということを通信相手に伝える努力はすべきではないだろうか？通信はお互いの協力があって初めて成り立つものであるから、 spammer と区別してもらうための努力もせずに、 spammer と一緒にするなと叫んでいるだけでは解決にならない。もちろん、spammer と区別してもらう方法が DNS逆引きの設定だけであると主張するつもりはない。送信側と受信側、双方にとって最も合理的な判別法を選択していくべきであろう。じゃあ、逆引きをしないのがほぼ習慣になっているらしき中国韓国は伝える努力というものをしていないのか。中韓のよく見るドメインのうちのいくつかの TXT レコードを調べてみたら、以下はちゃんと SPF レコードが設定されていた。もちろん、yahoo や hotmail のような大手を筆頭として SPF がないドメインもたくさんあるけど、てきとーに思いついたものを調べたかぎりではけっこうな割合で SPF に対応していた。これらの国もそれなりに努力はしているみたいだよ（あんまり効果はないみたいだが）。SPF がないドメインならともかく、うちのドメインの from はこのホストから出るよ、とちゃんと SPF で宣言してるものならばそれに基づいて判断すればいいのであって、それを無視して逆引きの有無で蹴るってのはやっぱりズレてると思う。SPF に pass したホストと逆引きが存在するホストではどっちの方が素性が確かかなんて自明だよね。もちろん、SPF は pass するけど中身は spam だったというのもあるだろうけど、SPF ってのはそういうものではないので。
- 韓: daum.net、naver.com、hanmail.com、hanmir.com、dreamwiz.com、korea.com、hitel.net、paran.com、chol.com、lycos.co.kr
- 中: sina.com.cn、sina.com、21cn.com、163.com、163.net、126.com、sohu.com
_ ちなみに、日本では SPF 普及率が この前やっと 5% を越えた。これはドメイン数に対する割合だけど、大手 ISP から導入が進んでるから、実際のメール通数に占める SPF 宣言つきドメインの割合はもっと多いと思われる。
_ ひさびさの自転車通勤。出る前にサドルをほんの 5mm ほど上げてみた。これが効果テキメンで、ムチャクチャ軽くなった。あちこちで信号にひっかかる道ながら、25km を平均 25km/h で走破。しかも息は上がって汗もかいたが疲れはほとんどないという理想的な状態。
_ が、帰りは雨。えー。しかたないから電車で帰る。最近は 25km ぐらいじゃ走った気にならんのですが……。
_ また風邪ひいた。最近多いな。こまったことだ。それほどひどくはないのだが、外に出るのはヤメ。先月新しくノート PC を買ったので、お役御免になった旧 Let's note CF-W2 を次期自宅サーバにするべく FreeBSD をインストールする。
_ iso イメージを落としてきて CD-R に焼くのが一般的だが、どーせ1回しか使わないのにそんなことするのってバカバカしいよね。
_ というわけで、FD からインストーラを 起動してネットワークインストールしよう。最近の FreeBSD のインストーラは FD 4枚分あるのか。いつのまにこんなに太ったんだ。FD なんてうちにそんなにあったかな。……あちこちひっかきまわして探し集めてみたけど、何年も前のフロッピーだからエラーが頻発してまともにイメージを書きこめないものがたくさん。書けたと思っても起動すると読みこみエラーになったりするし。めげた。FD はヤメ。
_ んじゃ、USB メモリからブートかな。……あれー、どこいったんだろ。行方不明だ。んじゃ、CF カードからブートするか。……って、もしかしてこの機種は CF カードも USB メモリもブートデバイスとして使えないのか。だめじゃん。
_ そのかわりなぜか PXE ブートができるらしいので、こいつを試してみるか。
_ ブートサーバになる別マシンで DHCP、TFTP、NFS の準備をする。まず DHCP。うちではもともと DHCP で固定 IP アドレスを配ってるので、すでにある設定に TFTP の設定を追加するだけ。それ以外の部分はふつーの dhcpd の設定。
host sakaki { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address 192.168.1.11; filename "pxeboot"; option root-path "192.168.1.26:/export/pxe"; }_ TFTP の設定。inetd.conf に追加。
hosts.allow も忘れずに修正したら inetd に SIGHUP。dhcpd.conf で設定した pxeboot というファイルは /boot/pxeboot にあるはずなので、/export/pxe/ にコピーしておく。ただし、FreeBSD 4.11 の /boot/pxeboot では 6.2-BETA3 は起動できなかった。6.1 のマシンからコピーしてきたら動いた。tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /export/pxe_ NFS は前から動いてるので、うちでは設定不要。動いてない場合は /etc/exports を書いてデーモンいろいろを起動してやる。
_ インストールフロッピーの中身を抽出する。
同様にして kern[1-3].flp からもファイルを抽出する。kernel.gz.a[a-c] が入ってる。gz で圧縮されたファイルはそのままでも認識してくれるはずなのだが、実際にやってみるとどうにも gzipfs がどうので panic してしまうので展開してやる。kernel.gz.* もくっつけて kernel をとりだす。# mdconfig -a -t vnode -u 0 -f boot.flp # boot.flp を md0 として使う # mount /dev/md0 /mnt # ls -l /mnt total 1214 drwxrwxr-x 2 root operator 512 Oct 31 07:28 .snap -rw-r--r-- 1 root wheel 151139 Oct 31 07:28 acpi.ko.gz drwxr-xr-x 3 root wheel 512 Oct 31 07:28 boot -rw-r--r-- 1 root wheel 16384 Oct 31 07:28 kernel.gz.boot -rw-r--r-- 1 root wheel 122 Oct 31 07:28 kernel.gz.split -rw-r--r-- 1 root wheel 1063699 Oct 31 07:28 mfsroot.gz # cp -pr /mnt/ /export/pxe # umount /mnt # mdconfig -d -u 0 # md0 を解放boot/loader.rc に以下を追加。# find . -name '*.gz' | xargs gunzip # cat kernel.gz.boot kernel.gz.a? | gzip -dc > kernel # chmod +x kernel # rm kernel.gz.*ちなみに、USB メモリや CF カードでインストールするときは、メディアを newfs してブートラベルを書き込んだ上でこれらのファイルをコピーしてやれば、ちゃんとブートできる機種ならばインストーラが起動できるはず。たしか。set vfs.root.mountfrom="ufs:/dev/md0c"_ で、ここまでやってインストールするマシンを PXE 経由で起動してやると、見事インストーラが起動する。途中で FD を入れ替えろというメッセージが出るのはご愛嬌。あとはいつもどおりに FTP でダウンロードしながらインストールすればおっけー。
_ 参考。
_ 土曜からの風邪が治らず休み。まあ、そんなにひどくはなかったので無理すれば出られんこともなかったし、夕方にはもうほとんどなんともなかったんだけど、念のためということで。
_ うちの DNS は BIND でも djbdns でもなく NSD で動いてるのだが、とくに理由はなかったりする。BIND でとくに困ってないし不満もないんだけど、NSD はスジはよさそうなものだけど、誰も使ってないみたいだから使ってみるか、といった程度。
_ で、その NSD だが、バージョンが 3.0.x になってだいぶ変わった。あまりに変わりすぎてるので、うちはいまだに 2.3.5 から上げられない。けど、次期自宅サーバとなるべきマシンをインストールしたので、こいつにインストールしてちょっといじってみた。
_ 以下、箇条書きにて。風邪ひき頭でボケてるかもしれんので、これを信じる前に自分で調べ直せ。
表から見えるところで気がついたのはだいたいこんなかんじ。ほかにも変わったところはあるかもしれんし、内部がどうなったのかはさっぱりわからん。
- 設定ファイルが大きく変わった。2.x のものはまったく使えない。ゼロから書き直す必要がある。
- できることが増えたぶん設定項目は増えてるが、それでも BIND ほど大量のオプションはない。
- ついに IXFR をサポートしたらしい（2.x では使えなかった）。
- NOTIFY の受信もサポートしたらしい（2.x では NOTIFY を送るだけ）。
- セカンダリサーバとして使う場合、2.x では SOA レコードの refresh、expire の時間を無視して cron で定時に同期する運用だったが、ちゃんと SOA を見るようになったらしい（まだ cron は使う部分は残る）。
- 2.x では AXFR のアクセス制御を hosts.allow で設定していたが、3.x では AXFR/IXFR、NOTIFY をそれぞれ設定ファイル内でふつーにアクセス制御できるようになった。
_ これまでは、おれは孤高の DNS だぜっ、と単独運用するには特に問題なかったんだけど、マスター/スレーブという構成でそれぞれの連携を考えるちょっと使いづらいところがあった。3.x になってこれがだいぶ改善されて使いやすくなった感じ。かなり人に薦めやすくなった。積極的に NSD に乗り換えを迫るほどでもないけど。
_ とりあえずしばらくこれでつついてみて、問題ないようならば入れ替えてみるかな。
_ 軽く頭痛がして咳がでるけど、自分としては復活したつもりで出勤。
_ が、「今日なんかオフィス寒くね？」とまわりにこぼしたら、そう感じてるのはわしだけだったらしい。室温が低いんじゃなくて、わしひとりだけの悪寒かよ。だめじゃん。
_ わしがもたもたしてるうちに しお兄ちゃんも同じ主旨で書いちゃったけど、せっかくなので上げとく。 百式の中の人、RFC違反はもちろんWebサーバ運営者の迷惑をまるで考えない設定を推奨するの巻
_ 主旨に異を唱えるものではない、っつーか、むしろ同意なんだけど、でもそれを主張するためにウソをつくのはいただけない。
RFC2616には「同時接続数はhttp/1.1では2まで」と明確に定められている。紹介されている手法はこれに明確に違反しているちゃんと RFC を 読もうぜー。マイクロソフト社のサポート情報にも次のような記述がある。なんで RFC を引用しないで妙なところから引用するの？_ RFC 2616 の 8.1.4 Practical Considerations より。
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.SHOULD だよ。MUST じゃない。これを「明確に定められている」というのはどうなのかなぁ。SHOULD ってのは制限を逸脱したときに発生しうる問題をちゃーんと理解した上で、そうするだけの妥当な理由があるのならば無視してもかまわない、ってことであって、けっして強制はしていないし、破ってもただちに違反とはいえない。RFC 1945 (HTTP/1.0) ではまったく触れられてもいないし。_ もはや議論術の範囲になっちゃうかと思うんだけど、RFC で SHOULD となってる制限を無視しているものを糾弾するのに、RFC 違反だ！と主張して論破するの本来はムリがある。だって RFC では禁止してないんだもん。この論法が有効なのは RFC の読み方を知らんやつを騙すときぐらい。RFC ってのはインターネットのエラい規格なんだ、そこに大文字で SHOULD と強調してるぞ、だから従え。大嘘だけど。ある程度知ってる相手のときには違う攻め方をする。SHOULD となってる制限を無視するからには相応の納得できる理由を出せるんだろうだろうなだったらそれを言ってみろ、とか。トラブルが起きたときの責任のなすりつけあいに負けると困るので、どこまでやっていいか悪いかをちゃんと把握しておいて、自分の正当性を主張するためにグレーゾーンを白っぽく見せたり黒っぽく見せたりするこの種の詭弁術は必須:-)。そういえば最近この手の喧嘩はあんまりしてないな (*1)。
_ Web 屋を自称するぐらいだから、HTTP の同時接続数の上限 2 というのが RFC では MUST ではないということぐらいは当然承知してたと思う。メール屋のわしでも知ってるぐらいのことだし。だからこそ、RFC を引用せずにかわりに名前の知られた大企業のページをわざわざ探してきてそこから引用したんだんだろう。ここでは RFC の権威は借りるけど実際にはどう書かれているかを示さず、いちいち原典を参照したりしないほとんどの人を騙すという詭弁のトリックが使われているわけだ。根拠があるように見せかけるブラフとして RFC を使うことは、あんまり好ましいことじゃないけど、まあ否定はしない。でも、多くの人の目に触れるときにはブラフは通用しないということは覚えておかなければいけない。
_ 勘違いされないよう念のため書いておくと、そんなアホなことを宣伝するのはやめれ、という主張自体は支持する。その主張の論理組み立て（というかそもそもの前提）がおかしいということ。サーバ側で受け入れられる同時接続数には限りがあるから、ひとつのクライアントでたくさん占有しちゃうとほかの人がつながりにくくなるよね、そういう可能性を無視して自分の接続性を優先するってのは理由として妥当なの？ 正当な理由があるんじゃなくてただのエゴなんでしょ、RFC にもやるべきじゃない、って書いてあるよ、だからやめれ。こういうふうに議論をもっていかないとダメ。
_ (12/21 追記) なんとなく誤解されてそうな気がするので補足しておく。MUST NOT じゃないならやってもいいじゃん、といってるわけではない。日本語で「べきである」というとなんだか努力目標ぐらいの弱い意味にとらえられるかもしれないけど、英語の should はそれよりも意味が強く、日本語では「しなければならない」に近いぐらいの意味になる。要するに、RFC で SHOULD NOT だったら、基本的にはやっちゃダメと解するのが妥当。それでもどうしても必要で、万人を納得させられるような極めて合理的な理由がある場合にかぎり逸脱してもかまわない、ということ。強制はしていないし、破ってもただちに違反とはいえないけれど、原則は禁止、である。
(*1): リアルではこんなやくざなじゃなくて紳士な対応をしてるはずです信じてください。