配送できなかったメールをログで確認する方法 updated!

配送できなかったメールをログにおいて確認する方法とそれに付随する解説をまとめました。
内部から外部へのメールを送ろうとして配送できなかったメールを確認する場合、大きくは２段階、まずepstrdが行うSMTP受領時、続いてepstddが行うSMTP配送時と２回に分けてログを調べることが大事です。

・SMTP受領段階・・・epstrdサービス
・SMTP配送段階・・・epstddサービス

（１）epstrdが行うSMTP受領段階について

第一段階の epstrd が行うSMTP受領段階がうまく行っているのかを調べるには、acceptlog（マシン接続ログ）→inlog（SMTP受信ログ）、ないしはacceptlog（マシン接続ログ）→receivelog（SMTP受信詳細ログ）を順に追って調べます。
メール送信では、SMTP受領段階で失敗したり拒否されるものがあります。E-Postに機能実装されている「中継の制限」に引っかかるものや「送信先制限」設定に引っかかるものなど、epstrdサービスで行われ、詳細な理由は、epstrdの応答コードとともに、receivelogに記載されます。さらに受領段階で失敗するものの多くにSMTP認証によるものがあります。epstrdサービスで認証失敗か認証成功かが判断され、ok/abortの成否はacceptlogに載り、abortの詳細理由はreceivelog（SMTP受信詳細ログ）にepstrdの応答コードとともに載るという仕組みです。
とにかくacceptlogで'abort'されている記録がある場合は、その詳細理由や原因を知るためにはreceivelogの内容を調べる必要があります。acceptlogで見つけた同じ"B"で始まるメッセージIDでreceivelogを検索し調べます。
ちなみに、acceptlogで'ok'されている記録があるときは問題なく受領されていることを表します。inlogに記載されているものはすべて'ok'で受領されたものばかりです。
受領が問題なかったことが確認できれば続く（２）の配送段階での処理内容を調べます。

（参考FAQ）
●接続マシンログ（acceptlog）で abort されている理由を知るには
●acceptlogにメッセージIDが出ているのにreceivelogに見つからないケースがある理由

（２）epstddが行うSMTP配送段階について

第一段階が問題なく受領okが確認でき、問題なことがわかれば次は第二段階です。
第二段階のSMTP配送段階では、senderlog（配送時の詳細ログ）やfaillog（配送失敗ログ）を調べます。前段階の受領はうまく行っているのに、結果的にうまく送信ができていないようなときは、配送段階に何らかの問題があったと想定し、下記にあげるログからその理由と原因を調べます。
仮に配送段階に問題がなく、相手側のサーバが受信している記録がsenderlogから見つかったときは、こちら側には問題はなく、相手側サーバの問題があるという判断切り分けをして調べます。調べるログは、senderlog（配送時の詳細ログ）やfaillog（配送失敗ログ）です。引き当てるには第一段階のacceptlogやinlogで確認できた"B"で始まるメッセージID番号で引き当てるか、前出ログで確認できた時間をもとに見ていきます。
（※事例にあげるメッセージIDおよび送信元ドメイン、宛先ドメインは架空のもの）

【配送失敗ログ−faillogの例】
B0000123123＠test-sample00.jp send fail on [16/May/2018:11:18:39]
from info＠test-sample00.jp to user1＠test-sample01.jp ※1 [Unable to deliver to destination domain] ※2
B0000123123＠test-sample00.jp send fail on [16/May/2018:11:18:39]
from info＠test-sample00.jp to user2＠test-sample01.jp ※1 [Unable to deliver to destination domain] ※2
※１）仮に宛先をメールクライアントからTO,CC,BCCを区別して送信した場合でも、ログではエンベロープTOの内容に基づいて記録されるため、TO,CC,BCCの区別はされません。
※２）記載される配送失敗の理由はリトライの最終回においての失敗理由が記載されます。リトライ途中の理由はここに記載されず、senderlogを見る必要があります。言い換えるとここに記載される理由が本当の配送失敗理由だとは限りません。

配送失敗時にsenderlog（配送時の詳細ログ）やfaillog（配送失敗ログ）に記録される失敗理由の中に記載されるエラーコードは、E-Post側でなく接続相手先のSMTP(MTA)が発行したものとなります。規約上、500番台は永続的拒否、400番台は一時的拒否を意味します。
400番台だから一時的なものと思っても、実際には永続的な拒絶状態にあるものが存在します。また、相手が出すエラーコードのないケースも多くあります。たとえば、名前解決ができなかったもの、名前解決できても接続先サーバが無応答であったもの、これらはすべて接続がなかったので、faillogに記載されるエラーコードはありません。
また、一方で考慮しておくべき点もあります。それは接続できなかったり、一時的拒絶や永続的拒絶を受けた相手には、E-Post側の配送詳細設定に基づいてリトライ動作が行われることです。これらはみなsenderlog（SMTP配送詳細ログ）に記録されますが、リトライのたびに失敗理由が異なるケースもあり得る話しです。
faillogには、リトライした後の最終回で最後に失敗した理由が記載されることになりますので、リトライ途中の理由とは異なるケースが理論的にあります。そういう意味でfaillogの失敗理由や相手のエラーコードだけを見ておればよいということにもなりません。関連記事を紹介します。

（関連FAQ）
●senderlog と faillog に記載された配送失敗の理由が異なる
●送信できなかったエラーメールの内容とfaillogの内容が異なる

【配送時の詳細ログ−senderlogの例その１】
[11:08:39:119] [B0000123123-R0001] ※3 [test-sample01.jp] GetTryServer:()
　　　（中略）　　　　
[11:09:11:404] [B0000123123-R0001] ※3 ConnectHost:
socket connect failed. (socket error code=61) ※4
※３）メッセージIDの後の枝番付き"-R0001"はリトライを表わします。
※４）socket error code=61は、相手先MTAへの接続ができないケース。socket error code=60なら、DNSサーバを参照できなかったりDNSサーバの動作状況に問題があるケースです。

（関連FAQ）
●ログに記録されるメッセージIDの後の枝番種類について
●senderlogに送信リトライのたび"socket error code=60"のエラーが記録される場合
●socket エラーコード表

【配送時の詳細ログ−senderlogの例その２】
[11:18:39:184] [B0000123123-R0001] [001]:ReturnMail Start:domain:
[test-sample00.jp] smtp server:[192.168.0.xx]
[11:18:39:200] [B0000123123-R0001] [001]:ReturnMail Completed.
[11:18:39:231] [B0000123123-R0001-E001] [test-sample00.jp] GetTryServer:() ※5
[11:18:39:231] [B0000123123-R0001-E001] [test-sample00.jp] GetTryServer:
(ltime(13170910719)-otime(13170910719))/30=(0)
[11:18:39:231] [B0000123123-R0001-E001] [test-sample00.jp] GetTryServer:()
※５）この部分はエラーメールの生成と送信元への送信を表わします。

（関連FAQ）
●senderlogに"GetTryServer:(xxxx)/120=(0)"が記録される意味について

【SMTP送信ローカルログ−outlocallogの例】
B0000123123＠test-sample00.jp sent on [16/May/2018:11:18:39]
to 192.168.0.xx from - to user＠test-sample00.jp ※6
B0000123123＠test-sample00.jp sent on [16/May/2018:11:18:39]
to 192.168.0.xx from - to user＠test-sample00.jp ※6
※６）エラーメールの送信元への送信を表わします。"from - to [送信元アドレス]"というように、fromの後が空白なのは、E-Postが自動で生成したメールのためです。

（関連FAQ）
●SMTP送信ローカルログ（outlocallog）などのログで fromアドレスが空白になっているケースがあるのはなぜ？