Your IMAP server doesn't comply. You need to get the vendor to fix it, 
or pick a different server. You should see this when you use the 
literal syntax:



0 login username {8}

+ OK

... etc.

no proxy, horde is running on the same box as the mail daemon. after 
me edit things work. the password is never sent, if as you said it's 
expecting a pass on the next line then there would be a error on the 
next line about a invalid command with the password exposed.



so:

$read = $this->_runCommand("LOGIN \"$username\" {" . strlen($password) . "}");

if (!is_a($read, 'PEAR_Error') && ($read->type == 
IMP_IMAPCLIENT_CONTINUATION)) {

  $read = $this->_runCommand($password);

}



should result in:

LOGIN "username@password" {8}

password



with a clean login.



and my edit of:

$read = $this->_runCommand("LOGIN $username " . $password);

if (!is_a($read, 'PEAR_Error') && ($read->type == 
IMP_IMAPCLIENT_CONTINUATION)) {

  $read = $this->_runCommand($password);

}



should result in:

LOGIN username@password password

password



which would throw an error because of "password" clearly password isn't sent.



time to do it by hand... telnet...



* OK IMAP Module of ArGoSoft Mail Server Pro for WinNT/2000/XP, 
Version 1.8 (1.8

.9.5)

A001 CAPABILITY

* CAPABILITY IMAP4 IMAP4rev1 ArgosoftExt

A001 OK CAPABILITY completed

A002 LOGIN "username@password" {8}

A002 NO LOGIN failed

password

password BAD Unknown command

A003 LOGIN "username@password" {8}password

A003 NO LOGIN failed

A004 LOGIN "username@password" {8} password

A004 NO LOGIN failed

A005 LOGOUT

* BYE Aba he

A005 OK LOGOUT completed





no chance for a next line to have a password there is no window so if 
it's a compliance issue others have the same problem. some kinda 
switch is needed to turn that on/off.



those additional tries were to see if a space might work or if ti was 
just not looking for the line ending.



telnet to a different (linux) box



* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE 
THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION 
STARTTLS] Courier-IMAP ready. Copyright 1998-2004 Double Precision, 
Inc.  See COPYING for distribution information.

A001 CAPABILITY

* CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE 
THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION 
STARTTLS

A001 OK CAPABILITY completed

A002 LOGIN "username@password" {8}

+ OK

password

A002 OK LOGIN Ok.

A003 LOGOUT

* BYE Courier-IMAP server shutting down

A003 OK LOGOUT completed



seems pretty hit and miss for ones that support it.



maybe a switch to force the normal version, literal, or auto. auto 
maybe tries a second time using normal if literal fails before the 
bailing.



is there a existing function that can be used to clean the variable 
from injections where my modification is?

See RFC 3501 section 4.3.  This is a literal.  We send the { password 
length } and then the password on the next line.  Helps us avoid 
having to escape the password.  Your server should support this.  Are 
you connecting directly to the server or via some proxy?



You can also try changing the password to not use the literal form, 
but I bet the problem is somewhere else.

"Could not complete request. Reason Given: LOGIN failed" on the horde 
login screen.



8/10/2008 9:52:17 PM - {     1} START IMAP

8/10/2008 9:52:17 PM - Requested IMAP connection from 127.0.0.1 
[localhost], ID=1

8/10/2008 9:52:17 PM - (     1) * OK IMAP Module of ArGoSoft Mail 
Server Pro for WinNT/2000/XP, Version 1.8 (1.8.9.5)

8/10/2008 9:52:18 PM - (     1) 00000000 CAPABILITY

8/10/2008 9:52:18 PM - (     1) * CAPABILITY IMAP4 IMAP4rev1 ArgosoftExt

8/10/2008 9:52:18 PM - (     1) 00000000 OK CAPABILITY completed

8/10/2008 9:52:18 PM - (     1) 00000001 LOGIN username@domain password

8/10/2008 9:52:18 PM - (     1) 00000001 OK LOGIN successful

8/10/2008 9:52:19 PM - (     1) 00000002 CAPABILITY

8/10/2008 9:52:19 PM - (     1) * CAPABILITY IMAP4 IMAP4rev1 ArgosoftExt

8/10/2008 9:52:19 PM - (     1) 00000002 OK CAPABILITY completed

8/10/2008 9:52:20 PM - (     1) 00000003 LOGOUT

8/10/2008 9:52:20 PM - (     1) * BYE Aba he

8/10/2008 9:52:20 PM - (     1) 00000003 OK LOGOUT completed

8/10/2008 9:52:20 PM - IMAP connection with 127.0.0.1 [localhost] ended. ID=1

8/10/2008 9:52:20 PM - {     1} END IMAP



second buggy connection in the login:



8/10/2008 9:52:19 PM - {     2} START IMAP

8/10/2008 9:52:19 PM - Requested IMAP connection from 127.0.0.1 
[localhost], ID=2

8/10/2008 9:52:19 PM - (     2) * OK IMAP Module of ArGoSoft Mail 
Server Pro for WinNT/2000/XP, Version 1.8 (1.8.9.5)

8/10/2008 9:52:19 PM - (     2) A001 CAPABILITY

8/10/2008 9:52:19 PM - (     2) * CAPABILITY IMAP4 IMAP4rev1 ArgosoftExt

8/10/2008 9:52:19 PM - (     2) A001 OK CAPABILITY completed

8/10/2008 9:52:20 PM - (     2) A002 LOGIN "username@domain" {8}

8/10/2008 9:52:20 PM - (     2) A002 NO LOGIN failed

8/10/2008 9:52:20 PM - (     2) A003 LOGOUT

8/10/2008 9:52:20 PM - (     2) * BYE Aba he

8/10/2008 9:52:20 PM - (     2) A003 OK LOGOUT completed

8/10/2008 9:52:20 PM - IMAP connection with 127.0.0.1 [localhost] ended. ID=2

8/10/2008 9:52:20 PM - {     2} END IMAP





there is no way on this planet "{8}" is the right password never mind 
the quoted username@domain part ;)

That code is fine.  It just uses IMAP atoms instead of strings.  What 
errors are you seeing?

if you mean mail server, in this specific case it's Argosoft however, 
it doesn't matter since it's an error in the code... other servers 
have the same issue. if you mean OS this is a windows 2003 server 
where both horde/imp and the mail server are. this is trivial though...

What IMAP server are you using?

lib/IMAP/Client.php is littered with stuff like:



line 442:

$read = $this->_runCommand("LOGIN \"$username\" {" . strlen($password) . "}");



should be:

$read = $this->_runCommand("LOGIN $username " . $password);



which looks like maybe a debug or something but it 100% kills IMP from 
running. why even have this second connection, the first should be 
doing this?



for some reason 2 connections happen, the first is the expected IMAP 
connection which has no issues, the second is the weird one.



another bug:

line: 635

$res = $this->_runCommand('LIST "" ""');



return nothing perhaps should be:

$res = $this->_runCommand('LIST "" "%"');

and/or

$res = $this->_runCommand('LIST "" "*"');

to get the list or just simply don't call it/them if there is no use.



still not sure why this second connection is made though...