師走に書いてるのですが、どこかのアドベントカレンダーの記事でもなんでもない野良の記事でありSMTP Advent Calendarがあったら十日目ぐらいの記事です。

少し前から、というか考えてみればもっと前の平成年間から「人や組織や立場や文脈によってハードバウンスの定義が違う」と思ってた話で、厳密な定義も正解も未だによく分からんって状態ではありますが「マァ人それぞれやと思うけどウチはこうですわ」って内容を書いときます。

要点とか結論

AIに完食してもらって要約を作るまでもなく、そして例によって一文も全体も長い(1.7万文字ぐらいある)ので先に要点とか書いておきますと、ハードバウンスって言葉は多義的な要素がある中でウチは少数派ながらメールアドレスが存在しないことによるバウンスだけをハードバウンスと定義してて、 ハードバウンスの扱いは戻・即・除を大原則としつつも、実際のところ日々の運用においてはメールアドレスは存在するからハードバウンスには当てはまらないものの次からメールを送らない方が望ましいケースも多々あって、それらを毒性のあるバウンスとしてライブラリ側で識別できる項目を実装したから、もう既にみんな実施してはると思うんやけど、開発者が判断基準の一つを示したから薬として効果があるうちに少しぐらいは対処しやすくなったかもしれへん気がするでって話です。

ハードバウンスの定義が分からん

僕が理解しているハードバウンスとは宛先メールアドレスが存在しないことによるバウンスであり、次に列挙するものに限定しています。

宛先メールアドレスのローカルパートが存在しない (SMTPのRCPTでUser Unknownが出た)
宛先メールアドレスのドメインパートが存在しない (DNSで一時的に引けなかったことを除く)
宛先メールアドレスは既にどこかへ移動した (拡張ステータスコード5.1.6が返ってくる・滅多に見ない)
宛先メールアドレスのドメインパートがNull MXを指している(RFC7505) *1

しかしながら、メール系の記事を読んでいると上記より広い範囲のバウンスも含んでハードバウンスと表現しているのをしばしば見かけます。

ハードバウンス・ソフトバウンスの定義

そもそもの話として、宛先メールアドレスが存在しない==ハードバウンスってのは、誰かに教えてもらったか、何処かで聞いたか何かを見たか読んだか、わりと昔に端を発している気がしてるものの何も覚えてません。

本には書いてない

「あ、メール系のO'REILLY本に書いてたんやったっけ？」で七冊ぐらいを本棚から取ってきて索引を見て探したのですが、バウンスに関して求めているような記述は特にありませんでした。

O'REILLYのsendmail 4th Editionとsendmailクックブックと電子メールプロトコルの三冊

2007年に出た本*2書いてないとなるとですよ、ハードバウンス・ソフトバウンスって言葉は何処からいつごろ現れたものか？という疑問がでてきます。上記のSendmail 4th Editionを筆頭に二冊に分かれた第三版日本語版*3に加え、Postfix実用ガイドとPostfix詳解も参照しましたがハードバウンスもソフトバウンスも単語としては見つけられませんでした。実は2010年前後に現れた単語？って気もしてきましたが、僕は少なくとも2008年の時点では知っていたので、それよりは古くからあるはずです、たぶん。

RFCにも書いてない

「もしかしてRFCで何か書いてたりするかも？」と思ったのですが、特に定義らしい記述はありませんでした。

Googleでietf.orgにHard BounceとSoft Bounceがあるかどうか確認した(2件)

複数の技術書にもRFCにも言及が無い*4ということは他のところ、僕が知らない業界や世界、例えばメール系のマーケティング業界から現れた言葉*5なのかも知れません。

みんなのハードバウンス定義

メール系の記事とかで言及されているハードバウンスは、概ね永続的(恒久的)で時間の経過とともに解決しないエラーとされているものが多いように見えますし、多数派の印象です。

冒頭で書いたとおり「人それぞれ」なんで業界や執筆者の所属や立場で変化しているケースもあるやろうし、何を指しているかが分かれば細いことは良いかなと考えています。

