ククログ

milter-greylistでtaRgrey

milter-greylistにtarpit機能が取り込まれました。これにより、milter-greylistでtaRgreyを実現できるようになりました。

taRgrey

taRgreyはメールの送信側情報や送り方などから迷惑メールを排除する方法で、現在のところ90%以上の迷惑メールを排除できます。taRgrey以外にも送信側の情報を利用する迷惑メール対策はありますが、taRgreyは誤検出を抑えることを重視した対策であることが特徴です。（taRgrey関連技術の長所・短所や迷惑メール対策に関する考え方などは第9回まっちゃ445勉強会でのさとうさんの発表を参照してください。）

導入までの流れ

taRgreyのページにある通り、現在taRgreyを実現するためにはPostgreyにパッチをあてる必要があります。Postgrey自体はパッケージシステムで提供されている環境が多いため導入が容易ですが、その後、手動でパッチをあてなければいけないため、多少、導入の敷居があがっています。

milter-greylistもPostgreyと同様にパッケージシステムで提供されている環境が多く、導入が容易です。今回、milter-greylist本体にtarpit機能が取り込まれたことにより、パッケージシステムでmilter-greylistを導入し、設定を変更するだけでtaRgreyを実現できるようになりました。

とはいえ、tarpit機能が取り込まれたバージョンが安定版としてリリースされるのはもう少し先になるので、今はまだパッケージシステムで導入したmilter-greylistでtaRgreyを実現することはできません。

設定

milter managerと一緒にmilter-greylistを使う場合、milter-greylistの設定はこれだけです。

racl whitelist tarpit 125s
racl greylist default

非常に簡潔に書けることがわかります。

まとめ

milter-greylist本体にtarpit機能が取り込まれたことにより、より簡単にtaRgreyが実現できるようになったことを紹介しました。

tarpit機能が取り込まれたバージョンがリリースされるまでの間に変更される部分もあるかもしれないので、ここではあまり詳細に立ち入らずに簡単な紹介にとどめました。安定版としてリリースされたら、より詳細な設定方法や注意点などを紹介する予定です。

この記事の続き

2009-09-07

(tokyo-emacs #x02)の資料公開

クリアコードのインターンシップに参加したはやみずさんが主催する(tokyo-emacs #x02)で使った資料を公開しました。

tokyo-emacsの発表資料一覧ページ（PDF）
run-test.el（HTML）

現在のところ、まだ、上記の一覧ページには発表者全員の資料が揃っていませんが、おいおい揃っていくでしょう。参加できなかった方は公開された資料で内容を感じてみてください。ただ、当日はデモまじりの発表も多かったため、資料だけでは伝わらない部分もあるでしょう。

(tokyo-emacs #x02) レポまとめから辿れるレポートを読めば、資料からだけではわからないことも垣間見れるでしょう。資料だけ、レポートだけで物足りない場合は、次回は参加してみてはいかがでしょうか。

デモ

発表ではテスト起動を支援するrun-test.elのデモをするという名目でRabbitのデモをしました。

会場にRabbitユーザはほとんどいませんでしたが、Rabbitユーザにとってはよだれものだったはずです。

自動サイズ調整

簡単なデモであればスライドに穴を開けてデモをしますが、今回のようにEmacsでコードを書きながらのデモではスペースが小さくなってしまいます。また、穴を開けるとスライドを参照することができないという問題もあります。

今回のデモではウィンドウのサイズを変えて、縦は最大化・横は200px程度とし、画面左にスライド、右にEmacsという並びにしました。Rabbitは縦横比が変わってもそれっぽくレンダリングするので、今回のような使い方ができます。

Rabbitでデモをするときは、穴を開けるだけではなく、ウィンドウサイズを変えることも検討してみてください。

rabbit-commmand

RabbitにはdRubyなどでRabbitを遠隔操作するrabbit-commandというコマンドが付属しています。また、Emacs上でRabbit用スライドを編集するためのrabbit-modeにはrabbit-commandを利用してスライドを進めるコマンドが用意されています。

今回はスライドに書かれている内容を実際に動かしながらデモを行ったため、スライドの内容を取得できるとタイピングしなくてもよいためとても便利です。そこで、trunkにrabbit-command経由で現在のスライドの内容を取得するコマンドを追加しました。デモでは、EmacsからC-uM-!でrabbit-commandを呼び出すことにより、スライドの内容をEmacsに貼り付けてタイピングの手間を省きました。

もちろん、次のスライドへの移動はrabbit-modeのコマンドを利用しました。

現在のスライドの内容を取得するコマンドは以下の通りです。Rabbitを使った発表でコードを書くようなデモをするときに役立つでしょう。

% rabbit-command --current-slide-rd

まとめ

はやみずさんが、tokyo-emacsはみんなで作るものだ、ということを強調していたのが印象的でした。11月にあるらしい(tokyo-emacs #x03)に参加して、tokyo-emacsを作ってみてください。

Emacsに少しでも関連していれば発表側で参加することもできそうな雰囲気でした。発表側でtokyo-emacsを作るのも面白いかもしれませんよ。

この記事の続き

2009-09-09

とちぎRuby会議02参加登録受付中

10月24日に開催されるとちぎRuby会議02の参加登録が行われています。懇親会参加の状況から推測するとまだ登録できそうです。

今回は、超優良企業の1つとして声をかけてもらい、出場者として参加できることになりました。ワイクルの角さん、ヴァインカーブのやまだあきらさん、タワーズ・クエストの和田さんも出場者として参加されます。とても楽しみですね。

咳さんのdRuby本をテキストとしたtoRuby勉強会も開催されるそうです。こちらもとても楽しみですね。

都合があう方は参加してみてはいかがでしょうか。

2009-09-11

るびま0027号

週末にるびま0027号がリリースされました。5周年だそうです。おめでとうございます。

ささださんのコメント

n周年のときに毎年ささださんがコメントを書いていますが、今年のささださんのコメントが明るめになっているのが印象的です。「脱ささだ体制」が進んでいる影響でしょうか。

URLを集めていて気づいたのですが、4周年のときだけ「ko1-comment」ではなく、「4th-ko1」なんですね。

まとめ

るびま0027号の興味深い記事を2つ紹介しました。

自分でも何かできることはないか、と思っている方は、ただのRubyistであるかずひこさんのRubyist にできることがおすすめです。あるいは、記事の提供や編集でるびまに参加するというのもいかがでしょうか。

まだRubyNewsを読んだことがない方は一度読んでみてはいかがでしょうか。日本Ruby会議2009の間にたくさんのフリーソフトウェアがリリースされたことがわかります。

今回もここでは紹介しきれないくらい盛りだくさんのるびま0027号をぜひ読んでみて下さい。

2009-09-14

milter manager 1.3.1リリース

迷惑メール対策ソフトウェアmilter manager 1.3.1をリリースしました。

開発版

milter managerのバージョン番号は「MAJOR.MINOR.MICRO」というルールに従ってつけています。例えば、今回のバージョンの「1.3.1」は以下のようになります。

MAJOR: 1: メジャーバージョン
MINOR: 3: マイナーバージョン
MICRO: 1: マイクロバージョン

このうち、マイナーバージョンが偶数のリリースは安定版、奇数のリリースは開発版という扱いになっています。そのため、「1.3.1」は開発版になります。

開発版は安定版よりも新しい機能がありますが、安定して動作しない可能性があります。しかし、次期安定版が近くなった開発版はわりと安定して動作します。そして、今回の1.3.1はわりと次期安定版に近いリリースになります。もし、以下で紹介する開発版のみにある「評価モード」を利用したい場合は試してみて下さい。

評価モード

世の中にはたくさんのmilterがありますが、すべてのmilterがすべての環境で効果的なわけではありません。それぞれの環境にあった迷惑メール対策を行えるmilterを導入する必要があります。

そのためには、導入する前にどのような効果になるかを試してみる必要があります。ENMAやOpenDKIMのように結果をメールヘッダに追加するタイプのmilterであれば、想定とは違う動作だったとしても既存のメールシステムにはほとんど影響はないため、既存のメールシステムに導入して効果を確かめることができます。一方、milter-greylistなどのように一時拒否や拒否をするタイプのmilterであれば、誤判定のメールを受信できなかったなど、既存のメールシステムに与える影響が大きくなるため、既存のメールシステムで効果を確かめることが難しくなります。

そのような場合でもmilterの効果を確かめることができるようにするのが1.3.1で追加された「評価モード」です。評価モードを用いると、実際にmilterを動かしますが結果は無視します。実際にmilterを動かしているので、milter managerやmilter自身が出力するログなどでどのように動作したかを確認することができます。milter managerはログからグラフを生成する機能もあるので、視覚的に効果を確認することもできます。

先日の第09回まっちゃ445勉強会の資料で評価モードについて説明した図があるので、それを見てみましょう。

まず、評価モードを使っていない通常時の動作の流れです。

milterがメール本文を変更するなどの操作をした場合は、milter managerはそれをそのまま呼び出し元のメールサーバ（図では受信側と書いている部分）に返します。注目してほしいのは、milterと呼び出し元のメールサーバの間にいるmilter managerがやりとりをログに残し、グラフ化している部分です。milterやメールサーバに結果の統計情報を収集する機能がなくても、間にmilter managerを導入するだけで結果の統計情報を収集することができます。これは、milterの効果を確認するときにとても便利です。

それでは、評価モードを使っているときの動作の流れです。

上の2つのmilterが評価モードで動いています。評価モードのmilterがメール本文を変更するなどの操作をしていますが、呼び出し元のメールサーバにはその結果は返っていません。つまり、milterの結果が既存のメールシステムに影響を与えないということです。しかし、milterの結果の統計情報を収集する部分は動作します。これにより、既存のメールシステムに影響を与えずにmilterの効果を確認することができるようになります。

いつまでも同じ迷惑メール対策が効果があるとは限りません。迷惑メール送信側も進化していますが、それに対する有効な対策も考案されています。そのような対策を導入する場合、ここで紹介した評価モードが有用になるでしょう。

まとめ

1.3.1がリリースされたので、新機能「評価モード」を紹介しました。

1.3.x系列は他にも1SMTPセッションで複数のメールを送る場合の処理が改善されていたり、milter-greylistを用いたtaRgreyに対応していたりします。

このような機能が必要な場合は1.3.1を試してみてください。もし、問題があった場合はメーリングリストで報告してもらえると助かります。

また、milter manager導入情報もお待ちしています。以下のような情報をメーリングリストかkou@clear-code.comまで送ってもらえると、今後の開発などの参考になるので助かります。

milter managerを利用しているメールサーバのスペック（OS、CPU、メモリ量など）
milter managerを利用しているメールサーバの規模（単位時間あたりの流量やアカウント数など）
milter managerの使い方（どのようなmilterと一緒に使っているか、特別な設定をしているかなど）
その他、コメント（ここが便利だ、この機能が不足している、こういう情報が欲しいなど）

最後になりましたが、先日発売されたセキュリティExpert 2009に迷惑メール対策関連の小さな記事（4ページ）を書きました。見かけた場合はぜひ手に取ってみてください。

セキュリティExpert 2009
編集部/B5
技術評論社
(no price)

この記事の続き

2009-09-16

デバッグで大事なこと: 必要な部分だけに集中

1ヶ月ほど前、Ubuntu上にSamba 4で構築したActive Directoryドメインに、FreeBSDマシン上のLikewise*1を使ってドメイン参加できるか試してみました。

Windows VistaやWindows XPなどからはSamba 4にドメイン参加できましたが、Likewiseからは失敗しました。Samba 4側に問題がありそうだったので、調べて直してSamba本家へパッチを登録していました。数日前に取り込まれたのでSamba 4 alpha9からはLikewiseを利用したクライアントからもSamba 4にドメイン参加できることでしょう。

バグを直したことについて書いたので、デバッグのことについても少し書きます。デバッグ作業は以下のような流れになります。

確実に問題を再現できるパターンを見つける
問題箇所を絞り込む
問題を修正する
問題が解決されていることを確認
コミットする or パッチを送る

問題の修正の仕方については言語や分野などによって様々な方法があるので、ここでは取り上げません。ここでは、デバッグ作業の中でも重要な「問題箇所を絞り込む」ことについて書きます。

知らないソフトウェアのデバッグ

クリアコードではフリーソフトウェアを扱うことが多く、また、ソースコードレベルまで立ち入った問題修正やカスタマイズなども行います。もちろん精通しているフリーソフトウェアも多くありますが、すべてのフリーソフトウェアについて精通しているわけではありません。

例えば、Samba 4もすべてを把握していないフリーソフトウェアの1つです。それでも、問題を修正したりカスタマイズしたりすることができるのは、すべてのことを知ろうとせず、必要な部分だけに集中するからです。

デバッグをする場合に重要なことはこの必要な部分だけに集中することです。

クリアコードでは「ソースコードがあれば大丈夫です」と言うことがよくあります。これは、たとえ大きなソフトウェアでも必要な部分だけに集中すればすべてを把握しなくとも問題を解決できることを経験して知っているからです。ソースコードがあれば、たとえドキュメントでは触れられていない問題に遭遇した場合でも、必要な部分に集中して問題を解決することができます。

問題箇所を見つける方法

デバッグをするときに必要な部分はどこでしょうか。それは、問題が発生している箇所です。ここを見つけたら半分位解決したようなものです。

ケースバイケースですが、以下のような流れで問題が発生している箇所を見つけることができます。

ログレベルをあげて、再現パターンを実行
エラーメッセージをWeb検索（最新版では修正されているかもしれません）
エラーメッセージでソースコードをgrep
ログメッセージを追加し、さらに絞り込む

Sambaのようにネットワーク通信を行うようなソフトウェアであれば、Wiresharkなどでパケットをのぞくのもよいでしょう。ネットワーク通信を行わないようなソフトウェアであれば、デバッガで絞り込む方法もあります。

そのような場合も、ある程度ログメッセージからあたりをつけておいた方が効率よく問題箇所を見つけるとができます。まずログをみることは重要なポイントです。

問題箇所を見つけることができたら、あとは修正するだけです。頑張ってください。

まとめ

効率よくデバッグをするために重要なこと「必要な部分だけに集中する」を紹介しました。

ソフトウェアを開発しているとバグに遭遇することは多くあるでしょう。バグを直すときは、必要な部分がどこかを見失わないようにしてください。必要な部分を見つけられなかったり、間違ってしまうと、なかなかバグにたどり着けません。そういうときは少し時間をあけてからもう一度さがしてみると必要な部分を見つけられることがあります。

バグを見つけたときはレベルアップするチャンスです。ぜひデバッグして直してみてください。

*1 Likewiseはオープンソース版のLikewise Openを使いました。

この記事の続き

2009-09-24

インストールするだけでActiveScaffoldのメニューを日本語化

以前、ActiveScaffoldの地域化の中で、ActiveScaffoldLocalizeを使ってActiveScaffoldのメニューを日本語化する方法を紹介しました。

時は流れて、ActiveScaffoldLocalizeから日本語メニューのリソースが削除（！）されたり、ActiveScaffold本体に各言語のリソースが含まれるようになったりしました。しかし、本体には日本語リソースが含まれていなかったため、Web上には、いまだにActiveScaffold Japanese L10Nを使う、自分で日本語リソースを作成して使う、というような情報がでていました。

本家にフィードバックして取り込んでもらえれば、多くの人がより手軽に日本語化されたActiveScaffoldを使えるだろうに、ということで、先日、本家に日本語リソースを取り込んでもらいました。これからは、ActiveScaffoldLocalizeなどを使わずにActiveScaffold本体のみで日本語メニューを使うことができます。

手順

簡単に日本語メニューのActiveScaffoldを使う手順を説明します。

まず、ActiveScaffoldに依存しない、一般的なI18nまわりを整備します。

% rails shelf
% cd shelf
% script/generate resource book title:string
% rake db:migrate
% gem install amatsuda-i18n_generators -s http://gems.github.com/
% script/generate i18n ja

続いて、ActiveScaffoldまわりを整備します。

% script/plugin install git://github.com/activescaffold/active_scaffold.git

config/routes.rb:

1 2	- map.resources :books + map.resources :books, :active_scaffold => true

app/controllers/books_controller.rb:

1
2
3

class BooksController < ApplicationController
  active_scaffold :book
end

app/views/layouts/application.html.erb:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="content-type" content="text/html;charset=UTF-8" />
    <title>ActiveScaffold l10n</title>
    <%= javascript_include_tag(:defaults) %>
    <%= active_scaffold_includes %>
  </head>

  <body>
    <h1>ActiveScaffold l10n</h1>
    <%= yield %>
  </body>
</html>