| unix.ba | text • research • links • about |
Has it ever happened to you that someone claimed they hadn't received your e-mail, while you were completely sure you sent it? Have you ever used e-mail to apply for an important position, only to find out that your application has not even been considered because you have supposedly never sent it? Were you able to prove that your message has been delivered to its destination?
If you run into this type of trouble (especially at work), you may find this article useful. I have done my best to avoid going into any sort of detailed technical discussion and have concentrated on providing information which should be useful to an average e-mail user.
Sometimes people try to avoid responsibility by hiding behind unreliability of e-mail communication. And the fact that the process of e-mail transfer is inherently unreliable makes it difficult to establish any sort of proof of message delivery. Once your e-mail reaches the Internet, you cannot control it or track its transfer, so you can hardly ever claim with certainty that your message has reached someone's mailbox or has been read by the recipient.
Most modern e-mail clients allow you to request a so-called “receipt notification”, technically known as a message disposition notification (MDN). The purpose of an MDN is to provide a confirmation to the sender that his message has been read (well, at least opened) by the recipient. One problem with MDNs is that they are not sent without the recipient's consent, as this would be a privacy violation. To solve this problem, e-mail applications usually display a popup window whenever a receipt notification is requested. The recipient can then choose whether to send a notification back to the sender or not. So if someone is trying to escape responsibility, they most definitely won't send you a receipt notification. Some people also find these popups annoying and disable them completely in their e-mail client's preferences.
The question then remains: How do you know if someone received your e-mail and how can you prove it?
While it isn't easy to determine if your message really reached the intended recipient, you could use the simple method described in the next section to check if it has been accepted for delivery by the recipient's mail server. The described method exploits another type of notification, called a delivery status notification (DSN). In contrast to an MDN, which is a request to the message recipient, a DSN is a request to a mail server on the recipient's domain. With a DSN the recipient is never asked to confirm message receipt and is also not aware that the mail server has sent a notification to the sender.
The main drawback of using DSNs is that you cannot prove that your message has reached the recipient's e-mail application or has been read. You can only prove that your message has been accepted by the recipient's mail server for delivery to their mailbox. Nonetheless, a returned DSN contains information which can be very useful in case you need any sort of proof that you really sent the message.
Say you want to send an e-mail to valid.user@example.com. Here is the simple procedure you should follow to obtain a DSN from the receiving mail server:
And here is what normally happens: The mail server of example.com has two addresses to deliver your e-mail to. Since valid.user@example.com is a valid recipient, the mail server proceeds and delivers your message to his mailbox. On the other hand, there is no mailbox associated with no.such.user@example.com, so the mail server returns a delivery status notification to you, complaining about the non-existent user.
What does the returned DSN prove? It proves that your e-mail reached the mail server of example.com, and since the server only complained about no.such.user@example.com, you could assume it recognized valid.user@example.com as an existing user and proceeded to deliver your e-mail to his mailbox. The headers of your original message, which are returned as a part of the DSN, contain a great amount of valuable information:
Diagnostic information for administrators: Generating server: mail.example.com no.such.user@example.com #550 5.1.1 RESOLVER.ADR.RecipNotFound; not found ## Original message headers: Received: from edge.example.com (192.168.12.5) by head.example.com (192.168.10.15) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 30 Jan 2012 09:44:23 +0100 Received: from mail-11.unix.ba (172.20.160.11) by edge.example.com (192.168.12.5) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 09:46:41 +0100 Received: by out.unix.ba with SMTP id r8yw3871904txa.14 for <no.such.user@example.com>; Mon, 30 Jan 2012 00:44:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.10.10.10 with SMTP id b3iv29542052qac.21; Mon, 30 Jan 2012 00:44:18 -0800 (PST) Date: Mon, 30 Jan 2012 09:44:18 +0100 Message-ID: <Vw4YY2PnKQB6oO98C5EoktjFA3zv79vcyfVHlRiT@out.unix.ba> Subject: Application for the open position in Software Engineering From: Kenan Kalajdzic <kenan@unix.ba> To: Valid User <valid.user@example.com> Bcc: <no.such.user@example.com> Content-Type: text/plain; charset="UTF-8" Return-Path: kenan@unix.ba Received-SPF: Neutral (edge.example.com: 172.20.160.11 is neither permitted nor denied by domain of kenan@unix.ba)
Despite the fact that this is not a firm proof of delivery, you may still extract useful information from the returned headers. For instance, the headers show that you sent this e-mail to the intended recipient on a particular date and at a particular time. You also get a complete trace of e-mail transfer, which shows how your message traveled from your mail client to the mail server of the recipient. Further information from the headers, such as various message IDs and timestamps, could serve as a basis for a more thorough inspection in case of a formal investigation (e.g. reviewing server logs).
Note that we could have also explicitly requested a DSN for a successful delivery, instead of adding a fake e-mail address as Bcc to trick the receiving mail server into generating a failure notification. In that case, however, we would have to modify the MAIL and RCPT SMTP commands, which requires special support from the e-mail client. Playing with raw SMTP is usually not well supported in desktop e-mail clients, let alone web-based e-mail applications, which are in an ever-increasing use today.
The method presented in this article allows any user to obtain a delivery status notification using any e-mail client software or a web-based e-mail service. It requires no technical knowledge or understanding of the underlying protocols.
• • •