bounceHammer has been EOL'ed on February 29, 2016

製品ライフサイクルの終了

2010年3月にオープンソースソフトウェアとして公開して以来、多くのユーザ様・企業様にダウンロードし、 ご利用いただきましたbounceHammerは、2016年2月29日(月)を持ちまして製品ライフサイクルの終了(EOL: End Of Life) となりました。長きにわたりbounceHammerをご使用いただき誠に有り難う御座いました。 開発元では後継となるバウンスメール解析ライブラリとして、より高精度で高速なSisimai(シシマイ) を二条項BSDライセンスで公開しています。

Sisimai
商用サポート

  • 1一式導入・設定・保守・開発の補助
  • 2独自MTA用解析モジュールの開発
  • 3個別案件の対応とメールサポート
  • 4バウンス管理・運用コンサルティング
  • 5スポット解析・解析済みデータ提供

バウンスした宛先に再送できるかどうか?

2010/11/03

バウンスした理由毎の処理

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

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

技術的な助言・サポート

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

99%: 再送信はほぼ不可能

 

次に列挙する理由でバウンスした宛先はほぼ確実に再送信が不可能と言えるものです。 できるだけ早く配信対象から除外するほうがよいでしょう。

不明なホスト(hostunknown)

宛先メールアドレスの ドメインパート(@の右側)が間違っている、ドメインが存在しない、ドメインが消滅した などの理由で、多くはメールアドレスの綴り間違いです。

Webサイトなどで登録時のメールアドレスチェックが甘い場合、 無茶苦茶なアドレスで登録されるとこのエラーが頻発します。

宛先不明(userunknown)

宛先メールアドレスの ローカルパート(@の左側)が間違っている、メールボックスが存在しないなどの理由です。

日本の携帯電話宛では宛先不明で返ってきたアドレスにメールを送り続けると、キャリア側から受信ブロックをもらうこと があるので要注意です。

85%: 再送信はかなり困難

 

次に列挙する理由でバウンスした宛先に再送信しても到達する確率はかなり低いでしょう。

日本国内の携帯電話宛配信ではフィルターによる拒否(filtered)はドメイン指定拒否や URLフィルターによる拒否を表していますので、キャリア側から受信ブロックを されないうちに配信対象から 除外したほうがよいでしょう。

フィルターによる拒否(filtered)

多くは送信した電子メールヘッダの内容によって拒否されたものです。 宛先メールアドレスのメールボックス自体は存在しますが、現在 受け取れない状態になっている、受信を拒否している状態などです。

日本の携帯電話宛ではドメイン指定拒否URLフィルターによる拒否がこれに該当します。

発信者アドレスによる拒否(rejected)

この理由でバウンスした場合、宛先メールサーバのサーバレベル(受信者単位ではなく)で Fromのアドレスが拒否されている可能性があります。

拒否される理由は、相手側が発信者をスパム送信者とみなしてサーバの設定で拒否しているか、 あるいはFromに設定しているメールアドレスのドメイン部分が名前解決できない為、存在しない ドメインからのメールは受け取らないという方針で拒否されている、が大部分です。

後者の場合は配信側のメールサーバの設定や、メールアドレスのドメインを管理している DNSの設定が正しいか確認した方がよいでしょう。

メールボックスは移動した(hasmoved)

宛先メールアドレスが別のメールアドレスに変更になった場合、このエラーが返ってきますが 滅多に見かける事はないでしょう。このエラーは メールアドレスは変更になったが自動転送はされない、 ということを意味していますので、再度配信しても宛先に到達する事はありません。

また、日本の携帯電話でユーザがメールアドレスを変更してもこのエラーが返ってくる事はありません。

セキュリティ上のエラー(securityerr)

このエラーは送信したメールの内容(ヘッダも含む)が、宛先メールサーバのセキュリティポリシーに 違反する場合に返ってくるものです。例えば送信したメールにウィルスがくっついていたり、 発信者アドレスや発信元IPアドレスがスパマー・スパム送信ホストとして登録されていたり することが考えられますが、単に接続を拒否されただけでもこのエラーになることがあります。

宛先不明(userunknown)の代替として

そう数は多く有りませんが、宛先不明(userunknown)を返すべきところを このエラーで返してくるメールサーバもありますので、このエラー理由となった場合は、 その詳細をメールログなどで注意深く調べる必要があります。

60%: 再送信が成功するかもしれない

 

次に列挙する理由でバウンスした宛先は、一時的に宛先メールボックスが受け取れない状態で あったと言えます。 一時的に受け取れない理由はさまざまですが、 しばらく時間を置いて再送信すると配信が成功する可能性があります。

バウンスしてから直後に送っても同じエラーでバウンスしてくることが多いですので、 しばらく時間をあけて再送信 する点が重要です。

メールボックス一杯(mailboxfull)