とは言え、SMTP応答コードの400系と500系は、それぞれ一時エラー(Temporary|Transient Error)と恒久エラー(Permanent Error)という表現があるので、単にそれらを(?:ソフト|ハード)バウンスと言い換えただけなのかもしれません。

マーケティング用語？

この記事を書くに際し改めて「ハードバウンス」で検索して20個か30個ぐらいのページを廻ってきたのですが、マーケティング関係の情報共有を主としている記事が殆どでした。となるとですよ、ハードバウンス・ソフトバウンスって表現はマーケティング業界*6 から現れたもので、そもそもの意味が永続的エラー・一時的エラーを示すものである可能性も考えられます、たぶん。

僕と同じハードバウンスの定義

もしかして僕の定義は世界で僕しか使ってないとかる？と心配しつつ世の中ではハードバウンスをどう定義しているかを調べる過程で、自分と同じく「宛先メールアドレスに関するバウンス」と述べているSendGridさんの記事を見つけました、安心感が高まります。 Microsoftさんの記事には明確に連絡先リストに関する問題(ハードバウンス)と書かれています、安心感が高まります。

やはりハードバウンスを宛先メールアドレスの存在に関するバウンスとしているのは少数派みたいで、これはもう単語として現れた当時の用例を見て推測するしかないかなぁってとこです。

ハードバウンス・ソフトバウンスの出自

出自を辿るにあたり、Googleとか検索エンジンで出てくる結果で遡れるのって古くても2000年あたり？で高が知れてますし、閉鎖で失われた数多のウェブサイトからは探せないとなると、今も残っていて参照も可能な当時のNews Groupを漁るのが妥当です。

comp.mail.sendmail

だいたいこういう言葉はアメリカを筆頭に外国から来るもんやろ？ってことで、仕事でメールサーバーの世話をするようになった頃から購読していた comp.mail.sendmailの中で探したところ何件かメールがエラーになる文脈でハードバウンスまたはソフトバウンスって表現が使われているのを見つけました、朗報です。

1995年10月7日(平成7年)

探した中では30年前の投稿が最古でした。メール系ニュースグループではなくcomp.database.informixなんですが、全体検索で最古のものが引っかかったので入れておきます。

ハリケーンの影響で停電してサーバーが一時的にオフラインって話に「ハードバウンスってのはMailer-Daemonから来る配送できなかったってメッセージやで」と書いてあり、 Mailer-Daemonからくる遅延通知との対比でバードバウンスという表現が使われています。

https://groups.google.com/g/comp.databases.informix/c/8HP0_vUY-bk/m/uFjpMvte5f0J の抜粋

当時は家と学校の往復ばっかりで、たしかDOORS って雑誌を読んだ覚えがありインターネットの存在はギリギリ知っていた程度でして、メールシステムとかバウンスとか難しいことは当然しらない筈です。なので定かではないにしろ、当時って今ほどバウンスの種類が多種多様ではなかったでしょうし、だいたいMailer-Daemonが何かを返してきたときって遅延通知を除いて宛先不明の類いが大半であったと推測されますので、30年前の時点ではハードバウンスが指すものは宛先メールアドレスが存在しないことを示すと言えなくもない気がします、たぶん。

1998年4月8日(平成10年)

Permission Deniedってエラーをどうにかしたいって話にハードバウンスとソフトバウンスの双方が出てきます。内容は「書き込み先のメールボックスがロック中やとPermission Deniedでハードバウンスが返ってしまうんやけど、これをエラーを直ぐに返さないソフトバウンス (つまりキュー内で遅延扱いして)処理したいねん」って話です。

https://groups.google.com/g/comp.mail.sendmail/c/CUMzKDSX9sg/m/AUq5V5YskV0J の抜粋

1995年の用例と同様に、ここでもMailer-Daemonが配送失敗のバウンスメールを返すかどうかという文脈で使われていると読めますが、エラーの内容からして宛先不明などではなくシステム側の一時的なエラーなので、メールアドレスの存在とは別のハードバウンス、つまり恒久エラー全般を指していると推測されます。

