最近、「〜に行ってきた」ばかりになってる気もするけど、2010年8月21日に行われた株式会社ハートビーツさん主催のインフラエンジニア勉強会、第14回hbstudyへ行ってきた。

インフラ専門というわけではないんだけど、スパムメールフィルタのSpamassassinの管理をやっていたことがあり、その辺の話や送信ドメイン認証辺りの話も聞けるということなので参加決定。
残念なことになっているGoogle Waveの「Google Wave追悼会」も同じ日に開催ということで迷いに迷ったあげくこちらに決定。当日はまさかのGoogleオフィスでの開催で、結構盛り上がったみたいだ(Togetter – 「Google wave追悼会」)。
Wave本は買わせていただきます。

当日は、麻布十番祭りともカブっていて、街中には浴衣の女子が沢山。ぶっちゃけ祭り行きたかった(笑)。

ここから本題。
当日発表されたのは、
SpamAssassin – 60分間スパム・クッキング 滝澤 隆史さん

SpamAssassinは前に、スコアリングがおかしくなってスパム判定されてしまう事態に直面したことがあったので、是非とも業界標準的なところを知っておきたかった。
以下メモ

・SpamAssassinは2010年8月現在、Perl5.12環境下では動作しない
・Perlで書かれているので、Perlのプログラムに組み込むことができる
 →メール(テキスト)の内容を解析してスコアリングするロジックは何かに使えそうな気がする。
・SpamAssassinの処理時間の長さは、ネットワークテストにおけるDNSクエリの応答によるものなので、専用にDNSキャッシュサーバを用意すれば緩和される(unboundがおすすめらしい)
・スパムの反対語ってハムだそうだ(笑)。

迷惑メールと判定する条件について
・経路情報(IP逆引きができるか、DNSBLに登録されていないか)
・エンベロープ情報
・SMTPセッションの挙動
・メールの内容

SMTPセッションの挙動に関して…この辺の仕組みはあまり分かっていなかった
Greylisting
一時拒否した後に再送してきたら受け取るというGreylistingという方法があるらしい(スパムは大量送信するため、再送しない)。
配送遅延やスパム配信元ではないが再配信しないシステムのために、疑わしい時のみGreylistingを行うSelective Greylistingというやり方もある。
Tarpitting
SMTPセッション中の応答を遅らせる
スパムは大量配信するために、タイムアウト時間を短くして自らセッションを切断するという考えに基づく

メールの内容の判定について
ベイジアンフィルタ
ベイズテストはハム・スパム共に200通学習したら判定を開始する

送信ドメイン認証
SPF、DKIM、Sender ID、Domain Keysなど。
当然SPFをpassしたからといって、スパムではないとは言い切れない。
サイト作って、サーバからメール送信する必要がある場合は、送信ドメイン認証(SPFとお金に余裕があればDKIMも)とIPの逆引き、最後に送信されたメールのヘッダの確認は必ずしましょうってことで。

送信ドメイン認証最新動向と ENMA の導入・活用・展望 鈴木高彦さん

View more presentations from SUZUKI Takahiko.

こちらはIIJでメール一筋の方の発表。

送信ドメイン認証の動機
・増え続ける迷惑メール
・素のSMTPには送信者情報を保証する仕組みがない
 エンベロープFromもヘッダFromも書き換え放題
というわけでメールが正当な送信ドメインから発信されていることを保証
・エンドユーザの管理はドメインの責任
・ドメインは送信されるメールに対して責任を持つ

迷惑メールの根絶において、いわゆる「銀の弾」にはなりえない
信頼できるドメインかどうかは別途リストが必要

SPFの導入が進んだのは、2007年11月のドコモショックが契機
NTTドコモが迷惑メール対策に、SPFを導入。これによりドコモ宛にメールが送信できなくなり、導入が進んだ。
という経緯から、国内では圧倒的な普及率を誇る。具体的な数字は秘密だが、海外でも実用に十分な普及率らしい。
SPFレコードを書く際、最後は強く「-all」を宣言する。
SPFレコードのincludeのループに注意する。
認証結果を見る際には、passとそれ以外と見る。スコアよりも認証されたドメインの方かどうかが大事。

DKIM
信頼性の高さから本命と見る向きは多い。金融業界などでDKIMの採用例は多い。
主要なMTAでは実装済み
国内で対応しているISPは数社程度(送信ドメイン認証|迷惑メール相談センター)。

SPFかDKIMかと言われれば両方必要。適切に送信しないと受け取ってもらえない時代へ。

SPF、DKIM導入に当たって、組織によってはメールストリームの洗い出しが最大の難所となる。
自社メールサーバ、メルマガ配信委託先、自宅・出張先などからの個人契約でのISP経由での送信etc…
自網内からの送信は最悪FWで止めてしまう。そうすれば送信できないと騒ぎ出す(笑)。ただし他の手を尽くしてからの最終手段。
できれば異なるメールポリシーを持つメールストリームには異なるドメインを割り当てる(社員アドレス用、メルマガ用、機械メール用など)。

いろいろな統計やSPFの認証結果の見方なども詳しく書かれているので、一度目を通しておくと良いと思われ。

関連記事

コメント一覧

コメントはまだありません

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

スパム防止のため下の計算結果を入力して下さい *

ページの先頭へ