どさにっき 2.0 〜2006年4月上旬〜

by やまや
<< = >>

2006年4月1日(土)

無題

_ そんなわけで風邪ひいてます。頭いたい喉いたい咳がでる熱はないけど悪寒がする。

_ 天気いいから花見でもいきたかったんだけどなぁ。でも大丈夫。かわいい嫁さんが甲斐甲斐しくつきっきりでめんどう見てくれてます。いいですなぁ。

_ エイプリルフールだけど嘘じゃないよ。正真正銘ホンモノの妄想だよ。……死のう。


2006年4月2日(日)

無題

_ 全快とはいかんまでも、まあなんとか復活したらしい。

_ 週末を風邪で寝込むが月曜日には治っていつもどおり仕事にいく、ってなんかものすごく損した気になるよな。どうせ2日動けないのならば平日に仕事を休んだ方が。

めも

_ シスコの導入事例。ふーん。


2006年4月3日(月)

無題

_ 今朝はちょっと熱っぽかったけど、きのうよりだいぶラクだったので、治りかけで快方に向かうんだろうと思った。新年度で組織とかいろいろ変わるから休むのはアレだし。ということでふだんどおりうちを出た。

_ 快方に向かうどころか悪化しやがった。素直に休んでおけばよかった。つらい。つーか、新年度いっぱつめの重要なお話を定時後にするのはやめてくれ。ほとんどそのために早退せずに洟たらしながらがんばってたんだが、ぼーっとしててあんまり頭に残ってない。

_ あしたは、具合が悪そうなところがちょっとでもあれば休んでやります。ええ。


2006年4月4日(火)

無題

_ そんなわけで今日も風邪で死亡中。あー、もー、いや。


2006年4月5日(水)

無題

_ 今日もお休み。が、休みますメールを投げても届いてないみたい。調べてみたらメールサーバが腐ってた。応急措置だけしてからぶったおれる。

_ 夕方ぐらいになってほぼ復活。まだ咳は止まらないし本調子ではないけど、あしたにはふつーに動けるようになってるだろう。たぶん。きっと。そうだといいな。

_ 月曜日に無理してなければこんなに長引かなかっただろーなー。

Inbound Port 25 Blocking

_ OCN が Outbound ならぬ Inbound Port 25 Blockingを導入だって。名前は違うけど、まあ、やってることは S25Rとたいして変わらんな。

_ これ、いくつかの ISP には動的 IP アドレスの範囲\ について事前に聞いてまわってたみたいだけど、あったりまえながらすべての ISP の動的ブロックを把握できるはずなんかない。事前に問い合わせのなかった ISP の動的ブロックからの送信はどう扱われるんだろうか。もし S25R と同じように、「逆引きホスト名がそれっぽいものなら蹴る」というロジックを使っているのならば、false positive が多くてとてもサービス提供できるレベルにはならんはず。まあ、「順次対象を拡大していく予定」という文言があるので、そんなことはせず、OCN からの問い合わせに回答のあった ISP の動的ブロックしか蹴られることはないと思うんだけど。

_ ただ、OCN のこれも S25R もそうなんだけど、動的 IP アドレスからまともなメールを送ってるホストの存在をまるっきり無視してるんだよね。たとえば、 ここのメルマガはまぐまぐとか melma とか配送ルートがいくつかあるんだけど、それ以外に UCOMの動的 IP アドレスから直接送りつけてくるものがある。UCOM の IP アドレスが今回の OCN の措置の対象に含まれてるかどうかは知らないけど、もし含まれていれば UCOM 発 OCN 宛のこのメルマガは今後届かなくなる。読者がかなり多いメルマガ( 99年時点で16.5万人らしい)だから馬鹿にならん数が影響を受けるはず。OP25B ならば送信者とブロックする ISP が同じだから、「うちの ISP はそういう方針ですので、こちらで提供するサーバから送信してください」と言えるんだけど、IP25R は送信者とブロックする ISP が異なるから、そういうことを言っても「てめぇの AUP をよその ISP の契約者に押しつけるなっての」というまっとうな反論が返されるだけ。いいのかなー。知らねーぞー。

_ IP25B も S25Rも、これだけを理由に受信拒否するには根拠が弱すぎるとわしは思う。動的 IP から送信されるメールと spam との間には高い「相関関係」があるのは事実だろうが、「因果関係」があるわけではない。spam の蓋然性は高いかもしれないけど、断定はできないはずだ。

_ もちろん、この手法がまったくダメだというつもりはない。「これだけを理由に受信拒否する」のが問題なのであって、ほかの情報も考慮して根拠を積み上げればいい。許可か拒否かシロかクロかという二値論理で判断するのではなく、スコアベースのスパムフィルタを使って、動的 IP 発のメールに中程度のスコア加算をする、という使い方をするのならばかなり有効だろう。判定にひっかかったものを、拒否するのではなく greylisting との二重チェックをおこなう Rgreyもその方向として順当なものといえる(ただし、わしは greylisting もウンコだと思ってるので、素の S25R を使うよりはマシという程度にしか思っていない)。

_ つーかさ、「動的 IP アドレスをふさぐ」という考え自体が腐ってると思うよ。OP25B もたいていは固定 IP アドレス契約のユーザは対象外だよね。だけど、OP25B が完全に普及して動的 IP アドレスからの spam 送信ができなくなったとしても、そのときは spammer は固定 IP アドレスを取得してそっちから spam 送信を続けるだけ。フレッツがある日本の場合、ISP を移ればいいだけだから spammer にとっては固定 IP であることに大した意味があるわけではない。

_ そりゃゾンビとなってユーザ自身に spam 送信の自覚がないような場合は動的 IP アドレスをふさぐのは大きな効果があるだろうけどね。でも、そうなればレジストリから認証情報を勝手に盗みだして「正当に」submission ポート経由で spam を送信する malware が生み出されてそっちが主流になっていくだけのことだろう。いや、「生み出されて」というのは正しくないな。大量メール送信型ワームというのは以前は自前の SMTP エンジンを持たず、メーラーの設定情報どおりに送信するものが大半だったんだから、むしろ先祖返りだ。


2006年4月6日(木)

無題

_ 咳はまだ出るが、ほぼ復調。

無題

_ ネコを怒らせて顔面にひっかき傷を作られるってのはきわめてマンガ的表現なわけですが。

_ そのいかにもマンガ的なひっかき傷が、まったく知らないうちに左腕にできていた。風呂で「なんかしみるな」と目をやるまでまったく気がついていなかった。いつのまにこんなものができたのか、さっぱり心あたりがない。とーぜんネコにひっかかれたわけではない。ここ数日風邪で伏せっていて、うちから外に出る機会すらなかったし、そもそも、この季節ではまだ上腕部をむきだしにするのは風呂か着替えのときの短い時間だけしかない。わしはこんなひっかき傷をいったいどこで作ってきたんだ?

_ はっ、もしや宇宙人にアブダクトされてあやしげな手術をされた痕跡か? しばらく体調が悪いのもこれで説明がつく。記憶が消されてしまって何も覚えていないのがかえすがえすも残念だ:-)


2006年4月7日(金)

Dovecot に乗り換えた

_ 1.4 だったっけ? そのからずっと Courier-IMAP を使ってたんだけど、バージョンが上がるたびにけっこう大きな変更がされるので追いかけていくのがたいへん。4.0 では認証まわりが大きく変わってしまって、こっそりメンテしていた pop3d 用の APOP パッチもとうとう使えなくなった。4.x になってからもうずいぶんたつのに、これのせいでいまだに 3.x のまま。いや、IMAP だけ courier で、POP は別のものを使ってもいいんだけどさ。

_ というわけで、もうすぐ 1.0 が出そうな Dovecot に乗り換えてみた。こっちは APOP 標準サポートだし、調べてみたらフォルダの構造も Courier と互換性が高いようなので。

