How to get notified when an e-mail has been read/delivered?

Last Update 2006-03-31

Content: DSN, RFCs, How? , MUAs, Receipt Notification

This text tries to explain what standards and other means are available to get a notification when your e-mail has been delivered, received, or read.

First, let's define the terminology:

delivery
means that the e-mail has been delivered by an MTA to a recipient's mailbox;
receipt
means that a user has received the e-mail.
As you can immediately see, there are several problems involved with these definitions. What is the recipient's mailbox? Is it just the spool file on her mailhost? What if she gets her e-mail forwarded by a fax or pager or something similar?
What does it mean that the user has received the e-mail? That is has actually been read? Just the subject of the e-mail? That some program has sorted the e-mail?

As you can see, these are complicated questions, and they can be formally defined only in a fixed framework, as it has been done in X.400. There are two documents available about this topic from the Canonical Internet vs X.400 Debate: Delivery Report Notifications and Receipt Notifications (which are quite old).

In this document, I'll concentrate on what the Internet, i.e, (E)SMTP, has to offer for these topics. If you have any corrections or additions please let me know.

Delivery Status Notification

Delivery Status Notification (DSN) is a function of the MTA. There are two different kinds: positive and negative delivery status notifications. Negative delivery status notifications have been available for a long time: Sorry, your message could not be delivered to:... and hopefully some meaningful explanation. Depending on some implementation stuff, you probably get your complete message back.

Positive delivery status notifications have not been available as a standard. sendmail prior to version 8.7 (and other MTAs) supported Return-Receipt-To: (I patched my sendmail 8.7, since one of my friends asked for it). There are several problems with this, but it has been useful for me in many situation. You just have to know, that

  1. the recipient's MTA does support Return-Receipt-To:;
  2. you should use it only with one recipient (or a very few), but not with a mailing list;
  3. it doesn't mean that much if you don't get a notification.
The first problem is addressed by DSN in the following way: if it delivers an e-mail to an MTA which doesn't support DSNs it will tell the sender so (using a MIME message as defined in RFC 1892 ):
   ----- The following addresses have delivery notifications -----
RECIPIENT  (relayed to non-DSN-aware mailer)

   ----- Transcript of session follows -----
RECIPIENT relayed; expect no further notifications

The second problem is addressed by DSN too: you have to specify for each recipient, whether you want a DSN for her. This has also been addressed by D.J. Bernstein: he proposes a header Notice-Requested-Upon-Delivery-To: orig.recipient@host.dom.ain in his proposal for an RFC. This is implemented in qmail.

The third problem isn't solved. Since the DSN is sent with a null sender ( <> ), it will be dumped if it can't be delivered.

Delivery Status Notification: The RFCs

The relevant RFC for DSN is RFC 1891 K. Moore: SMTP Service Extension for Delivery Status Notifications (31 pages).

RFC 1892 G. Vaudreuil: The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (4 pages)
defines the framework for notification messages. This framework ist used for the message format of DSNs:
RFC 1894 K. Moore: An Extensible Message Format for Delivery Status Notifications (39 pages).

Delivery Status Notification: How does it work?

sendmail 8.7 has no hook to request a DSN from the commandline, it can be only done in an ESMTP dialogue. This is quite reasonable, since options (as introduced in sendmail 8.8), are barely flexible enough to allow for something like this (slightly modified from the RFC):
R: 220 Pure-Heart.ORG SMTP server here
S: EHLO Pure-Heart.ORG
R: 250-Pure-Heart.ORG
R: 250-DSN
R: 250 SIZE
S: MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
R: 250 <Alice@Pure-Heart.ORG> sender ok
S: RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS,DELAY ORCPT=rfc822;Bob@Big-Bucks.COM
R: 250 <Bob@Big-Bucks.COM> recipient ok
S: RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE ORCPT=rfc822;Carol@Ivory.EDU
R: 250 <Carol@Ivory.EDU> recipient ok
S: RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;Dana@Ivory.EDU
R: 250 <Eric@Bombs.AF.MIL> recipient ok
S: RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER
R: 250 <Fred@Bombs.AF.MIL> recipient ok
Let's look at some of the additional keywords: In the MAIL command you can specify what to return (RET=). This only applies to an e-mail that couldn't be delivered. For each RCPT you specify what kind of DSN you want (NOTIFY=):
  1. SUCCESS when the e-mail has successfully been delivered.
  2. FAILURE when the e-mail couldn't be delivered.
  3. DELAY when the e-mail delivery has been delayed.
  4. NEVER you want no DSN at all.
The first three parameters may be combined, the last one must occur only on its own.

In sendmail 8.8.x (x > 4), you can trigger a DSN with the Return-Receipt-To: header, if you re-compile sendmail and set a switch.

Other MTA which support DSNs are ISOCOR's N-PLEX and TeamWARE Office.

Delivery Status Notification: Which MUA supports it?

ELM 2.4ME supports from PL27 on DSN, if you have sendmail 8.8 or higher. You can select several options from a menu. Mutt is another MUA with DSN support. It looks similar to elm, but is a complete new start, without all the legacy code elm has. Ratatosk is still in beta, but it has support for DSN.
Exmh 2.0 supports DSN too (but only with a patch).
Pine supports DSN since about version 4.0 according to Vladimír Solnický. Older (outdated?) versions may need a patch for Pine to enable DSN (but it's limited: there is an option in the config screen for delivery SUCCESS notifications). It is from Chris Taylor.
Netscape is another MUA which supports DSN (thanks to Diane Davidowicz for pointing this out).
Novell GroupWise (as of v7.0 it runs on Linux) supports DSN too (according to David Bank).

I don't know many MUAs, so please tell me, when you know other MUAs (for Unix of course), which support DSN.

Receipt Notification

This is a function of the MUA. Take a look at the Charter of the IETF group working on this topic.
Extensible Message Format for Message Disposition Notification is the current RFC (2298).

This is a rather controversial topic, since it touches privacy issues. So the best is to ask the recipient that she sends you an acknowledge :-).

Receipt Notification: Which MUA supports it?

Chris Koenigsberg told me that Exmh 2.0 supports MDN. Ron Arts wrote me that Netscape 4.5 which supports MDN too.

I don't know any other MUA that supports receipt notification. But I assume there are many available in proprietary system. However, these don't count here. Please tell me, when you know a MUA (for Unix of course) which supports receipt notification.

Some more things about DSN

Robert Sargent added the following information about DSN in sendmail 8.8:

In the sendmail.cf file you must have these options set:

# deliver MIME-encapsulated error messages?
O SendMimeErrors=True
# privacy flags must NOT be set for "goaway" or "noreceipts".  The
#   tightest the Privacy can be set to is:
O PrivacyOptions=authwarnings,noexpn,novrfy,needmailhelo,restrictmailq,restrictqrun
And of course you must be in an ESMTP session (i.e., DSN doesn't work over plain old SMTP sessions). The starting MUA must have requested DSN (or Return-Receipt-To: (RRT) and if so, sendmail must support the option to convert RRT to DSN. Then after doing all of the above, DSN still won't work all the time and when it does, you'll be amazed at how much detail it can provide an outsider about your internal (thought to be trusted) network topology, operating systems, local delivery situations, aliases, mailing lists, etc., etc..
[(links)] [Hints] [Avoiding UBE] [cf/README] [New]
Copyright © Claus Aßmann Please send comments to: <ca at sendmail.org>
Disclaimer: the information provided may be inaccurate or outdated or incomplete. Please contact me if you find an error.