Re: [otlkcon-devel] may we help each other?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Luca Bortot wrote: > >> Charles N Wyble wrote: >> >>> Well have you looked on MSDN? >> >> [...] >> >>> What files are you refering to? The Visual Studio files? >> >> yes. >> >> maybe it's my limit, but I found this documentation quite confusing: >> it's the kind of "read three times to begin understanding" > > Nah. I don't think its you. It takes me several passes as well. I think > everyone has to do at least 2 passes and a rain dance while having there > toes pinched and there arms twisted or something like that to > understand the ms docs > :) Hello Charles and and Luca, I'd like to echo Charles' sentiment. I'd also add that some of the documentation seems to be outright misleading if not technically incorrect. Then, there's all of the undocumented MAPI properties that Outlook *requires*, plus the "optional" MAPI stuff that Outlook *requires*, etc. One key issue is the difference between writing a general MAPI service provider versus writing a MAPI service provider for use by Outlook... Huge difference. All of the publicly available documentation is for general MAPI service providers, not Outlook MAPI service providers. InsideMAPI is a good start, but extremely outdated. I'll add that I've been a subscriber of this list for a long time, but am finally posting after seeing a nice bit of activity lately. 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. A bit about my background: I have about 11 years Windows programming experience, mostly with C and C++ writing GUI apps, NT services, TCP/IP communication modules, and some device drivers (WinCE and some Windows and NT). I've done some work with Simple MAPI and spent about 6 months working with Enhanced MAPI. I have other experience not related to this project, but I'll leave that for another time. Is there any interest in help from myself or my company, SourceXtreme? If so, how can I help, or what would be the most helpful way my company could contribute to this project? > -- > Charles N Wyble > Homepage: http://www.thewybles.com/~charles > Blog: http://jackshck.livejournal.com > Developer/Consultant. 30.00 an hour is my fee. Regards, Jason Nocks [EMAIL PROTECTED] or [EMAIL PROTECTED] 610.457.8648 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB791I3CryLfCgqRkRAssDAJ9ckFJG+5IKLFTop4APrBF4XvkL0QCbBa6z zuUgVBJEzf7fz0sATVb4Sgw= =VTBL -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
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] 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
Re: [Fwd: Re: [otlkcon-devel] undocumented MAPI in Outlook]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > [EMAIL PROTECTED] wrote: >> >> I haven't looked into the SapiMapi subproject too much, but it looks >> like >> it is basically intended for similar purposes. > > SapiMapi is a testing utility put together to analyse > Mapi objects and properties in memory. I couldn't use > OutSpy because it relied on Outlook properly loading > the Mapi plugin before it can do anything. That's a > problem if the plugin has not got to that point yet. Yes, I know of that problem as well :) > I haven't seen any open-source Mapi inspectors yet. Are you familiar with the message store viewer from Microsoft? I wouldn't call it open-source, but I do have source code for a version of it. Unfortunately, due to M$ licensing, I don't think I can publicly redistribute the sample source code. Ugh. Perhaps I can dig up the location of it. I found the message store viewer from Microsoft to be helpful for calling one MAPI function at a time. Very helpful when the message store is crashing Outlook (yes, I admit to having caused this to happen more than a few times). With the source code, you can put a breakpoint in the Message Store viewer, have it just load the message store, then put a breakpoint in the message store code itself, then actually step through the message store code. A madenning process without any code at all from a message store viewer. Prior to finding the Message Store viewer source code, I started constructing my own sample MAPI client primarily for debugging purposes. Speaking of debugging, were you ever able to locate a debug version of the MAPI DLLs? Oh, and I do agree that there are very few GPL or LGPL MAPI tools available, present company excluded of course :) > I also needed something that can do scripted testcases > and something that can easily be installed by users. > For example, we can ask someone to install SapiMapi then > run some stock data retrivial scripts for diagnosis. Sounds quite useful. I ran into a situation where someone told me a MAPI service provider didn't work, only to find out that it was never installed. Very frustrating... > I big issue is displaying objects for inspection during > debugging. If, say, a table you are returning to > MAPI is crashing Outlook, then you need to inspect > that table to see if any data is off or missing. > Since most Mapi browsing programs work *through* Mapi, > that is hard to do. Sapimapi has a client-side library > routines that serialize the Mapi properties and tables > in XML and sends them via a shared memory segment. Very cool indeed. Much better than the simple logging I was doing to gather similar information. > - > Kervin Regards, Jason Nocks -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB+UjM3CryLfCgqRkRAj/BAJ96GKqQ/dpCLUbwTD6wSjE/16JshgCfSI0l r++tKCLghaHpr7saoUO1QOk= =k7/o -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
Re: [otlkcon-devel] Exchange 5.5 Server project
On Tuesday 01 February 2005 01:18 pm, Luke Kenneth Casson Leighton wrote: > dear outlook connectors, > > i wrote last week to say that i'm doing an exchange 5.5 server which > basically means implementing a MAPI server. My understanding (in MAPI speak) is that Exchange acts like the server side of the MAPI transport provider. Exchange *also* implements a MAPI message store and address book (and...). Not having access to the source code behind Exchange, I'm basing this assumption on the fact that the MAPI API is also available for code running on the server and that you can access folders, etc. similarly to accessing the message store on the client side. No doubt there are some differences, of course. > i've since discovered a few things: > > 1) the MSRPC Nspi interface's data structures are >identical to those in mapidefs.h (according to >/usr/include/wine/windows/mapidefs.h) This seems to support the notion that the data between Outlook and Exchange is basically serialized MAPI properties. > 2) the otlkcon0/mstore/*.cpp code looks like a more "full" and >"complete" version of what i'm rather foolishly trying >to implement as hard-coded data structures in my >network-reverse-engineering efforts. There's still some distance to go to implement all of the MAPI interfaces (plus all of the methods Outlook expects to be supported in those interfaces). But Kervin (and others?) has done a great job getting an initial MAPI message store to load in Outlook. This is not a small feat. > therefore, i would envisage a situation where porting and tweaking > otklon's mstore code to a linux FreeDCE service behind an Nspi > and EMSMDB interface would result in well... a free software > exchange 5.5 server where you didn't have to plug in DLLs on > the client or the exchange server. We might be able to have the best of both worlds. Two projects with significant overlap and code reused between them. How does that sound? Some people might want to install a custom service in Outlook that communicates natively (and more optimally) with an existing groupware server. Others may just want to get rid of Exchange and would be happy with an Open Source MAPI server. Not having to install binaries on every Windows desktop will certainly appeal to many. Personally, I don't see the two projects as mutually exclusive. Actually, I seem them as having a great deal in common. I think the greatest unknown is "undocumented MAPI properties" that Outlook relies on. I think these need to be figured out whether you are talking directly to Outlook as a local message store DLL, or as an Exchange server. > how about it? > anyone interested? Yes! > l. Regards, Jason Nocks pgp37WMRYWkQ4.pgp Description: PGP signature
