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

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

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

> Anthony's fix (changing the Lotus mail format) does not work in our 
> configuration. In fact, the "Keep in Sender's format" is still the 
> default here for all users. We see mutilated emails regularly. They are 
> generally from the Lotus webmail system or Lotus notes. Attachments from 
> those are almost always mangled.

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?

> I've done a few hours hacking away at the server and fetchmail and can 
> only conclude that separate header and body retrieval must be abandoned 
> for the very broken actions of Lotus. In digging through fetchmail, it 
> appears that the only way to "cleanly" (I use that loosely) accomplish 
> this is to make a new protocol. "LotusIMAP" maybe?

Jason,

I wonder if a separate protocol is needed - and I'd like to avoid that
if possible since that will sooner or later lead to bit rot.

Some alternatives to FETCH 1234 RFC822.HEADER (where 1234 is the message
number) I could think of:

  BODY.PEEK[HEADER]
  BODY.PEEK[MIME]   - nonstandard, may cause BAD reply
  BODY.PEEK[0.MIME] - nonstandard, may cause BAD reply
  BODY.PEEK[HEADER.FIELDS (MIME-Version Content-Type Content-Transfer-Encoding Content-Disposition)]
  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)?

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.

-- 
Matthias Andree