バウンスメッセージ

バウンスメッセージまたは単に「バウンス」は、電子メール システムからの自動メッセージであり、以前のメッセージの送信者に、メッセージが配信されなかった (または、その他の配信問題が発生した) ことを通知します。元のメッセージは「バウンス」されたとみなされます。

このフィードバックは即時に届く場合もあれば (ここで説明されている原因の一部)、送信システムが再試行できる場合は再試行が終了してから数日後に到着する場合もあります。

バウンスメッセージのより正式な用語には、「配信不能レポート」または「配信不能受領書」(NDR)、[失敗]「配信状態通知」(DSN) メッセージ、または「配信不能通知」(NDN) などがあります。^[1]

SMTPは30年以上の歴史を持つ成熟した技術ですが、そのアーキテクチャは通常の負荷と迷惑な負荷の両方によってますます負担がかかっています。 ^[2]電子メールシステムは、偽造された送信者がプロトコルで使用されている場合、受信者の電子メールサーバーが電子メールを拒否するという考え方に基づいて、電子メールの実際の送信者に結び付けられた評判システムによって強化されました。^[3]

そのため、ハードバウンスとソフトバウンスの2種類のメールバウンスが生まれました。^[4]メールサービスプロバイダー（ESP）は、メールをユーザーの受信トレイに送る際に、合計バウンス率を決定要因として考慮するため、どちらも送信者のIPレピュテーションに影響を与えます。簡単に言えば、合計バウンス率は、ハードバウンス率とソフトバウンス率の合計として計算されます。

ハード バウンスは永続的であり、送信者の IP の損害の点ではスコアが高くなります。ハード バウンスは、送信者のメール サーバーが、受信者が利用できない可能性が高いと判断し、今後も利用できない状態が続くと判断した場合に発生します。ハード バウンスが発生する状況としては、電子メールの受信者が次のいずれかの状況に陥った場合が挙げられます。識別子/ドメインが間違っている (電子メール アドレスまたはドメインの入力ミスなど)、またはサーバーが電子メールを受け入れなくなった場合です。この場合、バウンスした電子メール アドレスの削除は必須です。

ソフト バウンスは一時的なものです。ソフト バウンスを経験したバウンス メッセージは、別の時間に再配信される可能性があります。^[5]ソフト バウンスは、電子メールの受信者の受信トレイがいっぱいで別の電子メールを保存するスペースがない場合、または受信できる電子メールのサイズの制限に達した場合に発生します。ソフト バウンスが発生するその他の状況としては、受信者の電子メールにブロックが設定され、特定の送信者が「スパム」送信者としてマークされている場合、または特定の送信者がブラックリストに登録されている場合などがあります。さらに、受信者の電子メールが一時的に停止されている場合や、サーバー上で一時的なエラーが発生した場合も、ソフト バウンスの原因となります。

メール配信の複数の場所でエラーが発生する場合があります。送信者は、自分のメール サーバーからメッセージを送信できなかったことを報告するバウンス メッセージを受信する場合もあれば、受信者のメール サーバーから、メッセージを受け取ったものの指定されたユーザーに配信できなかったことを報告するバウンス メッセージを受信する場合もあります。サーバーが配信のためにメッセージを受け入れると、配信が失敗した場合にバウンス メッセージを配信する責任も引き受けることになります。

電子メールが宛先サーバーにアドレス (たとえば、alice@ mymail.example に送信する場合の mymail.example) 宛てに到着すると、サーバーの基盤となるハード ドライブに十分なスペースがない場合、メールデーモンが指定されたユーザーのメールボックスにメッセージを保存できないことがあります。

電子メールを送信する際、電子メールの送信元サービスが宛先アドレスに到達できない場合があります。このような場合、送信者は自分のメール サーバーからバウンス メッセージを受け取ります。メール サーバーが宛先に到達できない一般的な原因:

• 宛先アドレスを解決できません。たとえば、ドメイン名が存在しない場合などです。
• 宛先アドレスとの接続を確立できません。たとえば、IP アドレスがサーバーに割り当てられていない場合や、サーバーがオフラインの場合などです。

ユーザーは、実際には送信していないメッセージに関する誤ったバウンス メッセージを受け取る場合があります。これは、特に電子メール スパムや電子メール ウイルスのコンテキストで発生する可能性があります。この場合、スパマー (送信者) が別のユーザー (スパムの意図された受信者) 宛てのメッセージを偽造し、さらに別のユーザー (第三者) からのメッセージであるように偽造することがあります。メッセージが意図された受信者に配信できない場合、バウンス メッセージはスパマーではなく第三者に「返送」されます。これをバックスキャッターと呼びます。

library.exampleメール サーバーが、メッセージが配信できないことを知っていた場合(たとえば、Jill がユーザー アカウントを持っていない場合)、そもそもメッセージを受け入れず、したがってバウンスを送信しなかったでしょう。代わりに、SMTP エラー コードでメッセージを拒否したでしょう。これにより、バウンスを作成して配信する義務がJack のメール サーバー ( store.example ) に残ります。

バウンスは、自動応答の特殊な形式です。自動応答 (自動返信) は、受信したメールへの返信として、人間のユーザーではなくプログラムによってバウンス アドレスに送信されるメールです。

その他の自動返信の例としては、休暇メール、チャレンジレスポンススパムフィルタリングからのチャレンジ、リストサーバーからの返信、フィードバックレポートなどがあります。これらのその他の自動返信については、RFC 3834 で説明されています。自動返信は、自動返信をトリガーした受信メールに記載されている宛先に送信する必要があります。この応答は通常、空の Return-Path で送信されます。そうしないと、自動応答が何度も送信されてしまう可能性があります。^{[引用が必要]}Return-Path

は、SMTPメール配信エージェント( MDA ) (通常はメール転送エージェント( MTA )と組み合わされます)によって挿入されるReturn-Pathヘッダー フィールドとして配信されたメールに表示されます。MDA は、SMTPコマンドの逆パスを にコピーするだけです。MDA は、他の MTA によって挿入された偽のヘッダー フィールドも削除します。このヘッダー フィールドは通常、コマンドで確認された最後の逆パスを反映することが保証されています。 Return-PathMAIL FROMReturn-PathReturn-PathMAIL FROM

現在、これらのパスは通常、通常の電子メール アドレスに縮小されています。これは、古い SMTP の「ソース ルーティング」が 1989 年に廃止されたためです。歴史的背景情報については、送信者書き換えスキームMAIL FROM:<>を参照してください。パスの特殊な形式が 1 つ残っています。それは、多くの自動返信や特にすべてのバウンスに使用される 空のパスです。

厳密に言えば、空でない で送信されたバウンスはReturn-Path正しくありません。RFC 3834 では、空でない のアドレスのローカル部分 (「@」の前の左側) に基づいて誤ったバウンスを識別するためのヒューリスティックがいくつか提供されており、Return-Path自動返信を識別するためのメール ヘッダー フィールド も定義されていますAuto-Submitted。ただし、メール ヘッダーはメール データ (SMTP コマンド ) の一部であり、MTA は通常メールをDATA調べません。MTA は、アドレス (別名、 、または「リバース パス」)を含むエンベロープを処理しますが、たとえばメール ヘッダー フィールド のRFC 2822- は処理しません。これらの詳細は、 BATVなどのスキームにとって重要です。 MAIL FROMReturn-PathEnvelope-FROMFromFrom

残りの空のバウンスは、非配信レポート( NDR ) または配信状態通知Return-Path(DSN)です。DSN は SMTP サービス拡張で明示的に要求できますが、広く使用されていません。配信失敗の詳細の明示的な要求は、可変エンベロープ リターン パス(VERP)で実装されることが多くなっていますが、それらの明示的な要求はほとんど実装されていません。^[6]

NDR は基本的な SMTP 機能です。MTA が転送または配信のためにメールを受け入れると、それを黙って削除 (「ドロップ」) することはできません。転送または配信が失敗した場合は、バウンス メッセージを作成して送信元に送信する必要があります。

MDA を除き、すべての MTA はメールを別の MTA に転送します。この次の MTA は、「ユーザー不明」、「クォータ超過」などの SMTP エラー メッセージでメールを拒否できます。この時点で、送信側 MTA はメッセージを返送する、つまり発信者に通知する必要があります。拒否する MTA がなくても返送が発生する場合があります。RFC 5321 では次のように定義されています。

「SMTP サーバーがメールの中継タスクを受け入れ、その後宛先が間違っているか、または他の何らかの理由でメールを配信できないことが判明した場合、サーバーは「配信不能メール」通知メッセージを作成し、配信不能メールの送信者 (リバース パスで示される) に送信する必要があります。」

このルールは SMTP にとって不可欠です。名前の通り、これは「シンプルな」プロトコルであり、メールがブラックホールに静かに消えてしまうと確実に機能しないため、問題を見つけて修正するにはバウンスが必要です。

しかし、今日では、偽造された s を使用したスパムメールがほとんど受信されるのが一般的ですReturn-Path。その場合、MTA が送信者に通知することは不可能であることが多く、偽造されたメールにバウンスを送信すると、無実の第三者に損害を与えることになります。さらに、メッセージを拒否する(ましてやバウンスする)のではなく、黙ってメッセージを破棄するReturn-Pathことが望ましい特定の理由があります。

• ヒューリスティックにフィルタリングされたスパム。スパム フィルターは完璧ではありません。コンテンツ フィルタリングに基づいてスパムを拒否することは、フィルターを通過するコンテンツが見つかるまで、スパマーが複数の代替案を試すことができるテスト環境をスパマーに提供することを意味します。
• ウイルスとワーム。ほとんどの場合、これらは感染したマシンから自動的に送信されます。バウンスにはワーム自体のコピーが含まれている可能性があるため、ワームの拡散につながる可能性があります。

