Re: [fetchmail-devel] mapi again

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

Am 02.09.2009, 10:25 Uhr, schrieb mojmir svoboda  
<moj...@2k...>:

> good morning Matthias,
>
> * mat...@gm... <mat...@gm...> [2009-08-28 06:15:43  
> +0000]:
>
>> * Don't introduce security holes, avoid static buffers
>
> oh i must read some secure programming stuff, i was never involved :)
> by avoiding static buffers (local? global ones?) you mean allocate
> every buffer on heap?

Most importantly: don't trust data you got over the network, through  
openchange or any other library. Don't assume data makes sense or has  
sensible lenghts, or integers are positive or make sense. Sanity check  
array indexes that they aren't out of bounds. Make sure string copies are  
always length limited or that you the output is allocated properly. Do not  
use functions that copy arbitrary length data. Note that strncpy has  
awkward implications about the NUL byte termination, but you can use  
strlcpy and strlcat instead.

>> > 4. mapi todo
>> > - threading of messages does not work
>>
>> Is the cause known yet? Incomplete headers, such as In-Reply-To: or
>> References:?
>
> yes, only very few fields from the whole header is passed to mda. i have
> to add the other fields, the problem is which ones, mapi has cca 1000 of
> these tags :) i'll talk with openchange people about this.

:-( That's tough luck. I had hoped that there were some function to fetch  
internet headers fully (Outlook 2003 can do that, so I'd assume Exchange  
can deliver that - but I may be wrong and Outlook just emulates it).

>
>> > - when > 1000 messages, fetchmail says it cannot open MDA
>> > 	  report(stderr, GT_("MDA open failed\n"));
>>
>> Try running with -vvv and see if you still get the "about to deliver
>> with:" message, and please show it to me.
>
> oka, next time, i had to run outlook and flush everything so every time
> that happens i loose some of messages.
>
>> Can I also see your mda option's argument?
>
> mda "procmail -d x"

Hm. Should be safe - but make sure that "x" is sensible - procmail tries  
to setuid to x, and if x doesn't exist, there's no way it will succeed --  
the exact implications depend on whether fetchmail is in multidrop or  
singledrop mode.

>> strace or truss could help. You could also grep "ps ax" or "ps -ef"  
>> output
>
> good idea - will do next time that happens.
> weren't there some performance monitor for linux? three or four letters
> that was... oh i cannot remember the name :)

Hm. top? But that doesn't show leaks. There are several memory leak  
checkers around, Google should come up with things like memprof, valgrind,  
an efence spinoff with a new name that I forgot.

HTH

Best regards

-- 
Matthias Andree