なお、この手の問題を解決する定石は、失敗したら || exit 75でバウンスしないようにすれば質問者の意図した動作になるはずです、たぶん。

1998年8月24日(平成10年)

Quotaを設定したんやけどハードバウンスさせたいケースがあるって話です。複数の受信者宛メールが一部のMailbox Fullなメールボックスがあるために遅延して同じ人に何回もメールが行ってしまうので困っているそうで、ここでのハードバウンスはMailbox FullなバウンスメッセージをMailer-Daemonから送信者に返したいんやけど？と読めます。

この用例においても上記のそれと同様に宛先メールアドレスの存在とは別の、単にMailer-Daemonが配送失敗の旨を伝えることを指してのハードバウンスです。

2000年6月21日(平成12年)

ソフトバウンスもハードバウンスも区別せずうまいことPostmaster宛メールを処理するアプリケーションってない？って質問です。で、その回答もまた興味深くて「バウンスにソフトもハードも無いで？」と言ってはって「やっぱり？確かにそうやんな」と思いました。

https://groups.google.com/g/comp.mail.sendmail/c/VmpVjp4W8XA/m/FwCHxRbH_HEJ の抜粋

25年前の時点で、バウンスの種類が今よりも少ない時代においてすら解釈がばらついているわけですよ。

2001年12月17日(平成13年)

エンベロープのFromで拒否されたソフトバンスなんやけど？って話です。 なんと553 5.7.1の恒久エラーをソフトバウンスと認識している用例で、これは僕のハードバウンス定義と一致、つまり宛先メールアドレスの存在に関係のない理由でバウンスしたからハードバウンスとして扱わない、と等しいって言うと過言かも知れないですが、かなり近く実質的に同義と見做せそうな気がする認識です。

https://groups.google.com/g/comp.mail.sendmail/c/mtxM9SuHevc/m/et6xzELRqMoJ の抜粋

この投稿に対して「それはソフトバウンスではない」「ハードバウンスですよ？」みたいな回答も付いてないので、少なくとも上述の認識は異常なものではないと推測できます、たぶん。

2014年10月20日(平成26年)

リンクだけ載せておきますが、恒久エラーをハードバウンスと表現している用例です。

Hard BounceとSoft Bounceで検索してこの程度の数*7しか一致しないので、 ハードバウンスやソフトバウンスは表現としてはあまり一般的ではない可能性があります。

「ソフトでもハードでも」

余談なんですけど、バウンスメールの話やのにソフトとかハードって単語を何回も何回も出すと子供の頃にテレビから流れてた目玉専用高度管理医療機器装着時でも使用可能な点眼薬のCM曲が勝手にアタマの中で再生されるので止め方が知りたいです。

fj.mail.system.sendmail

日本語で流れてきていたfj.mail.system.sendmailにはバウンスに関してハードとかソフトとかって表現は何も見つからずで、comp.mail.sendmailも数件しか一致する投稿が無く、活発に流れていた期間において技術者の間ではハードバウンスやソフトバウンスって表現は一般的ではなかったのかも知れません、たぶん。

ハードバウンス何も分からない

いやもうなんかNews Groupの投稿で数少ない用例を調べた限り、20世紀末の時点でなんか人によって意味が違うし、結局のところ初登場時の用法も原義もよく分からんしホンマなんやねんもう💢って感想です。

あるのがいけない

「コンタクトレンズやあるまいし、そもそもバウンスにハードもソフトもあるかよ」と思いつつ調べて調べて comp.mail.sendmailの投稿でも同じことを言う人が居てはったわけですし、いろいろ思い返せば、過去の経験や業務において、メールサーバーに流れてくるキューを捌いてエラーで返ってきたバウンスメールは、 SMTP応答コードと拡張ステータスコードとエラーメッセージを確認して内容に従ってメールサーバー側で何かしらの対応をするぐらいでした。なのでバウンス自体をハード・ソフトで分けると言う意識もなく、言葉としては知っていても気にしたことはないと言えるぐらいの存在でしたし。

