Webは日々進化を続け，目まぐるしく変化し，次々と新しい技術が生まれています。一方，電子メールは昔からさほど変わっておらず，また，メールに取って代わるものも出てきていません。今後も電子メールは生き残って行くと思います。

筆者はそんなメールに焦点を当ててバウンスメール（エラーメール）解析専用のシステムを開発し，2010年3月に国産オープンソースソフトウェアとして公開しました。本稿はバウンスメール解析システム“⁠BounceHammer⁠”（バウンスハンマー）を，その役割や特徴，導入方法，構成事例を中心に紹介します。

バウンスメールとは

バウンスメールとは，配信したメールや配信しようとしたメールが，何らかのエラーによって送信者に差し戻されたメールのことです。バウンスメールの他の表現としてエラーメール，リターンメール，不達メールなどと表記されることもありますが，本稿ではバウンスメールと表記します。

バウンスメールでは，メールの送信者（From）が“⁠MAILER-DAEMON⁠”や“⁠Postmaster⁠”として，件名（Subject）が“⁠Returned mail:see transcript for details⁠”や“⁠Mail System Error - Returned Mail⁠”などで返ってきます。

バウンスメールを放置すると...

その配信する量の大小にかかわらず，バウンスメールは確実に処理すべきであると筆者は考えています。バウンスメール処理を行わず，配信できないアドレスを放置していると，次に挙げるような不都合が生じます。

遅延の発生

メールサーバ管理者は，管理下のメールサーバにスパムが送られている，あるいは攻撃されていると判断した場合，Tarpitting（注1）やGreylisting（注2）⁠，そして接続の拒否という対応を採ります。多くの宛先不明アドレスに対していつまでも送信し続けると，このような対応を受けることになるでしょう。

前述の対策は，いずれも送信元のサーバにとってはメール配信の遅延につながるもので，フリーのWebメールなどでも，宛先不明が多く含まれている場合は，接続がたびたび拒否されることがを確認されています。宛先サーバの管理方針次第では，公開ブラックリスト（DNSBL（注3）⁠）に登録されることもあるでしょう。登録されると遅延の範囲は更に広がります。

遅延が発生してしまうと，配送完了までの時間がかかり，サーバリソースを無駄遣いしてしまう結果を招きます（図1）⁠。

注1）

SMTP応答の遅延です。

注2）

初回接続時に一時エラーを返し，再接続してきたらメールを受けとるしくみです。

注3）

DNS-Based Blackhole List

携帯電話宛での遅延／受信ブロック

日本国内の携帯電話宛メール配信では事情はもっと厳しくなります。送信するメールの宛先に宛先不明アドレス／ドメイン指定拒否になっているアドレスが一定の数／割合以上であると数分間，酷いときには1時間近くキャリアのメールサーバに接続できないという状況になってしまいます。これは受信ブロックと呼ばれていますが，その結果，大量の遅延が発生し，Webサイトにおけるメールの信頼性の低下，そしてユーザが離れ，売上が下るという事態にもなりかねません。

有効なメールアドレスの把握ができない

多くのメールを送信するWebサイトやメールマガジンでは，バウンス処理を適切に行い，配信ごとにメールアドレスの状態変化を把握するべきでしょう。さもなければ，どれほどのユーザにメールが配信できるのかが把握できない，メールサーバでの遅延発生頻度が高くなるといった問題が顕著になってきます。

メール本文内に広告を入れている場合は，配信可能なアドレス数が把握できていないと，広告の効果測定に用いる数値自体が信用できなくなります。送信できるアドレスと宛先不明で返ってくるアドレスが混在していると，配信時間もかかって非効率的です。

BounceHammerの特徴

バウンスメールは確実に処理すべき

前節ではバウンスメールを放置したことによるデメリットを述べました。筆者は配信するメール量の多少にかかわらずバウンス処理は確実に行うべきであると考えています。バウンス処理をすることによって，前述のデメリットはかなり解決（注4）できます。

注4）

遅延や受信ブロックは他にも要因があります。

