I believe this statement is incorrect.  Running the test script given 
in the PHP bug below, it strips the whitespace on my username and I 
login properly.  However, directly connecting to my IMAP server 
(Dovecot 1.2), I can verify that it does NOT strip whitespace from the 
username (in other words, Dovecot is RFC compliant).

FYI - the PHP people closed the bug and said it is a problem in c-client.

I did some further testing and it appears Cyrus is stripping the 
whitespace from the username, but only under certain circumstances.  I 
was reading my tcpdump packets wrong, php / c-client are putting 
quotes around the username as expected.

If there is nothing but white space around the username, Cyrus is 
stripping all whitespace:

* OK cyrus.ccac.edu Cyrus IMAP4 v2.2.12-Invoca-RPM-2.2.12-10.el4_8.4 
server ready
00001 login "       testmail    " password
00001 OK User logged in
00002 logout
* BYE LOGOUT received
00002 OK Completed

May  3 13:35:25 cyrus imap[15802]: login: cyrus [127.0.0.1] testmail 
plaintext User logged in

If Cyrus sees characters separated by white space, the exact username 
specified is used.

* OK cyrus.ccac.edu Cyrus IMAP4 v2.2.12-Invoca-RPM-2.2.12-10.el4_8.4 
server ready
00001 login "          testmail   xxx" password
00001 NO Login failed: authentication failure
0002 logout
* BYE LOGOUT received
0002 OK Completed

May  3 13:37:16 cyrus imap[16876]: badlogin: cyrus [127.0.0.1] 
plaintext           testmail   xxx SASL(-13): authentication failure: 
checkpass failed

http://bugs.php.net/bug.php?id=51708

I tried an updated PHP and c-client and still see the same problem.   
Specifically I copied the horde environment to a RHEL6-Beta machine 
with PHP 5.3.1 and libc-client-2007e installed.  The original report 
was on a CentOS 5 machine with PHP 5.1.6 and libc-client-2004g.

I don't know how to report this upstream to PHP since I have no clue 
how IMP calls libc-client.

Updating c-client/PHP can't hurt.  If that doesn't fix things, opening 
a PHP bug makes the most sense.  c-client can be tremendously 
inefficient, but it does tend to be very standards compliant so I 
would be very surprised to find that it was not properly quoting the 
username - my guess is that the username has already been trimmed by 
the time it is passed to the c-client function.

Thanks Michael, I suspect you're right.  I ran a tcpdump on the IMAP 
server and see that the login request is stripping the trailing 
whitespace, it always appears as such:

00000001 LOGIN testmail password\r\n

Not sure where to go from here.  Is my c-client way out of date or can 
anybody else replicate this one?

Theoretically, your fix is incorrect.  Per RFC 3501, a username is 
allowed to have spaces.  I personally can't think of a rational 
situation where a username would have leading/trailing whitespace, but 
those are the rules.

However, c-client should be sending the username in a quoted string 
and/or a literal.  So these logins *should* be failing in the first 
place (the expected behavior) since "user " != "user".  So either 
PHP/c-client is internally trimming the whitespace on the username in 
an imap_open() call, it is sending the username without quoting, or 
cyrus is ignoring the trailing whitespace.  I would guess the 1st, but 
you would have to do IMAP logging on the cyrus side to verify.

Attaching compose window screenshot

We're seeing a problem if our users logging to IMP and accidentally 
add whitespace in their username.  Our Horde is configured to let IMP 
handle authentication, and IMP is set to authenticate against Cyrus 
IMAP.

The authentication against the Cyrus IMAP server works just fine, but 
any white space is added to the session information and ends up 
looking like this:

testmail @acd.ccac.edu [xxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
Session Timestamp: Thu, 29 Apr 2010 14:12:14 -0400
Browser: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) 
Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Realm: [None]
Remote Host: xyz.ccac.edu [xxx.xxx.xxx.xxx]

This causes a few problems, the biggest of which is that the user 
cannot send email (see attached image).  The username also doesn't 
line up properly with the preferences stored in the MySQL database.

I notice that if I go into redirect.php and change this:

IMP_Session::createSession($imapuser, $pass, $sessArray['server'], $sessArray)

to this:

IMP_Session::createSession(trim($imapuser), $pass, 
$sessArray['server'], $sessArray)

The problem seems to disappear.  But that probably isn't the recommended fix.