パスワードを忘れた？ アカウント作成
Close
15157 story

IPアドレスの最近傍識別を行うSPAM Filter 101

ストーリー by kazekiri
ここまで公開してるのは珍しい？ 部門より

twada 曰く、

今まで私は，約5年間本業の画像の研究の傍ら，SPAMフィルタの研究と開発を行なってきました．コンテンツ内のURLなどのフィンガープリントを用いた方法，ベイジアンフィルタ，など色々作ってみては，精度が十分高くないことに満足が行かず，何度も試行錯誤を繰り返しました．そして，最終的に行き着いたのが，このNNIPFと名づけたフィルタです．説明とソースはこちらのサイトにあります．(続く)

このフィルタの特殊性は，１）自分が外部からメイルを受けるときに使っている信頼できるMTAを登録しておき，そのMTAが生成したReceived:行から送信元のIPアドレスを割り出すという点，２）IPアドレスを最近傍識別することによってSPAM検出を行うという点，です．これが妥当性を持つ理由は，Received行の改竄に対応でき，しかもIPアドレスは，組織の種別によって番号の偏りがあるので，まっとうなメイルの送信元と，SPAMメイルの送信元にはかなりの偏りがあるためです．現在登録しているSPAM-IPは1万8千以上，HAM-IPは千数百程度ですが，最近傍識別は木探索を用いて一瞬で終わります．

ABUSEされたマシンから送ったまっとうなメイルがブロックされるという問題はあるかもしれませんが，私が使ってみた限りそういうケースは０でした．また，SMTP強制切断を行いRFC2821準拠でないものを落とすことで十分ではないかという話もありますが，これを用いても一旦他のMTAで中継されたメイルは通り抜けます．また，最近は専用SPAM送信マシンからRFC2821準拠で送られてくるSPAMもあるようです．こういったわけで，うちの組織も入り口でRFC2821のチェックをしてますが，私個人の場合は毎日10通以上は楽に通り抜けてきます．

そこでやっぱりフィルターは必要になるのですが，コンテンツを見て識別するフィルターはやっぱりミスをしますし，なかなか学習がいつどのように行なわれるのかが分からず，うまく御すことが難しいと思っておられる方は多いと思います．NNIPFは最近傍識別を用いたことで，これまで我々が開発してきたどんなフィルタよりも，精度が高く，学習も一瞬で終わるという性質をもちます．また，MTA上でSPAM検出をしますので，検出されたメイルはダウンロードされません．つまり，出張先のPHS接続で，SPAMばかりダウンロードするといったことが起きません．また，誤識別や，検出漏れなどがあった場合には，WEBインタフェースから修正を行なうことができます．このフィルタの長所はこういったところですが，逆に短所はというと，

  • MTA＋POP/IMAPサーバ＋WEBサーバという3つの機能の揃ったLinux上でしか動かない
  • メイルのメカニズムが分かっていない素人には設定や運用が難しい
の2点です．ですから，個々人で利用するよりもメイルの管理者が導入してユーザに利用法を教えるという形が取られると思います． Perlで書かれたフリーソフトですので，ご自由にお使いください．
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