宛先のメールボックスがサーバで決められた容量を超過している場合です。 数多くメールを受けとる人がたまたまメールボックスを溢れさせた、あるいはたまたま メール爆弾の餌食になっていたという一時的な原因もありますが、メールを 受信せずに放置しているという状態もあります。

放置されている可能性もある

長期間にわたって連続的にこの理由でバウンスしてくる場合は、 宛先メールボックスが放置されている可能性が高くなります。

配送時間切れ(expired)

宛先メールサーバが応答しない、宛先メールアドレスのドメイン部分が名前解決できないなどの理由で 数時間から数日間配送を試みたが失敗した場合のエラーです。多くは宛先メールアドレスの ドメインが消滅していたり、メールサーバが停止していたりするとこのエラーになりますが、配送自体は 長くて数日間に渡って再試行されますので、何日もメールが受け取れない状態にある宛先は、既に メールサーバが止められている、サービスを終了したなどの可能性があります。

配信側のDNSやネットワークが原因

一方、配信側のDNSやネットワークの不具合によって配信できなかった場合や相手側の Firewallで接続拒否(無視)されている場合もこのエラーが返ってくる事がありますので、 バウンスした原因は配信側にあるのか宛先側にあるのか、しっかりと見極めなくてはなりません。

50%: 時間を空けて再送するとよい

 

次に列挙する理由でバウンスした場合、宛先メールアドレスに起因するのではなく、 宛先メールサーバに起因する問題によってバウンスしたものです。

多くは宛先メールサーバが一時的に外部からの電子メールを受け取れない状態 にあったためにエラーを返したという状況にあてはまりますので、 しばらく時間をおいてから再送信するとよいでしょう。

メールの量が限界(exceedlimit), メールサーバのディスクが一杯(systemfull)

宛先メールサーバのハードディスクが溢れそうになっている状態です。

これ以上メールを受け取ってもハードディスクに保存できないのでバウンスしたという解釈です。 宛先メールサーバの管理者がディスク容量を空けるか、増量すればメールを受け取ってくれる はずですので、バウンスしてからしばらく時間を空けて再送信するとよいでしょう。

メールサーバはメールを受け取らない(notaccept), 一時停止中(suspend)

宛先メールサーバが一時的に過負荷になっていたり、メンテナンス中であった ために一時的にメールを受け取らない状態によりこのエラーが返ってくる事があります。 このエラーが返ってきた場合もしばらく時間を空けてから再送信するとよいでしょう。

一方、長期間にわたってこのエラーばかり返してくる宛先は、恒久的にメールを 受け取らないようになっているかもしれませんので、その場合はそのメールサーバが 受け取るメールアドレス全てについて再送信する事を再検討する必要があるでしょう。

メーラーエラー(mailererror)

Webサイトなどでよく使われる仕組みで、メールを受け取ったらプログラムを起動する設定が されている場合にこのエラーが返ってきます。通常であれば空メールを送って何かしらの返信 が返ってくる事が想定されていますが、起動するプログラムのバグやバックエンドの 不具合・例外などで想定外のエラーが発生して発信者にプログラムのエラー内容も含めて 送信された場合、このエラーとして検出されます。

開発中のWebサイト宛に送るとよく発生するので、しばらく待ってデバッグが完了した頃に 再送信するとよいでしょう。

システムエラー(systemerror)

このエラーは宛先メールアドレスに起因するものではなく、宛先メールサーバの設定や周辺の ネットワーク環境、バックエンドでのエラーによって発生するものです。 配信側のメールサーバ設定やネットワークに不具合があっても発生します。開発元では、 宛先メールサーバの設定に問題がある場合がもっとも多く観測されました。

しばらく時間をおいて宛先メールサーバの管理者が設定を正しく修正したころに再送信するとよいでしょう。 長期間にわたってこのエラーが返ってくる場合は、メールサーバがまっとうに管理されていないかもしれません。

30%: 内容を変えて再送するとよい

 

次に列挙する理由でバウンスした場合、送信したメールの内容や形式に起因する ものとして解釈できます。宛先アドレスや発信者アドレス、発信元IPアドレスではなくメール内容 ですので、内容を変えて再送信すると成功するかもしれません。

このエラーとして検出される最も多い理由は、送信したメールが大きすぎて 相手側メールサーバが受け取らなかった場合です。

メールが大きすぎる(mesgtoobig)

相手側メールサーバが受け取れるメールの最大サイズを超過したメールを送信 しようとした場合、このエラーでバウンスします。企業などでは添付ファイルが大きすぎた というのが最も多い事例でしょう。

送信するメールサイズを小さくして再送信すると成功する可能性は高くなります。

メール形式のエラー(contenterr)

配信側メールサーバまたは相手側メールサーバが解釈できない・変換できないメール形式 で送信した場合にこのエラーでバウンスします。

近年においてはこのエラーでバウンスしてくる事はほとんどないでしょう。