Entry

電子メールを有料化してみてはどうか:迷惑(スパム)メール対策

「メール」ということばの意味を辞書で調べると、まずまちがいなく、最初に出てくるのは、はがきや封書などの郵便物、つまり紙に書かれたメッセージを届けるサービスだ。しかし世間で「メール」といえば、今やまず「電子メール」を指すと考えてよいのではないか。老若男女問わず、私たちの生活は、PCや携帯電話を通じて行われるこうした通信サービスに強く依存するようになってきている。

幅広い普及はもちろんその便利さゆえだ。端末機器さえあればどこからでも簡単に送受信が可能で、(たいていは)すぐに届く。それになんといってもコストが安い。大量に送ってもほぼ無料というのは、送信者にとって願ってもない条件だろう。

しかしそれゆえの弊害もある。中でも、スパムメールの氾濫はばかにできない問題だ。スパムメールの被害者というのは、メールの利用者とほぼ同数と考えていいと思う。聞くところによると、世界中でやりとりされる電子メールの約8割、企業や個人が実際に受け取る電子メールの約2から3割がスパムメールだそうで、1日に100通を超えるスパムメールを受け取る人だってざらにいる。スパムフィルタを利用することで、かなりの部分を避けることができるにしても、それでもフィルタをかいくぐってくるスパムメールは少なからずあるし、フィルタの誤分類を定期的にチェックしなければならないから、煩わしいにはちがいない。携帯メールの場合は受信者にもコスト負担があったりするから、なおさら腹立たしかろう。

SNSのメンバー間メール機能を電子メールの代わりに利用する人たちがけっこういる、とも聞く。紹介制のSNSではお互いの身元が間接的にせよ知れているから、スパムメールを送る人は少ない。そういう計算だ。確かにそういう面はあるが、しかしこれも、SNSの規模が大きくなってくるといろいろな人が交じってくるし、架空のアカウントが増えてきたりもするから、なかなかうまくいかなくなってくる。それにそもそも、知らない人とやりとりができるのも電子メールの重要な機能だから、閉鎖的なSNS内のメール機能は、電子メールの一部の補完にはなっても、代替とはならない。

幅広い人とのやりとりが可能で、しかもスパムメールを排除できるしくみ。あるいは、スパムメールに煩わされるいらいらを多少なりとも解消できるしくみ。そんなものはできないだろうか。

思いつきレベルの案だが、電子メールを有料化したらどうか、と考えてみた。もっと正確にいうと、有料「にもできる」電子メールサービスを作ってみてはどうか、ということだ。

といっても、単にメール送信者に課金すればいいというものではない。課金すれば、それは電子メールの主要なメリットの1つである「安さ」を手放すことになるが、それではメールのやりとり自体を阻害してしまう。それに、有料化といっても、メールサービスの提供者が料金を徴収するだけでは、無料のメールサービスがあふれる中で、利用者がそのメリットを実感できない。

そうではなく、電子メール送信者が支払う料金を、ある範囲内で受信者が決められるようにしたらどうか。たとえば「1通当たり0から100円」のように。金銭ではなく、ポイントのようなかたちでもいいかもしれない。しかも、その料金の全部ないし大半を、メールサービスの提供者ではなく、受信者が受け取るようにする。

このしくみの下では、メールの送信料は、受信者との関係によって決められる。友人からのメールであれば、料金をとる人はいないだろう。しかしスパムメールであれば、不要で煩わしいものを送りつけられた「迷惑料」として、1通あたりたとえば100円を徴収する受信者が多くなるはずだ。これなら、友人間のメールのやりとりを阻害しない。しかしスパムメールの送信者は、あっという間に莫大な料金を徴収されることになって、送信を持続できなくなるだろう。受信者側も、料金を受け取ることで、多少は不満が解消するのではないか。もちろん支払を承諾せずに送信する者もいるだろうが、それこそ自らがスパマーであるとの宣言になる。

知らない個人からのメールはどうか。個人間のメールで、当事者間に料金のやりとりが発生するのは違和感があるが、ありえない話でもないだろう。受信者の立場からすれば、勝手に送りつけられて迷惑ということもあるかもしれないし、送信者の立場からすれば、料金を支払ってでもいいから読んでほしいといった事情があるかもしれない。とはいえ、知らない相手だから料金をとってしまえとばかりにがめつく料金を徴収する受信者がいれば、ネット上で「悪評」が立ち、その人にメールを送ろうとする人はいなくなってしまうだろうから、少なからず歯止めがかかるのではないか。

