Re: [fetchmail-devel] fetchmail and mapi II

[Yangyan Li <yan...@gm...>]

Hi Matthias,

Sorry for the messing up of branch MAPI, I will try to fix these
issues one by one.

Roughly speaking, I will concentrate on:
1. a complete review of the existing code, probably a rewriting is required.
2. port this branch to match the latest libmapi release.

In fact, I test on the Exchange Server inside my Virtualbox, it will
be great if anyone can provide some testing environments.

I will seek more advice from you during my development and welcome opinions!

Best Regards!
Yangyan

On Tue, Jul 7, 2009 at 5:09 AM, Matthias Andree<mat...@gm...> wrote:
> 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
>