A question that comes up often enough to merit a post is: "How does one block read receipts from leaving or entering my org?"
Good question. I'm glad you asked!
And to answer that we need to go into the way back machine to Exchange 2003.
In Exchange 2003 we used the IIS SMTP engine. As you know all the relevant settings were kept in the IIS metabase (taken from AD during the DS2MB 1 way process or natively there) so when it was requested that the ability to block read receipts be put into the product we obliged with a hotfix that allowed the creation of a key in the metabase to block these (after it was discovered that checking off "Do not send delivery reports" on the remote domain object did not accomplish this. More on that later.)
You can read about this in all its glory here.
While you are reading that you may notice the first sentence which mentions how editing the Remote Domain "Do not send delivery reports" will NOT block read receipts from entering/leaving your org (told you we'd come back to that).
Without getting too much into RFCs, a read receipt is not a delivery report. A delivery report is defined in RFC 1891. The mime content type of a delivery report is a multipart/report; report-type=delivery-status.
Actual shot of a delivery report below:
A read receipt is defined in RFC 2298 and has a mime content type of multipart/report; report-type=disposition-notification.
Actual read receipt found in the wild below:
A further thing to note is that delivery reports originate from the system administrator or postmaster or Microsoft Exchange Recipient account (depending on which version of Exchange we are talking about) while Read Receipts come from the recipient that has requested a receipt.
Still with me? Ok so if we circle back to the original Exchange 2003 kb it should be noted that those instructions only prevent INCOMING read receipts from entering your org. They do NOT stop internal users from sending read receipts to each other or from requesting read receipts of external users.
What adding that key to the metabase actually accomplishes is stripping of the Disposition-Notification-To mime header from incoming read receipt requests.
Read that again: read receipt REQUESTS.
Going back to the RFCs (I'll be quick I promise) there is a difference between the actual read receipt itself and the read receipt request (same goes for delivery reports and the initial delivery report request).
A read receipt request contains a Disposition-Notification-To header like the one below:
This is an important distinction as it is the read receipt request that causes the receiver to generate a Read Receipt.
This is what causes the receiver of the request to see this pop-up in Outlook:
If we strip that header the receiver is never prompted for a Read Receipt and thus never generates one.
Doing this for incoming messages is easy in Exchange 2003 since it is just a mime header we can strip.
Outgoing is not possible as the header is now a tnef MAPI property and part of the message structure.
Stopping outgoing read receipt requests requires a much greater code change investment and ultimately was never possible in exchange 2003 (for the curious and for completeness sake - a delivery report also has a corresponding delivery report request which is identified by the NOTIFY=SUCESS,FAILURE,DELAY parameters after a RCPT TO:. However unchecking "Allow Delivery Reports" on the remote domain object effectively blocks all Delivery Reports from coming out.)
Enter Exchange 2007. Yippee!
With Exchange 2007 we now have transport rules so we can totally block Read Receipts from leaving and entering, right?
Well, sort of.
For incoming read receipt requests we can create a transport rule to strip the Disposition-Notification-To header. Such a rule might look like this:
For outgoing Read Receipt requests we fall into a new twist on the Exchange 2003 issue.
Certain properties of an outgoing internally originated message are kept in a special x-header called X-ExtendedProps and you guessed it, Read Receipt request information is one of them.
This is a "pesudo-base64" encoded header that Exchange hub transport servers stamp on internal messages and which gets stripped out later by header firewall.
You can see this header by suspending the submission queue on a hub and export one of the suspended messages in there.
You will see something like this:
I'd like to pause here for a brief break and say that you will not see this header if you do a pipeline trace. It will only be visible if you export the message from the queue. The reason for this is that due to certain issues with custom transport agents in Exchange 2007 SP 1 we moved the content conversion stage further down the transport pipeline in Categorizer so a pipeline trace will only show you the state of a message PRE-conversion.
Ok, break over.
Since we have all the Read Receipt request info in this X-ExtendedProps header having a rule strip the Disposition-Notification-To header will have no effect. And transport rules cannot act on the system X-header (and even if they could very bad things may happen if you try to strip them. Just sayin').
Really the best way to strip outgoing Read Receipt requests is to stand up an Edge Transport server and have the identical rule above as an Edge rule. As stated earlier, once the message leaves the org Header Firewall will strip the X-header and replace it (in our case) with the standard RFC Disposition-Notification-TO.
This will prevent external recipients from receiving the dreaded pop-up (shown here again for effect) which will generate a incoming read receipt:
A second option is to deploy the Office ADM template in a GPO to remove the ability of users to send out read receipt requests. (You will still need the hub transport rule to block incoming Read Receipt requests).
Now we can move on to Exchange 2010 (can I hear a double yippee?).
With Exchange 2010 we have many new additions to transport rules which would make the subject of a great blog post on its own. The one new addition we are concerned with here is the ability to act on messages based on class. Specifically here we are concerned with the read receipt class. With Exchange 2010 we can craft a transport rule to drop messages based on the read receipt class as shown below:
Now the above Exchange 2010 rule should solve our issue! This is great and wonderful! Finally no read receipt requests leaving OR entering my org!
Well... not so fast.
You see, what the above rule does is block the actual read receipt (the multipart/report; report-type=disposition-notification content type. Check the beginning of this blog post if you forgot. Its ok I'll wait).
This rule will not block the original read receipt request (shown here again because I believe in learning through repetition):
So we are back to either:
So at the end of all this we've learned that while finally in Exchange 2010 we can block actual read receipts with ease, it still takes a bit of doing to block the read receipt request and be rid of all types of RRs entirely. But it is possible.