そう考えると多義的な単語としてあるのがいけないって結論になります。

ただ、わりと使われている単語なので完全に無視するのもアレですし、とは言え言葉として発する・聞いて理解する際に解釈や認識の不一致が起きるかも知れないので、出自がどうであれ、現代においても解釈にバラつきがある以上はソフトバウンスとハードバウンスって単語は口に出しにくい気がします。

もちろん、僕の目が節穴で僕が知らないまま何年も過ごしていただけで、実は宛先メールアドレスが存在するか否かを示す別の単語は別にあって昔から使われている可能性もありますが。

Postfix実用ガイドとPostfix詳解とsendmail 8.13 Companionの三冊にも載ってなかった

ハードバウンスは戻・即・除

言葉の出自や元々の意味は結局のところ分からず仕舞いですが、冒頭で書いたとおり「他所さんのことは知らんけど、うちのハードバウンスは宛先メールアドレスの存在に関係したものです」という立場なので、それを前提に続きを書きます。

大原則としてハードバウンスに対する行動は、発生したら宛先メールアドレスを配信対象から即時除外すべきもの、つまり戻・即・除(レイ・ソク・ジョ)*8です。

ハードバウンスを分類する

実は既にビシャッとした分類、あるいは使い分けや別の呼び名が存在するのかもしれませんが、見つけられてないので自分で分類しました。 A<B<Cで、CがBを、BがAを内包しています。

A. 原理的ハードバウンス

僕が使う「ハードバウンス」は正にこれで、宛先メールアドレスが存在しているかどうかに主眼を置いたハードバウンスです。冒頭で書いたとおりSMTPで拡張ステータスコードが5.1.1や5.1.6など明確に宛先が存在しないという応答が得られるものであり、あるいはNull MXが設定されていて明示的なメールを受け取らない意思が技術的に確認できるものです。

   ----- The following addresses had permanent fatal errors -----
<kijitora@example.org>
    (reason: 550 Host unknown)

   ----- Transcript of session follows -----
550 5.1.2 <kijitora@example.org>... Host unknown (Name server: smtp24.example.org: no data known)

送信過程の順番で並べると次のようになります。

信元MTA
- (1) 宛先メールアドレスのドメインが存在しない・MXもAも引けない
  - 550 5.1.2 Host unknownでバウンスする
  - あるいは名前解決がTimeoutになったことでバウンスする
- (2) 宛先メールアドレスのドメインはMXに0 . (Null MX)を設定している
  - ドメインは存在するが全てのローカルパートが存在しない
宛先のMTA
- (3) 宛先メールアドレスはRCPTコマンドで550 5.1.1 User unknownを返す
- (4) 宛先メールアドレスはRCPTコマンドで550 5.1.6 The recipient has movedを返す

SMTP関連のRFCで述べられている配送先であるメールアドレス自体が存在しないことを示す拡張ステータスコードを伴って返してくるので、 実在性ハードバウンスとも言えるでしょう。

B. 運用的ハードバウンス

これは宛先メールアドレスのメールボックスへ到達できるかどうかを主眼に置いたハードバウンスです。実際の運用で必要なのはこの部分、宛先メールアドレスが存在しているのは大前提で、メールがその先のメールボックスへ届くかどうかが重要なので 到達性ハードバウンスと言ってもよいでしょう。

前述のA(実在性ハードバウンス)に加えて、主に以下のようなバウンスが到達性ハードバウンスに分類されます。

恒久エラーのMailbox Full: 552 5.2.2とかで返ってくる
- Gmailは長期間メールボックスが一杯の状態で放置しているとこれを返してくる
Account disabledとかInactiveとかメールボックスが使われていないことを示すバウンス
かつて携帯電話メールアドレスで返ってきてたドメイン指定拒否・受信によるバウンス
- NTTドコモはSMTPのDATAに対して550 Unknown userを返してきてたのでエラー文言は信用ならない
RCPTに対するリレー拒否応答によるバウンス

   ----- Transcript of session follows -----
... while talking to mfsmax.docomo.ne.jp.:
>>> DATA
<<< 550 Unknown user *****@docomo.ne.jp
554 5.0.0 Service unavailable

--2A18Nuql028789.1667291036/nijo.example.jp
Content-Type: message/delivery-status

Reporting-MTA: dns; nijo.example.jp
Received-From-MTA: DNS; localhost
Arrival-Date: Tue, 1 Nov 2022 17:23:25 +0900

Final-Recipient: RFC822; *****@docomo.ne.jp
Action: failed
Status: 5.2.0
Remote-MTA: DNS; mfsmax.docomo.ne.jp
Diagnostic-Code: SMTP; 550 Unknown user *****@docomo.ne.jp
Last-Attempt-Date: Tue, 1 Nov 2022 17:23:56 +0900

RFC3463 Section 3.3 Mailbox Statusに書いているとおり、存在しているけど届けられないX.2.Zの拡張ステータスコードを伴って返ってくるものが主体です。

C. 対比的ハードバウンス

これは近現代のマーケティング業界の記事で出てくるハードバウンスを指す分類のつもりです。上述のとおり多数派であると認識したそれぞれの記事ではハードバウンス==永続的、ソフトバウンス==一時的と書かれています。この等式を愚直に解釈すればSMTP応答コードが500系または拡張ステータスコードが5系であるものは全てハードバウンスとなりますが、実際の運用では500系で返ってくる「メールのサイズが大きすぎる」や「スパム判定された」や「DMARCの不備」などはハードバウンスと分類しても、そのバウンスで発生した宛先メールアドレスをリストから除外 *9することはしないでしょう。

スライドにはsoft bounceを400系エラー、hard bounceを500系エラーと書いてた上にハードバウンスは発生したら直ぐに宛先をリストから削除しろって話があったけど、そういう定義と対応やとGoogleの5.7.27とかで困ることになると思う、たぶん。
— ネコ物質¹³⁰³¹ (@azumakuniyuki) October 8, 2024

極僅かでしたが、News Group内で使われた20世紀末あたりならバウンスの種類も少ないので、恒久エラーのほぼ全ては宛先メールアドレスが存在しないことによるバウンスであると確定しやすかったはずですし、 500系エラーは全て宛先リストから除外しても大きな問題にはならなかったと考えられます。

よって、永続的なエラーか否かのざっくりとした分類であり、宛先メールアドレスをリストから除外するかどうかの判断から離れたハードバウンスです。 伝統的ハードバウンスや本質的ハードバウンスとも言えますが、当初から恒久エラーか一時エラーかの区別や別表現であったならば、単に無印のハードバウンスで良いでしょう。

本文ともSMTPとも全く関係ない別居しているうちのネコ殿と同居している頃の画像を出したのは本文が長すぎて「ここからやっと本題ですよ」の看板的な役割を担ってもらうのネコ殿

ハードバウンスとソフトバウンスの間

掲題どおりここでやっと本題です。

前置きが一万文字もあって正気を疑う構成かもしれないのですが、長いので二部作に分割しようかとも思いましたが現代ではAIが読んで要約できますし、長い一文ばかりで書かれた長い文章をAIがちゃーんと読めるのかどうか知りませんが、今日のAIが読めなくても明日のAIは読めるかも知れませんし、そもそも冒頭で要約と結論を書いてますので大丈夫です、たぶん。

シシマイの実装におけるハードバウンス

実はですね、僕はバウンスメールをいい感じに読んでうまいこと構造化するSisimaiっていうライブラリを開発してまして OSSとして公開もしているので聞いたことがある人も居てはるかもしれませんが、出力するデータの一つに"hardbounce": true|false (1|0)ってのがあります。文字通りハードバウンスならtrueになる項目です。

前置きの中で単語として使いにくい雰囲気はあるとか言いながら実装した項目名として使ってるんですが、マァみんな使ってる感じの単語やし、意味するところにバラつきはあるものの指し示していることの概念は把握しやすいかな？って考えに基づきます。

