メモ > サーバ > 各論: コマンド > バウンスメールを解析
■バウンスメールを解析
メールログの調査だけではなく、バウンスメールも解析するといい
でも「バウンスは発生しないが、メールも届かない」はあり得るのでこれも絶対ではない(迷惑メール扱いされた、など)
Postfix+VERPでメールを識別できるようにする…という方法はあるが、
maillogを解析して「どのアドレスに届かなかったか」が判ればある程度は対応できる
が、可能ならmaillogとバウンスメールの両方を調査できる状態にしておくことが好ましい
バウンスメールとは何か?
http://bouncehammer.jp/ja/what-is-bounced-email
バウンスが発生する3つのタイミング
http://bouncehammer.jp/ja/email-topics/when-does-email-bounce
携帯電話宛バウンスの見分け
http://bouncehammer.jp/ja/email-topics/distinguish-between-the-unknown-and-the-filtered
携帯のドメイン指定フィルタが原因でバウンスしてしまいました。再送するにはどうすればよいですか?
https://support.sendgrid.kke.co.jp/hc/ja/articles/206442433
VERP でメール不達エラーの宛先アドレスを識別する
https://fumiyas.github.io/2014/12/25/verp.postfix-advent-calendar.html
バウンス理由の一覧 | Sisimai: Mail Analyzing Interface
https://libsisimai.org/ja/reason/
■バウンスメールの送信
バウンスメールを返すか否かは、送信先サーバの設定にも依存する
よって「バウンスメールが送られてこない=メールが届いた」というわけでは無いので注意
以下は「存在しないアカウント宛に送られたメールには、バウンスメールを返さない」設定の例
unknown user のバウンスメールの削除
http://www.ice.is.kit.ac.jp/~umehara/misc/comp/20091218c.html
■バウンスメールの送信先
バウンスメールは、「Return-Path」に対して通知される
ただし Return-Path に差出人のメールアドレスと異なるメールアドレスを指定すると、迷惑メール扱いされやすくなるので注意
詳細は Trouble.txt の「メールを送信しても届かない / 迷惑メールとして処理される」を参照
Return-Pathとは何か? | SendGridブログ
https://sendgrid.kke.co.jp/blog/?p=12803
Return-Path(エンベロープFrom)とは? | JCOMサポート
https://cs.myjcom.jp/knowledgeDetail?an=000003212
また、root宛にも同じ内容が通知されるみたい
ただしメールを見落としがちだし確認も手間なので、root宛メールは自身のメールアドレス(もしくはサーバ管理用のメールアドレス)に転送しておくのが無難
rootメールの転送については、Basis.txtの「root宛メールを転送」を参照
以下は相手に届かないけどバウンスメールも送られない…というケース
携帯のドメイン指定フィルタが原因でバウンスしてしまいました。再送するにはどうすればよいですか?
https://support.sendgrid.kke.co.jp/hc/ja/articles/206442433-%E6%90%BA%E5%B8%AF%E3%81%AE%E3%83%89%E3%...
■バウンスメールの書式
バウンスメールの書式はRFCで定義されているが、定義に沿っていないものもあるようなので注意
5.3 バウンスメールにより通知される送信失敗|Cuenote
https://www.cuenote.jp/documents/smtp/000203.html
以下はRFCによるものだが推測も含む
メールヘッダの「Content-Type」に以下が記録されるみたい
これにより、バウンスメールか否かを判断できそう
multipart/report; report-type=delivery-status;
バウンスメールの場合、メール本文に以下のような情報が記載される
これにより、バウンスの理由などを判断できそう
Reporting-MTA: dns; web1.refirio.net
Received-From-MTA: DNS; localhost
Arrival-Date: Tue, 1 Jun 2021 13:06:22 +0900
Final-Recipient: RFC822; xxxxxxxxxx@ezweb.be.jp
Action: failed
Status: 5.1.2
Remote-MTA: DNS; ezweb.be.jp
Diagnostic-Code: SMTP; 550 Host unknown
Last-Attempt-Date: Tue, 1 Jun 2021 13:06:22 +0900
以下のようなものもある。似た内容が記録されるが、項目には差がある
Reporting-MTA: dns; web1.refirio.net
Arrival-Date: Tue, 1 Jun 2021 08:52:57 +0900
Final-Recipient: RFC822; xxxxxxxxxxxx@icliud.com
Action: delayed
Status: 4.4.1
Remote-MTA: DNS; icliud.com
Last-Attempt-Date: Tue, 1 Jun 2021 13:45:01 +0900
Will-Retry-Until: Sun, 6 Jun 2021 08:52:57 +0900
「550」のような値は応答コード、「5.1.1」のような値はステータスコード
これらにより、バウンスメール扱いとなった理由を知ることができる
メール配信が失敗した時のエラーコード一覧!エラー内容を把握して配信リストの質を高めよう - Benchmark Email
https://www.benchmarkemail.com/jp/blog/error-codes-of-bounced-emails/
メールのエラーコード(SMTPステータスコード)の意味と対策 | ベアメールブログ
https://baremail.jp/blog/2021/02/25/1020/
■バウンスメールの種類
バウンスメールはソフトバウンスとハードバウンスに分けられる
ソフトバウンスは、メールアドレスが正しく、受信者のサーバに到達したが、以下の様な理由で返されたということを意味する
・メールボックスが一杯だった
・サーバがダウンしていた
・メッセージサイズが大きすぎた
ハードバウンスは、以下の様な理由で受信を恒久的に拒否された場合に発生する
・メールアドレスが無効/不正
・メールアドレスが存在しない
ハードバウンスが発生したメールアドレスにメールを送り続けると、手当たり次第にスパムを送信していると判定される可能性がある
メール送信サービスによっては、ハードバウンスの割合が一定数を超えると利用警告されることがあるので注意
場合によっては、実際にメールを送信する前にアドレスの妥当性を検証する仕組みの導入を検討する
メールアドレスをリアルタイムに検証してハードバウンスをなくす方法 | SendGridブログ
https://sendgrid.kke.co.jp/blog/?p=7837
なお、ハードバウンスは
「応答コードが550で、ステータスコードが5.1.1 もしくは 5.1.2」
という判定ができそう(要検証)
バウンスメールとその対策 | SendGridブログ
https://sendgrid.kke.co.jp/blog/?p=1338
ステータスコードが5.2.0としてバウンスメールになることもあるが、
これはドメイン指定拒否の場合に記録されるものみたい
携帯電話宛バウンスの宛先不明とドメイン指定拒否を見分ける | Sisimai: Mail Analyzing Interface
https://libsisimai.org/ja/docs/distinguish-between-the-unknown-and-the-filtered.html
メールを解析していると、はじめから件名に「[SPAM]」と付いていることがある
プロバイダなどが自動で付与しているものだと思われるので、基本的にはスパム扱いで問題なさそう
タイトルに[spam]とついたメールが届く | よくある質問(FAQ) | BIGLOBE会員サポート
https://faq.support.biglobe.ne.jp/faq_detail.html?faq_id=12363