Thank you for the response.  Knowing that it is believed to be fixed 
in recent versions is useful; I'll see if I can bring this up with my 
local maintainers.

Your problem is that this was fixed in one of the 3.2.x releases, but 
since you're not the admin, you have no idea what you're running. You 
need to be talking to your site admin, not to us. They have the 
information to file bug reports when such are valid.

Respectfully, this is not a bug in c-client.  I can use Pine to 
successfully use backslash-containing passwords.  Pine uses c-client.   
This is a bug in IMP.  IMP is successfully preserving backslashes in 
email subjects and email bodies, but is not preserving backslashes in 
login passwords.



The core of my bug report is

(1) IMP should allow the full range of passwords that the IMAP 
protocol allows.

(2) IMP does not  successfully do this.



If you need more information, I would be happy to provide more.  This 
bug is simple to reproduce, and I provided instructions in my first 
message.



Regards,



Jacob Morzinski

Athena User Accounts / Computing Help Desk

MIT Information Services and Technology

It's a bug in the c-client library then, that should correctly escape 
characters as necessary.

Respectfully, I think the person who replied has misunderstood my report.



IMP builds and sends an IMAP command when it tries to log me in.  My 
bug report concerns the fact that IMP builds the command wrongly.  As 
far as I can see, php's handling of backslashes is completely clean 
and proper, and is not part of this bug report.



As proof that PHP is correctly configured, I point out that I can 
successfully use IMP to send myself email with tricky subjects ilke:

   test \\ of \ backslash



The doubled backslash between "test" and "of" is properly preserved in 
my email, and the single backslash between "of" and "backslash" is 
also properly preserved.  IMP's php code is doing the right thing.





However, when I try to log in, the php code is doing the right thing, 
but IMP constructs the login command incorrectly.  A login command 
must escape any backslashes in the password.  This is specified in RFC 
2060, which is recommend reading for anyone who is trying to write an 
IMAP client.  Because IMP is not escaping the backslashes when it 
constructs the IMAP login command, the command fails.  If the user is 
an IMAP guru who knows probably IMAP failure modes and know that the 
*protocol layer* requires doubled backslashes, the user can compensate 
for IMP's shortcomings...



IMP should not require the user to be a guru, and should build 
correctly-formatted password strings before trying to log in to the 
server.





Thank you

  Jacob Morzinski

PHP automatically strips the backslash because it has been setup with 
magic_quotes_gpc enabled. There is no way to get to the original 
value. Magic quotes need to be turned off in php.ini.

Hello,



I'm using IMP webmail 3.2 (<https://webmail.mit.edu/>).  I am not the 
site administrator, and so do not know exactly which version of 3.2 is 
installed.  I searched the bug database, and did not find any bug 
reports concerning backslashes in passwords, so I believe this bug is 
still present in current versions of IMP.





Description of problem:



If a person's password contains a backslash character, they need to 
type each backslash twice in order to be able to log in.  If they only 
type the backslash a single time, they get an error:



"Login failed for some reason. Most likely your username or password 
was entered incorrectly. "



Doubling the backslashes does enable correct login.





How to reproduce:



+ Choose or create an IMAP account whose password contains a backslash.

+ Use Outlook or Mozilla or some other IMAP client to verify that the 
password is correctly stored on the server, and that the IMAP client 
only needs to type the backslash once for each time it appears in the 
password.

+ Use Horde IMP to access the accound, and observe that the backslash 
has to be typed into IMP's login screen twice.





Comments and speculation:



My own speculation is that IMP is failing to encode password strings 
before sending the passwords on to the server.  The IMAP 
specification, RFC 2060, allows passwords to be either atoms or quoted 
strings, but specifies that backslashes in quoted strings must be 
doubled.  If IMP is failing to double backslashes before sending the 
password on to the IMAP server, this could be causing the observed 
behavior.  When the user manually doubles each backslash, they correct 
for IMP's omission.





Thank you,

  Jacob Morzinski











Related information:



RFC 2060 definitions that are relevant to passwords follow:





login           ::= "LOGIN" SPACE userid SPACE password



password        ::= astring

astring         ::= atom / string



atom            ::= 1*ATOM_CHAR

ATOM_CHAR       ::= <any CHAR except atom_specials>

atom_specials   ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards /

                    quoted_specials

list_wildcards  ::= "%" / "*"

quoted_specials ::= <"> / "\"



string          ::= quoted / literal

quoted          ::= <"> *QUOTED_CHAR <">

QUOTED_CHAR     ::= <any TEXT_CHAR except quoted_specials> /

                    "\" quoted_specials

TEXT_CHAR       ::= <any CHAR except CR and LF>

quoted_specials ::= <"> / "\"



literal         ::= "{" number "}" CRLF *CHAR8

                    ;; Number represents the number of CHAR8 octets

number          ::= 1*digit

                    ;; Unsigned 32-bit integer

                    ;; (0 <= n < 4,294,967,296)

CHAR8           ::= <any 8-bit octet except NUL, 0x01 - 0xff>