IPアドレスの最近傍識別を行うSPAM Filter More

  • ベイジアンフィルタだと (スコア:3, 参考になる)

    by tarosuke (2403) <webmaster@tarosuke.net> on 2007年04月13日 13時49分 (#1142267) 日記
    ヘッダのみをチェック/学習対称にした方が断然精度がいいみたいなんだけど、それと関係あるのかもね。

  • バグレポート (スコア:3, 参考になる)

    by Ryo.F (3896) on 2007年04月13日 18時17分 (#1142422) 日記
    ソース見ました。動かしてませんが、バグがあるんじゃないかと思います。
    というのは、メール送信者IPアドレスを抽出する(NNIPF/PERL/header.plの中のmain'HeaderAnalysis)時に、メールヘッダの最初から走査して、Received:行の内、最後にMTAOBのリストに一致したものからメール送信者IPアドレスを抽出しているように見えます(違ったらすまん)。普通、Received:行は、新しいものが最初の方に来ますから、MTAOBのリストと一致するものの中で、一番古いものと一致することになります。
    という事は、MTAOBのリストを知っているスパマーは、偽のReceived:行を紛れ込ませることによって、この偽のメール送信者IPアドレスを与えることが可能です。普通、スパマーが挿入するReceived:行の方が古いですから。
    通常、MTAOBのリストは、DNSのMXレコードを引けば知ることができそうですから、割と簡単にこの攻撃は成立します。

    ところで、このコード、汚いです。せめてインデントだけでもマトモにした方が…役に立たないきれいなコードより役に立つ汚いコードを書く方が偉いとは思いますが。
    俺様がリファクタリングしてやろうか、っつーか、Rubyで書き直したろか、っつーか、MILTERにできんか、っつーか。きれいに書き直したらまだバグが見つかりそうな気も…

    • 作り直すのなら (スコア:2, 興味深い)

      by tmiura (6268) on 2007年04月13日 18時25分 (#1142428) 日記

      作り直しを考えるのなら、DNSBLとして振舞うように仕立てると、ヘッダ解析しなくてもメールサーバが接続元IPアドレスを拾ってくれるし、負荷や管理対象絞込みの観点でもメールサーバとうまく分離できて幸せかもしれませんよ。

      シェア
      親コメント

      • Re:作り直すのなら (スコア:1)

        by Ryo.F (3896) on 2007年04月13日 19時49分 (#1142464) 日記
        作者の意図としては、組織のファイアウォールの内側の奥のほうにある、IP reachableですらないようなローカルのMTAでも動く、ってところが売りなんじゃないかと。
        インターネットから引けるMXレコードに載ってるようなMTA向けであれば、おっしゃる通りだと思います。
        シェア
        親コメント

        • Re:作り直すのなら (スコア:1)

          by tmiura (6268) on 2007年04月13日 20時01分 (#1142469) 日記

          いや、組織内のローカルなDNSBLサーバって位置づけでいいじゃないですか。

          メールサーバが参照するローカルなDBバックエンドサーバのひとつってことで、アカウントや設定情報を抱えたLDAPサーバと同じようなところに置けば。

          シェア
          親コメント

          • Re:作り直すのなら (スコア:2, 参考になる)

            by tmiura (6268) on 2007年04月13日 20時07分 (#1142470) 日記

            読み返して勘違いに気づきました。

            組織のボーダゲートウェイなメールサーバから中継されて受け取る自分のメールサーバにフィルタを仕掛けたいってことですか。 それならまあ確かにReceivedヘッダにしか情報がないかな。

            シェア
            親コメント
    • ソースコードをざっと見たら汚いなーと云うのが第一印象。

      jcode.plではなくEncodeの方に書き直したりとか、フィルタの部分だけクラス化させたりとか、`hostname`をSys::Hostnameモジュールを使った方が良いと思う。

      # あ・・・う・・・見てたらうずうずと・・・
      シェア
      親コメント
    • Received:行の内、最後にMTAOBのリストに一致したものからメール送信者IPアドレスを抽出しているように見えます(違ったらすまん)。普通、Received:行は、新しいものが最初の方に来ますから、MTAOBのリストと一致するものの中で、一番古いものと一致することになります。

      この問題をよくよく考えると、「外部からMTAOBに接続した部分のReceived:行の抽出」って簡単にはできそうにないですね。

      MXにサーバが複数あって、セカンダリMX以降のサーバが外から受信して、プライマリMXのホストに転送した場合、
      Received: は新しい順に「プライマリMXホストが受け取ったときのもの」「セカンダリMXホストが受け取ったときのもの」と並びます。
      スパム送信ホストががセカンダリMXを偽装したヘッダを付けてプライマリMXに接続した場合にも、やはり「プライマリMX」「セカンダリMX」と並びますから、この二つはホスト名ベースでは区別できません。

      Received: には、新しい順には、内部ホスト群→MTAOBホスト群→外部ホスト群、と並ぶはずですから、
      MTAOBはホスト名だけではなく、IPアドレスも把握した上で、
      「最初のMTAOBホスト群の中で、MTAOB以外のIPアドレスから接続したもの」というReceived:行を検出すればいいのかな。
      シェア
      親コメント

    • Re:バグレポート (スコア:1)

      by twada (33858) on 2007年04月16日 8時52分 (#1143079) 日記
      コメントありがとうございます． この指摘はいずれ出てくるだろうと思っていました．最後のMTAOBのみを評価している理由は，うちの大学では外部接続ルータでsmtp接続を強制的にメイルのフィルタリングマシンにredirectしているため，私に来るメイルのReceived行に複数回MTAOBが出てくるため，暫定的に最後のMTAOBの直前のReceived行からIPを引き抜いてくるようにしているためです．ですから，現バージョンでは仰るとおり，偽造されたReceived行には対応できません．ただ，現状ではそんな奇特なスパマーはいないようで，スパマーがこれに気がつくまでは使えるはずです．キッチリやるのなら，メイルの束からオートマトンを作らないといけないのですが，これをやると（事前にメイルの束が必要なので）ただでさえ使いづらいのに，もっとつかいづらくなるため躊躇しております．ご意見を参考にして，もうすこしましな方法を検討してみます． コードが汚いのは仰るとおりです．ちょっと書き直しをしてjcodeとmimerは不用にしました．時間があるときに書き直したいと思います．
      シェア
      親コメント

      • Re:バグレポート (スコア:1)

        by Ryo.F (3896) on 2007年04月19日 14時52分 (#1145112) 日記
        キッチリやるのなら，メイルの束からオートマトン
        いや、キッチリやるなら、taka2さんの様なやり方 [srad.jp]でしょう。
        過去のReceived:列を正しく喰うオートマトンを作ったところで、それがすべてのケースを網羅しているとは限りませんよね。障害が起こった場合、別の経路でメールを受け取る仕組みになってるかも知れないわけだし。

        スパマーがこれに気がつくまでは使えるはずです．
        「Macではウイルスを心配しなくてよい」程度の話ですね。あまりカッコのイイ主張ではない気がします。
        シェア
        親コメント

        • Re:バグレポート (スコア:1)

          by twada (33858) on 2007年04月19日 15時59分 (#1145143) 日記
          taka2さんの方法は，最初のMTAOBのIPアドレスを把握して，それに対してそれ以外のアドレスからの接続があった場合，そのIPを拾うということでした．ですが，私の場合，先のコメントで書いたように，下記のようなReceived行のメイルを受けています．(by 以下に mgate が6回も表れており，最後の by mgateが本来のIPアドレスをつかまえています．)
          Received: from mgate.center.wakayama-u.ac.jp (mgate.center.wakayama-u.ac.jp [133.42.248.34])
              by wada5.cv (Postfix) with ESMTP id 7B0D3E982FE
              for <twada@wada1.sys.wakayama-u.ac.jp>; Tue, 17 Apr 2007 01:05:32 +0900 (JST)
          Received: from mgate.center.wakayama-u.ac.jp (mgate.center.wakayama-u.ac.jp [127.0.0.1])
              by mgate.center.wakayama-u.ac.jp (8.13.6/8.13.6) with ESMTP id l3GGHprR012095
              for <twada@wada1.sys.wakayama-u.ac.jp>; Tue, 17 Apr 2007 01:17:51 +0900
          Received: from leo.ieee.org (leo.ieee.org [140.98.193.29])
              by mgate.center.wakayama-u.ac.jp (8.13.6/8.13.6) with ESMTP id l3GGHmxA012065
              for <twada@wada1.sys.wakayama-u.ac.jp>; Tue, 17 Apr 2007 01:17:49 +0900
          Received: from gemini3.ieee.org (gemini3.ieee.org [140.98.193.188])
              by leo.ieee.org (8.12.10/8.12.10) with ESMTP id l3GGHhvL011239
              for <twada@ieee.org>; Mon, 16 Apr 2007 12:17:43 -0400
          Received: from hormel8.ieee.org (hormel8.ieee.org [140.98.193.231])
              by gemini3.ieee.org (Postfix) with ESMTP id B1CA84D178
              for <twada@ieee.org>; Mon, 16 Apr 2007 12:17:42 -0400 (EDT)
          Received: from mgate.center.wakayama-u.ac.jp (mgate.center.wakayama-u.ac.jp [133.42.248.34])
              by hormel8.ieee.org (8.13.8+Sun/8.13.8) with ESMTP id l3GGHc8f020641
              for <twada@ieee.org>; Mon, 16 Apr 2007 12:17:39 -0400 (EDT)
          Received: from mgate.center.wakayama-u.ac.jp (mgate.center.wakayama-u.ac.jp [127.0.0.1])
              by mgate.center.wakayama-u.ac.jp (8.13.6/8.13.6) with ESMTP id l3GGHcvO012055
              for <twada@ieee.org>; Tue, 17 Apr 2007 01:17:38 +0900
          Received: from mail.sys.wakayama-u.ac.jp (mail.sys.wakayama-u.ac.jp [133.42.159.1])
              by mgate.center.wakayama-u.ac.jp (8.13.6/8.13.6) with ESMTP id l3GGHbn6012050
              for <twada@ieee.org>; Tue, 17 Apr 2007 01:17:37 +0900
          Received: by mail.sys.wakayama-u.ac.jp (Postfix, from userid 1086)
              id CBA673823E3; Tue, 17 Apr 2007 01:17:37 +0900 (JST)
          Received: from mgate.center.wakayama-u.ac.jp (mgate.center.wakayama-u.ac.jp [133.42.248.34])
              by mail.sys.wakayama-u.ac.jp (Postfix) with ESMTP id AB0ED3823E2
              for <twada@sys.wakayama-u.ac.jp>; Tue, 17 Apr 2007 01:17:37 +0900 (JST)
          Received: from mgate.center.wakayama-u.ac.jp (mgate.center.wakayama-u.ac.jp [127.0.0.1])
              by mgate.center.wakayama-u.ac.jp (8.13.6/8.13.6) with ESMTP id l3GGHbYb012047
              for <twada@sys.wakayama-u.ac.jp>; Tue, 17 Apr 2007 01:17:37 +0900
          Received: from alert.hindawi.org ([82.129.218.7])
              by mgate.center.wakayama-u.ac.jp (8.13.6/8.13.6) with SMTP id l3GGGuca011900
              for <twada@sys.wakayama-u.ac.jp>; Tue, 17 Apr 2007 01:17:36 +0900
          x-esmtp: 0 0 1
          Message-ID: <twadasyswakayama-uacjpvtcsatwadasyswakayama-uacjp@hindawi>
          こういうメイルの設定をしているやつが悪いといえば，それまでですが，私の場合，これでも（とりあえず）動くようにしたかった訳です．このように，私の場合，最初にこだわっても正しい答えには至りません．ですので，将来現れるかもしれないbyの偽造にどう「かっこよく」対処すべきか悩んでおります．良いアイデアがあったら教えてください．
          シェア
          親コメント

          • Re:バグレポート (スコア:1)

            by twada (33858) on 2007年04月19日 18時20分 (#1145221) 日記
            自分で自分にコメントします．by MTAOBのfrom部分全てで弁別度を計算し，それの最大値を取るという方法なら，偽造しても影響はないはず．唯一の問題点は，GIPやBIPへの反映をさせるためのプログラムがややこしくなるということです．
            シェア
            親コメント

        • Re:バグレポート (スコア:1)

          by twada (33858) on 2007年04月21日 2時04分 (#1145971) 日記
          MTAOBがbyに出てきたときの弁別度の最大値を使うバージョン（コードも前よりだいぶまし）0.05-betaを作りました．自分でヘッダのbyの偽造を試してみましたが，騙されずにきちんと検出できました．これで，もし正常なIPの近辺からスパムが来たらどうするかという問題だけが残りました．これは基本的にスパム・非スパムのIPがもし入り混じった部分ができてしまい，そこからメイルが来たら，NNIPFではなく別途作っているBayesianフィルタにかますという対処を予定しています．
          皆さんコメントありがとうございます．
          ちなみに，httpdのログを調べ，6000台ほどのアクセス元IPアドレスの弁別度を調べたところ，99％以上の弁別度をもつものが約4％くらい含まれていました．ある意味，感心しました．
          シェア
          親コメント

  • 学習効果 (スコア:3, 興味深い)

    by Anonymous Coward on 2007年04月13日 23時36分 (#1142551)
    実はこの方法とほぼ同じ方法をしかなりの期間試してみたことがあります。
    (実際の距離の計算のところはもう少し複雑なアルゴリズムでしたが)

    この方法のミソはヘッダや本文やその他の情報は偽造したり頻繁に変更す
    ることは簡単だが、IPアドレスを頻繁に(大きく)変更することは難しいと
    いう点にあり、ダイナミックIPからのスパム等にかなり効果があることは
    確かです。

    ただ長期に試した結果としては「学習効果が強過ぎるかな」といった問題
    がでています。

    よく判定に失敗した例としては

        - 最近のスパムbotは普通にISPのメールサーバを使用して送信してきたりする
            ⇒ 大手のISPのメールサーバがスパムサーバとして登録されたりする

        - スパマーの中には複数のサーバホスティング業者を渡り歩いて送信サーバを
            変更してくるものがいる
            ⇒ 同じ業者のサーバホスティングを使用している他の人たちからのメールも
                  全てスパム扱いしてしまう

        - 通常のメールに比べてスパムの数が圧倒的に多いと、そのうち知らないとこ
            ろから来たメールは全てスパム扱いしてくれる
            ⇒ それはそれで良しという気がしないでもないが、ただのホワイトリス
                  トと変らないんじゃないかと

    結局単独利用では不十分なので他の方法と組み合わせて何とかできないかと試行錯誤中

    • Re:学習効果 (スコア:2, 興味深い)

      by twada (33858) on 2007年04月16日 10時13分 (#1143125) 日記
      コメントありがとうございます．
      こういった現象はほんの僅かではありますが，起きております．ただ，スパムだけでなく，普通のメイルもIPを登録しますので，これらのせめぎ合いでうまく動くようです．それと，うちの場合，大学の入り口でSMTPタービットやら強制切断でチェックしているので，botから直接流れてくるスパムが少ないこともあるかもしれません．そういう意味では組み合わせとしてはタービットやら強制切断と組み合わせるのがいいかもしれません．
      >- 最近のスパムbotは普通にISPのメールサーバを使用して送信してきたりする
      > ⇒ 大手のISPのメールサーバがスパムサーバとして登録されたりする
      これはyahoo，gmail，hotmailなどで昔はあったのですが，最近はほとんどないようです．少なくとも私のところでは過去半年こういうのはないです．
      > - スパマーの中には複数のサーバホスティング業者を渡り歩いて送信サーバを 変更してくるものがいる
      > ⇒ 同じ業者のサーバホスティングを使用している他の人たちからのメールも 全てスパム扱いしてしまう
      時々ありますね．こういうことは．でも先に述べたせめぎ合いで，全部スパム扱いにはなりません．日ごろのトレーニングのせいかもしれません．
      > - 通常のメールに比べてスパムの数が圧倒的に多いと、そのうち知らないとこ ろから来たメールは全てスパム扱いしてくれる
      これは先に述べたせめぎ合いで，うちでは殆ど起きておりません．
      > ⇒ それはそれで良しという気がしないでもないが、ただのホワイトリス トと変らないんじゃないかと
      ちょっとどう答えていいか分からないのですが，ホワイトリスト，ブラックリストとせずに距離の比較をしてるので，汎化性能はいいみたいです．
      シェア
      親コメント

      • Re:学習効果 (スコア:1)

        by tmiura (6268) on 2007年04月17日 12時40分 (#1143855) 日記
        - 最近のスパムbotは普通にISPのメールサーバを使用して送信してきたりする ⇒ 大手のISPのメールサーバがスパムサーバとして登録されたりする
        これはyahoo，gmail，hotmailなどで昔はあったのですが，最近はほとんどないようです．少なくとも私のところでは過去半年こういうのはないです．

        OP25Bの普及とともにそちらへ移っていきますよ、これから。

        シェア
        親コメント

        • Re:学習効果 (スコア:1)

          by twada (33858) on 2007年04月17日 18時27分 (#1144041) 日記
          25番が閉じられたらISPのメールサーバかWEBメールに移行というパターンは可能性としてあると思います．ただ，私の見ている限りbotよりも，専用中継サーバからのスパムが圧倒的に多いです．ISPはターピットや強制切断で対策を講じるでしょうし，WEBメールもコンテンツフィルタや，通信パターンから遮断をかけるくらいの技術はもっているでしょう．そういうわけで，今のところは楽観的にとらえてます．ただ，顕在化したときのためにIPアドレス以外の部分も拾えるようにヘッダ全部を一旦メモリに乗せておくように変更しようと思います．また，学生が作っているBayesianフィルタとの組み合わせも検討してみます．コメントありがとうございました．
          シェア
          親コメント

  • SPFなどとの併用も (スコア:2, 興味深い)

    by Livingdead (18685) on 2007年04月13日 13時10分 (#1142225) ホームページ 日記
    IPアドレスベースでの迷惑メール防止技術ということではSPFのようなドメイン詐称を見抜く技術がありますが、そもそもドメイン管理者がゾーン情報にSPFレコードを追加してくれなければ利用できないとか転送に弱かったり [mew.org]するので、受け手側（に近いMTA）だけでできる対策としてよさそうですね。よい学習結果が得られるようにSPFなどを併用してドメインを詐称しているメールは取り除いてしまうというのもいいかもしれません。

    それはそうと最近ふと携帯電話(au)のメール設定をみてみたらSPFに対応 [kddi.com]しているんですね。設定したとたんに Yahoo ドメインを騙っている迷惑メールが携帯電話に来なくなって快適になりました。いつからこんな設定ができるようになってたんだろう。

    Yahoo は DomainKeys 派かと思ってたんですが、そもそもこの手の技術／規格にはもう○○派とか○○陣営とかはないのかな。
    --
    屍体メモ [windy.cx]

    • Re:SPFなどとの併用も (スコア:2)

      by shojin (28072) on 2007年04月13日 13時59分 (#1142278) 日記
      既にSPFを設定しているspammerがいるのでこれ単体での迷惑メール対策というのはありえないと思います。手抜きspammerは+allやallという設定なので一発で判断できますが、spammerによっては送信に使うアドレスブロックを書いていたりするのでSPFだけで一概に迷惑メールか否かを判断できません。さりとて、迷惑メール中のアドレスがSPFを使っていた場合、関係ない人々を巻き込む恐れがあるのでやっていませんが、これは重要な判断材料にはなると思います。

      近傍の判断方法が良くわからないのですけれど、手元のspammer IPアドレス集を見る限り、同じ/24から送って来ない方が多いのでこの記事の方法の有効性は少し眉唾です。

      Yahoo!JAPANはSPFも使っていますが、米国のYahoo!はDKIM (DomainKeys) だけだと思いますよ。
      シェア
      親コメント

  • 本業は画像 (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2007年04月13日 13時31分 (#1142245)
    和田センセイの本業は画像と言うだけあって、特徴ベクトルだとか4次元だとか、ネットワーク分野ではあまり目にしない単語が出てくるのがおもしろい。

  • 公表 (スコア:1)

    by flutist (16098) on 2007年04月13日 12時56分 (#1142214)
    どこかの論文誌に投稿してたりします？
    すでに publish されているようでしたら、読んでみたいです。アルゴリズムそのものに加え、その効果をどう検証するかも興味があります。

    • Re:公表 (スコア:1)

      by saitoh (10803) on 2007年04月15日 10時39分 (#1142939)
      リンク先に
      謝辞：　本プログラムは，平成１７年度（H17-H18）和歌山大学「オンリー・ワン創成プロジェクト経費」の補助を受けて開発された．
      とあるので、そのうち研究会に発表されるか投稿されると思いますよ。

      この研究の前段階に当たると思われる研究は情報処理学会DSM研究会で発表されています。

      IPSJ-DSM03032013
      ■文 献 名 ： マスメイルデータベースとそれを用いたマスメイル検出システム
      ■著　　者： 松浦広明 (和歌山大学システム工学部) 齋藤彰一 (和歌山大学システム工学部) 上原哲太郎 (京都大学大学院工学研究科) 泉裕 (和歌山大学システム情報学センター) 和田俊和 (和歌山大学システム工学部)
      ■発行年月： 2004年 3月 Vol.2004 No.37 2003-DSM-032

      ■抄　　録： マスメイルによる被害は日に日に増大している．本研究では，マスメイルを検出するために，マスメイルデータベースとPOPサーバからなるシステムを構築した．データベースでは，マスメイルを自動的に収集し，各マスメイルを正規化・解析したのち計算されたチェックサムを蓄積する．POPサーバでは，転送するメイルのチェックサムを同様に計算し，データベースに問い合わせることで，マスメイルかどうかを判断する．このシステムでは，チューニングや学習は不要である．処理速度が速く，データベースの内容が正しい限り誤検出は起きないのが大きな特徴である．このシステムを和歌山大学内のPOPサーバで稼動させた結果，マスメイルの認識率はおよそ80-90%であった．
      シェア
      親コメント

    • Re:公表 (スコア:1)

      by twada (33858) on 2007年04月16日 8時31分 (#1143073) 日記
      まだ，公表してません．効果の評価は，ジャックナイフ処理というかone out of なんとかという方法で，あるIPアドレスを削除したDBで識別を行い，正しく識別できるかどうかで評価します．BIP/GIPにはCountというファイルがあって，そのIPから何件メイルを受けたかも記録してあるので，これと合わせれば未知のIPをどの程度正しく識別できるかが評価できる筈です．また，この結果が出ればお知らせします．
      シェア
      親コメント

  • 最近傍識別 (スコア:1, 興味深い)

    by Anonymous Coward on 2007年04月13日 13時38分 (#1142252)
    1番目「信頼できるメールサーバ(MTA)に接続してきた(相手側)マシンのIPアドレスはReceived:に記録され、偽装されていない」は理解できました。

    2番目の「最近傍識別」(nearest neighbor method)がわかりません。パターン認識関連で使われているようですが。

    識別結果として、同じネットワークは同一とみなす、みたいな感じになるのでしょうか?

    • Re:最近傍識別 (スコア:2, 参考になる)

      by Anonymous Coward on 2007年04月13日 14時40分 (#1142303)
      > 2番目の「最近傍識別」(nearest neighbor method)
      「何に一番似ているか」を判断（定量化）する技術みたいですね。手書き文字認識とかで使ってるものなんじゃないでしょうか。

      > メイル送信者のIPアドレスを4次元の特徴ベクトルとして用いています
      これは、オクテットごとに区切ったものを行列（ベクトル）と見なしてるってことかな？127.0.0.1=>(127,0,0,1)みたいな感じで。

      で、最近傍識別器というのを使って、受け取ったメールに対して「過去のspamの中で一番特徴が似ているもの」と「過去のhamの中で一番特徴が似ているもの」を探し出して、それぞれ「どのくらい違うのか（弁別度）」を判定すると。

      最終的には「過去にspamを送ってきたアドレスと似たようなアドレスからのメールで、かつ似たようなアドレスからhamを受け取ったこともないから多分spam」もしくは「過去にhamを送ってきたアドレスと似たようなアドレスからのメールで、かつ似たようなアドレスからspamを受け取ったこともないから多分ham」という判断になるのかな？

      IPアドレスが地理的/ネットワーク的に偏って存在していることと、同一のマシン（あるいはアドレスが非常に似通ったマシン）からspamとhamの両方が送られてくる機会が少ないことを前提にしてるんだと思う。半分以上推測なので、数学がわかる人のフォロー希望。

      # しかしスラドにはこういう使い方もあったのか。
      シェア
      親コメント

  • メールだけじゃなくて (スコア:1, 興味深い)

    by Anonymous Coward on 2007年04月13日 13時45分 (#1142263)

    BlogやWikiへのコメントspamにも応用できないかな。最終的にIPアドレスでフィルタリングするなら何とかなりそうな気がするんだけど。

    mod_auth_externalなどへのラッパーを作ればいいのかな？

  • 特徴ベクトルをどう使っているのかよく分からないのですが IronMailとかOpenwaveあたりなら使っていそうな方式でしょうか。 ただ、OSSというのは他には知らないですね。 掘り出し物かもしれない。

  • 副作用が大きく実用にはならない (スコア:1, 興味深い)

    by Anonymous Coward on 2007年04月16日 12時27分 (#1143216)
    説明を読んだが、正直、使い物になるとは思えない。

    最近のspamはbotnetを利用して不特定多数のPCから送信する [cnet.com]のが流行だ。
    またインターネットの世界的な普及に伴い、その分布はダイナミックに変動 [sophos.co.jp]し続けている。
    このような状況において、単純なIPアドレスベースのspamフィルタがどれだけ使い物になるのか疑問だ。

    例えば…
    普段やりとりするメールが日本国内に限定されるユーザーの場合、海外からのメールは問答無用でspam扱いされてしまうだろう。
    海外からのメールを切り捨てて構わないのなら、そもそも日本国内のIPアドレスに限定して受信すれば良いことになる。
    こんな面倒な仕組みを導入する必要はない。

    しかし、最近のフィルタはgreylistやtarpit [ya.maya.st]を併用してその副作用をなるべく少なくしようと努力するのが常識だと思ってたが…
    • ＞最近のspamはbotnetを利用して不特定多数のPCから送信するのが流行だ。
      ＞またインターネットの世界的な普及に伴い、その分布はダイナミックに変動し続けている。
      ＞このような状況において、単純なIPアドレスベースのspamフィルタがどれだけ使い物になるのか疑問だ。

      botに関しての上の情報は常識ですが、
      SMTPに関しては、ISPがポートをふさぐなどして
      直接、相手のSMTPサーバに接続されないようになってきている
      現状もご存じかと思います。

      つまり、通常のメールはISPのSMTPサーバを経由するのが普通なのです。
      (家でSMTPサーバを立てている場合もISPのSMTPサーバを経由させることになります)
      解説を読めば分かりますが、
      スパムの多くが直接受信者のSMTPサーバに送られているという
      状況を利用してのフィルタなのです。

      つまり(受信者にとって)メジャーなSMTPサーバではない
      雑多なbotはいくら分布が移り変わっても全てスパム発信源です。
      十分、効果があると思いますが？
      シェア
      親コメント

  • mailとwebが同一サーバ? (スコア:0)

    by Anonymous Coward on 2007年04月13日 13時00分 (#1142217)
    個人向けか?
    「管理者が…」なんて書いてあるけど。

    • Re:mailとwebが同一サーバ? (スコア:2, 参考になる)

      by tmiura (6268) on 2007年04月13日 13時19分 (#1142231) 日記

      webサーバまで同居しなきゃいけないのは 学習というか教示機能をCGIで実装してるせいなので、 設定管理デーモンを一つ作ってやるなど適当な手を打てば メールサーバを単機能に保ったまま 管理インタフェースを手元へ持ってくることはできるでしょう。

      シェア
      親コメント
typodupeerror

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり