The evil read receipt

The ability to have the recipient confirm receipt of one’s email has existed for a long time. Unfortunately this functionality is not used with due care, and creates headaches.

The intent of read receipts is fine — knowing that you important message has reached the recipient can be quite comforting. Included in the intent of RFC 3798 is also the notion that one would request a read receipt only with consent of the recipient. Two improper actions are happening all too frequently:

  1. Some senders request read read receipts without consent, instead indiscriminately requesting read receipts for just about anything.
  2. Some recipients allow automatic read receipts to be sent. This is even worse, because they are replying to spam and to “no reply” email addresses as well.

In our opinion, the practice of read receipts has become a circus. Especially those clueless clowns with the automatic read recipients — are you trying to create the impression that you have a super busy high-profile job?

The result of these poor practices is a lot of email noise. Read receipts can clog our email queues to the point of detriment of the delivery of actual useful messages.

As of today, we have implemented a system that strips read receipt headers from incoming email. This should result in no (or very few) requests for read receipts still reaching recipients.

If you do not like this new approach, then we regret the inconvenience. If knowledge of the delivery of your message in important, we recommend you use the “Track Delivery” function in cPanel — it will confirm if your message was sent successfully.