■SMTP-AUTHによる投函
送信者のメーラーから送信側メールサーバへの投函(*)には、サブミッションポート（ポート587）を用いたSMTP-AUTHによるユーザー認証を必要とする。当然、送信者がアカウントを持たない受信側メールサーバに直接投函することはできない。
メーラーは、パスワードを他プログラムから見破られにくいように作られる。したがって、PCがボットにやられたとしても、ボットが正規の送信者を装ってスパムを投函することは困難になる。
(*) 投函：サブミッションポートによる送信は「投稿」と呼ばれているようであるが、これは、ネットニュースでの言い方「記事（an article）をpostする」の「post」の訳語を継承したものではないかと思われる。私は、電子メールにおいては郵便になぞらえて「post」の訳を「投函」と呼びたい。英和辞典にもそう書かれていることだし。
■送信サーバのドメイン認証
送信側メールサーバは、メールをポート25のSMTPで受信側メールサーバへ転送する。受信側メールサーバは、SMTPアクセスしてきたホストが正規のメールサーバであるかどうかをドメイン認証でチェックする。ボットにやられたエンドユーザーPCがSMTPで受信側メールサーバへ直接投函しようとしても、ドメイン認証をパスしないので、受信が拒否される。
ただし、ドメイン認証をパスしないクライアントを安心して拒絶できるためには、すべてのサイトで、メール送信サーバがドメイン認証をパスするように設定していなければならない。その前提として、ドメイン認証方式が標準化されなければならない。それは、スパムの抑止に効果が高く、かつサイト管理者が誰でも容易に実装できるものであることが望まれる。私は、SPF（Sender Policy Framework）もDKIM（DomainKeys Identified Mail）も、インターネット全域で合意されて速やかにあまねく実装されるには理想的なものではないと思っている。道は遠い。
■流量制限
それでもボットあるいは悪意あるユーザーがスパムを送信するならば、送信側メールサーバで流量制限をかける。一メッセージについての宛先の数を制限するとともに、一クライアントからの常軌を逸した頻度の送信に対しては、応答遅延、または投函の一時拒否によるスロットリングをかける。これにより、大量スパム配信が抑制される。
■内容検査による送信保留
ボットあるいは悪意あるユーザーによるスパム送信へのもう一つの対抗手段は内容検査である。送信されるスパムのデータを集めながら、送信側メールサーバでベイジアンフィルタによる内容検査を行う。もしスパム判定されたら、次のような内容のバウンシングバックメールを送信者に返して認証を求める。
| あなたが送信されたメールは、不正メールの疑いがあると判定されたため、メールサーバで送信が保留されています。判定は誤りかもしれません。送信するためには、以下のURLにアクセスして送信手続きを行ってください。 http://… |
バウンシングバックメールとはいっても、詐称されているかもしれない送信者アドレスに向かって誰彼かまわず投げまくるOptPlusのバウンシングバック認証方式とは異なる。送り先は、そのメールサーバにアカウントを持つユーザーのメールボックスだけである。
もしボットによるスパムだったならば、ユーザーは身に覚えのないバウンシングバックメールを受けて、アカウントの悪用に気付くことができる。もしユーザーが故意にスパムを送信したならば、送信手続きの手間を強いられるので、スパムの大量送信が非常に困難になる。
こうして考えてみると、いずれS25R方式が不要になる時が来ても、ベイジアンフィルタの出番はなおも残るわけだな。私は、ベイジアンフィルタを使わずに済む簡単なアンチスパム技術を考案して、「頭のいい人って、なんで難しいことを考えるのだろう」と思っていたが、やっぱ、頭のいい人が作るものは違うわ。
さて、このような将来像が実現してもなおスパムはペイするでしょうか。私は、スパムを根絶できるとは思わないが、今のような傍若無人な大量スパム配信はできなくなると思う。これでもスパムを今くらいに大量にばらまく抜け道があることに気付かれた方はコメントください。
0 件のコメント:
コメントを投稿