ソフトバウンス・ハードバウンス

Adobe Campaign(以下「Campaign」)におけるメールのバウンスについて、本連載第1回・第2回と「同期」「非同期」という観点から見てきました。しかし一般には、バウンスを種類に分けるとすると次の２つがあげられるでしょう――すなわち「ソフトバウンス」「ハードバウンス」です。今回はソフト・ハードという切り口でCampaignバウンスの世界を攻めていきましょう。語り口はソフトでも、中身はハードだよ！

配信ログの検証

ソフトバウンス・ハードバウンスの違いは、ごくごくざっくり言うならば、前者は送信したメールの「一時的」エラー。後者は「恒久的」エラーです。ではCampaignの世界では何がそれらに当たるのでしょう。
クライアントコンソールで、「管理」>「キャンペーン管理」>「配信不能件数の管理」>「配信ログの検証」を見てください¹。これは製品標準スキーマ「nms:broadLogMsg」の画面。宛先メールサーバーからのSMTPレスポンスを分類したものです:

「エラータイプ」が件のソフトバウンス・ハードバウンスの別。「理由」がおおまかなエラー内容で、「テキスト」は詳細なエラーメッセージです。
Campaignがメールを配信して宛先サーバーからのSMTPレスポンスを受信すると、その本体メッセージをこの「テキスト」と照合します。その動きを具体例で追ってみましょう:

Campaignから「unknown@adobe.test」というアドレスへメールを送付しました。そのときのmtachild冗長ログの一部が上図です。
宛先ドメイン「adobe.test」には「unknown」というアカウントは存在しません。怒った宛先メールサーバーは、受け取れない旨のSMTPレスポンスを返してきます。赤枠で囲った行です。「No thank you」とか「Forgery」とかいちいちむかつきますね。しかしCampaignサーバーは冷静に、そのレスポンステキストを「配信ログの検証」と突き合わせます。検索してみると:

ありました。テキストが図の赤枠と一致しますね。そしてエラータイプはハード。というわけで、「unknown@adobe.test」に対する配信結果はハードバウンス、という判定になります。

配信不能件数およびアドレス

ハードバウンス、と判定されると何が起こるでしょう。「強制隔離」されます。コロナ禍のご時世にいやな言葉ですが、Campaignの世界ではどういう意味かというと、そのアドレスにはもう二度とメールを送らない、ってこと。厳しいですね。だから「ハード」なのです。
またクライアントコンソールで見てみます。「管理」>「キャンペーン管理」>「配信不能件数の管理」>「配信不能件数およびアドレス」と進んでください。製品標準スキーマ「nms:address」の画面です:

さきほどの「unknown@adobe.test」がありますね。ハードバウンスと判定されたことによってこの「配信不能件数およびアドレス」にステータス「強制隔離」として登録されたのです。すると、以降のメール配信はこのスキーマを参照し、「強制隔離」された「unknown@adobe.test」を配信対象から排除します。こうして、ハードバウンスのアドレスにはもうメールが送られなくなるのです。

ではソフトバウンスだと？　やはりこの「配信不能件数およびアドレス」に登録されます。しかし決定的にちがう点があります。ハードバウンスは一発アウトで「強制隔離」とされ、それっきりメールが送られなくなりますが、ソフトバウンスだと猶予があるのです。再び「配信不能件数およびアドレス」で具体例を見てみましょう:

「unreachable@neolane.test」というアドレスが「mailbox unavailable」というエラーでソフトバウンスです。「エラー数」が4となってますね。ということはこのアドレスは、これまでにもすでに3回、ソフトバウンスだったのです。冒頭でソフトバウンスは「一時的」エラーと言いました。「一時的」とは、いつかは不達状態が直って届くかもしれないということ。なので、ハードバウンスのように1回であきらめず、また出してみるのです。

とはいえ、何度出してもだめなら、いっそあきらめたほうがいい。というわけで、5回ソフトバウンスが続くと、ハードバウンスと同様「強制隔離」送りです:

「mboxfull@adobe.test」というアドレスはメールボックス容量超過が5回続いたため「強制隔離」となりました。こうなると、たとえワークフローで配信対象に選ばれたとしても、排除されてしまいます。