_ つーか、IMAP をサポートした AirEDGE の端末が出てくれたら POP なんてもういらんのだけどなぁ。そんなことは期待できそうにないのでこの先もほそぼそと。

_ 認証まわりで若干ハマったけど、なんとか動いた。実際アクセスしてみると、……んー、なんか遅いなー。フォルダ内のメッセージ一覧を取得するのに時間がかかる。いちおうキャッシュを生成してはいるようなんだけど、それでもかなり遅い。それ以外の部分の速度はまったく問題ないし、負荷はかなり軽くなってるんだけど。

_ とりあえずはしばらくこのまま使ってみるかのぉ。

Postfix + Dovecot

_ Dovecot に乗り換えたもうひとつの理由が、最近の Postfix 2.3-SNAPSHOT では Cyrus SASL ではなく Dovecot の認証ルーチンを使った SMTP AUTH も選べるようになったこと。Cyrus と Courier は認証のしくみが異なるから、SMTP AUTH と IMAP の認証も別管理だった。認証系を統一できるのならば、そっちの方がメンテが楽だもんね。まあ、Dovecot で Cyrus SASL を使うこともできるから、そっちに統一してもいいんだけど。

_ というわけで、SASL_README に書いてあるとおりにほげほげっと設定変更。……はい、ふつーに CRAM-MD5 で認証して送信に成功しました。おめでとう。あまりに簡単であっけない。

_ ただ、Postfix の応答がアレ。

250-AUTH PLAIN CRAM-MD5 APOP
SMTP AUTH なのに APOP ってなんだーっ。っていうか、LOGIN がないな(使わないけど)。要するに、dovecot.conf の mechanism = で列挙したものがそのまま載ってしまうんだな。これはちょっとアレだ。

_ なので、修正。postfix の方はいじらず、dovecot.conf をこんなふうに変更。実際にはもう少し細かい設定が入ってるけど。

auth default {
  mechanisms = cram-md5 plain apop
  passdb passwd-file {
    args = /usr/local/etc/dovecot.passwd
  }
  userdb passwd-file {
    args = /usr/local/etc/dovecot.passwd
  }
}

auth postfix {
  mechanisms = cram-md5 plain login
  passdb passwd-file {
    args = /usr/local/etc/dovecot.passwd
  }
  userdb passwd-file {
    args = /usr/local/etc/dovecot.passwd
  }
  socket listen {
    client {
      path = /var/spool/postfix/private/auth
      mode = 0666
      user = postfix
      group = postfix
    }
  }
}
SASL_README には socket listen { ... } を auth default { ... } の中に入れろとあるけど、それだと POP/IMAP 用の認証メカニズムが SMTP AUTH でも使われちゃうので分離。あんまり詳しくチェックはしてないけど、たぶんこれで問題ないと思う。

_ ただ、これはうちみたいな小規模なところはいいけど、ある程度のユーザがいるサイトでは使えんな。規模が大きくなると送信用、受信用、POP/IMAP 用、認証用とサーバを用途ごとに分離したくなるものだけど、この方法では Postfix と Dovecot が同じホストで動いてるのが前提で、分離することができない。もっとも、別にこの方法じゃなくても、共通の認証バックエンドを参照するように両者を設定すれば実現は可能なので、それが問題になることはないはずだけど。

_ なお、Dovecot を使った SASL 認証は、サーバサイドの認証だけに対応。Postfix がよそに中継するときに SMTP AUTH が必要な場合には Cyrus SASL じゃなきゃ無理。


2006年4月8日(土)

アレのその後

_ うーん。 先月書いたことのフォローをいただいた。 なぜか /.J で。ありがたいことではあるんだけど、完全なるオフトピックですがな。

_ とりあえず、その後の調査で debian の apache がそういうウンコな設定になっていることはこちらで確認済み。debian 以外にも同じようになっているものがあるのかは知らん。

