Re: [fetchmail-devel] Continuation of "Domino IMAP and missing Content-Transfer-Encoding"

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

Jason Ostermann <jo...@ra...> writes:

>> Heck, can't vendors be bothered to repair the known defects in their
>> software or at least sponsor workarounds in third-party software they
>> are breaking?
>
> Agreed. Of course, if I had a say (or if any of my fellow 80,000 minions 
> had a say) we'd not be using Lotus.
>
>>   BODY.PEEK[HEADER.FIELDS (MIME-Version Content-Type Content-Transfer-Encoding Content-Disposition)]

> This returned the fields, although only the Content-Transfer-Encoding 
> was missing from the RFC822 header output.

OK, so we'll have to re-request that header.

>> What does
>> 
>>   FETCH 1 BODYSTRUCTURE
>> 
>> give you (replace 1 by the number of a 'broken' message)?
>
> * 574 FETCH (BODYSTRUCTURE ("text" "html"  ("charset" "ISO-8859-1") NIL 
> NIL "quoted-printable" 1287 22 NIL NIL NIL))
> I don't know how to parse this output, although the strings presented 
> are correct. Don't know what the numbers are supposed to reflect.

These are the contents of some headers, see section 7.4.2 in RFC-3501.

> Sadly, I didn't manage to do an imap isolated patch yesterday. To get my 
> hack to work, I mutilated imap.c to make the getsizes, getpartialsizes 
> and fetch body NULL and changed fetch_headers to submit FETCH %d 
> (BODY[]). I also had to change driver.c by adding len-=msgblk.msglen 
> before the readbody. Otherwise, it'd try to read the whole message size 
> off of the socket. I was very confused by the last bit, as it seemed 
> that changing the fetch body to NULL should've induced driver.c to do 
> the same to handle the POP protocols. I expect I missed something somewhere.
>
> Is there a way to identify an imap server? The banner on login only states:
> * OK IMAP Server Ready Tue, 8 Aug 2006 08:37:04 -0500

Perhaps the reply to a CAPABILITY request can help with identifying the
server.

What does Lotus respond to such a command?

Another workaround idea: what if we check the received headers from the
RFC822.HEADERS request if it contains "MIME-Header: 1.0", and if it
does, but is missing Content-Transfer-Encoding, request the latter
explicitly and attach it to the headers if we get one?

Such a workaround would reorder headers, but better that
than a missing quoted-printable or base64 tag.

What do you think?

-- 
Matthias Andree