この実装におけるハードバウンスは上述のメールアドレスが存在するかどうかに主眼を置いた原理的ハードバウンスです。よってバウンスメールの解析で得られたhardbounceがtrueか1であれば、 戻・即・除*10の掟に従い宛先メールアドレスをリストから削除するのが妥当です。

原理的ハードバウンスでは不十分

上述のとおり、Sisimaiではバウンスメールを読んで送ろうとした宛先メールアドレスが存在しないものならば"hardbounce": trueとしています。しかしながら、現代においては到達性に主眼を置いた運用的ハードバウンスも考慮する必要があり、宛先のメールボックスへ配送できないものは配信対象から除外する必要があります。

レピュテーションを筆頭に、現代においては送信者の振る舞いや送ったメールが読まれているかどうかが重要な指標になっていて、 Sisimaiの出力における分類ではハードバウンスに相当しないものの、実質的にハードバウンスとして扱う必要があるバウンスも幾つか存在します。

ちょっと前にTwitterでたくさん流れてきたヒゲ眼鏡のお兄さん画像を思い浮かべながら ハードバウンスとソフトバウンスの間には、宛先メールアドレスは存在するんやけど二度と送らない方が良い宛先なバウンスがたくさんあると念頭に置いてもらえば理解の助けになるかもしれません、たぶん。

メールの送信頻度による

従来は、どれを実質的なハードバウンス(到達性に欠ける)とするかは、メールを配信する頻度が組織によって異なりますので、運用側の判断でやってもらっていました。実際の業務でもお客さんの環境における配信頻度やメールの特性を聞いて除外判定に至る基準を作ってました。

一つ具体例を上げるとMailboxFullの扱いです。その多くは400系エラーで戻ってくるのですが、10回を超えてMailboxFullであれば全く読まれていないと判断して配信対象から除外するのが妥当です。

しかし、毎日メールを送っているところであれば10回は10日ですが、一週間に一回しか送ってないところでは10回は10週間(二ヶ月半ぐらい)です。宛先メールアドレスの受信量が分からない以上、前者なら10回10日は短すぎるかもしれませんし、後者なら10回二ヶ月は長すぎるかも知れません。

Toxic

一方で、上述のMailboxFullで例示するように組織によって異なる基準もあれば、共通するであろう基準もあります。 500系エラーで返ってきたMailboxFullは長期間にわたって満室状態であったからメールボックスプロバイダが恒久エラーに遷移させたので、送信者側でも宛先リストから除外すべきと判断が出来ます。

このようにメールの配信頻度に依存しない非ハードバウンス(そして配信対象から除外するのが望ましい)を示す指標としてToxicを、この前リリースしたSisimai 5.5.0にて試験的に実装しました。

Toxicは毒性を表す単語で、当該バウンスを放置すると毒として配信リスト全体を蝕み送信者のレピュテーションを低下させる危険性すらあるので、除外が望ましい宛先メールアドレスを識別できる薬として効果があるかも知れない、って感じの命名由来*11です。

なお、Toxicの値はあくまでも一回のバウンス、単体のバウンスメールだけで決定しています。よって前述の送信頻度や組織固有の事情を考慮してバウンスの発生履歴データベースなどから総合的に判断する運用を平行して継続するのが妥当です。

"toxic": trueの具体例

現在の実装における具体例をあげます。

原理的ハードバウンスの全て

Sisimaiの検出するバウンス理由においては以下の三つか四つです。毒的に言えば直ぐに配信対象から除外すべきものです。

Host Unknown
User Unknown
Has Moved
Not Accept ただし500系に限定される

Feedbackの一部

