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

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

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

> Matthias Andree wrote:
>> Jason Ostermann <jo...@ra...> writes:
>> 
>> 
>> Perhaps the reply to a CAPABILITY request can help with identifying the
>> server.
>> 
>> What does Lotus respond to such a command?
>
> * OK IMAP Server Ready Tue, 8 Aug 2006 17:11:19 -0500
> a capability
> * CAPABILITY IMAP4rev1 AUTH=PLAIN LITERAL+ NAMESPACE QUOTA UIDPLUS
> a OK CAPABILITY completed

Not very distinctive.

>> 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?
>
> Sounds like a PITA to code. =( Would that fit into the current execution 
> scheme of
> 1) request headers
> 2) read headers
> 3) request body
> 4) ready body??

Sort of. We could move writing of the delimiter out of
transact.c/readheaders() into driver.c/fetch_messages(), in order to
make room for a new header fixup method, and make that method re-request
the missing header.

> Or, at least, would it fit any better than making a single header/body 
> read version of imap?

Whatever, I wonder if I should defer such a workaround for 6.4.0 since
it involves major code changes I'm not comfortable with for the stable
version, the bug isn't a new regression and it's really IBM's turn to
fix it.

-- 
Matthias Andree