迷惑メール対策サービス「+abmail」

[2008/3/21新規] [2009/4/2追記]

もくじ

はじめに

当社では、迷惑メール判定プログラム「abmail」を独自に開発し、当社メールサーバにて2006年はじめより運用しておりますが、長期に渡る社内外での運用実績の中で利用者に大変好評を頂きつつ、周辺プログラムの拡充や可搬性・可用性の向上を経て、迷惑メール対策ツール「abmail」としてバージョンアップを重ねて参りました。

迷惑メール判定プログラム「abmail」は、極めてシンプルな仕組み―メールの経路情報とMTA(メール配送エージェント)アドレス管理―により正当なメールと迷惑メールの判別を行っており、メール本文の走査はいっさい行いません。本ツールの開発者は、メール本文の走査やそれに係る統計的手法による対策はスパマー(迷惑メール送信者)とのイタチごっこを誘発し易く、むしろ、統計的・確率的要素が介在しない「経路情報とMTAアドレス管理」に徹した方が対策コストと被害コストの両面で有利であると考えます。そして実際に、その仕組みは非常にうまく機能しています。

その仕組みは極めてシンプルで、基本的な動作は、組織のメールの経路情報とメールの『信頼できるところまでの Received 行』の情報から、迷惑メール発信者かそうでないかを推定し、スパマーが自由にできる本文その他は決して判断材料とはしません。加えて、当人が送ってもいない不達通知に対してもこのシンプルな仕組みがそのまま適用できるので、偽の不達通知に困惑している利用者にも有効です。

昨今のインターネット社会における迷惑メールに係る損害や対策を鑑み、このようなシンプルな仕組みでさえ実運用に耐えうる実装が他に成されていない事から、当社はこの成果の「インターネット社会への還元」及び「利用者への支援」を以下の方法で実施する事にしました。

まず、電子メールは公共性が高いインフラであり、他のインターネット技術同様に仕様や仕組みが公開されています。その電子メールを利用する上で必須の「迷惑メール対策」もまた、仕組みが公開されて然るべきです。よって、ソースコードを適切なライセンスの下で公開しております。

また、本判定プログラムは、誤判定が全く無いわけではありません。よって、導入方法に依りますが、誤判定を自動的もしくは手動的に救済する仕組みが必要となり、その為の周辺プログラムが迷惑メール対策ツール「abmail」には同梱されています。また、電子メールを利用する組織の目的に応じて、メールサーバの負荷低減にも本判定プログラムは活用でき、その為の周辺プログラムも同梱されています。このような周辺プログラムの拡充のために、各種サービスを提供することを通じて、開発を継続していく必要があると考えています。

迷惑メール対策ツール「abmail」その設計方針と機能・運用

迷惑メール判定プログラム「abmail」の機能

迷惑メール判定プログラム「abmail」は基本的に以下の仕組みで機能します。

  1. メールヘッダの複数の Received 行を信頼できるところまで走査し、
  2. HELO/EHLO(SMTPグリーティング)、IPアドレス、逆引きから「正当なMTAからのメールか否か」を調べます。

ここで「正当なMTAからのメールか否か」は同梱されている設定ファイル(HELO/EHLOのパターン、IPアドレスの範囲、逆引き名のパターン)であるホワイトリスト及びブラックリストに基づき、一切の曖昧さなく判定することになります。

さらに、正当なMTAからのメールが、不達通知(バウンスメール)の場合に、以下の仕組みで機能します。

  1. メールのMIMEマルチパート構造から得られる、バウンスの起因となった元のメールにおいて、メールヘッダの複数の Received行を信頼できるところまで走査し、
  2. 同様に「正当なMTAからのメールか否か」を調べます。

