RoundCube SVN rev 360 fails to display email headers

[Redhatter]

Hi all,

I've been using RoundCube for a while now, using a checkout from SVN, and have been updating it on a regular basis. The system is great so far, however, there's one niggle that I've struck repeatedly at various occasions.

When viewing some emails (not consistent), the client fails to display the email headers. This manifests itself when viewing some emails -- there is no email header area up the top above the body, and when forwarding/replying to the email, the fields which would normally be filled in (To:, Subject:, etc...), are left blank.

When going back to the mail folder, the subject and other metadata now show up blank, dispite being displayed prior to opening the email.

The server is running Gentoo Linux/x86 2006.1, with Apache 2.0.58, PHP 4.4.4-hardened, MySQL 4.1.21, qmail 1.03 and BInc IMAP 1.2.12. I'm happy to provide test accounts on the server if need be (contact me privately).

Where do I start looking to trace this bug? RoundCube is totally different to most other mail systems I've used, and thus I'm a little lost regarding where to start debugging.

Regards, Stuart Longland (redhatter@…)

[jpingle]

This is a known issue with BincIMAP since SVN r326. Recently, a rewrite to how the messages were fetched from the server was done and the new method simply does not work with BincIMAP. I never was able to get any header information at all. Unfortunately the change was made to fix DBMail, so either one or the other will be broken (unless a server type option is added...)

I've had many other problems with BincIMAP and RoundCube (as shown by many messages on the dev list and in trouble tickets) but they had been resoved without too much trouble. This header bug was the last one I felt like dealing with. Just today I finished converting that server over to Courier IMAP instead of BincIMAP.

See this thread from August for details on when this bug cropped up: http://lists.roundcube.net/mail-archive/roundcube.dev/2006/08/231/

[Redhatter]

Ahh, so it's an imapd implementation issue.

Perhaps autodetecting the server, and adjusting the behaviour accordingly has some merit?

I'm happy to go digging into the code if need be, I'm reasonably comfortable with PHP (new to AJAX apps though). Where would be the best place to start?

[jpingle]

The problem here is probably pretty far away from anything AJAX-like, in the backend IMAP code, so you'd be safe. :) It may take some connection sniffing to see the interactions with the server, and finding out how those transactions are happening.

Unfortunately I don't have a whole lot of time right now, or I could help. I still have BincIMAP configured on that server, it's just shut down. If one had Binc and another IMAP server running with the same mailboxes/accounts, the differences in the transactions should be readily apparent.

Another approach might be to contact the BincIMAP dev(s) to see if they have any input. The 'new' message retrieval method, according to Thomas, is part of IMAPv4 spec and BincIMAP claims to have IMAPv4rev1 which is what Courier also supports. I suppose this could be called a bug in BincIMAP, but they haven't had a release in almost a year and a half so I'm not sure if it is still in active development.

I would start by looking at the changes made in r325 and r326 in imap.inc and rcube_imap.inc. Even if those changes can't be backed out, there may be parts in there that it might be possible to run based on a server config variable. Autodetection would be ideal, but might be harder to implement.

[thomasb]

Please test with latest SVN trunk and re-open if the problem remains.