[Kroupware] Re: client compatibility

[Kervin L. Pierre]

Interesting article.  I try to get a full copy.

But this is why working with the MAPI layer is promising.  By replacing 
the default MAPI Transport Provider,  one never has to work with the DCE 
/RPC/whatever MS feels like.  The transport layer is replaced entirely, 
we're looking at using IMAP only initiallly, for instance.

There is still some reverse engineering involved, but it is limited to 
when we try to translate the outlook calendar properties ( data ).  Work 
on this has been started in some places on the web. eg
http://www.cdolive.com/cdo10.htm

I think the difference in approach with the author of the article is 
that they are trying to use the MS provided default Message Store and 
Transport provider to speak to a remote server.  I think they'd fair 
better if they tried to replace the default MAPI service providers on 
the client side entirely.  Which is what everybody else who's selling an 
exchange replacement is doing.

--Kervin


Henning Holtschneider wrote:
> --On Montag, 20. Januar 2003 15:38 -0500 "Kervin L. Pierre" 
> <kervin@blueprint-tech.com> wrote:
> 
>> In the end I think it's a harder fight tricking outlook into thinking
>> that it's speaking to an exchange server or something similar, than it is
>> to provide alternate default MAPI service providers for the outlook
>> client.
> 
> 
> Did you read the article in the February issue of Linux Journal? I think 
> the most valuable part is this:
> 
> ----- snip -----
> In Outlook's Workgroup mode, or when connected to an Exchange server, 
> its data moves around in binary form. That binary data becomes 
> impossible to recognize by an uninformed observer.
> 
> While researching, I found a developers' site on SourceForge.net that 
> was porting Open DCE to Linux. I e-mailed one of the developers who 
> wrote back and mentioned that the Open Group contributed the code.
> 
> I went to the Open Group's web site, searched the archives and found an 
> old article mentioning that Microsoft had licensed DCE. We downloaded 
> the Open DCE code and, using the engine, shook hands with Outlook and 
> then Exchange. We knew more about the transport protocol as a result. We 
> also understood the presence of binary data streams.
> 
> What we discovered is Microsoft uses the distributed computing 
> environment (DCE) as its transport when using Exchange and Outlook in 
> the Corporate Workgroup mode. Microsoft provides a programming interface 
> on top of DCE, which it calls MAPI. Still, underneath MAPI exists an 
> open standards-based protocol (DCE), which Microsoft bought from the 
> Open Group and modified.
> 
> One of the default functions in DCE automatically translates ASCII text 
> into binary objects. Microsoft leaves the binary object undocumented. So 
> most of the MAPI properties programmers tag wind up as binary code they 
> would not recognize. To make matters a little more complex, Microsoft 
> embeds the binary property code in a large array of null binary data, 
> thus hiding it.
> 
> We began to understand the transport, but we realized that Outlook sent 
> MIME attachments to other Outlook clients. Those attachments did not 
> transform themselves into binary data. We concluded that Outlook also 
> used encapsulation to pass attachments around, which led us to the TNEF 
> object.
> 
> ----- snap -----
> 
> hh
> _______________________________________________
> Kroupware mailing list
> Kroupware@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kroupware