The following issue has been RESOLVED. ====================================================================== http://www.dbmail.org/mantis/view.php?id=815 ====================================================================== Reported By: maximP Assigned To: paul ====================================================================== Project: DBMail Issue ID: 815 Category: IMAP daemon Reproducibility: have not tried Severity: major Priority: normal Status: resolved target: Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 02-Nov-09 17:18 CET Last Modified: 23-May-10 16:55 CEST ====================================================================== Summary: IMAP + Thunderbird - inability to receive a message Description: By default, Thunderbird tries to get message attachments (message parts) from IMAP by small chunks (10 KBytes), and relies on accuracy of attachment sizes information (IMAP server must inform MUA about the exact size of message parts). Most of messages are OK, but sometimes the problem arises, and Thunderbird can't get a message from IMAP server. Probably, dbmail-imapd lies about sizes of message parts, and Thunderbird doesn't understand DBMail's answer with message part body (and closes the connection on timeout, if I understand correctly). Similar problem (with Exchange IMAP server) is discussed here: https://bugzilla.mozilla.org/show_bug.cgi?id=92111 and the recommendation is to turn off chunk fetching by modifying hidden Thunderbird setting. It helps with dbmail-imapd also, but is it possible to fix DBMail itself? BTW, when Thunderbird asks dbmail-imapd to send 10Kb, then next 10Kb, then next... what does DBMail do? Does it utilize some caches, or the whole message or message part is fetched from the DB every time? Moreover, is DBMail handle large messages with many attachments in optimal way? I'd say, DBMail + Thunderbird combination is too slow for large messages. ======================================================================
---------------------------------------------------------------------- (0003043) paul (administrator) - 28-Apr-10 14:44 http://www.dbmail.org/mantis/view.php?id=815#c3043 ---------------------------------------------------------------------- I'm unable to reproduce this on the current codebase. ---------------------------------------------------------------------- (0003058) paul (administrator) - 23-May-10 16:55 http://www.dbmail.org/mantis/view.php?id=815#c3058 ---------------------------------------------------------------------- I've managed to observe this behaviour myself now and fixed it. There was a problem with message length since an optimization I did recently. I've now re-instated the old solution of crlf encoding all output send by the imapd. The problem made TB+dbmail very slow because TB tried to fetch a message in chunks, received less data than expected, and retried to fetch the message in one big chunk. And yes, DBMail does cache the active message so repeated FETCH-ing on the same message does not hit the database unnecessarily. Issue History Date Modified Username Field Change ====================================================================== 02-Nov-09 17:18 maximP New Issue 28-Apr-10 14:44 paul Note Added: 0003043 28-Apr-10 14:44 paul Assigned To => paul 28-Apr-10 14:44 paul Status new => feedback 28-Apr-10 14:44 paul Resolution open => unable to reproduce 23-May-10 16:55 paul Note Added: 0003058 23-May-10 16:55 paul Status feedback => resolved 23-May-10 16:55 paul Resolution unable to reproduce => fixed ====================================================================== _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
