アカウント名:
パスワード:
ここをご覧になっている方だったらコメントを書く時にゴミmailが来てもいいようなmail addressを使う技はご存知でしょう。それを少し発展させれば、逆にspam業者側をギャフンといわせることができるのではないでしょうか。
まず、mail転送サービスなどを用いてmail addressを大量に作ります。転送先はある1つのmail address(以下収集用mail address)にします。生成したmail addressを、webのあちこちにばらまいておきます。そのうち、収集用mail address宛にspamがたまります。こいつらのheaderを解
収集用mail addressは、例えば自分が知り合いにmailを送るなどの目的には使いません。spamを集めることだけを目的としたmail addressです(だからオトリ)。
また、完全自動化は考えていません。現実にやるとすれば、まず疑わしきはrejectし、そのなかにrejectすべきでないものがあればblacklistから削るという方法です(これは実際に実施している)。また、Received:がfakeされたものでも、それはspam業者がどのようなfakeを行うかを表しているので、意味がある情報です(似
それに、dial upによって動的に割当てられたIP addressから直接SMTPでspamを投げるという手口が横行している現状を考えると、無実の人をトラブルに巻き込むことが続出するのではないでしょうか?
前提ですが、わたしの場合受けとるspamはほぼ全てがPC-Unixのmailing list(英語)に投げ込まれたものなので、それを扱ってきた経験から考えます。
ppp用のaddressがReceived:に入ることは確かにありますが、経験的にそのaddressがspamでないmailに再利用されることは思ったほど頻繁にはありま
「おとりaddress」を使うことによってRBLへの登録を効率よくやろうということでしょうか?
キモはそういうことです。相手が自分から出てきてくれるなら、こっちは力押しではなく罠にはめる戦略の方が安上がりになるだろうと。
締め出し方については単にいくつか例を述べただけで、硬軟の度合いは現場で考えても十分でしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
オトリ作戦 (スコア:2, すばらしい洞察)
ここをご覧になっている方だったらコメントを書く時にゴミmailが来てもいいようなmail addressを使う技はご存知でしょう。それを少し発展させれば、逆にspam業者側をギャフンといわせることができるのではないでしょうか。
まず、mail転送サービスなどを用いてmail addressを大量に作ります。転送先はある1つのmail address(以下収集用mail address)にします。生成したmail addressを、webのあちこちにばらまいておきます。そのうち、収集用mail address宛にspamがたまります。こいつらのheaderを解
Re:オトリ作戦 (スコア:1)
この「収集用mail address」にたまったmailがspamであるかどうかはどのように判別するのでしょうか?
>こいつらのheaderを解析し、適宜blacklistに追加すれば半自動的にfilteringすることができそうです。
headerがfakeでないことを半自動で証明するのは不可能に思えます。
>Internetからの追放までやりたいというので
Re:オトリ作戦 (スコア:1)
収集用mail addressは、例えば自分が知り合いにmailを送るなどの目的には使いません。spamを集めることだけを目的としたmail addressです(だからオトリ)。
また、完全自動化は考えていません。現実にやるとすれば、まず疑わしきはrejectし、そのなかにrejectすべきでないものがあればblacklistから削るという方法です(これは実際に実施している)。また、Received:がfakeされたものでも、それはspam業者がどのようなfakeを行うかを表しているので、意味がある情報です(似
Re:オトリ作戦 (スコア:1)
Webに「このaddressにはmailを送信しないで下さい。もし送信した場合には無条件にspamとみなし、送信元のIP addressはフィルタリングの対象になります。」となどと書いておいて、閲覧者がそれに従ってくれることを期待するということでしょうか?
>現実にやるとすれば、まず疑わしきはrejectし、そのなかにrejectすべきでないものがあればblacklistから削るという方法です(これは実際に実施している)。また、Received:がfakeされたものでも、それはspam業者がどのようなfakeを行うかを表しているの
Re:オトリ作戦 (スコア:1)
前提ですが、わたしの場合受けとるspamはほぼ全てがPC-Unixのmailing list(英語)に投げ込まれたものなので、それを扱ってきた経験から考えます。
ppp用のaddressがReceived:に入ることは確かにありますが、経験的にそのaddressがspamでないmailに再利用されることは思ったほど頻繁にはありま
Re:オトリ作戦 (スコア:1)
SMTPの制限だけならともかく、brake-handleさんの提案には対象となったIP addressに対するroutingそのものの制限が含まれていますので、
> 無実の人をトラブルに巻き込むことが続出するのではないでしょうか?
と書きました。割当てられたaddressを前に使っていた人のspamせいで、Webも見られなくなってしまうなんてまっぴら御免です。
Re:オトリ作戦 (スコア:1)
キモはそういうことです。相手が自分から出てきてくれるなら、こっちは力押しではなく罠にはめる戦略の方が安上がりになるだろうと。
締め出し方については単にいくつか例を述べただけで、硬軟の度合いは現場で考えても十分でしょう。
Re:オトリ作戦 (スコア:1)
# もちろんやらないよりは良いと思いますが。
>硬軟の度合いは現場で考えても十分でしょう。
「硬」のほう(routing拒否)はやり過ぎだろうと思った次第です。
Re:オトリ作戦 (スコア:1)
okome
Re:オトリ作戦 (スコア:1)
spam用MLへの登録は自動でおこなっているのでしょうか、それとも読んだうえでspamと判断されたもののみを登録しているのでしょうか?