28941 - backslash and Double Quote " not escaped for IMAP username Login

Status: VERIFIED FIXED

(MailNews Core :: Networking, defect, P2)

Description

[Sam Winstanley]

In an MS Exchange IMAP account it is fairly normal for the username to contain
\(backslash) characters. Also " (double quote) characters are valid in passwords.

The bug with \ in specific to the username entry of the account setup wizard,
such that a username DOMAIN\user needs to get into the prefs.js as
DOMAIN\\\\user (or needs to be escaped on reading prefs.js).

The bug with " is specific to the protocol output of IMAP such that all "
characters that are not representing the beginning or end of a password string
need to be passed as \"

Many thanks
Sam Winstanley
Senior QA Engineer
SPSS Inc. (London,UK)

Comment 1

[Dawn Endico]

No one has looked at this bug in quite a while. Samw, could you download
M15 and see if you still find this problem? Confirming this bug since it
looks well defined.

Comment 2

[Sam Winstanley]

I can confirm that this is still a bug in the M15 build. 

Comment 3

[Scott MacGregor]

alecf, would the first part of this bug belong to you in the account wizard?
That is, if the user name contains a '\' as in DOMAIN\user, we need to escape
that before going into prefs.js.

The second part sounds like me or jefft.

Comment 4

[Alec Flett]

yes, I think so.

Comment 5

[Scott MacGregor]

Okay, re-assigning to alecf to fix the first part. Re-assign to me and I'll fix
the protocol part when you are done.

Comment 6

[scottputterman]

moving to M18 and marking nsbeta3 and interop

Comment 7

[selmer (gone)]

Adding mail2 nomination keyword for triage effort.

Comment 8

[lchiang]

+ per mail triage

Comment 9

[David :Bienvenu]

I'll look at this.

Comment 10

[lchiang]

second pass - per mail triage

Comment 11

[pohl]

Since this bug impacts my use of the mozilla mail agent at work, I tested this
today.  The account wizard correctly escaped the backslashes in my username when
it stored them into prefs.js (Linux/i386 built from cvs this morning)  So, it
appears that we now need to do the second part (making sure these characters are
escaped going over the wire to the IMAP server.

Comment 12

[scottputterman]

sorry for the extra email. Removing mail2 keyword.

Comment 13

[David :Bienvenu]

adding keyword

Comment 14

[David :Bienvenu]

Looks like bug 59231 is a dup of most of this bug (the backslash part) so I'm
changing the summary to just the remaining double quote part. Thanks for fixing
59231, Seth.

Comment 15

[Sam Winstanley]

Ok, I will retest in M15 and M16

Comment 16

[David :Bienvenu]

What do you mean about testing with m15 and m16? I think this was fixed very
very recently, post Netscape 6.0 release.

Comment 17

[Sam Winstanley]

OK I retested in M18 and the problem is still exists, there is more than one 
bug here (or there are several parts) and some have been fixed.

Firstly on the \ character in logins for MS servers:

1. Do wizard for account setup and enter a username DOMAIN\user
2. username is successfully placed in prefs.js and is properly escaped into 
DOMAIN\\user (this gets around the javascript need for escaping). 
3. Subsequent attempts to read the string from prefs.js are also successful, 
such that the account properties for the IMAP account display the name as 
entered, this is also correct.
4. When tracing the IMAP conversation with the server is is clear that the 
problem is more likely to be in the IMAP protocol handler, e.g. the name is 
read from prefs.js as DOMAIN\user, this string is not escaped to the IMAP 
convention which would be DOMAIN\\user it is merely sent as DOMAIN\user.

With passwords the same problem exists, passwords are sent as plain text and 
can contain characters like '\' '"' and these need escaping using the same 
C/javascript convention before they are sent to the server. 

Updated the platform to All... I can reproduce this on Linux NT 4.0 and Win2k. 
The server is MS Windows NT but the client could be any platform.
 

Comment 18

[David :Bienvenu]

by m18, do you mean a daily build from 11/18/00 or later? Because only a build
after that would contain Seth's fix.

Comment 19

[pohl]

I just tested this from a linux/i386 machine.  The build is fresh from cvs
sources as of this morning.  I had the same results that Sam described with M18:
the prefs.js file correctly shows the backslashes escaped, but the login fails.
 I'm trying to figure out how to use something like tcpdump to show the
conversation with the IMAP/Exchange server, but haven't managed to see whether
the backslashes are being escaped over the wire yet.

Comment 20

[pohl]

Could it be that Seth's fix is not in the trunk?

Comment 21

[David :Bienvenu]

I'm pretty sure Seth's fix is *only* on the trunk. Actually, I think I'm an
idiot about this - Seth's fix is for passwords, not usernames.

Comment 22

[(not reading, please use [e-mail] instead)]

my fix is on the trunk.  henrik gemal has verified it.

my fix was only for passwords with a "\" that were sent during insecure imap login.

let me go find the bug number.

Comment 23

[(not reading, please use [e-mail] instead)]

for you curious types, the bug was #59231

Comment 24

[pohl]

I figured out tcpdump.   The trunk build I just tested is not escaping the
backslashes.

# tcpdump -i eth0 -s 2048 -w /tmp/DUMP dst exchng7
  ^C when done attempting to authenticate.
# strings /tmp/DUMPl\_f
l\_fTP
l\_fTP
1 capability
z\_f
z\_f
2 login "Gallup\pohl longsine\pohl_longsine" "********"
3 logout
\_gSP

Comment 25

[David :Bienvenu]

I've taked Seth's fix for login id's and extended it to passwords in the
proposed fix I've attached. Can I get some r=?

Comment 26

[David :Bienvenu]

Attachment: proposed fix

Comment 27

[David :Bienvenu]

actually, reverse that, I've taken Seth's fix for passwords and extended it to
usernames.

Comment 28

[(not reading, please use [e-mail] instead)]

r=sspitzer

Comment 29

[pohl]

I applied the patch & built it.  It works fine...I can log into my Exchange
server.  Bravo!

2 login "Gallup\\pohl longsine\\pohl_longsine" "*******"

P.S.  Could you guys tell me what this supersecret "r=foo" notation means?

Comment 30

[David :Bienvenu]

r means review, as in code review, reading the code and making sure there's
nothing obviously wrong with it. =foo is the person doing the review. thanks for
running the code (the true test :-) )

Comment 31

[scottputterman]

did this get checked in?

Comment 32

[David :Bienvenu]

yes, I think so.

Comment 33

[Henrik Gemal]

tested on a InterMail IMAP with the password net."scape and it worked...
build 20011018