Outgoing is not possible as the header is now a tnef MAPI property and part of the message structure. If we strip that header the receiver is never prompted for a Read Receipt and thus never generates one.ĭoing this for incoming messages is easy in Exchange 2003 since it is just a mime header we can strip. This is what causes the receiver of the request to see this pop-up in Outlook: This is an important distinction as it is the read receipt request that causes the receiver to generate a Read Receipt. 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).Ī read receipt request contains a Disposition-Notification-To header like the one below: What adding that key to the metabase actually accomplishes is stripping of the Disposition-Notification-To mime header from incoming read receipt requests. They do NOT stop internal users from sending read receipts to each other or from requesting read receipts of external users. 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. The mime content type of a delivery report is a multipart/report report-type=delivery-status.Ī read receipt is defined in RFC 2298 and has a mime content type of multipart/report report-type=disposition-notification.Īctual read receipt found in the wild below:Ī 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.
A delivery report is defined in RFC 1891. Without getting too much into RFCs, a read receipt is not a delivery report. 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). You can read about this in all its glory here. 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. In Exchange 2003 we used the IIS SMTP engine. A question that comes up often enough to merit a post is: "How does one block read receipts from leaving or entering my org?"Īnd to answer that we need to go into the way back machine to Exchange 2003.
0 kommentar(er)
