none
Delivery reports sometimes appear before their message. Using EWS, is there a way to consistently get delivery reports after the message they correspond to? RRS feed

  • Question

  • Environment: Exchange 2010+SP3

    I'm using SyncFolderItems and notifications to process all items coming into a mailbox.

    The application needs to correlate delivery reports (and NDRs, and other custom messages) to the original message.

    In some circumstances (maybe when Exchange is heavily loaded, we're not sure), some notification messages appear in the mailbox (as obtained by using SFI) some time before the original message, and in extreme cases we have logged evidence of the original message appearing over 3 minutes after the notifications arrived.

    As we delete the notifications when we process them, we lose the correlation of them to the message (which has yet to arrive).

    So, my question is, is this out of logical order delivery to be expected, and might some alternative way of getting the messages from the mailbox ensure we'd get the original message before the notifications?

    Friday, October 30, 2015 3:50 PM

All replies

  • While this doesn't answer the question as posed (how to get DRs after the message they correspond to), I've discovered a flaw in my code that may explain the 3 minute delay we experienced.

    I use SyncFolderItems with the maximum allowed number of items (512). When there was a large number of items returned I passed them all to BindToItems and eventually found that the 251'st item had an error recorded against it, so I lost that item.

    The failed item is due to an Exchange Server limit setting; the event viewer showed this occurring:

    Mapi session "..." exceeded the maximum of 250 objects of type "objtMessage".

    Quite how Exchange managed to return the subsequent 261 items without a repeat of the error I have no idea, but that's irrelevant.

    Although I lost the item initially, it would be picked up when the Exchange connection was disconnected/re-initialised, so I believe that would have accounted for the 3 minute delay we logged.

    My workaround is to call BindToItems in a loop with smaller batches of items so as not to encounter the 250 (default value) limit.

    My solution to the general out of order delivery is to retain any unmatched notification messages for a short period.

    Tuesday, November 10, 2015 12:30 PM