アカウント名:
パスワード:
ここをご覧になっている方だったらコメントを書く時にゴミmailが来てもいいようなmail addressを使う技はご存知でしょう。それを少し発展させれば、逆にspam業者側をギャフンといわせることができるのではないでしょうか。
まず、mail転送サービスなどを用いてmail addressを大量に作ります。転送先はある1つのmail address(以下収集用mail address)にします。生成したmail addressを、webのあちこちにばらまいておきます。そのうち、収集用mail address宛にspamがたまります。こいつらのheaderを解析し、適宜blacklistに追加すれば半自動的にfilteringすることができそうです。
blacklistはSMTP用にしてもよいのですが、Internetからの追放までやりたいというのであればbgpでblackhole routeを流すようにするのもよいかも知れません。大手IXが参加してくれればかなり効果がありそう。
収集用mail addressは、例えば自分が知り合いにmailを送るなどの目的には使いません。spamを集めることだけを目的としたmail addressです(だからオトリ)。
また、完全自動化は考えていません。現実にやるとすれば、まず疑わしきはrejectし、そのなかにrejectすべきでないものがあればblacklistから削るという方法です(これは実際に実施している)。また、Received:がfakeされたものでも、それはspam業者がどのようなfakeを行うかを表しているので、意味がある情報です(似たようなことを考える業者をまとめて締め出せる)。
bgpによる締め出しですが、最終的な選択権は各々のrouterにあります。Local preference [wide.ad.jp]を調整するだけです。
それに、dial upによって動的に割当てられたIP addressから直接SMTPでspamを投げるという手口が横行している現状を考えると、無実の人をトラブルに巻き込むことが続出するのではないでしょうか?
前提ですが、わたしの場合受けとるspamはほぼ全てがPC-Unixのmailing list(英語)に投げ込まれたものなので、それを扱ってきた経験から考えます。
ppp用のaddressがReceived:に入ることは確かにありますが、経験的にそのaddressがspamでないmailに再利用されることは思ったほど頻繁にはありません(数千通に1回程度)。むしろ、spammerはいくつかのmailを同じ経路で送ることが多く(単発spamの4倍ぐらい)、途中の経路を潰すことはむしろよい効果を出しています。
それから、現在でも8割方のspamは踏み台を使っています。自前の計算機ではありません。これは、まだ発見すべき踏み台が大量に残っていることを示しています。
「おとりaddress」を使うことによってRBLへの登録を効率よくやろうということでしょうか?
キモはそういうことです。相手が自分から出てきてくれるなら、こっちは力押しではなく罠にはめる戦略の方が安上がりになるだろうと。
締め出し方については単にいくつか例を述べただけで、硬軟の度合いは現場で考えても十分でしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
オトリ作戦 (スコア:2, すばらしい洞察)
ここをご覧になっている方だったらコメントを書く時にゴミmailが来てもいいようなmail addressを使う技はご存知でしょう。それを少し発展させれば、逆にspam業者側をギャフンといわせることができるのではないでしょうか。
まず、mail転送サービスなどを用いてmail addressを大量に作ります。転送先はある1つのmail address(以下収集用mail address)にします。生成したmail addressを、webのあちこちにばらまいておきます。そのうち、収集用mail address宛にspamがたまります。こいつらのheaderを解析し、適宜blacklistに追加すれば半自動的にfilteringすることができそうです。
blacklistはSMTP用にしてもよいのですが、Internetからの追放までやりたいというのであればbgpでblackhole routeを流すようにするのもよいかも知れません。大手IXが参加してくれればかなり効果がありそう。
Re:オトリ作戦 (スコア:1)
この「収集用mail address」にたまったmailがspamであるかどうかはどのように判別するのでしょうか?
>こいつらのheaderを解析し、適宜blacklistに追加すれば半自動的にfilteringすることができそうです。
headerがfakeでないことを半自動で証明するのは不可能に思えます。
>Internetからの追放までやりたいというのであればbgpでblackhole routeを流すようにするのもよいかも知れません。大手IXが参加してくれればかなり効果がありそう。
機械的にInternet death penaltyの対象を定めるというのは、あまりにも乱暴なやり方でしょう。
Re:オトリ作戦 (スコア:1)
収集用mail addressは、例えば自分が知り合いにmailを送るなどの目的には使いません。spamを集めることだけを目的としたmail addressです(だからオトリ)。
また、完全自動化は考えていません。現実にやるとすれば、まず疑わしきはrejectし、そのなかにrejectすべきでないものがあればblacklistから削るという方法です(これは実際に実施している)。また、Received:がfakeされたものでも、それはspam業者がどのようなfakeを行うかを表しているので、意味がある情報です(似たようなことを考える業者をまとめて締め出せる)。
bgpによる締め出しですが、最終的な選択権は各々のrouterにあります。Local preference [wide.ad.jp]を調整するだけです。
Re:オトリ作戦 (スコア:1)
Webに「このaddressにはmailを送信しないで下さい。もし送信した場合には無条件にspamとみなし、送信元のIP addressはフィルタリングの対象になります。」となどと書いておいて、閲覧者がそれに従ってくれることを期待するということでしょうか?
>現実にやるとすれば、まず疑わしきはrejectし、そのなかにrejectすべきでないものがあればblacklistから削るという方法です(これは実際に実施している)。また、Received:がfakeされたものでも、それはspam業者がどのようなfakeを行うかを表しているので、意味がある情報です(似たようなことを考える業者をまとめて締め出せる)。
これだと現状のRBLの管理と大して変らないと思うのですが。
>bgpによる締め出しですが、最終的な選択権は各々のrouterにあります。
基幹部分のrouterが採用するのであれば、Internet death penaltyそのものですし、末端のrouterのみが採用するのであれば、やはり現状のRBLを利用した接続拒否とほとんど同じではないでしょうか。
それに、dial upによって動的に割当てられたIP addressから直接SMTPでspamを投げるという手口が横行している現状を考えると、無実の人をトラブルに巻き込むことが続出するのではないでしょうか?
Re:オトリ作戦 (スコア:1)
前提ですが、わたしの場合受けとるspamはほぼ全てがPC-Unixのmailing list(英語)に投げ込まれたものなので、それを扱ってきた経験から考えます。
ppp用のaddressがReceived:に入ることは確かにありますが、経験的にそのaddressがspamでないmailに再利用されることは思ったほど頻繁にはありません(数千通に1回程度)。むしろ、spammerはいくつかのmailを同じ経路で送ることが多く(単発spamの4倍ぐらい)、途中の経路を潰すことはむしろよい効果を出しています。
それから、現在でも8割方のspamは踏み台を使っています。自前の計算機ではありません。これは、まだ発見すべき踏み台が大量に残っていることを示しています。
Re:オトリ作戦 (スコア:1)
SMTPの制限だけならともかく、brake-handleさんの提案には対象となったIP addressに対するroutingそのものの制限が含まれていますので、
> 無実の人をトラブルに巻き込むことが続出するのではないでしょうか?
と書きました。割当てられたaddressを前に使っていた人のspamせいで、Webも見られなくなってしまうなんてまっぴら御免です。
>それから、現在でも8割方のspamは踏み台を使っています。自前の計算機ではありません。これは、まだ発見すべき踏み台が大量に残っていることを示しています。
もちろんこれには同意しますが、brake-handleさんの提案と従来の手法との違いがよくわかりません。「おとりaddress」を使うことによってRBLへの登録を効率よくやろうということでしょうか?
Re:オトリ作戦 (スコア:1)
キモはそういうことです。相手が自分から出てきてくれるなら、こっちは力押しではなく罠にはめる戦略の方が安上がりになるだろうと。
締め出し方については単にいくつか例を述べただけで、硬軟の度合いは現場で考えても十分でしょう。
Re:オトリ作戦 (スコア:1)
# もちろんやらないよりは良いと思いますが。
>硬軟の度合いは現場で考えても十分でしょう。
「硬」のほう(routing拒否)はやり過ぎだろうと思った次第です。
Re:オトリ作戦 (スコア:1)
okome
Re:オトリ作戦 (スコア:1)
spam用MLへの登録は自動でおこなっているのでしょうか、それとも読んだうえでspamと判断されたもののみを登録しているのでしょうか?
Re:オトリ作戦 (スコア:1, 興味深い)
いつも、この点が問題になりますので、プロパイダに自分の配下のSMTPパケットは直接インターネットへの送信を禁止させ、プロパイダのSMTPサーバー経由を義務付けるという法律があればことは簡単になるのではないでしょうか。そうすれば、ダイアルアップ系のSMTP送信がなくなり、プロバイダもSMTPパケット中継料をとって儲けるという商売がなりたち、フイルタリングも簡単になると。あまいかな?
Re:オトリ作戦 (スコア:1)
いけないのがあったような気がするのですが、気のせいでしょうか。
# たしか、mutt なんかそうだったような。。。
Re:オトリ作戦 (スコア:0)
単にローカル宛のメール以外はISPのサーバに
relayさせるように設定すればいいだけだと思いますが。。。
sendmailにしたって同じことですし。
それができないユーザならもっと楽なメーラ使うだろうし。
Re:オトリ作戦 (スコア:1)
これだと、プロバイダの固定IPアドレスサービスを利用して、メールサーバを立てることが不可能になるので、個人的には嫌ですね。
>プロバイダもSMTPパケット中継料をとって儲けるという商売がなりたち、
ユーザがメールを出すたびに課金するんですか?今時そんなプロバイダは客がつかないと思います。
Re:オトリ作戦 (スコア:1)
Re:オトリ作戦 (スコア:1)
そんでもって、各種のWeb上での登録にはこのアドレスを使います。
各事業者ごとに一つずつ別のアドレスにします。どの事業者が
漏らした/売った/別利用したのかを知りたいからです。
同様に公開するアドレスにもできる限りこれを使います。
けど、最近はメールアドレスさらす機会もないし、サービスに
登録する機会もないので、あんまり意味ないですね。