BounceHammerとは?

BounceHammerはオープンソースのバウンスメール解析システムです。バウンスメールを解析し，発信者アドレス／宛先アドレス／エラー理由／宛先分類／バウンス時刻などを構造化されたデータとしてYAML形式で書き出し，データベースに蓄積します。

ネットワークへの追加が容易

バウンスメール処理専用システムなので，ネットワークへの追加はBounceHammerをインストールしたホストを設置してバウンスメールを渡すだけです。

オープンソースのMTAに対応

BounceHammerはSendmail，Postfix，qmail，Exim，Courier-MTAの生成するバウンスメールに対応しています。これらのMTAは非常に多く使われているので，よほど特殊なMTAでない限り解析可能といえるでしょう。

エラー理由が正確にわかる

BounceHammerは，一般的なバウンスメールに加えて，日本の携帯電話主要キャリアのバウンスメールに対応（注5）しています。BounceHammerでは，バウンスメールが返ってこない場合はエラーの理由を知ることはできませんが，携帯電話宛の宛先不明とドメイン指定拒否を区別して検出できます。表1では，検出できる10種類以上のエラーのうち，実際の運用で重要なものを挙げています。

何らかのバウンスメールが返ってきたら，そのメールアドレスを配信不能なアドレスとして扱うという単純なバウンス処理を行った場合，“⁠メールボックスがいっぱい⁠”や“⁠メールが大きすぎる⁠”のようなエラーで宛先アドレスに配信不能フラグを立ててしまうという誤った対処をしてしまう危険性があります。

エラーになった理由ごとに適切な対処をすれば，メールアドレスの状態変化を管理しつつ，宛先不明アドレスの割合増加による遅延を回避ができます。検出できるエラーについての詳細は，http://bouncehammer.jp/features/engine/reasonをご覧ください。

注5）

スマートフォンや著名なWebメールにも対応しています。

読みにくいバウンスメールを構造化する

BounceHammerは解析したバウンスメールの内容をYAML形式で出力します。YAML形式の解析結果は1行1レコードで書き出しているので，コマンドラインからcatで眺めたり，wcで行数計測することによって手軽に解析済みデータの確認が可能です。広く使われているYAML形式でデータを書き出すので，他のアプリケーションからも容易にバウンスした記録の参照ができます。

Webブラウザベースの管理画面

BounceHammerは基本的にコマンドライン上ですべての操作を行います。しかし，人間の目で内容を確認するには，やや見にくい点もありますし，バウンスの状況を確認するのはサーバにログインしてコマンドラインで操作する人ばかりではありません。

そこで図2のようなWebブラウザベースの管理画面（注6）を使えば，サーバにログインしない，あるいはコマンドラインに精通していない人でもバウンスメールの管理ができます。

注6）

システム上ではWebUIと称しています。

HTTPベースのAPI

BounceHammerはHTTPベースの簡易なAPIを持っていて，発信者アドレス（From）や宛先アドレス（To）⁠，宛先ドメインやエラー理由などを文字列としてURLに入れてアクセスし，その結果をJSON（注7）形式で受け取れます。図3はcurlコマンドでAPIにアクセスしたときの実行結果です。APIを利用すると，Webサイトにバウンス記録の参照機能を短い開発期間で実装できます。

< curl http://apitest.bouncehammer.jp/modperl/a.cgi/search/recipient/user01@example.org
[ { "bounced": 1234567890, "addresser": "sender01@example.jp", "recipient": "user01@example.org",
"senderdomain": "example.jp", "destination": "example.org", "reason": "exceedlimit", "hostgroup":
"reserved", "provider": "rfc2606", "frequency": 1, "description": { "deliverystatus": 500,
"diagnosticcode": "Example1", "timezoneoffset": "+0900" }, "token": "8dbb1b9ce9cc47eb6bb1316096c858cd" } ] 
↑実際は1レコード1行で表示される

注7）

HTTPベースのAPIは，JavaScriptでも処理できるようにYAMLではなくJSONで出力しています。