Fri, 10 Apr 2026 14:48:28 +0000 https://bugs.horde.org/ticket/8478 Bad or malformed request. Server Responded: Command unrecognized: LOGIN 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"] ------------- Tue, 04 Aug 2009 17:36:32 +0000 https://bugs.horde.org/ticket/8478#t55188 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. Wed, 05 Aug 2009 03:14:28 +0000 https://bugs.horde.org/ticket/8478#t55189 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. Wed, 05 Aug 2009 07:45:44 +0000 https://bugs.horde.org/ticket/8478#t55198 > 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. 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). Wed, 05 Aug 2009 08:07:04 +0000 https://bugs.horde.org/ticket/8478#t55201 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 Wed, 05 Aug 2009 08:36:39 +0000 https://bugs.horde.org/ticket/8478#t55204 And with all that being said, it may have been easier to fix the response parsing part. Try the patch listed below. Wed, 05 Aug 2009 08:37:29 +0000 https://bugs.horde.org/ticket/8478#t55206 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! Wed, 05 Aug 2009 14:03:47 +0000 https://bugs.horde.org/ticket/8478#t55212 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 Wed, 05 Aug 2009 19:23:12 +0000 https://bugs.horde.org/ticket/8478#t55226