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

[Jason O. <jo...@ra...>]

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

> Some alternatives to FETCH 1234 RFC822.HEADER (where 1234 is the message
> number) I could think of:
> 
>   BODY.PEEK[HEADER]
Still missing fields.

>   BODY.PEEK[MIME]   - nonstandard, may cause BAD reply
BAD Invalid Fetch argument body.peek[mime]

>   BODY.PEEK[0.MIME] - nonstandard, may cause BAD reply
BAD Invalid Fetch argument body.peek[o.mime]

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

>   BODY.PEEK[HEADER.FIELDS.NOT (foo)]
> 
> Does any of these provide you with the full header when RFC822.HEADER is
> incomplete?
> 
> 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.


> A full IMAP4r1 session might look like:
> 
> A LOGIN USER SECRETPASSWORDGOESHERE
> B SELECT INBOX
> C FETCH 1 BODY.PEEK[HEADER]
> D LOGOUT
> 
> 
> Generally, fetchmail has support for protocols that can only retrieve
> full messages (POP3, for instance, uses that), so some hacking away at
> imap.c might be sufficient to make the rest of fetchmail believe that
> IMAP could only support full messages. The protocol interface is OOP
> style (yes it's clumsy in C, but it works), in that driver.c/transact.c
> call protocol (imap.c/pop3.c) methods^Wfunctions.
> 
> Best would be a workaround that could automatically kick in, since
> that's easiest for users and distributors.
> 
> Such code might require minor internal rearrangements, such as moving
> what used to be hard-wired protocol attributes into methods that query
> the capabilities of the current connection.
> 

I've used structs of function pointers to do similar things in the past. 
Few surprises in that area. =)
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


Thanks!
Jason