RFC 5321 のセクション 6.2 を再度引用します。

「以下のセクション 7.8 およびセクション 7.9 で説明されているように、送信者に通知せずにメールをドロップすることは、実際には許可されています。ただし、これは非常に危険であり、メールが配信されるか返送されるという長年の伝統とコミュニティの期待に反します。サイレント メッセージ ドロップが悪用されると、インターネットのメール システムの信頼性に対する信頼が簡単に損なわれる可能性があります。したがって、メッセージが深刻な詐欺または不適切であるという確信が非常に高い場合にのみ、メッセージをサイレント ドロップすることを検討する必要があります。」

送信者を検証しないのは、前述の非推奨のソース ルートがない現在の SMTP に固有の欠陥です。この問題はさまざまな提案によって解決されていますが、最も直接的なのはBATVとSPFです。

電子メールがバウンスする理由は多数あります。1 つの理由は、受信者のアドレスが誤っているか、受信システムに存在しない場合です。これは、ユーザーには不明な状態です。他の理由としては、ディスクがいっぱいなどのリソースの枯渇や、スパムフィルターによるメッセージの拒否などがあります。さらに、ユーザーが要求に応じてメッセージを「バウンス」できるMUAもあります。 ^[7]これらのユーザーによって開始されたバウンスは偽のバウンスです。定義上、実際のバウンスは自動化されており、MTA または MDA によって発行されます。

SMTPのバウンス メッセージは、ヌル送信者アドレス<>と呼ばれるエンベロープ送信者アドレスとともに送信されます。バウンス メッセージは、受信者サイトの ヘッダー アドレスとともに送信されることがよくあります。From:MAILER-DAEMON

通常、バウンス メッセージには、元の送信者がメッセージが配信されなかった理由を理解するのに役立ついくつかの情報が含まれます。

• メッセージが返送された日時、
• 返送したメールサーバーのID、
• バウンスされた理由（例：ユーザーが不明、メールボックスがいっぱいなど）
• バウンスされたメッセージのヘッダーと
• バウンスされたメッセージの内容の一部またはすべて。

RFC 3463 では、バウンス理由を示すために使用されるコードについて説明しています。一般的なコードは、5.1.1 (不明なユーザー)、5.2.2 (メールボックスがいっぱい)、および 5.7.1 (セキュリティ ポリシー/メール フィルターによって拒否) です。

管理メッセージのレポート形式は、RFC 6522 で定義されています。DSN は、次の 3 つの部分から構成されるMIME マルチパート/レポートメッセージ です。

1. 人間が読める説明。
2. 機械が解析可能なメッセージ/配信ステータス、いくつかの可能なフィールドを示す「名前: タイプ; 値」行のリスト、および
3. 元のメッセージまたはその一部を、message/rfc822タイプのエンティティとして保存します。

DSN の 2 番目の部分も非常に読みやすいです。どの MTA がどの役割を果たしたかを理解することが重要です。Reporting -MTAは DSN の作成と送信を担当します。

リモートMTAがSMTPトランザクション中にメッセージを拒否した場合、その値を報告するためにsmtpタイプのフィールドDiagnostic-Codeが使用されることがあります。3桁の数値の他に、SMTP応答には人間が読める部分も含まれています。

リモート MTA:  dns; smtp.store.example [ 192.0.2.3 ]
診断コード: smtp; 550そのようなユーザーは存在
しません        

例えば、次のように報告されることもある。

smtp.store.example [192.0.2.3] と通信中
>>> RCPT TO:<nonexistinguser@store.example>
<<< 550 そのようなユーザーは存在しません

• バックスキャッター（電子メールスパムのバックスキャッター）
• バウンス アドレス タグ検証(BATV)
• メール追跡
• 送信者ポリシーフレームワーク(SPF)
• ドメインキー識別メール(DKIM)
• 送信者書き換えスキーム(SRS)
• 簡易メール転送プロトコル(SMTP)
• 可変エンベロープリターンパス(VERP)

• RFC 5321 - シンプルメール転送プロトコル
• RFC 3461 - 配信ステータス通知 (DSN) 用のシンプル メール転送プロトコル (SMTP) サービス拡張
• RFC 6522 - メール システム管理メッセージの報告のための Multipart/Report メディア タイプ
• RFC 3463 - SMTP の拡張ステータス コード
• RFC 3464 - 配信ステータス通知のための拡張可能なメッセージ形式
• RFC 3834 - 電子メールへの自動応答に関する推奨事項
• RFC 5337 - 国際化された配送ステータスと処理通知

• 配信不能メッセージによるメール DDoS 攻撃
• Exchange Server の Microsoft DSN と NDR
• バウンスメールを理解する