加えて、以下のような機能を備えます。

  1. ブラックリスト管理コストの軽減の一助となるDNSBL(DNSベースのブラックリスト)の併用
  2. 組織内利用者が外部のエンドユーザアドレス空間から内部SMTPサーバを介してメールを送信する際に、正当なメールとして扱う為の
    1. 信頼できる Received 行におけるSMTP認証などの検知
    2. DRACによるPOP before SMTPとの連動による検知
  3. メール経路情報の設定として、信頼できる Received 行のパターンの記述により、以下の状況での対策が可能
    1. 例えば外部のメーリングリストなどにて、組織外の正当なMTAから正当なメールと迷惑メールが届く場合における対策
    2. 別に所有するメールアカウントからの転送設定などにて、組織外の正当なMTAから正当なメールと迷惑メールが届く場合における対策
  4. Received 行の印字形式のパターン変換により、
    1. sendmail, postfix ほか、qmail, exim 等の多様なMTAへの対応
    2. 逆引き情報を付加しない MTA 経路情報への逆引き情報付加

一般利用者向け周辺プログラムの機能

ソースコードツリーにはメールサーバ管理者向けのツールを含め様々な周辺プログラムがありますが、ここでは一般利用者向け効用に絞った機能について紹介します。

隔離スパム報告及び誤判定救済用ツール「abmailsreport」の機能

迷惑メールと判定されたメールをサーバに隔離する運用方式を選択した場合、例えば前日の隔離メール状況を一通のメールとして利用者に通達することが出来ます。

さらに、その「隔離スパム報告」メールへの返信を利用して、利用者所望の隔離メールを再送する事ができます。すなわち、極めて稀に起こるかもしれない誤判定メールの救済が、ウェブメールや管理者の介在無しに実現できる仕組みが用意されています。

偽陽性の誤判定メールの自動救済ツール「abmails-rescue」の機能

「正当なMTAからのメールか否か」を判断する際に、DNSの逆引きを利用せざるを得ないケースがあります。しかし、極めて稀ですが、DNSサーバの過負荷などにより逆引きが失敗する場合が確かに存在し、それはこの場合、正当なメールが迷惑メールと判定されてしまう「偽陽性の誤判定」となり得ます。

しかし、DNSサーバの過負荷により逆引きが失敗したのであれば、ある程度の間を置き改めて逆引きの問い合わせを行えば、その際には逆引きが正常に行えることが期待できます。

そこで、迷惑メールと判定されたメールをサーバに隔離する運用方式を選択した場合、例えば前日の隔離メールについて逆引きを改めて試みて判断し然るべきは再送するこの機能により、こうした偽陽性の誤判定メールの自動的な救済が可能となります。

ちなみに私共は、この abmails-rescue を前述の『隔離スパム報告及び誤判定救済用ツール「abmailsreport」』と併用して運用しています。

管理者向け周辺プログラムの機能

次に、ソースコードツリーに同梱される様々な周辺プログラムのうち、ここでは管理者向け効用に絞った機能について紹介します。

アンチ後方散乱メールコンテンツフィルタ「abackscatter」の機能

宛先不明のメールがメールサーバに届けられると、メールサーバの設定に依りますが、MTAは送信元アドレスに不達通知(バウンスメール)を送ろうとします。その際、送信元アドレスがスパマーによって詐称されていると、詐称された当人には全く身に覚えのない「偽のバウンス」が届く事になります。この偽のバウンスを後方散乱メール(backscatter)といい、人にも依りますが大量の迷惑メールのうちかなりの割合を占めます。

さらに、詐称された送信元アドレスも宛先不明であった場合、メールサーバの設定に依りますが、MTAはバウンスメールを数日間再送を試みます。スパマーの動向によってはこうした迷惑メールが大量に発生し、正当なメールが遅延するほどメールサーバに過負荷を与えるようになります。

よって、不要なバウンスは送信すべきではありません。ひとつの方法はSMTPセッション中にエラーを出す事ですが、その対処は、有効なアドレス収集「ディレクトリ獲得攻撃(directory harvest attack)」を助てしまいます。

そこで、このアンチ後方散乱メールコンテンツフィルタ「abackscatter」を用いると、迷惑メールを起因とする不要なバウンスは送信しないようにし、正当なメールを起因とする必要なバウンスのみを送信することが出来ます。これは、このコンテンツフィルタ内部で迷惑メール判定プログラム「abmail」を利用しているからこそ可能な応用です。この abackscatter により、意図せず他者に迷惑を掛ける後方散乱メールを防ぎ、尚且つ、メールサーバの負荷も極めて軽くなります。

majordomo等メーリングリスト管理ツール対応の周辺プログラム

周辺プログラムにてmajordomo等のメーリングリスト管理ツールを含むエイリアス設定に対応していますので、例えば、誤判定の救済手続きをグループリーダーが代表して実施するといった運用も可能です。また、エイリアスを展開して各人に配送する前段で迷惑メール対策を行うので、メールサーバへの負荷も低減できます。

迷惑メール対策ツール「abmail」の設計方針

本手法は以下のような「スパマーに掛かるコスト」の大小関係を想定して設計されています。

迷惑メールの本文・題名・送信元アドレスを改変するコスト<他者のCPU資源を盗用するコスト<DNSサーバを不正に運用するコスト<送信元IPアドレス空間を移動し続けるコスト

つまり、スパマーが例えば送信元アドレスを詐称する事は極めて容易いので、この種の情報は(明白なスパマーの痕跡を除き)判定基準としていっさい採用しません。また、エンドユーザアドレス空間で稼働する多数のパソコンにその脆弱性を悪用して不正プログラムを仕込み、それらからスパムを大量に送信することも比較的容易い現実があります。エンドユーザアドレス空間を推定する方法として、S25R方式のなかで使用されている「逆引きの命名慣習から推測する方法」や「エンドユーザアドレスを収集するDNSBLを利用する方法」が挙げられますが、迷惑メール判定プログラム「abmail」では前者を援用する事でブラックリスト管理コストの低減を計っています。さらに、送信元IPアドレス空間を移動するコストもDNSサーバを不正に運用するコストもスパマーにとっては比較的高いので、それらに係る情報を判定基準とする事でイタチごっこになり難いように努めているわけです。

本手法はまた、文献「MTAのアクセス制御」を参考に、以下のような理由で「迷惑メール対策は組織内で完結すべき」という方針で設計されています。

  1. 稀にあるかもしれない誤判定に係る(送信が拒絶される等の)影響は、直接的に客先へ及ぼしてはならない
  2. 他者の正当なMTAに(再送キューを圧迫する等)不当に負荷を掛けてはならない
  3. 多数のアカウントを抱えるメールサーバにて、重量級スパム判定手法の廉でメールが遅延するようなことは避けなければならない
  4. 際限なしのルールの実装などで、雑多なパラメータチューンに煩わされたり、いたずらにセキュリティ脅威を広げてはならない

さらに本ツールは以下のような方針で実装されています。

  1. レガシーなサーバ機やオペレーティングシステムでも高速動作させるためにプログラミング言語Cによる実装
  2. sendmail, postfixなどMTAの種類に依存しない汎用性を考慮した周辺プログラム構成
  3. 大量のアカウントを抱えるサーバにおいて本手法が決してボトルネックにならない為の高速化を目指した実装

よって本手法は、例として S25R、greylisting、SpamAssassin などの手法とは異なるひとつの選択肢と言えます。

迷惑メール対策ツール「abmail」の運用方針

ちなみに、ここまではひとつの運用方針として、迷惑メール如何に関わらず(利用者からどのように見えるかとは別として)MTAとしては正常に受信することを前提として話を進めましたが、abmailを活用したMTAの制御として、

  1. SMTPセッション中で受信を(恒久的に、一時的に)拒否するか
  2. 受信を許可(バウンスで返す、直ちに削除、振り分け・判定情報付加など)するか

は利用者の要望を鑑みて組織の方針に応じた設定であって然るべきですし、そうしたカスタマイズも容易です。

例えば、メールの隔離などせずに、迷惑メール判定の結果をメールヘッダに情報付加すれば、あとは各自にMUA(メールユーザエージェント)の自動振り分け機能を利用してもらえれば事足りる組織もあるでしょう。また、通常業務に支障を来さないように、迷惑メール判定されたメールはサーバ側でまず隔離し、利用者が別途(IMAP4、WebMail、abmailsreportを介して)隔離されているメールが判れば良いという組織もあるでしょう。さらに、こうした選択肢が各人で選べる枠組みがあるべき組織もあるでしょう。当社はまさにそのように運用しておりますが、組織の利用者と管理者の生産性と管理コストのバランスが採れたソリューションがあるかと思われます。当社が提供するサービスにおけるソリューションの提案とオープンソースソフトウェア開発の相乗効果が、皆様の適切なメールサーバ運用の一助となると考えております。

サービス体系

導入費用

メールサーバ管理者が居り、迷惑メール判定ツールのソースコードとその導入に係る技術情報があれば十分である、といった方には以下の費用でご活用頂けます。

その他の導入作業、運用管理に係る費用については別途お見積もり致します。

さらに、本手法のアプライアンスやサービスへの組み込み等を検討されるサプライヤ向け技術支援についてもご相談下さい。

その他、関連資料

迷惑メール対策サービス 「+abmail」に関する各種資料を配布しています。

迷惑メール判定プログラム「abmail」に関する各種資料を配布しています。

隔離スパム報告及び誤判定救済用ツール「abmailsreport」に関する各種資料を配布しています。

ソースコード

迷惑メール対策ツール「abmail」のソースコードは GNU AGPLv3(Affero General Public License Version 3) に基づき配布しております。

運用実績のあるMTAやプラットフォームその他の詳細はそちらをご覧下さい。

利用者の声

ご利用頂いている方々から abmail の使用感などを寄せて頂きましたので、以下に紹介いたします。

2006年中頃に、社内ウェブページから申請して abmail を有効にしたら、迷惑メールがパッタリと来なくなり、逆に不安になったものですが、通常のメールはきちんと届いているし、朝には前日の「迷惑メール一覧」メールが届きます。当初は、登録したメルマガが迷惑メールに判定されたこともありましたが、「迷惑メール一覧」メールに救済したいメールを指定して返信すれば、それが再送されます。誤判定修正をした以降は通常メールとしてきちんと届いています。今はそういった問題もまったくなく、迷惑メールの存在すら忘れるような状態です。迷惑メールを削除しながらブツブツ怒っていたのが遠い過去のことのようです。他の社員も、朝の貴重な時間が有意義に使えるようになったので、会社の経費削減にも大きな効果があると思っています。

H.N.氏より

2007年はじめから、自宅、職場、いろいろなところで使わせて貰っています。主に FreeBSD や Linux で fetchmail, procmail 等と組み合わせて動かしていますが、abmail もオープンソースなので安心して使い続けています。この abmail は、他の対策ソフトと比べて物凄く軽量・高速、それでいて、極めて効果的な判定性能が素晴らしいです。前にいた所ですが、組織の上流で、別の迷惑メール対策専用マシン群で防御しているようなのですが、それでも一日に数百通ものスパムがすり抜けてきており、結局 abmail がサクサクと一手に引き受けていました。私は、CPU資源を迷惑メール対策などに使われたくないので、本当に助かります。ところで、そこではその後、さらにまた別の対策手法を加えたらしく、メールが遅延するようになってしまいました。それでもスパムが漏れてくるのですから、abmail に代わるものはちょっと考えられないです。

S.H.様より

2008年中頃に研究室の Mac OS X サーバに導入しました。となると Postfix, Cyrus-IMAP サーバにおける abmail の運用ということになるので、いろいろと助言を頂き、IMAP フォルダに迷惑メールを隔離することにしました。それ以前は、POP クライアントとして Mail.app でメールを受信していたのですが、IMAP の方が便利ですし、abmail の運用にも適しているのですね。abmail のおかげで、それまで Mail.app で習慣となっていた「迷惑メールの学習作業」から解放されました。導入当初の初期設定が済んでしまえば、あとはほぼメンテナンスフリーなのも助かります。余談ですが、迷惑メールが大量に採取されたフォルダをたまに眺めてみるのも面白いですね。

T.I.先生より

研究室に配属された当初は、私のメールアカウントは迷惑メールとはまったく無縁でした。しかし、研究の情報発信を目的に作成したホームページにメールアドレスを公開した頃から、迷惑メールを受信するようになりました。受信するといっても、始めは1日に2〜3件だったため、Mail.app の「迷惑メールの学習機能」で事足りており、迷惑メールの奇抜な内容を面白がってもいました。しかし、次第に受信件数が増えてくると、そう呑気に構えていられなくなりました。なぜなら、迷惑メールを受信する度に研究を中断し、「メールの確認、迷惑メールの学習作業」を行う必要があるからです。迷惑メールにイライラ感を募らせ始めた2008年中頃、研究室の Mac OS X サーバに abmail が導入されていることを知りました。abmail なら学習作業を行なう必要がないため、研究に集中することができ大変助かっています。

T.M.様より

利用者の方々のご意見に関して、開発者による補足及び解説を添えさせて頂きます。

POP, IMAP, MH, Maildir と abmailsreport (一般利用者向け)

上記「迷惑メール一覧」メールとは、IMAP を利用しておらず、POP でクライアントのメーラに受信している一般利用者向けに abmailsreport による「隔離スパム報告及び誤判定救済」機能を提供するためのものです。IMAP などで隔離スパムを容易に閲覧できる環境がない・慣れていない利用者のために開発されました。

一方、IMAP などで隔離スパムを閲覧できる環境や、procmail で振り分けられた MH 形式、Maildir 形式のメールフォルダを閲覧できるメーラと環境を使っている一般利用者は、abmailsreport のような仕組みは基本的には不要でしょう。但し、併用も可能な abmails-rescue による「偽陽性の誤判定メールの自動救済」の方は、いずれにもメリットがあります。abmailsreport, abmails-rescue ともにシステムのスケジューラによる処理ですので、管理・運用コスト等を鑑みて導入を検討すればよいと思います。

開発者 T.Y.より

メールの遅延について (管理者向け)

メールサーバで greylisting や Rgrey(S25R+greylisting) のような MTA コネクションレベルの対策を行うと、何もしていなければすぐさま届くような相手からのメールが、場合によっては遅延するようになります。企業の利用者によっては、客先からデータをメールで送って貰って、すぐさま電話でコンタクトを頂く、といった事は日常茶飯事でしょうし、大学のような研究機関でも、指導教員や共同研究者とのこうしたやり取りは普通でしょう。メールの遅延が、メールサーバや回線の不調が原因であれば、避け難かった稀なトラブルとして致し方なかったと思えます。しかし、その原因が「不適切な迷惑メール対策」だったとすればどうでしょうか。

メールの遅延は、一般利用者のそれまでの業務遂行のスタイルを変えてしまう可能性があります。利用者が組織内で閉じていれば、組織内で合意し周知すればよいことですが、この場合は、客先、指導教員、共同研究者のような相手が関わっており、互いの合意を得ることは、そう簡単にはいきません。個人運用のメールサーバならその管理者の裁量次第でしょうが、社会的責任のある企業や公的機関で、サーバ管理者が十分な配慮なしにそのような決定と運用をしてよいとは限らないのです。

その上、技術的見地からも、greylisting や Rgrey などは相手のメールサーバに再送の手続きを強いるなどの問題があります。例えば、宛先不明の受信について、対ディレクトリ獲得攻撃のために不達通知(バウンスメール)を返す設定しているメールサーバは、差出人が詐称されたスパムを起因とするバウンスがキューに数多く残されており、送信先の greylisting や Rgrey により再送メールがその圧迫されたキューに滞留することになります。abmail 同梱の abackscatter で対策されていれば、後方散乱メール(backscatter)加害になりうる不要なバウンスを抑制するだけでなく、バウンスと再送でキューが圧迫されることも防止できますが、そのような対策がなされたメールサーバばかりではないのです。よって、greylisting や Rgrey を採用するにしても、充実したホワイトリストで偽陽性の誤検知がほとんどない状態から始めた方が安心です。

開発者 T.Y.より

おわりに

迷惑メール判定手法の性能を示すための判定率については、配布資料で言及しているので正確にはそちらを参照頂くとして、本手法は基本的にメールの経路情報とMTAアドレス管理及び管理・運用コストを低減する周辺技術なので、判定率が高いのは当然と言えます。例えば、毎日500通を超える迷惑メールを受信している利用者が、試しにMTAアドレス管理を半年以上放置してみると、やはり一日に数通の迷惑メールがすり抜けるようになります。個人的にはその程度の偽陰性の誤判定率なら、それほど迷惑ではないし気にならないのですが、この実例は、何もしなくても判定率が高いまま比較的長く維持する、即ち、スパマーの住処に係る設定が極めて熟れてきていることを示唆していると思います。一方で、新規にオプトインした例えばメールマガジンなどは、MTAアドレス管理を怠ると偽陽性の誤判定のまま放置されてしまう可能性が少なからずあります。このように、本手法により業務に支障を来さない環境は得られるでしょうが、特に偽陽性の誤判定との付き合い方を周辺プログラム等を活用して工夫される事をお勧めします。

一日に数十通もの迷惑メールを受信していたある利用者は、本手法の対策後「迷惑メールの削除に費やしてた朝の30分間が有意義に使えるようになった」、一日に数百通もの迷惑メールを受信していた利用者は、「破綻しかけてた日常業務がスムーズになって本当に助かる」、同じく一日に数百通もの迷惑メールを受信しており、他の対策手法から乗り換えた利用者は「判定基準に曖昧さがないので、誤判定のマネジメントがし易く快適になった」そして「迷惑メール?別にもう迷惑してない」など、効用に対する興味深い反応があります。そして、迷惑メールの存在すら忘れてしまっても構わないシステム環境が理想的です。本サービスが、そういったシステム環境づくりの一助になれば幸甚です。

謝辞

DNSBLを管理されているボランティアの方々、S25R方式の提唱者である浅見秀雄氏、特に「MTAのアクセス制御」とスパム対策について詳細にまとめて下さっているやまぐちたかのり氏に感謝します。

参考文献

  1. やまぐち たかのり「MTAのアクセス制御」http://ya.maya.st/mail/accessctl.html
  2. B. Costales, E. Allman(著), 中村 素典(監訳), 林 秀幸(訳)「sendmail volume 1 運用編」オライリー・ジャパン, 2004.
  3. B. Costales, E. Allman(著), 中村 素典(監訳), 鈴木 克彦(訳)「sendmail volume 2 設定編」オライリー・ジャパン, 2004.
  4. 荒木 靖宏「Postfix詳解―MTAの理解とメールサーバの構築・運用」オーム社, 2004.
  5. 三田 典玄「qmail完全解説」九天社, 2005.
  6. R. C. Seacord(著), 歌代 和正(監訳), JPCERTコーディネーションセンター(訳)「C/C++セキュアコーディング」アスキー, 2006.

お問い合わせ

迷惑メール対策サービス「+abmail」については rdteam@aihara.co.jp までお問い合わせ下さい。

迷惑メール対策ツール「abmail」のソースコードについては開発者向けメーリングリスト abmail-devel@aihara.co.jp にご参加下さい。参加方法は、メール本文に

subscribe abmail-devel
end
と書いたメールを majordomo@aihara.co.jp 宛に送ります。詳しくはメーリングリスト管理システム majordomo のドキュメント等を参考にして下さい。

Copyright (C) 2008 R&D Team, AIHARA Electrical Engineering Co., Ltd. All rights reserved.