{{tag> blog}} ---json { "title":"(2021/09/04) 迷惑メールがなくならない", "description":"私が普段使っているメールアドレスはもう２０年くらい経ちますが、フィルタリングなどを駆使して排除するものの、何通かはフィルタを抜けて受信トレイに入ることがあります。" } --- \\ ====== (2021/09/04) 迷惑メールがなくならない ====== \\ ===== 前書き ===== 私が普段使っているメールアドレスはもう２０年くらい経ちますが、フィルタリングなどを駆使して排除するものの、何通かはフィルタを抜けて受信トレイに入ることがあります。\\ フィルタの効果を調べてみたところ、９５％程度は排除され、５％くらいが抜けているようで、それらのメールは英文によるフィッシングとなりすまして登録したWebサービスの通知メールで占めていました。\\ 前者についてはフィルタでは太刀打ちできずほぼお手上げですが、後者については思い込みとなど人的ミスによるもので仕方がないことかもしれません。また、サーバの仕様による問題と考えられることもあり、運営側に何度も対応するように連絡したものの改善の姿勢を見せないので、そういうものだと妥協していることもあります。\\ \\ ===== なぜなくならないのか？ ===== 迷惑メールがなぜなくならないのかを考えてみますが、スパムフィルタについて考えてみる必要があります。\\ スパムフィルタは受信したメールを条件（ルール）に照らし、信頼できるものは受信トレイへ、有害と判定されるものはスパムトレイに隔離するものですが、この方法ではフィルタを施すため、メール本文を受信する必要があります。\\ 220 localhost SMTP ********; 2021/09/05 18:08:37 HELO localhost 250 localhost Helo 127.0.0.1[127.0.0.1:57468], Pleased to meet you. RSET 250 Reset state MAIL FROM: 250 ... Sender ok RCPT TO: 250 user2@localhost... Recipient ok DATA 354 Enter mail,end with "." on a line by ltself (本文送信中...) 250 OK QUIT 221 closing connection プロトコルに従い、サーバが受け取りを完了すると送信側に受け取り完了のコード(250)を送りますが、これは言わば、送信先のメールアドレスが有効であることを送信元に伝えていることと同じで、これが原因で元を断つことができないのではないかと思います。\\ \\ ===== ではどうすればいいのか？ ===== では、どのような対策をすれば効果的であるかを考えてみると、プロトコル自体を変えることは、サーバはもちろんですが、クライアントにも変更を加える必要があるため現実的ではありませんので、サーバにちょっとした仕掛けをします。\\ まず、SMTPサーバがメールを受信するとき、クライアントからRCPT TOコマンドを呼び出し、SMTPサーバに送信先メールアドレスが登録されているかを問い合わせます。メールアドレスが登録されている(有効である)と250番を返しますが、登録されていない(または無効な)メールアドレスであるとエラーコードである500番以降が返りますので、これを活用します。 方法ですが、メールアカウントごとに送信元メールアドレス(From)の拒否リストを設けます。 リストにはメールアドレスやドメイン名など、なんらかのキーワードやパターンを登録しておきます。 SMTPサーバがメールを受信するとき、クライアントからMAIL FROMコマンドとREPT TOコマンドが呼び出されますが、REPT TOコマンドが入力されたタイミングで拒否リストに問い合わせ、送信元メールアドレス(From)が拒否リストに該当しない場合は通常通り250番を返してメール本文の受信を行いますが、拒否リストに該当する場合はエラーコードである500番以降を返すようにします。 例えば、user2@localhost というメールアカウントの拒否リストに送信元アドレス user1@localhost を登録したとします。 そして、SMTPサーバがメールを受信するとき、MAIL FROMコマンドとRCPT TOコマンドが呼び出され、そのタイミングで拒否リストに問い合わせます。拒否リストには送信元メールアドレス user1@localhost が登録されているので、ユーザが存在しないことを示す550番を返します。 220 localhost SMTP ********; 2021/09/05 18:10:03 HELO localhost 250 localhost Helo 127.0.0.1[127.0.0.1:51362], Pleased to meet you. RSET 250 Reset state MAIL FROM: 250 ... Sender ok RCPT TO: 550 user2... User unknown この方法ではSMTPサーバのプログラムを変更する必要がありますが、既存のクライアントは変更することなくそのまま使用することができます。 \\ ===== そんなことが可能なのか？ ===== スパム送信者の立場で考えてみれば、送信先メールアドレスは総当たりで生成したランダムなメールアドレスを用いることもあるかもしれませんが、大抵は地下で取引されているようなメールアドレスのリストが用いられていると思います。 このようなアドレスリストを用いてスパム送信を試みたとき、正しく送信できたものは有効なメールアドレスとみなされ、新たなスパムを送信するときのターゲットになってるのは、似たような内容の迷惑メールが複数回届いていることからも推測できます。 総当たりで生成したランダムなメールアドレスでは送信に失敗することも見込んで行うため、この方法を用いても防ぐことはできませんが、送信成功率は遥かに低い上、送信側でIPブロックされるリスクが非常に高いので成果としては十分ではありません。 一方、地下で取引したアドレスリストは、多少、実績もあるように謳っている(大半は「騙っている」方だと思うが)でしょうから総当たりに比べれば十分な成果は得られるので重宝されるのだと思いますし、賞味期限間近のアドレスリストから受信に成功したアドレスが抽出され更新されたアドレスリストは信頼性も上がるので、再び地下で取引される可能性もあります。 ここに示すような対策をしてスパム送信者のリストの大半がエラーを返せば、送信先アドレスが存在しないサーバには再び送信を試みようとは思わないと思いますし、リストもほとんどが無効なので、再び取引できるような代物ではない粗悪なリストになるので、仮に流通してもいずれ終息するはずです。 \\ ===== そもそも論 ===== メーリングリストやメールマガジン、商談や打合せなど、目的にもよりますが、そもそも、メールを不特定に受け入れていることが問題であり、特に業務などで交わすようなメールアドレスは送信者と受信者のメールアドレスが予め交換されているので、それらをホワイトリストに登録してそれ以外のメールは全て受信拒否しても問題ないはずであり、もし、間違ってそのメールアドレスに送信されたのであれば、再送するように連絡すれば済むことだと思います。 知らぬメールに目を通すようなことはストレスを増やすことにしかなりません。 \\ ===== 都市伝説ですが ===== なにかのサイトで見かけたのですが、迷惑メールのハニートラップを行うところがあるようで、 ショッピングサイトの取引の連絡用やWebサービスのアカウント作成としてメールアドレスを登録するのですが、そのメールアドレスのアカウントは誰にも口外されないため、そのメールアドレスに届くメールを調査して、流出の様子をチェックしているそうです。 もしそのようなメールアドレスに迷惑メールが届くと、ショッピングサイトやWebサービスで明らかなメールアドレスの漏洩が起こったことが確認でき、迷惑メールの送り主やどのような目的で送られたのかもわかるそうです。 最近の流出事件もその方法でリークされたのかもしれませんが、ハニートラップとなるメールアドレスに迷惑メールを出すと、メールの内容から発信者（または広告主）が正規の方法で取得していないことがわかるそうです。 あくまでも都市伝説ですが。ま、そんなメールはフィルタで廃棄されるし、見向きもしませんので。