そうはいうものの、メールボックス容量超過だったら、そのひとが気がついて解消してるってこともありそうですよね。というわけで、ソフトバウンスでもメールボックス容量超過だけは、30日たつと解除されてまた配信が再開されることになっています。上の「mboxfull@adobe.test」も30日後こうなりました:

ステータス「強制隔離」が「有効」になり、「エラー数」が0にリセットされています。これで「mboxfull@adobe.test」へは再び、配信が送られるようになりました。

ただし、メールボックス容量超過に対するこの扱いはあくまで例外です。その他のソフトバウンスは、5回で強制隔離のまま、解除されることはありません。――というように、バウンス・強制隔離・解除は、個別に細かいルールが設定されています。網羅的な説明はヘルプ記事を参照してください:

https://experienceleague.adobe.com/docs/campaign-classic/using/sending-messages/monitoring-deliveries/understanding-delivery-failures.html?lang=ja#delivery-failure-types-and-reasons
https://experienceleague.adobe.com/docs/campaign-classic/using/sending-messages/monitoring-deliveries/understanding-quarantine-management.html?lang=ja#removing-a-quarantined-address

配信パフォーマンスへの影響

さすがCampaign、いろいろ考えてくれてんじゃん。安心! おまかせ!! ――喝!!! 甘えてんじゃありませんよ。バウンスを放置しておくと恐ろしいことになるのです。

実例をお目にかけましょう。まずバウンスでない正常なアドレス10000件に対して配信してみます:

開始20分でほぼ送りきっちゃってます。これが、10000件のうち1%の100件がソフトバウンスだったらどうなるでしょう:

おおお、1%のソフトバウンスのために2時間半もかかっちゃいました²! しかも注目すべきは、ピーク時スループットが30000/hほどのこの環境で、エラー(バウンス)のための通信が正常分の倍も占めちゃってます(上側グラフの午後3時台)。わずか1%のソフトバウンスのためにですよ。しかもこれは検証環境のため他に何も動作していない状況でしたが、現実の商用環境だとしたら他の配信とかも動いてるはずで、パフォーマンス悪化はより深刻です。

現実にもメールアドレスの誤入力とかけっこう多いので³、バウンス1%なんて普通にある状況です。っていうか無頓着でいたら1%なんてレベルじゃ収まりません。配信パフォーマンスを維持するには、バウンスを管理する「配信不能件数およびアドレス」のメンテナンスが不可欠なのです。ビジネス状況に応じいろいろ要件があると思いますので、Adobe担当者へご相談ください。

ソフトバウンス・ハードバウンスをめぐってお話しましたが、いかがでしたか。ハードっていうと厳しくてソフトっていうと優しいのかな、って思っちゃいますが、ソフトは届く見込みがなくても送り続けちゃうという意味で、むしろ凶悪といえます。ソフトに見えても中身はやばい――なんてコンピューターも人間もいっしょだね、としみじみ思う跡部官辺がお届けしました!

本稿の内容は筆者のオンプレミス型デモ環境(Adobe Campaign Classic 9032@3a9dc9c・レガシーMTA)上で実施した検証に基づきます。別環境における同様の動作を保証するものではありません。またデータは架空のものであり、既存の配信や実在の組織とはいっさい関係がありません。

本連載では、オンプレミスのレガシーMTA環境を前提としています。Adobeマネージド環境の多くではエンハンスドMTAへ移行しており、「配信ログの検証」は使用されません。 ↩
この結果もレガシーMTA環境特有のものです。エンハンスドMTA環境では、中央サーバーにメールを渡すと送信成功状態になるため、配信スループットグラフ自体が意味をなしません。その意味で本連載第1回で論じた同期バウンスも存在しなくなります(いったん送信成功状態になるためバウンスがすべて非同期になる)。本連載ではCampaignメール機能の基本を理解するためレガシーMTAに限定して説明しています。 ↩
誤って存在しないドメイン名を入力した場合など、未来永劫届かないのですが、ドメイン名エラーはソフトバウンスです。DNSエラーで一時的にドメイン名を解決できないという場合もあるからです。 ↩