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...
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.

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.

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).

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. :)

If this is broken for you, then your IMAP server is broken.  This is 
how to quote literals in IMAP.  Please read RFC 3501.

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.