【回答】
本資料の目的
本資料は、メール送信失敗時のmaillogへの記録とバウンスメールの送信について、4つのパターンに分類して解説するものです。
メール配送失敗の検知方法は、送信側MTAと受信側サーバーの動作によって異なります。本資料を参考に、システムで採用する検知方法の特性を理解し、適切な運用設計を行ってください。
事前に知っておくべき情報
Accel-Mart Plusでのバウンスメール受信について
■ バウンスメールの受信設定
Accel-Mart Plusでは、デフォルト状態ではバウンスメールを受信することはサービス仕様上できません。
バウンスメールを受信したい場合は、送信元アドレス(Return-Path)に受信可能な独自ドメイン（accel-mart.com以外）のメールアドレスを設定する必要があります。
【実現するための手段】
送信元メールアドレスに独自ドメインを用いる場合は、以下の対応が必要です:
- ご契約者様にて独自のSMTPサーバをご用意いただく
- 設定ファイル（javamail-config.xml、rewriting-mail-address-config.xml）を修正し、独自SMTPサーバおよび送信元アドレスを設定する
SMTP設定とメール設定については、以下のドキュメントをご参照ください。
- intra-mart Accel Platform システム管理者操作ガイド - SMTPサーバ設定
- intra-mart Accel Platform 設定ファイルリファレンス - メール設定
- intra-mart Accel Platform 設定ファイルリファレンス - メールアドレス書き換え設定
※なぜ独自SMTPサーバが必要なのか
Accel-Mart PlusのSMTPサーバは標準ドメイン（mail.*.accel-mart.com）でのメール信頼性対応（SPF/DKIM/DMARC）が設定されているため、独自ドメインでのメール送信には使用できません。
Accel-Mart PlusのSMTPサーバは標準ドメイン（mail.*.accel-mart.com）でのメール信頼性対応（SPF/DKIM/DMARC）が設定されているため、独自ドメインでのメール送信には使用できません。
外部SMTPサーバの構築・運用はサービス対象外となりますので、実施される場合は十分な検証をお願いいたします。
また、独自ドメインを使用する際は、メールの信頼性を向上させるための対応が必要です。詳細は以下をご確認ください。
■ maillogでの配送失敗の検知について
送信先アドレスの問題や配送失敗を検知する方法として、maillogで検知できる可能性があります。ユーザー不明、メールボックス満杯、ドメイン不明などのエラーを確認できる場合があります。
ただし、以下の点にご注意ください:
- 受信側メールサーバーの仕様に依存するため、動作を保証するものではありません。
- 受信側メールサーバーが一旦メールを受け入れてから内部処理で失敗する場合、maillogには送信成功と記録され、配送失敗を検知できません。
- そのため、受信側メールサーバーの内部処理失敗を含む配送失敗を検知したい場合は、maillogの監視に加えて、バウンスメールの受信監視を併用することも検討してください。
期待する動作になるかは、実際の送信先サーバーに対してテスト送信を行うなど、十分に検証を行ってください。
「maillogに記録される／されない」と「バウンスメールが送信される／されない」による分類
| パターン | maillog記録 | バウンスメール | 発生ケース | 具体例 |
|---|---|---|---|---|
| パターン1 | ✅ 記録される | ✅ 送信される | MTAが受信側SMTPサーバーと直接通信し、即座または複数回の再送後に配送失敗が確定した場合。MTAから送信元にバウンスメールが送信されます。配送失敗がmaillogに記録されます。 | ユーザー不明、メールボックス満杯、ドメイン不明 |
| パターン2 | ✅ 記録される | ❌ 送信されない | MTAが配送失敗を検知してmaillogに記録しますが、バウンスメールを送信すべきでない、または送信できない状況です。null sender、二重バウンス、無効な差出人アドレスなどが該当します。 | null sender、二重バウンス、通知クラス制御 |
| パターン3 | ❌ 記録されない | ✅ 送信される | 送信側MTAの視点では送信成功(status=sent)としてmaillogに記録されますが、受信側サーバーが内部処理(ウイルススキャン、コンテンツフィルタ等)で失敗し、バウンスメールを生成・返送するパターンです。送信側のmaillogには配送失敗は記録されません。 | 受信側サーバー内部での配送失敗(ウイルス検出等) |
| パターン4 | ❌ 記録されない | ❌ 送信されない | システム障害、キュー消失、または意図的な破棄により、maillogに最終結果が記録されず、バウンスメールも送信されない状況です。メールが失われる最も問題のあるパターンです。 | システム障害、キュー消失、ブラックホール設定 |
各パターンの検出方法と対策
| パターン | 検出方法 | 対策 |
|---|---|---|
| パターン1 | grep "status=bounced" /var/log/maillog |
標準的なバウンス処理。バウンスメールを監視し、無効なアドレスをデータベースから削除します。 |
| パターン2 |
grep "from=<>" /var/log/maillog | grep bouncedgrep "double-bounce" /var/log/maillog
|
null senderや二重バウンスを監視します。postmasterアドレスを定期的に確認してください。 |
| パターン3 |
grep "status=sent" /var/log/maillog と受信したバウンスメールを相関分析 |
送信成功後のバウンスメール受信を監視します。受信側サーバーの問題を送信側では制御できないため、ログの相関分析が重要です。 |
| パターン4 | grep -E "status=(expired|discarded)" /var/log/maillog |
キューのバックアップ、最大キュー保持時間の適切な設定、監視アラート設定を実施します。 |
パターン詳細
パターン1: maillogに記録される かつ バウンスメールが送信される
※以下は代表的な例です。これ以外にも様々なケースが存在します。
| 発生ケース | maillogの記録内容 | DSNコード | バウンスメールの内容例 |
|---|---|---|---|
| ユーザー不明 |
status=bounceddsn=5.1.1relay=mx.example.com[192.168.1.100]:25550 5.1.1 User unknown in local recipient table
|
5.1.1 | Subject: Undelivered Mail Returned to Sender <nonexistent@example.com>: Recipient address rejected: User unknown in local recipient table |
| メールボックス満杯 |
status=bounceddsn=5.2.2relay=mx.example.com[192.168.1.100]:25552 5.2.2 Mailbox full
|
5.2.2 | <user@example.com>: Mailbox full |
| ドメイン不明 |
status=bounceddsn=5.4.4relay=noneHost or domain name not found. Name service error for name=nonexistent-domain.com type=MX: Host not found
|
5.4.4 | <user@nonexistent-domain.com>: Host or domain name not found. Name service error for name=nonexistent-domain.com type=MX: Host not found |
| スパムフィルタ拒否 |
status=bounceddsn=5.7.1relay=mx.example.com[192.168.1.100]:25550 5.7.1 Rejected by spam filter
|
5.7.1 | <user@example.com>: host mx.example.com said: 550 5.7.1 Rejected by spam filter |
| リレー拒否 |
status=bounceddsn=5.7.1relay=mx.example.com[192.168.1.100]:25554 5.7.1 Relay access denied
|
5.7.1 | <user@example.com>: Relay access denied |
パターン2: maillogに記録される かつ バウンスメールが送信されない
※以下は代表的な例です。これ以外にも様々なケースが存在します。
| 発生ケース | maillogの記録内容 | DSNコード | バウンスメールが送信されない理由 |
|---|---|---|---|
| null sender(差出人アドレス空) |
from=<>status=bounceddsn=5.1.1to=<user@example.com>550 5.1.1 User unknown
|
5.1.1 | バウンスループ防止のため。差出人アドレス(エンベロープFrom)が空(<>)の場合、MTAはバウンスメールを送信しません。 |
| 二重バウンス |
warning: bounce message failurefrom=<> to=<double-bounce@yourdomain.com>status=bounced
|
5.x.x | バウンスメール自体の配送が失敗。二重バウンスアドレス(デフォルト: postmaster)に転送され、元の送信者には届きません。 |
| 通知クラス制御 |
status=bounceddsn=5.x.x(通常のバウンスログ) |
5.x.x | 設定により、特定のエラークラスについて送信者への通知が抑制されています。管理者にのみ通知されます。 |
| 無効な差出人アドレス |
from=<invalid@nonexistent.com>status=bounced(unable to notify sender: return address is invalid)
|
5.x.x | 差出人アドレス自体が無効で、バウンスメールを送信できません。 |
パターン3: maillogに記録されない かつ バウンスメールが送信される
※以下は代表的な例です。これ以外にも様々なケースが存在します。
このパターンでは、送信側MTAは送信成功(status=sent)としてmaillogに記録しますが、受信側サーバーでの配送失敗は送信側のmaillogには記録されません。後でバウンスメールを受信した際のログはmaillogに記録されます。
| 発生ケース | maillogの記録内容(送信時) | バウンスメールの送信元 | バウンスメールの内容例 |
|---|---|---|---|
| 受信側サーバー内部での配送失敗(ウイルス検出) |
status=sent (250 2.0.0 OK: queued as XYZ999)dsn=2.0.0← MTAは「送信成功」と記録(配送失敗はmaillogに記録されない) |
受信側サーバー(mx.example.com) | From: MAILER-DAEMON@mx.example.com Subject: Delivery Status Notification (Failure) Message rejected by content filter: Virus detected |
| 受信側のコンテンツフィルタ拒否 |
status=sent (250 2.0.0 OK: queued)dsn=2.0.0
|
受信側サーバー | From: MAILER-DAEMON@mx.example.com Message rejected by content filter: Policy violation |
| 受信側の転送ループ検出 |
status=sent (250 2.0.0 OK)dsn=2.0.0
|
受信側サーバー | From: MAILER-DAEMON@mx.example.com Too many hops: Mail forwarding loop detected |
| 受信側のクォータチェック失敗(遅延チェック) |
status=sent (250 2.0.0 OK)dsn=2.0.0
|
受信側サーバー | From: MAILER-DAEMON@mx.example.com Mailbox quota exceeded |
補足: このパターンでは、バウンスメールを受信した際のログはmaillogに記録されます:
Oct 6 10:15:00 mail postfix/smtpd[12399]: STU123: client=mx.example.com[192.168.1.100] Oct 6 10:15:01 mail postfix/local[12402]: STU123: to=<sender@yourdomain.com>, relay=local, status=sent (delivered to mailbox)
パターン4: maillogに記録されない かつ バウンスメールも送信されない
※以下は代表的な例です。これ以外にも様々なケースが存在します。
| 発生ケース | maillogの状態 | 結果 | 備考 |
|---|---|---|---|
| システム障害によるキュー消失 | 最後のmaillogエントリ:status=deferreddsn=4.4.1Connection timed outその後、記録なし |
メールが完全に失われる | サーバーのクラッシュ、強制停止、ディスク障害等でキューが失われた場合 |
| 最大キュー保持時間超過(差出人アドレス無効) |
status=expired(unable to notify sender: return address is invalid)
|
バウンスメール送信を試みるが失敗 | デフォルト5日間再送後、差出人アドレスが無効でバウンスメールを送信できない。実質的にはパターン2に近い。 |
| ブラックホール設定(意図的破棄) |
status=discarded(intentionally discarded)
|
意図的に破棄 | 配送経路設定(transport)や受信者転送設定(recipient_bcc_maps)で /dev/null や discard: に転送設定されている場合 |
| ネットワーク分断中のキュー削除 | 最後のmaillogエントリ:status=deferreddsn=4.x.xその後、記録なし |
メールが失われる | 管理者による誤操作(キュー削除コマンド: postsuper -d ALL等)でキューが削除された場合 |
DSNコード一覧
| DSNコード | クラス | 意味 | 発生する主なケース |
|---|---|---|---|
| 2.0.0 | 成功 | 配送成功 | 正常な配送完了 |
| 4.2.2 | 一時的 | メールボックス満杯(一時的) | 一時的な容量制限 |
| 4.4.1 | 一時的 | 接続タイムアウト | ネットワーク問題、サーバー高負荷 |
| 4.4.2 | 一時的 | 接続失敗 | 受信サーバーがダウン |
| 4.7.1 | 一時的 | 配送遅延(グレーリスティング) | スパム対策としての遅延要求 |
| 5.1.1 | 恒久的 | ユーザー不明 | メールアドレスが存在しない |
| 5.1.2 | 恒久的 | ドメイン不明 | ドメインが存在しない |
| 5.2.2 | 恒久的 | メールボックス満杯(恒久的) | クォータ超過で新規メール受信不可 |
| 5.4.4 | 恒久的 | ドメインが見つからない | MXレコードが存在しない |
| 5.7.1 | 恒久的 | 送信拒否 | スパムフィルタ、ポリシー違反、リレー拒否 |
参考情報
各メールサービスプロバイダーのSMTPエラーコードに関する公式ドキュメント: