Log all SMTP issues during deliveries
TL;DR: Some SMTP issues are not logged as event, this can lead to multiple email sending without noticing it.
Let me tell you a (true) strory:
A customer calls us to let us know he receives the same email multiple times from us. We find this really weird… but, hey! He take time to notify us: let's dig into our multiple level of logs… We found nothing speaking to us… So we ask for an example to our customer… He send it back to us… We, now, can determine what mail was send multiple times… And, what a surprise when we jump to the mail history we see the following events:
Accepted, Opened, Opened, Opened, …
Look: no delivered event while the mail has been opened.
Asking for insights to Mailgun support, we get the following response:
Every time we submitted the request it failed internally with the following error,
data write failed: write tcp4 A.B.C.D:10277->E.F.G.H:25: i/o timeout
Because we didnt get delivered response we continued to attempt delivery until we receive the delivered response. This would be the cause of the multiple deliveries.
(where A.B.C.D is our sending IP and E.F.G.H the destination MX IP)
So we ask why we did not get the error event:
Our apologies for any inconvenience. Unfortunately, these types of failed events are actually classified as internal and are not public facing to the customer.
So… I think that this is an issue: we have no feedback on sending issue, we cannot monitor them, and over all, it could hurt our reputation without knowing it.
Ashton Severns commented
+1 to this. I was trying to diagnose why some messages had an "Accepted" status but no "Delivered" or any sort of failure status afterward. I contacted support and their reply was:
These failures are being classified as internal, thus the reason why they are not displaying in your logs. We had to remove these types of errors from the logs due to customers complaining about temporary failures congesting the logs section.
I think it does a disservice to folks trying to troubleshoot email deliverability. I would much rather see in the logs that the destination mail server has an issue rather than contact support each time.