Everything you wanted to know about read receipts and delivery reports but were (understandably) afraid to ask

Published 02-23-2011 02:23 PM 108K Views

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. < p>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:

  1. Create an incoming rule on your hub and an outgoing rule on your Edge to remove the header.
  2. Set an incoming rule on your hub and use the Outlook ADM file to create a GPO to remove the option to request Read Receipts

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.

Tom Kern

Not applicable
that was  a hard one :)
but cool writing
Not applicable
Is it possible to allow requests in but stop the Exchange server from automatically sending read receipts when users read new emails via IMAP? I've seen many spam senders adding headers to trick Exchange (and other servers) to send read receipts. Users don't expect a message to be sent automatically by the server just because they use IMAP to read messages, especially when they have set "Never send a response" in OWA.
Not applicable
Peter if you are running Exchange 2010 then a transport rule based on the "Read Receipt" message class with an action of Delete should work.
But this will block RR generated by OWA/Outlook as well (but you will get the inital RR request come in as described in my post)
Conversely you can set the IMAP client to not send RRs.
Not applicable
Peter - this can be a complicated topic.  If people read mail via IMAP, your best chance of stopping read receipts is if you can strip the "read receipt request" header from messages before the messages reach the people inboxes.  Tom's final section of "1. - Create an incoming rule on your hub and an outgoing rule on your Edge to remove the header." addresses this.

Ones messages are in the inboxes, you're at the mercy of each person's IMAP client.  Maybe their client ignores read receipt requests, maybe their client acts on read receipt requests (and sends out receipts).
Not applicable
tomkern and jacob: Some users wan't the functionality so I prefer not to do a total block. The problem is that it isn't the client that sends the RR but the Exchange server (as far as I can tell). The reply contains (among other things) this lines:

<meta name=3D"Generator" content=3D"Microsoft Exchange Server">

Disposition: automatic-action/MDN-sent-automatically; displayed

I've tried this with both Alpine and Thunderbird (with notifications in the client turned off) as imap clients with the same result. A message sent back too the address specified in the header of the message. Tried with the following DATA part in the smtp transaction:

Return-Receipt-To: peter@reuteras.com
Disposition-Notification-To: peter@reuteras.com
To: <user@example.com>
From: <peter@reuteras.com>
Subject: Test

Will this trigger an automatic reply.

Not applicable
Peter, you can try stripping that header with a transport rule.

Not applicable
Tom, that was some good writing..  

Anyway, why are Read receipts sent automatically from Mobile devices (read Blackberry - not "activesynch" type devices)?  In other words, are there other causes at play that are not mentioned here?
Not applicable
@tomkern: I rather not add a rule to strip the header since some users actually use the RR functionality. Isn't there a way to stop the imap server from sending the RR instead?
@Sankar: I guess you have the same problem that I have if your phone uses imap.
Not applicable
@sankar, you would have to ask RIM that question but ultimately BES device understands the header and sends the RR but the abilty to prompt the user whether or not to send the RR initially was not built into the OS.
The same is true for WM, btw.
@peter, whether you use IMAP or MAPI the backend server where your mailbox resides is the same (I am assuming you are using exchange imap access) thus if I allow the RR request in you will get prompted regardless of access protocol used to retrieve the message.
Its all in the same destination. There is no native way to filter RR requests based on protocol.
Not applicable
That's really good one...
Not applicable
@tomkern: The problem is that there is no prompt since the server sends the message and not a client. I know it's the same store and I don't want to filter RR requests just stop Exchange from automatically sending them.

I've played around with a raw connection to the server opened with openssl s_client and as soon as I send the following IMAP command to the Exchange server (a05 is the current command number and 31 is the message number in the current folder):

a05 fetch 31 body[text]

the exchange server sends the RR reply. The only expected result is to get the message body and add the "seen" flag to the message. There is no client involved in this test that can send the RR-message.

The exchange server also adds the recipient account name to the response telling the spammer the name associated with the email address. God to have for them to personalize the next spam message.
Not applicable
@peter you can create a transport rule to only block RRs for your IMAP users (create a group and add the IMAP accounts and block RR message class based on this group membership).

Not applicable
@tomkern: Thanks, I'll suggest that to the persons responsible for the Exchange server since the default behaviour is against local laws (acknowledgement without consent from the user, especially for users with protected identities). But I would really like to see a fix for this in the IMAP server instead so that users has the possibility to answer RR when used properly and for valid purposes.

I see this as a serious information disclosure bug (since you get name from email address and also know the second the user reads the message) and wonder how many users that know about this behaviour?
Not applicable

How do I know if someome has included a disposition notification attached to an email they sent me?  Is there annyway to prevent this?

Version history
Last update:
‎Feb 23 2011 02:23 PM
Updated by: