88171.net

記憶によると軽く5年以上は使ってるSE115。その外装のヤレが気になり始めたので、もうそろそろ隠居させてやろうかと。

Shure以外買う気にならなかったのと、予算感と、Specialという響きで、SE215のSpecial Editionを。まあ正直に言えばずっと前から「次はこれだな」と目をつけてました。ハイ。

音はまあ、低音強いかなどうなのかな、という感じ。そんな違いがわかる大した耳は持ってませんので十分良いです。ハイ。

仕事でちょっとHTML5を調べる機会があったので、せっかくだからとここのblosxomのテンプレートもXHTML 1.1からHTML5に（見よう見まねで）変えてみた。全然HTML5っぽいことしてないけど。

ついでにスタイルシートも書き直してるけど、まだまだ未完成。まあ追い追い調整する、つもり。

今でもあるのか知らないけど、昔のインターネッツには「Webにメールアドレスを貼るとボットに拾われてspamの嵐が来るよ」という風潮（まあ事実なんだけど）があって、実体参照化だの画像化だのJavaScriptで難読化だの、いろんな対策が考案されていた。俺も学生時代に独自ドメインを取って以来、大事なメールアドレスを守るべく涙ぐましい努力をしていたはずなんだけど、結局は数年経ってどっかから漏れたらしくspamが来るようになった。まあメールアドレスを使う限りはそれを誰かに教えないといけなくて、それがさらに別の誰かに漏れないなんて保証はないわけで。

そういえば昨今のspamメールの氾濫を指して「Eメールは死んだ」というような論調があるけど、そんなこと言ったら過去のオープンな通信手段なんてみんな死んでる。訪問セールス然り、テレアポ然り、ポスティングチラシ然り。我が家のメールボックス（物理）なんて不動産やら何やらのチラシという体裁をとったゴミで常にフルなので完全に死んどるわ。そんで稀に超重要な郵便物に気づかずに俺も死ぬ。誰かドラスティックなソリューションがあったら教えてくださいお願いしますよホント。

メールボックス（物理）をフィルタリングしようと思ったら究極的にはもう秘書でも雇うしかないんだけど、メールボックス（デジタル）の方は全自動かつ実践的な手法がいろいろ使えるので全然マシ。中でも全幅の信頼を置いてるのがベイジアンフィルタで、もうこれなしでは生きていけない。うちではbogofilterを使ってるんだけど誤検知はほぼゼロ。検知漏れはたまにあるけど、tri-state（Spam/Unsure/Ham）で使っていて最悪Unsure止まりだし、携帯はHamでしか鳴らないようにIMAPのSeenフラグを制御してるので実害ゼロ。特に流量の多いロシア・東欧の金融系spamとかアパレル系spamとかはだいたいHTMLのテンプレが使い回しの手抜きだから、HTMLの属性値でspamicity爆上げして勝手に自滅してくれる。チョロい。

ちなみに.jpなISPのアドレスもいくつか持ってるんだけど、日本語のspamは.jpなドメインにしか来ないことに最近気づいた。.netには本当に全然来ない。まあ日本語spamの文章ってどれも読んでると気色悪いというか生理的に受け付けないというか虫唾が走るからむしろ有難いんですけど。なんだろねあの感覚。spamに「Check this!!!」って言われても無感情に「No.」としか思わないけど、「ご確認ください！」って言われると「ﾀﾋねクソが」と思っちゃうこの差。母語かどうかの違いだけなのかどうなのか。ちなみにbogofilterは日本語spamも意外とちゃんと捌いてくれます。ただトーカナイズがダメなのでヘッダ丸ごと食わせないとたぶん検知漏れ増えるけど。

ともあれbogofilterサマサマのお陰で平穏な日々を過ごしてたんだけど、去年あたりから新たな刺客が来るようになった。そうLockyお前のことだよ。こいつらランダム文字列で難読化したスクリプトをアーカイブして添付してきやがるし、ヘッダもボディも短い上にパターンが多いからベイジアンフィルタだと捕まえにくい。前述の通り実害はないにせよ如何せんウザいのでClamAVを通すようにもしてみたんだけど、やっぱりスクリプトの検出率は気休め程度。

こいつらどう料理してくれようかと考えて最近入れた対策は、まずClamAVのサードパーティデータベース。SanesecurityのFoxhole databasesがテキメンに効くのでありがたい。SecuriteInfoのjavascript.ndbも試したんだけど、シグネチャベースであんまり効かなかったから外してしまった。メモリも食うし。あともう一つの対策は、エンベロープFromでここのドメインを騙るふてぇ野郎が増えたもんでそいつらはPostfixでreject、というか521で強制切断するようにした。MTAレベルで蹴っちゃうのはあんまり良い気分ではないけど、DKIMヘッダついちゃうしbogofilterの再学習にノイズが載るのは避けたいのでまあヤっちまえと。たぶんLockyの亜種のIKARUSdilapidatedにはこの対策が一番有効で、現在進行形でガンガン釣れてる。

そんなこんなで戦いはこれからも続くんだろうけど、まあ変な話、割とやりがいは感じる。

cacheentries

なんだかんだでこのBlosxomには1400超のエントリがあるわけで、これだけのファイルに毎度毎度stat()かけてるとさすがにちょっと重い。特に、試しにabで100並列でアクセスしてみたら悲惨なことになったので、ちょっとどうにかしてみるかと思い立った。

巷にはEntries Cache Pluginというのもあるんだけど、

• &$entries()を完全に上書きする構造で追うの正直しんどい。
• metaプラグイン対応とかいらない。
• わざわざ頑張ってテキストファイルをパースする必要あるのかこれ。
• キャッシュという割にはテンポラリな情報じゃなくないかこれ。
• lockしてないからキャッシュファイル破壊する可能性ないかこれ。

とか考えると欲しいものとはちょっと違うことがわかったので、車輪の再発明感を覚えつつも自分で書くことにした。

本当に何も凝ったことはせず、デフォの&$entries()から返ってきた[ \%files, \%indexes, \%others ]をStorableでファイルにぶっ込んでおき、一定時間内はそのファイルから読むという、ただそれだけ。ロックもStorableのアドバイザリロック機構をそのまま使ってるので何も考えてない。

これだけなんだけど、チョー適当に計測した感じでは100並列アクセスの所要時間がざっくり半分に、1並列アクセスでもちょっとだけ速くなった。よしよし。

まあそんなアクセスないんだけどな、ここ。

ここ88171.netではかれこれ4年以上StartComの無料証明書を使わせてもらってたんだけど、ここ最近の中国WoSign関係のニュースを見て正直うーんという感じだったので、以前から関心があったLet's Encryptに切り替えた。まあStartComが今後どういう動きをするかわからないから、別にまだしばらく様子を見てもよかったけど。

仕組みさえ作ってしまえば証明書の更新が完全自動化できるってのが地味に便利。年一回の作業とはいえ、やれクライアント証明書どれだっけとかやれ鍵長いくつにしてたっけとか、更新のたびに意外とめんどくさかったから。