2010年3月にオープンソースソフトウェアとして公開して以来、多くのユーザ様・企業様にダウンロードし、 ご利用いただきましたbounceHammerは、2016年2月29日(月)を持ちまして製品ライフサイクルの終了(EOL: End Of Life) となりました。長きにわたりbounceHammerをご使用いただき誠に有り難う御座いました。 開発元では後継となるバウンスメール解析ライブラリとして、より高精度で高速なSisimai(シシマイ) を二条項BSDライセンスで公開しています。
電子メールやSMTP、メールサーバの話題やbounceHammerの簡単な使い方などいろいろ
昨年、" 携帯電話宛バウンスの宛先不明とドメイン指定拒否を見分ける " という記事で、携帯電話に送ってエラーで返ってきたメールのうち宛先不明とドメイン指定拒否 (どちらも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つに分類できます。
この記事ではバウンスが発生する3つのタイミングについて説明します。
日本の携帯電話、例えばNTT DoCoMo(ドコモ)にメールを送ってバウンスしてくる場合、 その多くが宛先不明かドメイン指定拒否によるものです。宛先不明もドメイン指定拒否も、 どちらのバウンスメールも内容はUnknown Userと書かれていて、一見しただけでは判別しにくいのですが、 よく観察すると僅かな違いがあります。
bounceHammerは携帯電話宛バウンスの宛先不明とドメイン指定拒否を自動で 区別して検出しますが、ここでは目視による簡単な判別方法を紹介します。
通知関係の連絡を電子メールで配信するWebサービスでは、無料でサイトが利用できるかわりに広告も表示される、 あるいは定期的に広告を含んだメールを受け取る、というユーザ側が負担すべき部分があります。
しかし、特に携帯電話では多いと思いますが、ユーザがメールアドレスを変更したり、 ドメイン指定拒否の設定解除を忘れていたりして、 配信したメールが到達できないという状態にあるユーザも多々いるのではないでしょうか。
ここではWebサービスの中でbounceHammerが解析した結果を照合する簡単な例を紹介します。
一般的にメールアドレスのクリーニングと言われていますが、配信した後のアドレス管理は重要です bounceHammerが解析した結果を配信対象であるメールアドレスと照合して、 配信できないものは除外する、この繰り返しを毎回メールを配信する前に行えば、 遅延の回避やサーバの負荷軽減につながり、合理的な配信態勢が維持できます。
ここではbounceHammerが解析した結果をYAMLファイルとして書き出して、 配信対象アドレスの取捨選択をする一例を紹介します。
bounceHammerが検出する差戻理由(バウンスした理由・メールがエラーで返ってきた理由)は たくさんあります。
運用しているWebサイトやメールマガジンなどの 配信アドレスを整理整頓する際には、エラーになった理由によって次回の配信対象から 除外するかしないかの決定をしなくてはなりません。 ここではその判断基準となる解釈を紹介します。
BOUNCEHAMMER.JP |
Copyright 2009-2016 Cubicroot Co. Ltd.
(Kyoto, Japan) All Rights Reserved.
Powered by Linode - Xen VPS Hosting.
Blue Retro Rusted Grunge Icons by Icons Etc.