メールの話題 | bounceHammer

bounceHammerは多くのPerlモジュールを必要としています。 bounceHammerが要求するPerlモジュールはcpanコマンドやperlコマンドでインストールすると/usr/lib/perl5など システムの領域にインストールされます。しかし、これらのディレクトリに書き込み権限がない場合や、bounceHammer が必要としているモジュールは一ヶ所に固めて入れたい場合、cpanmコマンドを使うとよいでしょう。

昨年、"携帯電話宛バウンスの宛先不明とドメイン指定拒否を見分ける" という記事で、携帯電話に送ってエラーで返ってきたメールのうち宛先不明とドメイン指定拒否(どちらもUnknown Userと書いているのに)をどのように見分けるか、 という方法を紹介しましたが、主にSendmail,Postfix,qmailなど著名なMTAが作ったバウンスメールのみで、最も著名なWebメールの一つであるGmailについては 言及していませんでした。

Kenichi MaehashiさんのBlogでの記事 " DoCoMo SMTP のバウンスから宛先不明とドメイン拒否を区別する (Gmail 編) - Kenichi Maehashi's Blog" で、``state の一覧があれば便利なのですが、見当たりませんでした。''と仰っていましたので、 Gmailのバウンスメールにおけるstateの値を纏めてみました。

添付ファイルを含む電子メールを送信した時に、サイズが大きすぎて宛先サーバからエラーで戻ってくる(バウンス)ことがあります。特に業務で必要なファイルを送信する時には、予めどのくらいの大きさまでのメールが送信できるのか分かっている方が合理的かもしれません。この記事ではtelnetコマンドを使って宛先サーバが受信できる最大サイズを調べる方法を説明します。

先週は携帯電話宛バウンスの宛先不明とドメイン指定拒否を見分けるという記事で、主にNTT DoCoMo宛に送ったメールがバウンスした場合、それが宛先不明なのかドメイン指定拒否なのかを簡易に目視で見分ける方法を書きました。
今回の記事は、その原理といいますか、キャリア側メールゲートウェイの仕組みを推測してみることによって、より汎用的なバウンスの見分けを試みます。

送信した電子メールがなんらかのエラーで戻ってくる事をバウンスと表現します。送信したメールが自分のネットワークのメールサーバを通り、相手側メールサーバに到達し、宛先メールボックスに配送されるまでの間、バウンスが発生するタイミングは次の3つに分類できます。

• 自分のメールサーバから送信する時に発生
• 相手側メールサーバにSMTP接続している間に発生
• 相手側メールサーバにメールを送信した後に相手側メールサーバで発生

この記事ではバウンスが発生する3つのタイミングを説明します。

日本の携帯電話、例えばNTT DoCoMo(ドコモ)にメールを送ってバウンスしてくる場合、その多くが宛先不明かドメイン指定拒否によるものです。宛先不明もドメイン指定拒否も、どちらのバウンスメールも内容はUnknown Userと書かれていて、一見しただけでは判別しにくいのですが、よく観察すると僅かな違いがあります。

bouncehammerは携帯電話宛バウンスの宛先不明とドメイン指定拒否を自動で区別して検出しますが、ここでは目視による簡単な判別方法を紹介します。
データ消失につき復元中 書き直しました(2010/11/27)

通知関係の連絡を電子メールで配信するWebサービスでは、無料でサイトが利用できるかわりに広告も表示される、 あるいは定期的に広告を含んだメールを受け取る、というユーザ側が負担すべき部分があります。 しかし、特に携帯電話では多いと思いますが、ユーザがメールアドレスを変更したり、 ドメイン指定拒否の設定解除を忘れていたりして、 配信したメールが到達できないという状態にあるユーザも多々いるのではないでしょうか。

多くのユーザは自分のメールアドレスを変更しても、登録しているサイト側で変更手続きを忘れてしまっているでしょう。 サイト運営側としては登録アドレスの変更もしてほしい所ですが、メールはバウンスしてしまうので、その旨を通知する手段 としてはユーザのログイン後の画面ぐらいしかなさそうです。

前置きが長くなりましたが、Webサービスの中にbounceHammerが解析した結果を照合する簡単な例を紹介します。 HTTP-APIはブラウザでも動作の確認ができます。管理画面(WebUI)のデモ のAPIへのリンクをご覧ください。

一般的にメールアドレスのクリーニングと言われていますが、配信した後のアドレス管理は重要です。 bounceHammerが解析した結果を配信対象であるメールアドレスと照合して、配信できないものは除外する、 この繰り返しを毎回メールを配信する前に行えば、遅延の回避やサーバの負荷軽減につながり、 合理的な配信態勢が維持できます。

ここではbouncehammerが解析した結果をYAMLファイルとして書き出して、配信対象アドレスの取捨選択 をする一例を紹介します。例として宛先不明(userunknown)とフィルターによる拒否(filtered)、 そして不明なホスト(hostunknown)でバウンスした宛先を配信対象から除外します。どのエラー理由なら除外 すべきなどの決定については、 バウンスした宛先に再送できるかどうか? を参考にしてください。

bounceHammerが検出する差戻理由(バウンスした理由・メールがエラーで返ってきた理由)はたくさんあります。 実際に解析済みデータを使って運用しているWebサイトやメールマガジンなどの配信アドレスを整理整頓する際には、 エラーになった理由によって次回の配信対象から除外するかしないかの決定をしなくてはなりません。

このエラーなら配信対象から除外すべき、という明確な答えはありませんし、サイトの運営方針にもよりますが、 ここではその判断基準となる解釈を紹介します。各項目の%は感覚的なものを示すだけの数値で明確な根拠はありません。

バウンスをどう処理すべきかという個別事例への対応、バウンス処理の技術的助言は開発元による サポート契約 にて承っておりますので、必要な方は是非ご検討下さい。