スパムメール

　スパム（spam）メールは、何らかの方法で入手したメールアドレスに対して無差別に、本人の許諾を得ずに一方的に営利目的の広告メールを配信することです。

※「SPAM」はHormel Foods（ホーメルフーズ）社の味付け豚肉の商品名で、同社は商標登録しています。Hormel Foods社は自社サイトで、全て大文字の「SPAM」と区別するために、迷惑メールは小文字で[spam」と呼ぶように、呼びかけています。

• 1　スパムの問題点
• 2　スパム対策
• 3　スパマーの追跡

1　スパムの問題点

　スパムメールは迷惑メールといわれますが、どうして迷惑なのでしょうか？

1．1　メールの受信

　スパムメッセージの多くは広告メッセージです。無作為に選んだ人に広告のメッセージを送信する方法としては、以前は実際の郵便でダイレクトメールを送信するという方法がありました。しかし、この方法は手間がかかるうえに多額の印刷代、郵送料がかかります。しかし、電子メールを利用した広告メールではほとんど経費は掛かりませんし、手間もかかりません。経費は殆ど受け手が出しているといっても言い過ぎではありません。また、メールボックスに一杯になった迷惑メールを仕分けする手間も受け手が負担しています。

　送信者とすれば大量のメールを送信し、そのうちの一人でも引っかかってくれればそれで元が取れます。スパムメールは受信者の経費負担で不要なメールを受け取っているのと同じです。インターネットには今のところ、不要メールの送信、中継、格納にかかる経費、ユーザが読むのにかかる費用をスパマーに分担させる現実的な方法論が存在しません。

※スパムの受信者の支払うべきコストとしては、通信費、メールボックスの容量の消費、メールの整理、の他にメールを読んだ時の、気分の悪さもあります。こんなメールなど読みたくないとか、メールを読んで気分が悪くなったとか・・・

　今のところの対策としては、受信者としては、受信はしても読まなくてもいいように、プログラム等を利用して、自動的に迷惑メール用のフォルダーに振り分けるしかありません。しかし、仕訳が必ずしも、完ぺきとは言えないのと、正当なメールが迷惑メールに仕分けられた場合のトラブルがあります。更に、メールボックスの容量を消費するという問題点は残ります。

1．2　サーバの問題

　スパムメールの送信者はドメイン名からメールアドレスを類推してメールを発送することが多いいようです。メールのあて先は殆ど間違っています。大量に送信した迷惑メールのうち、たまたま宛先アドレスが実際のメールアドレスにマッチしたものが届きます。殆どがエラー（宛先不到達）ということで、送信元にエラーメッセージが送り返されます。ところが、スパムメールの送信者のアドレスは偽装されていることが殆どですので、エラーメッセージがまた、宛先不到達で戻ってくるということになります。これは、貴重な帯域を浪費することになります。また、エラーメッセージはサーバ内に溜められて、一定時間後に再送されることになりますが、これも帯域の浪費になります。

　また、スパムメールの処理に忙殺さるサーバは正当なメールの処理も遅れてしまうことになります。

　また、スパムメールはサーバの管理者にとっても迷惑です。何万通もの迷惑メールが中継されるので、CPU、メモリ、ログファイルなどの資源が消費されることになります。メール受信者から苦情メールに対して謝罪のメールを送らなくてはなりません。更に、スパムメールの中継サーバとしてブラックリストに載ってしまったら、スパムの片棒を担いでいるサーバとの悪評を立てられる可能性もありますし、リストから取り除いてもらうのも一苦労です。

1．3　スパムを利用したDoS攻撃

　スパムを利用したDoS攻撃もあります。攻撃対象を宛先に指定して、大量のスパムを送信する方法と、攻撃対象を送信元にして、その送信元に対してエラーメッセージを大量に送るように仕向ける方法があります。また、大量のあて先不正のスパムを送り付けて、メールサーバをエラー処理に忙殺させて、ダウンさせるという方法もあります。

1．4　第三者中継メールの問題

　第三者中継（Third-Party Mail Relay）とは自ドメインと関係のない第三者でも自由に電子メール送信ができるようなメールサーバの設定、あるいはそのような状態のことです。

　メールサーバを所有しているプロバイダのユーザだけ、あるいはメールサーバを管理している会社の社員だけが利用できるように設定されたサーバは「第三者中継をしない」メールサーバです。

　しかし、設定の都合上あるいは設定ミスで自ドメインとは無関係の第三者同士のメールを処理するようになっている場合があります。これが、第三者中継可能な状態です。このような状態のサイトを巧妙に経由させることによって、元々の送信元を隠ぺいすることがある程度可能になります。迷惑メールの中継とは、スパマーが、第三者中継可能なメールサーバを探し、迷惑メールの中継に利用することです。

※パソコン通信時代はその通信会社の会員間だけでメールのやり取りをしていました。しかし、インターネットが盛んになると、パソコン通信の会社のネットワーク間に通信経路が設けられるようになり、相互にメールのやり取りができるようになりました。こうなると、スパマーは自分が契約する会社のメールサーバではなく、他の会社が提供しているメールサーバを使って迷惑メールを送信し始めました。こうなると、どのユーザがメールを送信しているのか、各々のパソコン通信の会社ではつかめなくなってしまいました。このころから、迷惑メールが徐々に増えてきました。パソコン通信の会社は後に多くがインターネットサービスプロバイダになっていきますが、パソコン通信時代の教訓から、外部からのサーバ利用を阻止するようになっていきます。しかし、現在でも無知や、無理解から放置されている第三者中継サーバは多数存在しています。
　
　メールサーバが中継に利用されてしまうと、迷惑メールの送信者が分かりにくくなるだけではなく、サーバへの悪影響（処理の遅延、過負荷）の他に、送信元と疑われるという弊害が発生します。

※運用の都合上、第三者中継を一律に禁止できない場合もありますが、その場合は、個別のアドレスやドメインからのメールを制御する必要があります。

　sendmailのversion8.9.0以降であれば中継阻止のための設定が用意されています。Post.Officeの場合はversion3.1.2以降で中継に関する設定が可能となっています。

　メールの不正中継が可能なサイトのブラックリストが公開されていますので参考にしてください。
RBL.JP　http://www.rbl.jp/
MAPS/RBL Listings　http://www.mail-abuse.com/enduserinfo_rbl.html

　自サイトのメールサーバがこのリストに掲載されている場合は、spam対策にこのリストを使っているサイトから受信拒否される可能性がありますので、第三者中継に使われないように対策した上でリストからの削除依頼をするように検討してください。

2　スパム対策

2．1　ユーザの対応

2．2　ベイジアンフィルタ

　ベイジアンフィルタは統計学上の理論である「ベイズ定理」によってスパムの判定を行おうとするものです。ベイジアンフィルタはまずスパムだと分かっているメールの集まりと、まともなものだと分かっているメールの集まりを事前に調べ、この比較の結果を以後に受信するメールのスパム判断に利用しようとするものです。比較は、メール本文の内容だけでなく、ヘッダ情報、メタデータ、単語の組み合わせ、フレーズ、更には使用する色の指定情報を表すHTMLコードに至るまで行います。比較によって言葉（トークン）のデータベースを作成します。データベースが充実すればするほど判定の能力は高まります。

　スパムメールには「無料」とか、「ただ」、「ビジネスチャンス」、「独立して稼ごう」、「健康とダイエット」、「投資」などの言葉がよく見られますが、まともなメッセージにもこれらの言葉は出てきます。ベイジアンフィルタはこれらの言葉が出てきても単純に判断しないで、メッセージ内の他のトークンも総合的に比較して、判断を下します。

　ユーザはメールに対して、これは正常、これはスパムというように何日間かベイジアンフィルタに教育を授けます。1週間ほどベイジアンフィルタを鍛えると、ほとんど誤判断をしない位に賢くなってくれます。しかし、安心してはいけません。それでも時々、スパムが正当なメールに混じってきますので、その時にはフィルタに対して、「これはスパムです」と教えてください。

　ベイジアンフィルタは様々なメールサーバ、あるいはメーラで使えるようになっていますので、よく調べてください。実装として有名なものとしてはspamassassinなどがあります。

3　スパマーの追跡

　スパマーを追跡して、サーバ会社に連絡しましょう。配信停止にしてもらえるかもしれません。だめだとしても、少しは気分が晴れるかもしれません。

　スパムを追跡するためにはメールヘッダのReceived行の解析が有効です。Receivedフィールドはメールの転送処理をしたメールサーバが、自分が処理した印として、ヘッダに追加していくものです。従って、メール本文の近いところから（下から）、段々に上に（下にある方が古くて、一番新しいのが一番上に）追加されます。

　スパムメールのFrom、Reply-Toなどのヘッダフィールドに含まれるアドレスは殆ど偽造したものですので、信頼することはできませんが、Received行はある程度は信頼できます。なぜなら、メールを転送したメールサーバが自動的に追加していくフィールドだからです。しかし、偽のReceived行を追加したりすることもできますので、全面的に信頼することはできません。

　スパマーは自分を追跡されことを嫌います。追跡のための一番の手掛かりはReceived行ですので、追跡を免れるために、スパマーは偽のReceived行を途中に挿入したりします。SMTPにはメッセージヘッダの偽造を防止するメカニズムがありませんので、偽造しようとすればできてしまいます。

　Received行を追跡の手掛かりにするためにはReceived行のことをよく理解しなくてはなりませんので、まずReceived行の説明をします。Receivedフィールドの形式は次の通りです。

　メールの転送処理をしたメールサーバがReceived行を追加します。重要なのはfromとbyです。fromはメールを転送した転送元のサーバ名、ドメイン名、IPアドレス等を表し、byは転送処理をしたサーバ、つまりこのReceived行を追加したサーバのサーバ名、ドメイン名、IPアドレス等が表示されます。

　Received行は転送処理をしたメールサーバ名が（ヘッダ表示の例では上に）追加される形になりますので、前の行の「by」で表示されたサーバ名が、次の行（その上の行）の「from」で表示されるサーバ名と一致する形で追加されていきます。

　上の例では、「abcd」⇒「efgh」⇒「ijkl」⇒「mnop」⇒「qrst」⇒「uvwx」の経路でメールが転送されていることが分かります。

　上のように赤字のReceived行を1行挿入すると、「by」と「from」の間が論理的につながらなくなってしまいます。偽造情報の前の情報は、一見つじつまが合っているように見えても、迷惑メールの送信者が偽造したヘッダである可能性が高いので信頼することはできません。

　次の例はどうでしょうか？

　少し細かく見ていきましょう。全体を表示すると、ややこしくなりますので、Received行を1行だけ取り出してきました。「abc.example.com [120.10.30.45]」の部分はメールシステムが付け加えたものですので、有効な情報です。()の前の情報は送信者がHELLOコマンドで送信してきた文字列です。「abc.example.com [120.10.30.45]」の「abc.example.com」はメールシステムが「120.10.30.45」からDNSの逆引きによって検索した名前です。
　HELLOで送られてきた文字列である「abc.example.com」と「120.10.30.45」の逆引きが一致するか確認してください。一致しない場合は偽装の疑いがあります。

　次は典型的な偽造ヘッダの例です。
　>Fromフィールドは、送信したメールシステムがMAIL FROM SMTPコマンドで提供した情報です。これは一般的なメッセージでは、そのメッセージの送信者のメールアドレスです。これに対してFrom:フィールドには送信者が入れたい文字列を記述することができます。ただし、この2つのフィールドの値が異なっていても、即擬装とは言い切れません。メール本文の作成者が他者が送信することを承諾していることは十分にある得るからです（秘書と上司の関係など）。

　一番前の（下の）Received行の日付が次のReceived行の日付よりも後になっているのは、論理的おかしいです。2行目のReceivedの[10.1.1.1]を逆引きした値と、HELLOコマンドで送られてきた「abc.com」が違っているのも問題です。最後の行（一番上）のforはRCPT TOコマンドで送信された宛先です。これが、To:フィールドの値と全く異なっているのもおかしな点です。

　メッセージヘッダMessage-Id：行はメッセージを一意に識別する識別子を含みます。メールシステムのログファイルにはメッセージを自分のホストに転送してきたシステムの識別に利用できる情報が含まれるエントリが記録されています。Message-Idフィールドと他のヘッダ情報を組み合わせることで、スパムメッセージの配送に加担したホストや、転送したホストを調査することができます。

　メールサーバの管理者のメールアドレスはpostmaster@ドメイン名なので、スパムに関する報告をしておけば、メールサーバの管理者はログを確認して、スパマーの特定ができるかもしれません。

ネットワーク超入門講座 セキュリティ編【電子書籍】[ 久米原 栄 ] 価格:2,268円 (2018/1/20 12:25時点) 感想(0件)

Tweet

更新履歴