[Fwd: Re: [otlkcon-devel] undocumented MAPI in Outlook]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't think this actually went to the list. Sorry if it did and this results in a duplicate response. Regards, Jason Nocks - Original Message Subject: Re: [otlkcon-devel] undocumented MAPI in Outlook From:[EMAIL PROTECTED] Date:Tue, January 25, 2005 6:11 pm - -- - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > [EMAIL PROTECTED] wrote: >> Implementing *all* of the MAPI >> interfaces for every MAPI object you want to implement would simply be maddening. Reverse-engineering which MAPI interfaces Outlook is going to use is almost, but not quite, as madenning. > > Jason, > this last sentence is quite scary :-) Sorry about that. Just don't want to paint an overly optimistic view. The road ahead is a bit long and arduous. Fortunately, there seem to be a few key ingredients starting to come together (more than 1 or 2 people and possibly some people with some time to dig into some of the more time consuming elements). > It's _surely_ too early for me to think of it: I would better go on studying and practicing MAPI. Not necessarily. Ideas are always welcome (speaking for myself at least). They are free and always worth at least that much. > So pardon me if I dare to give a suggestion: what about a "MAPI sniffer"? A piece of software that presents itself as a MAPI provider and just forwards Outlook requests to the Exchange MAPI provider and passes back the answers, logging all the traffic. We had exactly the same thought when we started working on a message store about a year and a half ago. This could definitely be done either "on the wire" or at the MAPI API level, like a proxy. We haven't done either of these. Even stubbing the entire MAPI API and having it wrap another message service seems like still a lot of work. It turns out that there's a fairly easy way to get much of the information you need. There are a number of MAPI message store viewers available, commercial and non-commercial, with and without source. MAPI is all about MAPI properties. MAPI objects are essentially just one or more MAPI properties with some functions to get or modify those MAPI properties. And MAPI properties are primarily available through the message store. In fact, I would call Outlook basically a "message store viewer". The main exception is address books, but they were moved into the message store when the "Contacts" folder appeared. So, a message store viewer (other than Outlook) lets you view *most* of the information you need, in a more controlled fashion. The biggest remaining problem is figuring out what the MAPI properties actually mean. Some of the MAPI properties are documented. Many of the *interesting* ones are not. The trick is making sense out of the 160 MAPI properties Outlook requests when it wants to display one MAPI object. Guess how many of the 160 MAPI properties are documented... For added confusion, a number of the properties are really the same. Plus, things get complicated due to Outlook trying to be smart, the way named properties work, etc. I don't want to dump too much low-level technical details in this particular email, just trying to give you an idea of what problems are faced. Also, I don't remember all of the details in exact detail off the top of my head. MAPI sometimes gets a bit more complicated down at the nitty-gritty detailed level. Reverse engineering Outlook's expectations isn't really difficult work, just incredibly time consuming. So, for those doing it in their spare time, well, there's just not tons of time to spare. Pardon the pun. There are some websites with some very helpful documentation about some of the undocumented properties, but much of what we found we have to do is trial and error, observe and make educated guesses, spray and pray, etc. Perhaps just documenting these MAPI properties would be an area where you could get a better understanding of how MAPI works while contributing some time if you have it. I'd be happy to share the properties I'm aware of to get the list started if this idea seems worthwhile. I would think that the same MAPI properties would also be transmitted "over the wire" for anyone working on the "over the wire" exchange replacement project. > You could see the properties Outlook requests and try to clue from the answers what is their semantics. Right, you can also just log what Outlook is trying to do to your service, do the same thing to exchange, observe what exchange does and try to mimic it. This is what we were doing. It works, but takes a lot of time. We also started working on writing automated validation tests for the message store we were working on. Basically, using a tool that would parse text files, reading expected MAPI properties and comparing them to actual MAPI properties in the message store. We called this a "Mapi Property Inspector".
Re: [otlkcon-devel] undocumented MAPI in Outlook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > [EMAIL PROTECTED] wrote: >> A simple example is MAPI named properties. Technically, named properties >> are *optional*. A MAPI message store doesn't need to support named >> properties according to the MAPI documentation. But, if you want to work >> with Outlook calendar entries, todo items, etc., you really *do* need to >> support named properties, etc. Many of the *interesting* Outlook >> properties are undocumented named properties. >> >> If you want Outlook to open your message store and work with it the way >> Outlook works with the Exchange message service, etc., you need to >> implement and support named properties. The MAPI documentation, Inside >> MAPI book, etc. may indicate that a MAPI message store doesn't really >> have >> to do this, but Outlook works the way it works and wants what it wants. >> And, what Outlook expects from a message store is just not documented, >> not >> even in the Inside MAPI book. > that's what I thought first reading your mail. > Studying MAPI I'm understanding how this "standard" has been built: it > has to look like a "standard interface" for leagal issues (monopoly...), > yet it lets a vendor (MS?) implement lots of undocumented features. Well, you might be right. It could also be symptomatic of big, bloated, upfront design. Enhanced MAPI hasn't changed in about a decade. It's still at 1.0. Too complicated and bloated to change it. It's written on top of ancient C-style COM, not even COM+. > But, excuse my insistence: can you make some example of such > undocumented properties and the Outlook feature they implement? Sure, not a problem. Sorry I wasn't clearer earlier. Outlook asks for a property tag such as: 0x36D00102 I don't believe that this is documented anywhere by Microsoft. This MAPI Property tag consists of an actual ID and a Type. The lower 16 bits (the 0102 part) is the property type. In this case, 0x0102 represents PT_BINARY (byte-string, an SBinary value), basically the type used for MAPI Entry IDs. The upper 16 bits (the 0x36D0 part) is the actual identifier. Outlook expects this to be a Calendar Entry ID. If you don't return the Entry ID for the Calendar folder when MAPI asks for this property, Outlook won't treat your Calendar folder as a Calendar folder. The Inside MAPI documentation may refer to specifying the type of items that are contained within a folder (the PR_MESSAGE_CLASS type), I don't recall off the top of my head. You would set it to "IPM.Appointment" (also undocumented). This type could (should?) also be specified on each entry within the Calendar folder. Until I set all of these properly (and probably a few other magic incantations), I don't believe that my folder truly displayed as a calendar folder containing calendar entries (as opposed to just an email folder containing email entries). Not sure how clear the above is. The named properties are just a bit more complicated than this. This is the level of detail that needs to be understood to work with MAPI properties for reverse engineering. I believe that the same understanding is probably necessary for either "over the wire" reverse engineering for replacing Exchange or for writing code for the MAPI API. > thanks a lot > Luca Hope this helps, Jason Nocks -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB9t3B3CryLfCgqRkRAvbzAJ4/nN8wyoIPrn0MOLOI/gxyGqZdhgCeOLcI J8Thkf33QS+lU223q3naHEc= =OxsA -END PGP SIGNATURE- --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ otlkcon-devel mailing list otlkcon-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
[Fwd: Re: [otlkcon-devel] may we help each other?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Did I not send this to the list as well? Not sure why "Reply" seems to be replying to the author rather than the list. Could be I have something misconfigured in squirrelmail. Sorry about this. Cheers, Jason - Original Message Subject: Re: [otlkcon-devel] may we help each other? From:[EMAIL PROTECTED] Date:Mon, January 24, 2005 3:36 pm - -- - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Hello Jason, Hello Kervin, Thanks for the response. > [EMAIL PROTECTED] wrote: >> I'm the lead developer of the the MAPI toolkit at SourceXtreme, Inc. We also have the start of a MAPI message store and MAPI transport provider built using our MAPI toolkit. We haven't been working on it as fervently the last few months, but would happily join efforts with this group. We have no problems with GPL, LGPL, or dual-licensing. We do prefer C++ over >> straight C, but are willing to work with those who prefer straight C. >> >> We also have a separate IMAP library we would be willing to release under >> the same licensing terms. > > It would be good if we can combine efforts somehow. I'm > sure we would have a better chance of succeeding if we > did. Yes, couldn't agree more. > What does your toolkit do exactly? Well, I'll do my best to sum this up in short. First off, the toolkit doesn't do a lot on its own. It is primarily an Object-Oriented library to encapsulate much of the annoyances of working with MAPI. The *intent* is to write less lines of similar code when working with MAPI. The goal is to end up with code that is easier to read and maintain. For example, normally, when working with MAPI you might write 2 or 3 lines of code for every MAPI property, something like the following (just typing this up - forgive any typos): SPropValue Props[4]; memset(&Props, 0, sizeof(Props)); Props[propNum].ulPropTag = PR_DISPLAY_NAME; Props[propNum++].Value.lpszA = strdup(MESSAGE_STORE_NAME); Props[propNum].ulPropTag = PR_ENTRYID; Props[propNum].Value.bin.lpb = (LPBYTE)entryID; Props[propNum++].Value.bin.cb = sizeof(CUSTOM_ENTRYID); Props[propNum].ulPropTag = PR_VALID_FOLDER_MASK; Props[propNum++].Value.l = FOLDER_IPM_SUBTREE_VALID | FOLDER_FINDER_VALID | FOLDER_VIEWS_VALID | FOLDER_COMMON_VIEWS_VALID; With the MAPI Toolkit, you might instead write: MapiPropList propList; propList.AddProperty(PR_DISPLAY_NAME, new MapiStringValue(MESSAGE_STORE_NAME)); propList.AddProperty(PR_ENTRYID, new CustomEntryID(entryID)); propList.AddProperty(PR_VALID_FOLDER_MASK, new MapiLongValue(FOLDER_IPM_SUBTREE_VALID | FOLDER_FINDER_VALID | FOLDER_VIEWS_VALID | FOLDER_COMMON_VIEWS_VALID)); Does that help? Building up rowsets, etc. the idea is to encapsulate as much as would be useful, including allocation, deallocation, etc. Thoughts? > The connector is currently C++ Glad to hear that. > - > Kervin Cheers, Jason Nocks - -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB9VxQ3CryLfCgqRkRAiSlAJ9fdfZwHSKFztAxRCbyKAe7mMTGJgCfTbv1 kDjvESMsafg56hlo6oGzeec= =u2D3 - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB9t9U3CryLfCgqRkRAvXiAJ0aLCPe81iJJqmYYfBC+OBZBfDNywCfffBb fa3mooYLJtTRB5Pm9T7PsS4= =2YKO -END PGP SIGNATURE- --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ otlkcon-devel mailing list otlkcon-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
