Closed Bug 28941 Opened 25 years ago Closed 24 years ago

backslash and Double Quote " not escaped for IMAP username Login

Categories

(MailNews Core :: Networking, defect, P2)

x86
All
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: samw, Assigned: Bienvenu)

Details

(Keywords: imap-interop)

Attachments

(1 file)

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)
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can confirm that this is still a bug in the M15 build. 
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.
Target Milestone: --- → M17
yes, I think so.
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.
Assignee: mscott → alecf
moving to M18 and marking nsbeta3 and interop
Keywords: interop, nsbeta3
Target Milestone: M17 → M18
Status: NEW → ASSIGNED
Adding mail2 nomination keyword for triage effort.
Keywords: mail2
+ per mail triage
Whiteboard: [nsbeta3+]
Priority: P3 → P2
I'll look at this.
Assignee: alecf → bienvenu
Status: ASSIGNED → NEW
second pass - per mail triage
Whiteboard: [nsbeta3+] → [nsbeta3-][cut 8/29]
Status: NEW → ASSIGNED
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.
sorry for the extra email. Removing mail2 keyword.
Keywords: mail2
adding keyword
Keywords: nsbeta3mail3
Whiteboard: [nsbeta3-][cut 8/29]
Target Milestone: M18 → mozilla1.0
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.
Summary: Double Quote " and Backslash not escaped for IMAP Login → Double Quote " not escaped for IMAP Login
Ok, I will retest in M15 and M16
What do you mean about testing with m15 and m16? I think this was fixed very
very recently, post Netscape 6.0 release.
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.
 
OS: Windows 2000 → All
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.
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.
Could it be that Seth's fix is not in the trunk?
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.
Summary: Double Quote " not escaped for IMAP Login → backslash and Double Quote " not escaped for IMAP username Login
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.
for you curious types, the bug was #59231
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

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=?
Attached patch proposed fixSplinter Review
actually, reverse that, I've taken Seth's fix for passwords and extended it to
usernames.
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?
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 :-) )
did this get checked in?
yes, I think so.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
tested on a InterMail IMAP with the password net."scape and it worked...
build 20011018
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: