>Email Read/Received Reciepts


Here is some information to let you decide if using read or delivery recipients will really do what you think they will do.  Don’t expect getting back many acknowledgements to your requests.  Most users ignore them.  Anti-spam filters will remove them.

Read or delivery receipts are a *request* made by adding a header to the outbound message.  The name and value of these headers are defined by RFC or were defined by common usage (i.e., de facto standards).  Read receipt *requests* are handled by the recipient’s e-mail client.  Whether the e-mail client prompts, always sends, or always ignores these requests depends on how the user configured their e-mail client.  The default in most e-mail clients is to prompt when a sender has requested a read receipt.  This prompt usually spurs the user to configure their e-mail client to ignore all such further requests as they are not interested in divulging to the sender as to if and when they read the sender’s e-mail.  It’s a privacy and nuisance issue.  It is also an anti-spam issue to avoid telling a spammer they reached a valid e-mail account and it is active because their garbage got read.
Delivery receipt *requests* (which is also a header in the outbound e-mail) are handled by the recipient’s mail server and NOT by the recipient’s e-mail client.  Delivery receipts are handled by the recipient’s mail server and as such provide no proof that the message was actually placed in the recipient’s final mailbox (since there may be further internal routing before reaching the mailbox) or that the recipient was able to retrieve the message from their mailbox up on the mail server or that the message got delivered into the recipient’s e-mail client and then got viewed by the recipient.  Few mail servers waste their resources to respond to delivery receipt requests.  They will reject a message during a mail session with the sending mail server if they know the message is undeliverable which results in the sending mail server issuing an NDR (Non-Deliverable Report) message back to the sender, or they accept the message and later issue an NDR if the message is found to be undeliverable but after the mail session with the sending mail server was ended (a bad scheme since spammers can make use of this belated NDR delivery to abuse the mail server to send out their garbage using what the spammer claimed was their e-mail address) .  They are not interested in expending their limited and very busy resources to send back positive feedback for the much higher volume of deliverable messages since the lack of the negative feedback (reject during mail session or NDR sent later) is itself the positive feedback.  They don’t need to tell you when your e-mail was accepted by their mail server.  Instead they send back negative feedback when their mail server rejects or will not or can not accept an e-mail.  All a delivery receipt tells you is that it got accepted (but may get later rejected) by the recipient’s mail server.  That’s all.

Read receipts:   

Requests are handled by recipient’s e-mail client.
Most users configure their local e-mail client to ignore all such requests.
Webmail clients don’t respond to these requests.
Client-side anti-spam filters may remove these headers.

Delivery receipts:

Requests are handled by the receiving mail server.
Doesn’t prove the *recipient* got the e-mail.
Most mail servers ignore such requests.
Server-side anti-spam filters may remove these headers.
When read or delivery notifications are requested by the sender, one of the following headers are added into the outbound e-mail and seen in the received copy of the e-mail:
    Return-Receipt-To           (for delivery receipt requests)*
    Disposition-Notification-To (for read receipt requests; RFC 3798)*
    Generate-Delivery-Report    (for delivery receipt requests)
    * Used by Microsoft Outlook.
Some are obsolete or non-standard (but may be de facto standards); however, Microsoft has used them at some time.  Only the last 2 are standardized by RFC.  These headers have as their value the e-mail address to which the acknowledgement message (i.e., the notification or receipt) gets sent.  This could be a legitimate sender or a spammer.  Because the Disposition-Notification-To header is defined by RFC 3798 (http://www.rfc-editor.org/rfc/rfc3798.txt), so also is its MDN (Message Disposition Notification) format, the content of the acknowledgement, defined by that RFC.  Although widely used, Return-Receipt-To is not an RFC standard header (see http://www.rfc-editor.org/rfc/rfc2076.txt) but instead a de facto standard so it may not be recognized by all e-mail clients (for those that support read receipt handling).  Also, its acknowledgement message (i.e., receipt) is not defined by RFC so there is no standardized format for a delivery reciept.