IAjapan 第9回迷惑メール対策カンファレンス(5/27)　tsudaりまとめ

ぺんつー @pen2

1文字ずつwhitespace入れたり、アルファベット縦読みのspamメールも多いですよね～ #anti_spam

suzuki @suzuki

分散協調フィルタ（シグネチャベースフィルタ）。現在一番よく使われている。誰かが迷惑メールと判定しているものであれば、おそらく迷惑メールだろうと判定する。迷惑メールを受信したユーザが報告→DBに登録。別の人が迷惑メールっぽいものを受信→先程のDBへ問い合わせ #anti_spam

suzuki @suzuki

分散協調フィルタ。迷惑メールの認識率が低い点が問題。大量の迷惑メールを登録する必要あり。登録までのタイムラグがあり。内容変更の一部変更に弱い。 #anti_spam

suzuki @suzuki

分散協調フィルタ。大規模組織やISP向き。大量の迷惑メールが集めやすい。 #anti_spam

Kiyoshi SATOH @stealthinu

やっぱそこを最初に話してるとか RT @suzuki: 重要なのは誤検出率。見逃した迷惑メールは影響少ない、重要なメールが迷惑メールと判定されると影響が大きい。 #anti_spam

suzuki @suzuki

spammer 側の回避策。フィルタリング。単語の加工・挿入。背景と同じ色の単語埋め込み。Webサイトのリダイレクト機能を利用。ファイルへの埋め込み。画像ファイルの添付＋宛先ごとの変形など。 #anti_spam

suzuki @suzuki

フィルタリング側での対策。複数の技法の組み合わせ。フィルタリング技法の秘匿化。ハニーポットの活用で迷惑メールの収集。 #anti_spam

suzuki @suzuki

送信ドメイン認証。発信者ドメインの詐称を識別する手段。問題発生時の追跡が目的。 #anti_spam

Kiyoshi SATOH @stealthinu

これは利用ユーザのクラスタの問題もあると思う。日本じゃ低くてもアメリカでは高いとかありそう RT @suzuki: 分散協調フィルタ。迷惑メールの認識率が低い点が問題。大量の迷惑メールを登録する必要あり。登録までのタイムラグがあり。内容変更の一部変更に弱い。 #anti_spam

suzuki @suzuki

Sender ID。3種類の要素。ヘッダ内の送信者認証。エンベロープFROMの認証。送信者ドメインの認証。 #anti_spam

suzuki @suzuki

PRA。RFC4407。責任があるとするアドレス。Resent-Sender, Resent-From, Sender, From の順番 #anti_spam

suzuki @suzuki

SPFレコード。DNSのTXT(SPF)レコードで送信サーバを宣言。 #anti_spam

suzuki @suzuki

DKIM（ディーキム）。公開鍵暗号方式を利用。送信側が秘密鍵を持つ。受信側はDNSに登録された公開鍵を参照し確認する。 #anti_spam

suzuki @suzuki

2つの送信者認証。IPアドレスに基づく認証が普及先行。ヘッダや本文の書き換えには強いが転送に弱い。デジタル署名を利用した認証は、まだまだ普及していない。転送には強いがヘッダや本文の書き換えに弱い。相補的に利用することが重要 #anti_spam

suzuki @suzuki

普及後の問題点。迷惑メール送信者【も】送信ドメイン認証に対応。一時は迷惑メール業者の方が先行して対応していた。今後は認証後の判定が重要になる。認定サービス、評価サービスなど。ただし、これは新規ドメインの評価が問題。 #anti_spam

ぺんつー @pen2

Domain reputation への言及 #anti_spam

suzuki @suzuki

メール転送問題。転送MTAが迷惑メール送信元と誤判定→転送せずにメール取り込み機能（MailFetcherなど）の活用。 #anti_spam

suzuki @suzuki

転送先アドレスの間違い→これは宛先不明メールの大量送信が発生してしまう。送信失敗によるバウンスメール（NDR）送信の問題。 #anti_spam

suzuki @suzuki

SPF利用時の転送時の問題はSRSという技法で解決が提案 #anti_spam

suzuki @suzuki

NDR問題。Non Delivery Report。迷惑メールを宛先不明で返信すると、それが迷惑メールと解釈されてしまう。 #anti_spam

suzuki @suzuki

NDRを受け取らない方法。BATV。送信時に Return-Path へ署名を埋め込む方法。MX の TTL を長くして、DDoS 攻撃時には MX を切り替え。正しいメールは新しいMXで受け取る #anti_spam

flat/京山和将@昼夢堂 @flat_ff

DNSBLの難点は正確性。正確な運用を求めるなら情報提供には腰が引けるし、不正確な情報が多いと役に立たなくなる。これが自ドメインの拒否だけだったら、影響範囲も広くないし対応も柔軟になるのだけど。 #anti_spam

Kazunori ANDO @ando_Tw

辞書への登録単語数を絞ってパフォーマンスを確保するベイジアンフィルタもあるし、新出単語を評価しないものとか単語の切り出し精度、文字コードについてもコメントなかったなぁ #anti_spam

suzuki @suzuki

送信対策。ISPでのブロッキング。OP25B。自ネットワークからの迷惑メール送信を抑制。 #anti_spam

ぺんつー @pen2

Backscatter時にTTL長めにしたMXを切り替えて攻撃を回避するというのは始めて聞きました #anti_spam