Exchange and Outlook 2010/2013 - Read- and delivery receipt design is completely useless


  • The current implementation of read receipt and delivery receipt does not fulfill the needs we have to such a functionality.

    According to the older thread "Read receipt shows wrong sent time" it is "by design" that the read receipt does not contain the sending time of the original message, instead it contains (quite senseless from my point of view) the time when the receipt itself has been sent.

    The only information in the read receipt is the subject of the original mail which may be identical in longer mailthreads to several (dozends of) mails.

    So in this implementation you are not able to find out to which message a read receipt really relates.

    The delivery receipt does contain an "ID" but it also is unclear for a outlook user where this ID does belong to because you cannot find this ID anywhere in the sent mail.

    So we cannot prove at all if a single mail in a thread has been read or not.

    The printout of such a receipt does not have any information that can be used in a meeting or discussion.

    Since this situation obviously lasts for more than two years I'd like to ask how I can get a working read-receipt-functionality for professional eMail-handling? Didn't I see or recognize something obviously?

    Currently I have a quite annoyed customer who wishes back his Outlook Express!!!! I invested some time to make him change to outlook and now he is missing some professional features.

    Thanks for any help in this.



    Monday, July 15, 2013 11:03 AM

All replies

  • So, do you mean it was absolutely okay with earlier versions of Exchange? As far as I know, Message disposition notification (MDN) are compliant to RFC 2298. When I look through RFC 2298, section 4, I understand that the MDNs are at UA or user discretion and not the server that processes it. Server handled events will be triggered only when the message reaches an MTA or so ( please read the linked RFC to see understand what I mean). If that's the logic being followed here, MDNs are probably unreliable sources of being dependant of for tracking read or unread messages.

    Well, that is my thought; you may still need what you are looking for. Yet, can I ask the reason why you are so much interested in MDNs part?

    Milind Naphade | MCTS:M (Exchange 2007 and 2010) | RSS Feed

    Monday, July 15, 2013 11:20 AM
  • Thanks for this quick answer. It seems that the problem does not lie in the content of the MDN sent by the Exchange server.

    If I look into a copy of such a sent MDN with Thunderbird, it tells me for example, that my mail, sent on 15th Juli 2013 14:43:47 (UTC+1) has been read  on 15th Juli 2013 14:50:08, which is correct.

    But in combination with Outlook I get the same MDN displayed like follows:

    Your message at... subject... sent Monday, 15. Juli 2013 14:51:30 (UTC+01:00)... has been read on Monday, 15. Juli 2013 14:51:16 (UTC+01:00) (Text translated into German)

    So Outlook exchanges the timestamps and falsifies the content of the MDN.

    This does only appear in combination with an Exchange server. If I work with a POP3 account and Outlook and send a message to an Exchange 2010 mailbox the correct timestamps are displayed within the returned MDN-message.

    So this different behaviour between POP3 Mailaccounts and Exchange Mailboxes in Outlook indicates a bug - but this is denied in the former thread "Read receipt shows wrong sent time".

    I do not have any experiences with other Exchange servers than 2010. This problem appears with a professional hosted Exchange server outside es well as with an inhouse Exchange server.

    The user scenario is simple. The customer wants to know if a mail has been read by the receiver. In some cases he also wants to print out this MDN. This is the original function of reading confirmations and currently does not work.

    Could you help? Thanks, Conny


    Monday, July 15, 2013 1:18 PM
  • Well, that does look little weird. If Thunderbird shows a correct time stamp and then outlook fails to do so then there must be something wrong. A quick check though, can you confirm  your Windows Regional settings are set correctly and similar settings are also applied to Thunderbird or other clients that you have tried using. Outlook by default will use Windows Regional Settings defined in Regional Settings control panel applet.

    Milind Naphade | MCTS:M (Exchange 2007 and 2010) | RSS Feed

    Monday, July 15, 2013 1:27 PM
  • Yes, I can confirm: all involved systems are set to German (DE-de), the timezone on all systems is UTC+1

    Regards, Conny


    Monday, July 15, 2013 1:36 PM
  • Hi,

    Firstly, let’s double confirm the settings on the user’s mailbox is set correctly:

    Please check the “ReadReceiptResponse” parameter by running the “

    Set-MailboxMessageConfiguration” cmdlet


    If you have feedback for TechNet Subscriber Support, contact

    Simon Wu
    TechNet Community Support

    Tuesday, July 16, 2013 8:17 AM
  • I've run Get-MailboxMessageConfiguration ;-)

    The setting ist (of course): DoNotAutomaticallySend.

    But please take a look at the thread above. My problem is the content of the MDN (exactly the display of wrong content in Outlook in conjunction with an Exchange server) in some scenarios.

    Thanks and best regards



    Tuesday, July 16, 2013 9:03 AM
  • Unfortunately this problem is still unsolved. To clarify the problem, here a small table with my tests

    I've used Outlook on all Clients, 2010 and 2013.

    Sender: sends initial mail and gets the Reading Confirmation

    Receiver: gets the initial mail and sends the MDN


    Sender     |     Receiver     |     MDN Display

    POP3        |     Exchange   |     correct

    Exchange |     Exchange   |     fail (displays wrong "sent"-time)

    POP3        |     POP3         |     correct

    Exchange |     POP3         |     fail (displays wrong "sent"-time)


    It is obvious this cannot be a "feature". This is different behaviour depending on the senders Account type and one of this two scenarios must be a bug.

    Could you help me further on this, please?

    Thanks and regards



    Tuesday, July 30, 2013 10:33 AM