[Kroupware] Re: client compatibility

[Henning Holtschneider]

--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