Re: [fetchmail-devel] fetchmail and mapi II

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

Am 16.06.2009, 12:27 Uhr, schrieb mojmir svoboda  
<moj...@2k...>:

> first i'd like to note that i am not a mapi specialist.. or anything  
> close to that. i simply have to live with this exchange and not want to  
> use outlook.

No need to justify your goals - your input and observations are useful and  
welcome, even if you cannot provide full solutions to issues that you see.

>> > 3. missing mapi_session* argument
>> > 	affected functions are mapi_init, smtp_address
>> > 	(calls OpenMsgStore, GetGALTable)
>> > 	i had to introduce static global variable for that.
>
> you can find a patch in the attachment. this way it at least compiles  
> and runs.
>
> the things is: if i use s_mapi_session everywhere it stops to work  
> properly in mapi_getauth (MapiLogonProvider creates another session and  
> if the
> s_mapi_session passed as arg, it crashes later in ProcessNetworkProfile)
>
> so the s_mapi_session is shared only between mapi_init and smptp_address  
> for a moment.

I'll save this part and look at it later; perhaps Jelmer can help here.

>> > 4. buffer overflows
>> > 	affected functions get_base64_attachment, octool_get_stream
>> > 	perhaps all these memcpys should be reviewed
>
> i will toy with this few days until i figure what the correct form  
> should be.
>
> 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.

>> > 6. \r characters and = spread all around in mail body
>> What is this quoted_printable_encode part doing wrong? Could you provide
>> your solution to (6)? Perhaps we can build a full solution on top of  
>> yours.
>
> errr.. do not overestimate me... i simply removed the code that did not
> suited me ;)
>
> 	for example: what is this supposed to do? 8->7 bit?
> 			if (is_safe_char(ch))
> 				line[line_count++] = ch;
> 			else {
> 				line[line_count++] = '=';
> 				line[line_count++] = hex[(ch >> 4) & 15];
> 				line[line_count++] = hex[ch & 15];
> 			}

This looks like quoted printable encoding to me. hex is likely (i. e. I  
haven't looked at the code) a char array "0123456789ABCDEF" and if it's a  
safe character (no control character), it's emitted directly, otherwise,  
it's encoded as =XX, where XX is the associated ASCII value, expressed as  
a sedecimal number.

> 	if yes i wonder why mutt (set noallow_8bit) displays that incorrectly.

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

> 	and then there are these line[line_count++] = '\r';
> 	which are later visible in mutt.

If that's correct depends on the location in the code where you've found  
this.

> 	sincerely, i have no idea what proper solution should look like.
>
> there are more problems:
> 	- fetchmail modifies the "From: " header
> 	- fetchmail seems to drop any list-id and in-reply-to fields (and  
> perhaps
> 	  other fields). this makes mailing lists (and threading) a little bit
> 	  uncomfortable

Is it fetchmail or OpenChange or Exchange that does this?

I recall an internship some 8 years ago where the company also Exchange  
(that was in early 2001), and Emacs+Gnus was rather confused by the output  
(which also included blank lines in places where you didn't expect them,  
and where PINE didn't show them), while PINE worked reasonably well. I  
don't recall how well mutt fared at the time.

HTH
Matthias

-- 
Matthias Andree