_ たいしておもしろくもないネタをずっとひっぱるのもいやなので、あえてここには書かなかったんだけど、ちゃんと書いておいた方がよかったのかしらん。まったく関係ないことで /.j を汚してるし。あるいは、この日記にもコメント欄とかあったほうがいいのかねぇ。個人的にはそれほど重要性を感じてないからつけてないんだけど。

無題

_ セキュリティホール memoから ウィニー流出捜査資料にみる警察と各プロバイダの協力関係。うーん、これは……。

_ 中国ネット協会「体制批判は厳しく規制」という記事。なるほど。法の範囲内ならどんな好き勝手を書いてもいいけど、そのかわり気に食わなきゃ法の範囲内であってもどんどんフィルタするよ、ということか。ここまで堂々と語るとはある意味立派だ。


2006年4月9日(日)

中国からの spam を蹴る画期的な方法を思いついた

_ メールサーバに接続したときに出すグリーティングバナーに「天安門事件」とか「法輪功」とかの文字列を入れておけば、中国当局が勝手にフィルタリングしてくれるに違いない:-)


2006年4月10日(月)

XREA 障害

_ 障害なんてのはいつかどこかで起きるものだけど、自分のところに過失のない障害ほど無力なものはないよね。

原因は、上位レジストラ、レジストリにて、誤認情報に基づいたドメインの停止が行われた事であり、現在、弊社側と解決に向けて、法的問題を含め交渉中です。
だそうで。上位レジストラとは eNOM というところらしい。今回はドメインを勝手に止められちゃったみたいだけど、これとはまったく逆に、客の名義で勝手にドメインを取得しやがったというトラブルを起こしたこともあるらしい。 知らなかった。eNOM の名前を覚えておこう(もちろん悪い意味で)。

BIGLOBE の SMTP AUTH

_ 実は BIGLOBE のメールアドレスも持っているわけだ。もう10年近くも使ってるアドレスなので spam 込みで毎日150通くらいのメールを受けてる。送るときにこのアドレスを使うことは最近ではすっかり減ったけど、それでもゼロではない。

_ この BIGLOBE がいつのまにか SPF に対応していることに気がついた。自宅サーバから MX を調べてふつーに送ると SPF で softfail の判定を食らってしまう。えー。というわけで、from が BIGLOBE のメールだけそっち経由で送るように自宅サーバをいじる。

_ えーと、結論からいうと、BIGLOBE の SMTP AUTH を素の Postfix で乗り越えることはできない。BIGLOBE 以外の認証が必要なサーバに送るのと同じような設定だけでなく、以下のパッチを当ててコンパイルしなおす必要あり。

--- src/smtp/smtp_proto.c.orig	Tue Jan 24 00:19:07 2006
+++ src/smtp/smtp_proto.c	Mon Apr 10 22:24:29 2006
@@ -1070,11 +1070,13 @@
 	    /*
 	     * We authenticate the local MTA only, but not the sender.
 	     */
+/*
 #ifdef USE_SASL_AUTH
 	    if (var_smtp_sasl_enable
 		&& (session->features & SMTP_FEATURE_AUTH))
 		vstring_strcat(next_command, " AUTH=<>");
 #endif
+*/
 	    next_state = SMTP_STATE_RCPT;
 	    break;

_ このパッチを当てなくても認証自体は問題なく通る。が、その後でコケる。認証成功後、Postfix はこういうコマンドを送る。

MAIL FROM:<yamaya@mtj.biglobe.ne.jp> SIZE=2840 AUTH=<>
が、BIGLOBE のサーバはこの AUTH というパラメータを理解できずにエラーにしてしまう。よって送れない。この AUTH=<> をつけないようにするのが上のパッチ。

_ RFC2554 には AUTH コマンドだけでなく、MAIL FROM における AUTH パラメータがはっきりと定義されているんだから、これをサポートしない BIGLOBE の方がおかしいよなぁ。


<< = >>
やまや