バウンス理由がFeedbackになっているものでFeedbackTypeの値が明確に苦情(abuse)や詐欺の疑惑報告(fraud)や購読解除(opt-out)を伝達している場合、その宛先メールアドレスには再送すべきではないと判定しToxicにtrue(1`)を入れます。

ハードバウンスの扱いではありませんが、毒的に言えば可及的速やかに配信対象から除外すべきものと言えます。

Mailbox Full 500系に限定

これは前述の具体例であげたとおりです。以降のバウンス理由は、毒的に言えばなるべく早く、かつ他の組織固有の基準と合わせた総合的判断で配信リストから除外するのが望ましいものです。

Filtered

現代ではもうあまり見かけませんが、携帯電話宛でのドメイン指定拒否はFilteredという理由で検出され、これは原理的ハードバウンス(実在性)の扱いにはなりません。ただ、ドメイン指定拒否された宛先というのは明示的に受け取らない意思を示しているので、二回目以降は送信しないことが妥当で宛先リストから削除すべきものです。

DATAコマンドの応答でUser Unknown

このバウンス理由は大雑把に言えば エラーメッセージは宛先不明と言っているがエラーを返したSMTPコマンドはDATAであり*12 確実に存在しないメールアドレスとは断定できないという性質のものです。

そもそも携帯電話宛メールがドメイン指定拒否で返ってきた場合、その宛先アドレスを配信リストから除外しないと比較的短時間のうちにキャリア側SMTPサーバーから接続を拒否されるような事態を招いていました。ただ、割合としては少なかったのですが、ユーザーが意図せず、あるいは設定を間違えて拒否したことにより「なんか最近メールが来ないんですけど？💢」って問い合わせて来るケースもあったので、送信者側としては扱いにくい面倒なバウンスでもありました。

Suspend

エラーメッセージにInactiveやDisabledなど、アカウントが存在するが使用されていない・システムによって削除対象になっているアドレスはSuspendという理由で検出されます。嘗ては携帯電話のau(@ezweb.ne.jp)宛で料金未納によって止められているユーザーのメールアドレスに送ったときぐらいしか見かけませんでしたが、近年では一般的なメールボックスプロバイダでもチラチラと見かけるようになりました。

これも原理的ハードバウンス扱いでは無いのですが、活動していないことが明白なメールアドレス宛には二度と送るべきではないと言えます。

No Relaying

NoRelayingは、現代においてオープンリレーなメールサーバーはほぼ存在しないはずですが、相手側サーバーの立場で見れば、オープンリレー可能なサーバーを探している通信・送信元であると見做されレピュテーションの低下を招く危険性が高いと言えます。

NoRelaying(リレー拒否)なバウンスが発生する流れは以下のようなものが多く観測されます。

1) example.co.jp が或るメールホスティングサービスと契約する
- example.co.jp IN MX 10 そのメールホスティングのサーバー な状態
- この状態の時に各メールマガジンなどを購読し始める
2) 当該ドメインが(1)のメールホスティングを解約する
- 会社の合併とか社名変更によるドメインの変更とかいろいろ
3) example.co.jp のMXレコードは変更されないまま放置される
4) 当該メールホスティングはexample.co.jpを受け取らなくなってる
5) (1)の状態のときに購読したメールマガジンの購読解除もされてない
6) リレー拒否エラーNoRelaying が発生する

以上の理由により、500系エラーのNoRelayingは再送すべきではない宛先であると判定しToxicにtrue(1)を入れます。

仕様変更の可能性

実際のところはエラーになった際のSMTPコマンドCommandを見たり応答コードReplyCodeや拡張スタータスコードDeliveryStatusなどで複合的に判断しているので、細い点が気になる方はソースコード(GoよりPerlの方がバウンス理由を文字列で直に書いているので読みやすいかも)を見てください。

現在は真偽値を入れていますが、最初にスパムスコアみたく点数制にしようかな？とチラッと思ったりしましたし、発信者のFrom(エンベロープもヘッダーも)で拒否してくるケースも配信対象から除外した方が良い？どうかな？んー、と検討していますので、もしかすると僕の気まぐれと思いつき、あるいは運用において僕が不便やと思ったら、真偽値をやめて4ビットぐらいの小さい整数を使ったフラグに変える可能性はあります、たぶん。