電子メールを使ってビジネスを行っている健全な事業者も、メール送信にコストがかかるようになるという不安を持つかもしれない。しかし今でも、広告メールではオプトインやオプトアウトのようなしくみが使われるわけで、このケースでも、個々の利用者から「この送信者からは料金を徴収しない」という事前承諾をとることにすれば、事実上それほど大きな問題にはならないのではないか。

このようなサービスの利点は、このしくみに賛同しない者を排除しないため、外部に開かれていて、それがゆえにこれまでのメールの補完ではなく代替が可能な点だ。料金の決済さえ可能であれば、送受信者間で実名を明かす必要もないから、匿名性もかなりの程度保たれる。もちろん、このサービスを当初から積極的に選択する企業や事業者は少ないだろうから、多くの人が使うようにならないとその真価を発揮できないだろう。しかし逆に、一定数以上のユーザーが集まってきたらがらりと様相が変わって、このサービスに対応しない事業者はスパマーであるといった認識が広がってくるのではないかとも思う。

設定できる料金の幅に負の数字を入れられるようにすべきかは興味深い問題だ。料金が負ということは、すなわち受信者が送信者に料金を支払うケースとなる。つまり、メールを使って簡単に寄付を集めたり、メール自体を決済手段として使ったりできる可能性があるということだ。メールサービスにどの程度のセキュリティが確保できるのか不安な面もなくはないが、小額にとどめたり、ポイントのかたちにするなら、可能性は十分あるのではないかと思う。

この考え方は、アフィリエイトと少し似たところがある。アフィリエイトは、広告という情報の流れに手数料というお金の流れを付随させることにより、新たな商取引のモデルを作りだした。これと同じように、電子メールという情報の流れにお金の流れを付随させることはできないだろうか、と考えたものだ。

電子メールがビジネスや日常生活に使われるようになってから、まだ15年もたっていない。メールの便利さも、スパムメールの煩わしさもすべてその短い間のことであり、まだまだ若い技術といえるのではないか。もっとさまざまな工夫、新たな試みがなされてもいいように思う。

 

【編集部ピックアップ関連情報】

○MediaSabor  スパム「郵便」の復権?  2007/10/22
http://mediasabor.jp/2007/10/post_240.html


○CNET  2008/02/14
 「迷惑メール規制法 海外発のメールも摘発対象に」
 国内の業者が海外の業者に委託して迷惑メールを送信するケースにも、
 総務省が立ち入り検査を行い、業務停止を命ずることでき、それに
 従わない場合には摘発が可能となる。
http://japan.cnet.com/news/media/story/0,2000056023,20367223,00.htm


○ホームページを作る人のネタ帳 2008/02/05
 「Googleスパムメールフィルタ機能を自分のプロバイダメールで試してみた」
 導入からわずか28時間でスパムを完全駆除
http://e0166.blog89.fc2.com/blog-entry-383.html


○GIGAZINE  2008/01/27
 自分のメールアドレスを画像認証でスパムから守る「reCAPTCHA Mailhide」
http://gigazine.net/index.php?/news/comments/20080108_mailhide_recaptcha/


○チクナイドットネット 2007/12/20
 「メルマガの反応が上がる!迷惑メール対策法改正の状況」
http://www.chikunai.net/modules/weblog/details.php?blog_id=202

 

 


  • いただいたトラックバックは、編集部が内容を確認した上で掲載いたしますので、多少、時間がかかる場合があることをご了承ください。
    記事と全く関連性のないもの、明らかな誹謗中傷とおぼしきもの等につきましては掲載いたしません。公序良俗に反するサイトからの発信と判断された場合も同様です。
  • 本文中でトラックバック先記事のURLを記載していないブログからのトラックバックは無効とさせていただきます。トラックバックをされる際は、必ず該当のMediaSabor記事URLをエントリー中にご記載ください。
  • 外部からアクセスできない企業内ネットワークのイントラネット内などからのトラックバックは禁止とします。
  • トラックバックとして表示されている文章及び、リンクされているWebページは、この記事にリンクしている第三者が作成したものです。
    内容や安全性について株式会社メディアサボールでは一切の責任を負いませんのでご了承ください。
トラックバックURL
http://mediasabor.jp/mt/mt-tb.cgi/656