Most people have come to expect that when an email is sent it will arrive at it’s destination. Over the last decade, email delivery has become much more reliable due to many factors such as better network architecture, better mail server design, load-balancing and fail over design, all driven by increased reliance on email in todays world. There is also the ability to request a delivery receipt on most email clients although users typically disable this feature themselves, or the security policy of the organization disables it. Email however is not a guaranteed delivery service. The SMTP protocol as well as the process of email delivery on the Internet does not guarantee delivery.
One technique that I have used when someone has either not responded or indicated that they did not receive my email is to check the server delivery logs. While this does not guarantee that the email was placed in the destination users mailbox, it does indicate acceptance at the mail exchanger of the ISP or company.
Above is an email I sent to a friend last week confirming plans for dinner. By viewing the headers and looking for the SMTP “Message-ID” field, I can then search for that ID in the log files of the mail server.
# cat maillog | grep -i "4B618D6A.2070804" Jan 28 08:13:19 mailsvr sendmail[20093]: o0SDDGVS020093: from=<xx@xxxxxxxxxx.org>, size=399,, nrcpts=1, msgid=<4B618D6A.2070804@xxxxxxxxx.org>, proto=ESMTP, daemon=MTA, relay=eee.dddd.ca [216.bbb.ccc.12] # # cat maillog | grep -i "o0SDDGVS020093" Jan 28 08:13:19 mailsvr sendmail[20093]: o0SDDGVS020093: from=<xx@xxxxxxxxxx.org>, size=399,, nrcpts=1, msgid=<4B618D6A.2070804@xxxxxxxxx.org>, proto=ESMTP, daemon=MTA, relay=eee.dddd.ca [216.bbb.ccc.12] Jan 28 08:13:20 mailsvr sendmail[20098]: o0SDDGVS020093: to=<yyyyyy@gggggggg.com>, ctladdr=<xx@xxxxxxxxxxx.org> (501/501), delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=120399, relay=ttttttt.hhhhhhcom. [142.fff.rrr.227], dsn=2.0.0, stat=Sent (Ok: queued as 51E02514002) #
In this case the server logs are using Sendmail, so depending on your server, the procedure might be slightly different. Using the SMTP Message-ID field as a search parameter, I obtain the entry of the unique ID of the Sendmail delivery process for that message, in this case “o0SDDGVS020093″. Searching the log file for that unique ID, shows me the remote mail server that accepted the email for delivery. The status is “sent” and confirmed by a Deliver Status Notification (dsn) of 2.0.0.
There are many other fields and status messages with server logs, some you can see above, which are useful resources when troubleshooting or doing forensic activity involving an email transmission in an investigation. Although this might appear to be too technical for a general user, I have used the logs to confirm myself if email is getting to at least the mail exchanger. These records can assist in determining if the email arrived. At the very least, you can use it as evidence the email was received by the destination company. While it is not 100% proof, it is typically a good indicator.
In one instance, I was not getting a response from my daughter’s school concerning a particular issue. After several attempts, I sent a new email asking why they were not responding, as it appeared obvious the school board was receiving the emails and I attached the log. I had a response within the hour. I am sure the users didn’t fully understand each field, but it was enough to get a response. I don’t know of any service providers or companies that provide an on-line interface to check status of messages, but it might not be a bad service to offer.


