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:
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 (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
----- 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.
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).
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 okLet'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=):
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.
I don't know many MUAs, so please tell me, when you know other MUAs (for Unix of course), which support DSN.
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 :-).
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.
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,restrictqrunAnd 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..