Loading article…
バウンスメッセージ、または単に「バウンス」とは、電子メールシステムから送信される自動メッセージで、送信者が以前に送信したメッセージが届かなかった（または何らかの配信上の問題が発生した）ことを通知するものです。元のメッセージは「バウンスした」と言われます。
このフィードバックは即座に得られる場合もあれば（ここで説明した原因の一部）、送信システムが再試行できる場合は、再試行が終了した数日後に届く場合もある。
バウンスメッセージのより正式な用語には、「配信不能レポート」または「配信不能受領書」(NDR)、[配信失敗]「配信状況通知」(DSN) メッセージ、または「配信不能通知」(NDN) などがあります。[ 1 ]
SMTPは30年以上の歴史を持つ成熟した技術ですが、そのアーキテクチャは通常の負荷と迷惑な負荷の両方によってますます負荷がかかっています。[ 2 ]メールシステムは、メールの実際の送信者に関連付けられた評判システムによって強化されており、プロトコルで偽の送信者が使用されている場合に受信者のメールサーバーがメールを拒否するという考えに基づいています。[ 3 ]
そのため、ハードバウンスとソフトバウンスの 2 種類のメールバウンスが作成されました。[ 4 ]どちらも送信者の IP レピュテーションに影響を与えます。なぜなら、メール サービス プロバイダ(ESP) は、メールをユーザーの受信トレイに振り分ける際の決定要因として総バウンス率を考慮するからです。簡単に言うと、総バウンス率はハードバウンス率とソフトバウンス率の合計として計算されます。
ハードバウンスは永続的なエラーであり、送信者のIPアドレスへのダメージという点ではより深刻な問題となります。ハードバウンスは、送信者のメールサーバーが受信者が応答不能である可能性が高く、今後も応答不能状態が続く可能性が高いと判断した場合発生します。ハードバウンスが発生するケースとしては、受信者が次のような状況に陥っている場合が挙げられます。識別子/ドメインが間違っている（メールアドレスやドメインにタイプミスがあるなど）、または受信者のサーバーがメールを受け付けなくなっている。このような場合、バウンスするメールアドレスを削除することが必須となります。
ソフトバウンスは一時的なものです。ソフトバウンスが発生したバウンスメッセージは、別の時間に再配信が試みられることがあります。[ 5 ]ソフトバウンスは、メールの受信者の受信トレイがいっぱいで、別のメールを保存するスペースがない場合、または受信が許可されているメールのサイズ制限に達した場合に発生します。ソフトバウンスが発生するその他の状況としては、受信者のメールに特定の送信者を「スパム」送信者としてマークするためのブロックが設定されている場合、または特定の送信者をブラックリストに登録している場合などがあります。さらに、受信者のメールの一時的な停止やサーバーの一時的なエラーもソフトバウンスの原因となります。
メール配信の過程では、複数の箇所でエラーが発生する可能性があります。送信者は、自身のメールサーバーから送信できなかったことを示すバウンスメッセージを受け取る場合もあれば、受信者のメールサーバーから、メッセージは受け取ったものの、指定されたユーザーに配信できなかったことを示すバウンスメッセージを受け取る場合もあります。サーバーが配信のためにメッセージを受け取ると、配信が失敗した場合にバウンスメッセージを送信する責任も同時に引き受けます。
電子メールが宛先サーバーに特定のアドレス（例えば、alice@mymail.example 宛てにmymail.exampleというアドレス）に届いた場合、サーバーのハードドライブの空き容量が不足していると、メールデーモンが指定されたユーザーのメールボックスにメッセージを格納できない可能性があります。
電子メールを送信する際、送信元のサービスが宛先アドレスに到達できない場合があります。その場合、送信者は自身のメールサーバーからバウンスメッセージを受け取ります。メールサーバーが宛先に到達できない一般的な原因は以下のとおりです。
ユーザーは、実際には送信していないメッセージに関する誤ったバウンスメッセージを受け取ることがあります。これは特に、スパムメールやメールウイルスの場合に発生します。スパマー（送信者）が別のユーザー（スパムの受信者）宛てのメッセージを偽造し、さらに別のユーザー（第三者）から送信されたように見せかけることがあります。メッセージが意図した受信者に配信されない場合、バウンスメッセージはスパマーではなく第三者に「返送」されます。これをバックキャッターと呼びます。
もしlibrary.example のメールサーバーが、メッセージが配信不能になることを知っていた場合（例えば、ジルがそこにユーザーアカウントを持っていなかった場合など）、そもそもメッセージを受け付けず、したがってバウンスメールも送信しなかったでしょう。代わりに、SMTP エラーコードでメッセージを拒否したはずです。そうなると、ジャックのメールサーバー（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:<>
厳密に言えば、空でないバウンスメールReturn-Pathは不正です。RFC 3834 では、空でないバウンスメール内のアドレスのローカル部分 (「@」の前の左側) に基づいて不正なバウンスメールを識別するためのヒューリスティックReturn-Pathがいくつか提供されており、自動応答を識別するためのメール ヘッダー フィールドも定義されていますAuto-Submitted。しかし、メール ヘッダーはメール データ (SMTP コマンドDATA) の一部であり、MTA は通常メールの中身を調べません。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にとって不可欠です。名前が示すように、SMTPは「シンプルな」プロトコルであり、メールがブラックホールに消えてしまうような状況では確実に機能しません。そのため、問題を発見して修正するにはバウンスが必要となります。
しかし今日では、偽造されたメールアドレスを使用するスパムメールを大量に受信することが一般的です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
通常、バウンスメッセージには、送信者がメッセージが配信されなかった理由を理解するのに役立ついくつかの情報が含まれています。
RFC 3463では、バウンス理由を示すために使用されるコードについて説明しています。一般的なコードは、5.1.1（不明なユーザー）、5.2.2（メールボックスがいっぱい）、5.7.1（セキュリティポリシー/メールフィルタによって拒否）です。
管理メッセージの報告形式はRFC 6522で定義されています。DSNは、次の3つの部分から構成されるMIME multipart/reportメッセージです。
DSNの後半部分も非常に読みやすい。どのMTAがどの役割を担ったかを理解することが不可欠である。報告用MTAはDSNの作成と送信を担当する。
リモートMTAがSMTPトランザクション中にメッセージを拒否した場合、 smtp型のDiagnostic-Codeフィールドを使用してその値を報告できます。3桁の数値の他に、SMTP応答には人間が読める部分も含まれていることに注意してください。
Remote-MTA: dns; smtp.store.example [ 192.0.2.3 ] Diagnostic-Code: smtp; 550 No such user here smtp.store.example [192.0.2.3] と通信中 >>> 受信先:<nonexistinguser@store.example> <<< 550 該当するユーザーは存在しません
{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）スパム対策のもう 1 つの方法は、メールを相手に返送することです。これにより、アカウントが存在しないように見え、運が良ければ、相手があなたの名前をリストから削除することができます。、およびBreen, Christopher (2006-01-27)。「迷惑メールをバウンスする」。Macworld。2008-10-02に取得。
おそらくご存知のように、Mail のバウンス コマンド (メッセージ > バウンス) を使用しても、受信するスパムのほぼすべてに偽造された「送信元」アドレスが含まれているため、スパマーに対しては効果がありません。