Running mailwatch on xubuntu v6.06, installed version of mailwatch 1.0.0-0ubuntu4. PROBLEM: 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. OTHER INFORMATION: 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: INBOX- l-INBOX 4) There are 3 mailboxes configured in mailwatch, all IMAP and all show this problem.
Ok, I think this is fixed. Can you please try this version here: http://spuriousinterrupt.org/files/mailwatch/test/xfce4-mailwatch-plugin-r1757.tar.bz2 Be sure to pass the correct xfce prefix to 'configure'.
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.
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" 02 EXAMINE INBOX 03 SEARCH UNSEEN 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
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 2 EXAMINE INBOX * 1 EXISTS * 0 RECENT * 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 SEARCH UNSEEN * SEARCH 1 3 OK SEARCH completed 4 LOGOUT * BYE Binc IMAP shutting down 4 OK LOGOUT completed Connection closed by foreign host.
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. Thanks!
Ok will do that tomorrow (it's nearly midnight now in the UK and I'm off to bed)
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.
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.
Created attachment 735 Altered mailwatch-mailbox-imap.c Brian, 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.
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.
Created attachment 737 Differences file The difference file(patch)is attached.
Created attachment 743 Program to test responses from bincimap Brian, 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.
*** Bug 3552 has been marked as a duplicate of this bug. ***
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.