Compartilhar via

MAPIToMIME Changes Source Messages

  • Artigo

This week, we shipped the February Cumulative Update for Outlook 2010. One of the fixes in there relates to the MAPI<->MIME conversion API. In particular, with Outlook 2010 if you use MAPIToMIMEStm to convert a message to EML you’ll see the source message get updated. This didn’t happen with Outlook 2007. The reason for the change in behavior has to do with how we handle conversation threading, particularly for messages that don’t already have some of the conversation properties already stamped on them. In order to preserve threading should the MIME message come back in to MAPI (a scenario which occurs with POP3/SMTP profiles and replies), we would stamp the conversation properties on the source message during the export.

In general, this is fine, but it did cause a problem for some vendors who needed their export to not modify the source. So for them, in the February CU we enable a new flag:

 #define CCSF_PRESERVE_SOURCE  0x40000 // don't modify the source message

Pass this new flag in to MAPIToMIMEStm and we’ll bypass the new code that saves changes back to the source message.

One caveat: We may still make changes to the message. This flag skips the SaveChanges call that commits the changes. So if your code subsequently calls SaveChanges, you’ll see the changes made during the export get committed. Of course, if your code is calling SaveChanges, you probably won’t be using this flag in the first place.

Enjoy!

Comments

  • Anonymous
    February 29, 2012
    Steve, what happens in the older versions? Would IConverterSession bark at the new flag? Do we need to check the version first before using the flag?

  • Anonymous
    February 29, 2012
    The comment has been removed

  • Anonymous
    February 29, 2012
    We had to completely rewrite the conversion procedure in our software products in order to avoid this BUG! I just couldn't believe my eyes when I found that my conversations became corrupted after conversion! Actually, this new flag will not help at all. We're now doomed to copy message before converstion, because nobody guarantees that the end user has the latest CU. :(((

  • Anonymous
    February 29, 2012
    Moreover, it kills original PR_TRANSPORT_HEADERS which is totally unacceptable! I'd wish to see a single vendor that approves this weird behaviour.

  • Anonymous
    March 04, 2012
    I tell you about this problem in June 2011, but you say 'hard to believe'. As i understand this flag not help us. We already have procedure to avoid this bug. But thank you for additional information.

  • Anonymous
    March 04, 2012
    I do little tests, Outlook 2003, 2007 and Pre-CU 2010 ignore this flag without error.

  • Anonymous
    March 04, 2012
    Ah - you must be sharky72. What I found hard to believe was that you were seeing this problem having opened the message read-only. And I was right - the source message does not get changed if you open the message read-only. However, if you do that, the MAPIToMIMEStm call fails with MAPI_E_CALL_FAILED.

  • Anonymous
    March 05, 2012
    Yes it's me. Of course message not changed, but and conversion not complete :) Using read-only mode useless in this case. IMHO a very strange way to stamp the message. The same thing that export a Word document to Text changed content of original .doc.

  • Anonymous
    March 06, 2012
    This is an artifact of the primary purpose of this API being to handle inbound/outbound conversions for SMTP and POP3. And for that scenario, this behavior makes perfect sense. Anyway, you've got a flag now.