none
Using a name-to-id map RRS feed

  • Question

  • I have a time in a property list, which has (when I decode the property list 'straight') the following details:

    0040 Time 8045 Unknown 00000006 0cb34557a3dd4000 1 Jan 4501 00:00

    When I look at the msg file in Outlook Spy, it agrees with me on most details - except, critically, the tag - which it shows as 81EC (AttendeeCriticalChange).  When I open the file in a hex editor, the hex editor also shows 8045 (well, 45 80, but I've corrected for endianness).  Clearly, I need to find a way of converting 8045 into 81EC, and I guess that doing this with a lookup from a predefined list would be a bad thing.  From searching the web, I infer that I have to convert using a name-to-id map.  I suppose that this is a structure in the msg file, and that it may be different from one message file to another.  

    Searching the file in a hex editor, I can only find 45 80 once - so I think the mapping is not entirely straightforward!

    Just to make things difficult, I am developing on Linux - so techniques that rely on Windows APIs won't work for me - I need to know how the mapping table works.

    Monday, October 7, 2013 5:02 PM

Answers

All replies

  • On the low (MAPI) level, this is what IMAPIProp::GetIDsFromNames is for. See http://www.dimastr.com/redemption/utils.htm#named-props

    When you are using the DASL property name in Outlook Object Model, it includes both the GUID and the id, which Outlook uses to call IMAPIProp::GetIDsFromNames to get the property tag.

    Where are now are you accessing this data?


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Monday, October 7, 2013 7:33 PM
  • Wow!  Thanks for getting back to me.  In this case, however, I'm writing on Unix - and so I don't have access to "IMAPIProp::GetIDsFromNames".  All the Outlook OLE / MAPI decode is done by my code, so now I need to work out how to come up with an equivalent for "GetIDsFromNames".  That's why I want to know how the calculation is done.

    Of course, if (for example) the mappings never change and 81EC will always map to 8045 then there's no problem.  I can just develop my own mapping table.  I'm uneasy about this though, because I'm not confident that this will always be true, and I suspect that there must be a calculation, a formula, to get from one to the other.

    I'm also uneasy because I don't know why the name has to be obfuscated in this manner.  It just seems like obscurity for the sake of obscurity.

    Tuesday, October 8, 2013 8:38 AM
  • If your code is running on Unix, it is already too late.

    Whatever code is saving the data under Windows needs to use DASL property names or GUID/id  instead of integer tags for the named properties. Fixed MAPI properties (< 0x80000000) are fine.

    Note that the mapping is done on the per store basis, so different PST files / Exchange mailboxes / etc. will have different mappings.


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Tuesday, October 8, 2013 2:09 PM
  • I really want to understand what's going on here.  How can it be 'too late'?  Surely, the data required to make the mapping must be stored in the file?  If it isn't stored in the file then, once the .msg is copied onto a different computer, the .msg file will no longer be readable (even if the other computer is running Windows and Outlook)?

    If the data is stored in the file, then I need to know how to decode it. 

    Thanks for helping though.

    Tuesday, October 8, 2013 3:27 PM
  • Is it an Outlook MSG format?

    MSG file format is documented, and it does have a blob with the id mapping - http://msdn.microsoft.com/en-us/library/cc463912(v=exchg.80).aspx


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Tuesday, October 8, 2013 4:11 PM