Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/imp/docs/CHANGES?rt=horde&r1=1.699.2.398&r2=1.699.2.399&ty=u

I have incorporated the patch into our Horde Groupware v1.2.3 install, 
and it does modify the error behavior.  It isn't my "dream" solution, 
but it is supportable.



Knowing that it is truly fixed in the next release of IMP really helps 
a great deal.



Thank you for investigating this ticket and providing a workable patch!

And with all that being said, it may have been easier to fix the 
response parsing part.  Try the patch listed below.

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/imp/lib/IMAP/Client.php?rt=horde&r1=1.21.2.35&r2=1.21.2.36&ty=u

The error is not really caught by the library.  It is caught in the 
sense the text is captured, but the handling is not correct - that 
library doesn't like untagged non-OK responses in login code and it 
would be a non-trivial thing to rewrite.  And even if that was fixed, 
that still leaves the issue of displaying the alarms on login since 
that information is lost (the alarms displayed in IMP 4 are caught by 
c-client, not IMP_Imap_Client).

As far as I understood, the error is already catched by the imap 
extension and displayed in the interface. For IMP 4 being in 
maintenance mode, it should be sufficient to not error out if the 
response is not tagged.

This has already been fixed in IMP 5.0, where all alerts are caught by 
the new Imap Client library.  I am not inclined to fix this in IMP 
4.3.4, especially since this is such a fringe case.  If someone wanted 
to provide a patch, that would be great.  Essentially what needs to be 
done is that the IMAP responses need to be checked for response codes, 
if an [ALARM] response code is seen, it needs to be stored somehow, 
and then the login page would need to be rewritten to display this 
error.

Software that we are running:



         * Horde Groupware Webmail Edition (version 1.2.3) (IMP 4.3.4)

         * UW-IMAP (version 2007e)



Webmail is configured to authenticate using the IMP application.



The handling of the NO response for untagged responses doesn't appear 
to be consistent with RFC 3501 Section 7.1.2 (NO Response).



         http://www.rfc-editor.org/rfc/rfc3501.txt



From what I can tell from the logs and the corresponding code, the 
handling of the response is done in the case statment found in the 
_runCommand() function in

the file



         horde/imp/lib/IMAP/Client.php



We noticed this behavior while testing the following scenario:



* We use the IMAP host's native account expiration.



* From the time that the expiration field is set and excluding its 
final day, the status information, displayed by IMP (as provided by 
the IMAP server via an untagged alert), is correct:



         Account expires in x days(s)!



* On the final day (the account has not yet expired), the login 
attempt fails, and the following informational message is provided on 
the Horde login page:



    Bad or malformed request. Server Responded: Command unrecognized: LOGIN



* The expected behavior is a successful login and the status:



         Account expires today!



When we look at the untagged IMAP server responses for the two cases 
they were:



         * NO [ALERT] Account expires today!

         * OK [ALERT] Account expires in x day(s)!



Here is an excerpt from our logs:



-------------

Aug  3 16:38:20  HORDE[14505]: [imp] Could not complete request. 
Reason Given: [ALERT] Account expires today!: NO [pid 14505 on line 
382 of "/opt/horde-webmail-1.2.3/imp/lib/IMAP/Client.php"]

Aug  3 16:38:20 HORDE[14505]: [imp] Bad or malformed request. Server 
Responded: Command unrecognized: LOGIN: BAD [pid 14505 on line 382 of 
"/opt/horde-webmail-1.2.3/imp/lib/IMAP/Client.php"]

Aug  3 16:38:20 HORDE[14505]: [imp] IMAP alerts: [ALERT] Account 
expires today! [pid 14505 on line 170 of 
"/opt/horde-webmail-1.2.3/imp/lib/IMAP.php"]

-------------