! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
"A buffer was too small to receive all of an IMAP response"


Description ChrisW 2006-07-10 21:58:53 CEST
Running mailwatch on xubuntu v6.06, installed version of mailwatch 1.0.0-0ubuntu4.

When a new message comes into a IMAP mailbox configured in mailwatch, then the following message appears in the log file and the icon does not change to "new mail":
"A buffer was too small to receive all of an IMAP response. This is a bug!"
This is repeated everytime mailwatch checks the mailbox.

1) The IMAP server is running on another local PC (IMAP server is bincimap running on Fedora FC5). There are no error messages that I can see in the log on this machine.
2) Thunderbird running on the ubuntu machine connects to the IMAP mailbox with no problems.
3) When configuring the IMAP mailbox in mailwatch the "new mail folders" dialog correctly shows all the top-level folders in the mailbox but does not show the sub-folders but instead shows a repeat of the top-level folder (eg:
4) There are 3 mailboxes configured in mailwatch, all IMAP and all show this problem.
Comment 1 Brian J. Tarricone (not reading bugmail) 2006-07-11 17:59:33 CEST
Ok, I think this is fixed.  Can you please try this version here:

Be sure to pass the correct xfce prefix to 'configure'.
Comment 2 ChrisW 2006-07-11 20:03:33 CEST
The new version behaves as before but with a different message:

"The IMAP server returned a response we weren't quite expecting. This might be OK, or this plugin might need to be modified to support your mail server if the new message counts are incorrect"

Do you need me to "feed" bincimap via telnet to see what the returned responses are? If so, let me know what to send to bincimap.
Comment 3 Brian J. Tarricone (not reading bugmail) 2006-07-11 20:18:32 CEST
That's actually the same message, just I changed it to reflect what's really going on at that point since the bug referenced in the old message is now fixed.

Sure, let's try feeding the daemon:

01 LOGIN "username" "password"

If it's occurring on a folder other than inbox, replace INBOX with the folder name.  If it's a subfolder, it might be something like INBOX.foobar
Comment 4 ChrisW 2006-07-11 22:26:23 CEST
Hi Brian,

Here are the responses (with the IMAP folders in the same state as when mailwatch was running):

chris@WEST01:~$ telnet west02 143
Trying xxx.xxx.xx.xx...
Connected to west02.
Escape character is '^]'.
* OK Welcome to Binc IMAP Copyright (C) 2002-2004 Andreas Aardal Hanssen at 2006-07-11 23:18:44 BST
1 LOGIN xxxxxxxx yyyyyy
1 OK LOGIN completed
* OK [UNSEEN 1] Message 1 is first unseen
* OK [UIDVALIDITY 1108313866]
* OK [UIDNEXT 944] 944 is the next UID
* FLAGS (\Answered \Flagged \Deleted \Recent \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft)] Limited
2 OK [READ-ONLY] EXAMINE completed
3 OK SEARCH completed
* BYE Binc IMAP shutting down
4 OK LOGOUT completed
Connection closed by foreign host.
Comment 5 Brian J. Tarricone (not reading bugmail) 2006-07-11 22:36:40 CEST
Hmm, unfortunately that's what I expected to see (and what mailwatch is looking for).  Not sure what's wrong.  Ok, can you add the line:

DBG("Output was:\n'%s'", buf_extra);

to line 604 of libmailwatch-core/mailwatch-mailbox-imap.c?  (Right after the g_warning line.)

Then re-run configure with --enable-debug=yes, make, make install.  Then kill your panel (run "xfce4-panel -x"), and restart the panel from a terminal.  Save all the output to a file and attach it here.

Comment 6 ChrisW 2006-07-11 22:45:03 CEST
Ok will do that tomorrow (it's nearly midnight now in the UK and I'm off to bed)
Comment 7 ChrisW 2006-07-12 10:35:44 CEST
Created attachment 659 
Debug output as requested

Mailwatch behaved as before.
The last two lines in the output were me looking at the log file.
Comment 8 Brian J. Tarricone (not reading bugmail) 2006-07-12 11:03:07 CEST
Ok, it looks like it's just not getting the full reply for some reason.  Maybe the server is sending the reply in weird chunks?  Very strange.  I'm not really sure what to do with this, unfortunately.  Well... hmm.  I guess I could have the receive loop check for the ending "OK" token each time it receives something, and if it doesn't get it, keep trying, even if the receive buffer wasn't full.  At worst, that would lead to a 45-second timeout if there's an error.  Since it's a non-interactive task, I think that's probably acceptable.

Another option would be to just rewrite it all to use async i/o (probably just GIOChannels), but that would be way more effort than I want to put into it right now.  Not to mention I'm not sure if that would play nicely with gnutls.

Anyway, I don't have the energy to work on it right now (it's 4am).  If I don't get back to this by the end of the weekend, feel free to ping me.
Comment 9 ChrisW 2006-08-15 19:26:51 CEST
Created attachment 735 
Altered mailwatch-mailbox-imap.c

I have put some very crude changes into mailwatch-mailbox-imap.c that seem to fix the reported bug in my environment. The changes are between lines 598 & 640 and are commented. I'm not a C programer and the attached is only for your interest and not intended as a suggested patch! 

In a nutshell: the response the original code is expecting seems to be returned when there are no new messages but when there are new messages only "* SEARCH 1 2 3..." seems to be returned.
Comment 10 Brian J. Tarricone (not reading bugmail) 2006-08-15 20:52:59 CEST
Can you generate a patch?  I can't tell what you've changed.

diff -u originalfile newfile

will give you a patch.

At any rate, it seems like your mail server is violating spec.  The response should *always* end with "OK", unless there is an error.
Comment 11 ChrisW 2006-08-16 09:13:45 CEST
Created attachment 737 
Differences file

The difference file(patch)is attached.
Comment 12 ChrisW 2006-08-20 18:32:10 CEST
Created attachment 743 
Program to test responses from bincimap


The code I sent previously does detect new messages but always reports the new message count as 1 ...

... So to try to understand what bincimap is doing I wrote the attached simple test program (which returns the correct unseen message counts). Basically it is as you suggested on 12th July: The expected reply to SEARCH UNSEEN is returned but not all in one go. You have to loop around receiving and concatenating replies until the end (ie: "OK SEARCH completed") is returned. The concatenated reply will then be as expected.

Hope this helps and look forward to a fix when you get the chance.

And thank you for your time & effort on xfce code.
Comment 13 Brian J. Tarricone (not reading bugmail) 2007-09-17 04:41:56 CEST
*** Bug 3552 has been marked as a duplicate of this bug. ***
Comment 14 Brian J. Tarricone (not reading bugmail) 2008-03-12 05:54:51 CET
Pretty sure this should be fixed now as of svn rev 3915.  Please test if you can and reopen if things still don't work.

Bug #2009

Reported by:
Reported on: 2006-07-10
Last modified on: 2011-02-26
Duplicates (1):
  • 3552 A buffer was too small to receive all of an IMAP response. This is a bug!


Brian J. Tarricone (not reading bugmail)
CC List:
3 users


1.1.0 or older
Target Milestone:
1.1.0 or older


Debug output as requested (5.94 KB, text/plain)
2006-07-12 10:35 CEST , ChrisW
no flags
Altered mailwatch-mailbox-imap.c (63.92 KB, text/plain)
2006-08-15 19:26 CEST , ChrisW
no flags
Differences file (2.16 KB, text/plain)
2006-08-16 09:13 CEST , ChrisW
no flags
Program to test responses from bincimap (4.16 KB, text/plain)
2006-08-20 18:32 CEST , ChrisW
no flags

Additional information