[horde] Error when communicating with the server. (Horde_Imap_Client 2.11.3)

[Michael M Slusarz]

Quoting Samuel Wolf <samuel at sheepflock.de>:

> Zitat von Samuel Wolf <samuel at sheepflock.de>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>
>>> Quoting Samuel Wolf <samuel at sheepflock.de>:
>>>
>>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>>
>>>>> Quoting Samuel Wolf <samuel at sheepflock.de>:
>>>>>
>>>>>> Hi Michael,
>>>>>>
>>>>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>>>>
>>>>>>> Quoting Samuel Wolf <samuel at sheepflock.de>:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> upgrade today to Horde_Imap_Client-2.11.3.
>>>>>>>> If I press the refresh button in imp a notification comes up  
>>>>>>>> with "Error when communicating with the server.".
>>>>>>>
>>>>>>> Works fine here with all test VMs.  (For the record, here is  
>>>>>>> my current test VM setups:
>>>>>>>
>>>>>>> UWimap-2007f
>>>>>>> Courier 4.12.0
>>>>>>> Cyrus 2.2
>>>>>>> Dovecot 2.2
>>>>>>> Gmail
>>>>>>> hImapServer
>>>>>>>
>>>>>>> )
>>>>>>
>>>>>> I think it is a problem of the old dovecot version in debian 6  
>>>>>> (1.x.x), dovecot in debian 7 work fine.
>>>>>>
>>>>>>>
>>>>>>> Are you sure you are logging at a DEBUG level?  And you  
>>>>>>> haven't provided an IMAP log.
>>>>>>
>>>>>> maybe this helps (horde.log)?
>>>>>>
>>>>>> 21. Horde_Imap_Client_Data_Format_Mailbox->binary()  
>>>>>> /usr/share/php/Horde/Imap/Client/Socket.php:3945
>>>>>>
>>>>>> 2013-06-04T19:35:22+00:00 DEBUG: HORDE [imp] Client error: can  
>>>>>> not send mailbox to IMAP server as binary data. [pid 1220 on  
>>>>>> line 27 of  
>>>>>> "/usr/share/php/Horde/Core/Notification/Handler/Decorator/Hordelog.php"]
>>>>>
>>>>> Yes - I need the full backtrace.  IMP is broken somewhere and  
>>>>> instead of sending incorrect data to the IMAP server (which is  
>>>>> sure to cause an error), we catch it before sending.
>>>>>
>>>>> You wouldn't happen to be using nav_poll_all preference?
>>>>
>>>> root at mailserver:/var/www/https/horde/imp/config# cat  
>>>> prefs.local.php | grep nav_poll_all
>>>> $_prefs['nav_poll_all']['value'] = 1;
>>>> $_prefs['nav_poll_all']['locked'] = true;
>>>
>>> That's it then.  Disable that for now.  A fix was just added for  
>>> IMP 6.1.0 and will need to be backported to IMP 6.0.6.
>>
>> if I disable this option my users get a heart attack tomorrow  
>> morning after login into imp, because they missing the imap folders  
>> :-)

Sounds like you got this confused with subscriptions...

But for archive sake, the reason nav_poll_all (automatically polling  
all mailboxes) makes no sense is the following:

Users fall into one of two categories:

* Those who don't have filters (i.e. all new mail goes to INBOX).
* Those who do configure filters

The former only care about "new" (i.e. unseen) messages that appear in  
the INBOX.  Polling all mailboxes is a waste of everybody's time, and  
is not useful information for these users outside of INBOX.  E.g.  
showing the number of unseen messages in the Trash folder is both  
confusing and pointless.

The latter are assumed to be "smarter" about mail delivery.  It is not  
asking too much to have these more advanced users explicitly select  
which mailboxes they want unseen information.  There can't be an  
assumption that all mailboxes the user delivers messages to want to be  
polled either: it is a common occurrence to do things like, e.g.,  
route automated server status messages to a subfolder.  These may be  
low priority, and a user doesn't want to be constantly notified of  
these messages as they are more for archival purposes.

And these users are going to share the former's thoughts about things  
like Sent, Spam, and Trash mailboxes.  There is really no benefit of  
unseen message polling in these special mailboxes.  For those that  
disagree, which will be the outliers - not the majority, they can  
remedy this by manually tracking these mailboxes.

> forget it, I have confused it with the subscribe option.
> Work now fine with Horde_Imap_Client-2.11.3

Even so, it was probably a bit aggressive for me to cause this kind of  
error to throw Exceptions in the current 2.x branch.  Although *very*  
useful in finding bugs, and we certainly should not be sending this  
data to the IMAP server when we know its going to cause an incorrect  
response, this can be temporarily hacked around by instead sending a  
blank string.  I will readd the code throwing Exceptions for the 3.0  
Horde_Imap_Client release.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]