Re: [fetchmail-devel] fetchmail and mapi II

[Matthias A. <mat...@gm...>]

Am 16.06.2009, 17:55 Uhr, schrieb mojmir svoboda  
<moj...@2k...>:

> * Mat...@2k...rp  
> <Mat...@2k...rp> [2009-06-16 14:11:37 +0000]:
>
>> > as a hotfix i simply allocated lot of memory and removed the loop that
>> > did nothing. i assume you do not want that kind of solution (and  
>> neither
>> > do i.. in long term)
>>
>> Ah, ok.
>
> in attachment there is a patch fixing this (hopefuly) correctly.  still,
> the postscript attachment i sent myself got little bit scrambled
> (periodically at buffer boundaries). may be bug in stream, may be bug in
> ldb_base64_encode.
>
> btw: ldb_base64_encode can be removed from the source file mapi.c, as it
> is already present in samba4.
>
>> >> > 6. \r characters and = spread all around in mail body
>> This looks like quoted printable encoding to me. hex is likely (i. e. I
>
> i confirm. this seems to be hardcoded in mapi.c
> perhaps there should be an option specifying output format? i.e. if
> exchange sends it in 7bit, i'm fine with it. no need for another
> translation.
>
>> Perhaps headers do not properly declare content. Do you have an example  
>> of
>> such a message (inside mutt, just pipe it into "cat - >/tmp/msg.bin",  
>> then
>> mail msg.bin as application/octet-stream attachment).
>
> in attachment. it's in czech, sorry - only sample i did not deleted
>
>> > 	- fetchmail modifies the "From: " header
>> Is it fetchmail or OpenChange or Exchange that does this?
>
> this is what i have when i look out from outlook:
> 	From: "Matthias Andree" <matthias.andree@your.email>
> 	To: "mojmir svoboda" <mojmir.svoboda@my.email>,  
> fet...@li...
> 	Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
> 	Content-Transfer-Encoding: 7bit
>
> this is what i receive after fetchmailing via mapi:
> 	From: MatthiasAndree@exchange_server_address.here
> 	To: 2K Czech <MojmirSvoboda>;, fet...@li...
> 	Content-Type: text/plain; charset=us-ascii
> 	Content-Transfer-Encoding: quoted-printable
>
> there is some header manipulation code in mapi_fetch_headers, i'd start
> search there.
>
> best regards,
> mojmir

Hi Mojmir,

I have updated fetchmail's BRANCH_MAPI branch to release 6.3.10 including  
the post-release updates to Spanish and Chinese translations as of  
yesterday.

I have merged your mapi2.patch (thanks), but haven't yet had the time to  
look at the messages or other problems we discussed.

I fixed an issue in rcfile_y.y where the LCID parsing for strings that  
didn't start with 0x was utterly broken.

I fixed configure.ac logic so that --disable-MAPI (or not specifying this)  
works, and we only check for libmagic if needed.

So me new issues I discovered that also need addressing:

- all issues you've mentioned that haven't been addressed by your patch,  
for instance, message corruption as observed, or duplication of base64  
encoders.

- there are warnings about broken 4th arguments to one of the openchange  
functions

- mapi.c throws a zillion of warnings of mismatched signedness in  
comparisons, or unused variables. All have to be audited that they don't  
trigger integer overflows or negative indexes.

- the MAPI code adds quite a few if (blah.protocol != P_MAPI) ... #ifdef  
MAPI_ENABLE ... #endif that should be abstracted away rather than copy &  
paste code...

- the bug I fixed in rcfile_y.y was sort of target = sprintf("0x%04x",  
uint32_t); - oops. sprintf takes the output variable as argument and  
returns the length... I hope there isn't more of this bug.

- more will show up as fixup and integration proceed.


For better or for worse, the current BRANCH_MAPI code isn't currently fit  
for integration into the trunk, but needs considerable work. With the most  
recent commits, I can compile it on openSUSE 11.1 with the -devel packages  
 from  
http://download.opensuse.org/repositories/GNOME:/Evolution:/mapi/openSUSE_11.1  
and with file-devel installed (that is the openSUSE package containing  
libmagic development files), if I run

./autogen.sh
mkdir build
cd build
PKG_CONFIG_PATH=/usr/lib/samba4/lib/pkgconfig/ \
../configure -C --enable-MAPI --with-ssl \
CFLAGS="-O -pipe -ggdb3 -Wall -Wextra -W" \
&& make -sj4

You can check out sources from  
http://mknod.org/svn/fetchmail/branches/BRANCH_MAPI/


I'm not interested in doing any of the audit/cleanup/fixup work as  
assessed in this and related threads, but I am happy to help with the  
integration later and help with tracing the requirements.

Reasons are that I personally do not have interest in MAPI support, I have  
no Exchange server to test (Asif Iqbal offered help with testing, but I  
think the tests should be done by those who fix up the code). If someone  
is willing to pay pro rates, can provide an Exchange server to test  
against, be happy with low-profile effort (5 - 20 hours per month - not  
week!) that can start only in a few months' time, contact me off-list. No  
promises though.

So - any volunteers to audit and/or polish BRANCH_MAPI?

Thanks in advance

-- 
Matthias Andree