Fri, 10 Apr 2026 09:35:34 +0000 https://bugs.horde.org/ticket/8012 IMAP Login Loging Fail Message There is a bug in the /imp/lib/IMAP/Client.php file. On function _loging (almost line 442 on a vi terminal) the password for the IMAP server is send like {".strlen($password)."} which send the actual length of the password and not the password itself, this prevents the IMP application of logging to the mail server. I make a search on the web and others users may have this issue. In General words, the user can login to horde with a IMAP authentication method but can't login to IMP imap. Thu, 19 Feb 2009 02:44:25 +0000 https://bugs.horde.org/ticket/8012#t52683 > There is a bug in the /imp/lib/IMAP/Client.php file. On function > _loging (almost line 442 on a vi terminal) the password for the IMAP > server is send like {".strlen($password)."} which send the actual > length of the password and not the password itself, this prevents the > IMP application of logging to the mail server. I make a search on the > web and others users may have this issue. If this is broken for you, then your IMAP server is broken. This is how to quote literals in IMAP. Please read RFC 3501. Thu, 19 Feb 2009 06:08:22 +0000 https://bugs.horde.org/ticket/8012#t52685 >> There is a bug in the /imp/lib/IMAP/Client.php file. On function >> _loging (almost line 442 on a vi terminal) the password for the IMAP >> server is send like {".strlen($password)."} which send the actual >> length of the password and not the password itself, this prevents the >> IMP application of logging to the mail server. I make a search on the >> web and others users may have this issue. > > If this is broken for you, then your IMAP server is broken. This is > how to quote literals in IMAP. Please read RFC 3501. Take a look again an check: The client is not permitted to send the octets of the literal unless the server indicates that it is expected. This permits the server to process commands and reject errors on a line-by-line basis. The remainder of the command, including the CRLF that terminates a command, follows the octets of the literal. If there are any additional command arguments, the literal octets are followed by a space and those arguments. Example: C: A001 LOGIN {11} S: + Ready for additional command text C: FRED FOOBAR {7} S: + Ready for additional command text C: fat man S: A001 OK LOGIN completed C: A044 BLURDYBLOOP {102856} S: A044 BAD No such command as "BLURDYBLOOP" The implementation, makes the process fail. :) Fri, 20 Feb 2009 00:00:09 +0000 https://bugs.horde.org/ticket/8012#t52702 You are not understanding the protocol. What the text that you quoted means is that the client cannot sent the octets of the literal (i.e. the password) until the client receives the command continuation response (+) it does *not* mean that we cannot send a octet count to the server unsolicited. Further reading: 4.3. String A string is in one of two forms: either literal or quoted string. The literal form is the general form of string. The quoted string form is an alternative that avoids the overhead of processing a literal at the cost of limitations of characters which may be used. A literal is a sequence of zero or more octets (including CR and LF), prefix-quoted with an octet count in the form of an open brace ("{"), the number of octets, close brace ("}"), and CRLF. In the case of literals transmitted from server to client, the CRLF is immediately followed by the octet data. In the case of literals transmitted from client to server, the client MUST wait to receive a command continuation request (described later in this document) before sending the octet data (and the remainder of the command). Fri, 20 Feb 2009 01:12:21 +0000 https://bugs.horde.org/ticket/8012#t52703 > You are not understanding the protocol. What the text that you quoted > means is that the client cannot sent the octets of the literal (i.e. > the password) until the client receives the command continuation > response (+) it does *not* mean that we cannot send a octet count to > the server unsolicited. > > Further reading: > 4.3. String > > A string is in one of two forms: either literal or quoted > string. The literal form is the general form of string. The > quoted string form is an alternative that avoids the overhead of > processing a literal at the cost of limitations of characters > which may be used. > > A literal is a sequence of zero or more octets (including CR and > LF), prefix-quoted with an octet count in the form of an open > brace ("{"), the number of octets, close brace ("}"), and CRLF. > In the case of literals transmitted from server to client, the > CRLF is immediately followed by the octet data. In the case of > literals transmitted from client to server, the client MUST wait > to receive a command continuation request (described later in > this document) before sending the octet data (and the remainder > of the command). > This is not about password only, is in general, check your client well it is sending the username in a clearly violation of what you had copy above "the client MUST wait to receive a command continuation request (described later in this document) before sending the octet data (and the remainder of the command)" Check the example again of the RFC, it is clearly explained. Well it had been a pleasure but I don't have too much time to deal with this. The fact is that I change the procedure of the log in process to comply with the RFC example and now it works. Have a nice day. Fri, 20 Feb 2009 11:53:15 +0000 https://bugs.horde.org/ticket/8012#t52716 Normally I wouldn't reply to this kind of crap, but in the off-chance that someone would read this bug and be confused/misinformed... > This is not about password only, is in general, check your client > well it is sending the username in a clearly violation of what you > had copy above "the client MUST wait > to receive a command continuation request (described later in > this document) before sending the octet data (and the remainder > of the command)" Which is *exactly* what we do. Line 442 we send the literal length of the password (the string length between the {}). On line 443-444, we check to make sure the server sends back the command continuation request before continuing. And then on line 445, if that happens, we send the octet data (the actual password string). Considering we are doing exactly what you say we should be doing, I really have no idea what else to say. Fri, 20 Feb 2009 17:31:27 +0000 https://bugs.horde.org/ticket/8012#t52724