Closed Bug 53970 Opened 24 years ago Closed 24 years ago

Make username with "@" work without editing prefs.js file

Categories

(MailNews Core :: Networking: POP, defect, P3)

Product:
MailNews Core
Component:
Networking: POP
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: andewid, Assigned: sspitzer)

References

Details

(Whiteboard: relnote-user, [rtm-])

Attachments

(1 file)

fix
3.13 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m17) Gecko/20000807
BuildID:    2000080712

when using an @-sign in the username for a pop-serven Mozilla is unable to connect.

Reproducible: Always
Steps to Reproduce:
1.Create a pop-account on your mailserver that has a @-sign in the usename.
2.Type in that username and pop-server in the mailproperties
3.Press "Get Messages"

Actual Results:  "An error occured while sending the password to the mailserver"

Expected Results:  Mozilla should have downloaded new e-mails from the pop-server.

There is nothing worng with the POP-server as it has been tested with Outlook,
ICQ and other e-mail clients.
Yeah, I'm seeing this on the latest build under Linux. When the pop-up box comes
up asking for the password, it shows the username as user@pophost@pophost
(replace those with your appopriate username & POP mail host).
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: esther → huang
per bug 34996 you need to edit your prefs.js file for this type of user name

"something to remember when testing on usernames with "@" (like ww@cko) is that
you set the "mail.allow_at_sign_in_user_name" pref to true in your prefs.js 
file"

However, we found a new bug where the message body is not downloaded after a 
successful login.  We will log the new bug.  The edit of prefs.js should be 
release noted.  
Please try this again with the pref change to see that the login works.
Keywords: relnote3
FYI...the new bug for messages not displaying is 54054
I made a quick search and found bug 22450, wich had a similar problems with
@-signs in the usename for POP-server. However the quickfix
(user_pref("mail.allow_at_sign_in_user_name",true);) does not seem to work very
good. An escaped @-sign does not seem to solve the problem either.

don't manually escape the "@" the username.  that will cause other failure.

Removed blocker severity
We're release noting the need for a prefs.js line.
So is this bug's issue now that we need to make it work without a prefs.js line
inserted?  If so, someone in-house please change the summary and nominate or
future as appropriate.
Severity: blocker → major
I would think that a pref solution should sufficient. I would like to mark this
bug as a duplicate of 22450.


*** This bug has been marked as a duplicate of 22450 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
I am thinking that this bug should be dup of bug 34996 instead of bug 22450, 
But I won't mark as dup of bug 34996 since we still have the following issues 
left:

1)Adding "user_pref("mail.allow_at_sign_in_user_name", true);" in the prefs.js 
file is working on Netscape 6.0, but there is prefs.js reflect problem on 4.7: 
For some reason, users need to add prefs.js line correctly before login in this 
account successfully. If users add prefs.js line after login.....it won't 
reflect the change for the prefs.js file, even it did show the correct info on 
the prefs.js file, but just couldn't login successfully afterwards. The user 
name will skip the letters after @ sign and didn't reflect any change from the 
user name. I don't know how does 4.75 work? At least for 4.7 - with this 
workaround still having prefs.js reflect problem.....this should be 4.7 bug, but 
if users cannot go through from 4.7, they won't get the correct migration to 
6.0.

2)Even bug 34996 has been verified with editing prefs.js workaround, we really 
need to make it work without editing prefs.js file

3)Reopening this bug, changing summary to reflect the rest problem.
And I suggest to release notes for beta3 and let developers to decide the target 
milestone....

I am wondering to know whether this bug should reassign to Seth since he fix bug  
34996, and this is just the follow-up issue left......
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: "At sign" in pop username. → Make username with "@" work without editing prefs.js file
If we won't fix this for RTM, then we must release note for RTM....adding 
relnoteRTM for the keywords.
Keywords: relnoteRTM
from bug 34996 Additional Comments From timeless@bemail.org 2000-10-11 00:14 
> ... we need to relnote this.
> Seth, is there any risk in changing the default to true?
It seems we had some minor risks in the past due to incomplete implementation 
of other migration features (causing bug 22450)
> If there is, 
This is the bug, thanks huang@netscape.com
> .. pick an assignee, 
hi jeff, I guess this is yours :|
> and explain the risk.
Is there more risk to enabling ths preference by default?
<snip>
relnote: &branding; mailnews prefers not to accept account names containing 
&oddcharacters; if your account includes one of those characters please edit 
prefs.js (link explaining how to find and edit it) to include this string:
user_pref("mail.allow_at_sign_in_user_name", true); 
-
I'm doing the following: Adding relnote; marking depends on:
bug 34996 [implement support for user@host account names]
Not marking depends on
bug 54054 [POP user name with @ doesn't display message in message body]
^ This bug would probably also depends on 34996
bug 22450 [won't accept password if the pop username is the full email address]
^ I think this bug needs to be resummarized and is actually related to profile 
migration.
Depends on: 34996
Keywords: relnote
Future.
Target Milestone: --- → Future
Whiteboard: relnote-user
This bug is a major problem here, at least here in Germany. *Many* ISPs (I'd
guess 20-30%) use such usernames, and have to tell users to hand-edit their
prefs.js. This is not acceptable.

Please see bug 57129.
OS: Windows 2000 → All
Hardware: PC → All
Keywords: mozilla1.0
jefft, are you the correct owner for this?  seems more account manager related.

The correct way, sounds to me, is adding an UI check box (per account base) to
the account manager with default value set to false. It's rather unfortune that
we cannot make this to RTM. UI has been freezed for ages.
What is the problem with just changing the pref? After all MSOE lives fine
without being so "smart" (and seems to live better that way).

I'll bit and nominate for rtm. This breaks many sites (or alternatively requires
newbies to tamper with interal profile files, a risky task).
Keywords: rtm
Good argument. The pref isn't fully implemented. It only works for pop3 client.
I am happy to check it in if you can persuade the PDT team. :-)
Keywords: rtm
(readding rtm keyword, which has been (probably) accidently removed.)
Keywords: rtm
this pref was defaulted to false in 4.x.  there are 4.x users out there who have
set there pop username to "foo@bar.com" (mistakenly, it should be "foo") but it
worked fine in 4.x and when they migrated to 6.0 it works fine since the default
is still to truncate at the @.  if we change the default pref, we will be
breaking some users on migration.

Since there is a work around (albeit not a great one for newbies) and not a
simple fix that doesn't cause migration problem, I'm going to mark this rtm-.

here's what I think we should do:

1)  make this "allow @" a per server pref, not a global pref.
2)  when we migrate, if the user has a pop server 4.x pop server, that servers
pref == the 4.x global pref value
3)  for all new accounts, if the user enters a username with an "@" we set
"allow @" to be true.  (no new ui or checkboxes to the account setup.  the
design was to keep the setup simple, and add the advance stuff to the account
settings dialog.)
4)  add an "allow @" checkbox to the pop server panesl in account settings

comments?
Whiteboard: relnote-user → relnote-user, [rtm-]
Well said and I agreed. Might consider Imap account too. I am not sure whether
an Imap account username allows @ sign.
we already do the right thing for imap usernames.  let me go find the bug where
I fixed that.

i like everything you said except for the rtm- :| but that's irrelevant.
> 3)  for all new accounts, if the user enters a username with an "@" we set
> "allow @" to be true.  (no new ui or checkboxes to the account setup.  the
> design was to keep the setup simple, and add the advance stuff to the account
> settings dialog.)

So, why not just default to true in all cases, and make the 4.x-migrator set
"false" unless there is a *user*-pref that says otherwise?

That way, we could practically get rid of the pref altogether. It would also
allow us to avoid to...

> 4)  add an "allow @" checkbox to the pop server panesl in account settings

... and just add a static text blurb telling the user not to enter the domain
part unless explicitly told by the ISP. (That way, we could easily remove the
text for a wizard for advanced users.)

Why not have two usernames held in memory? In addition to m_username you could 
have m_Fullusername or something. m_username is the truncated username and 
m_Fullusername is the full username as entered. Let Mozilla go through the 
routine with m_username first. If that triggers a bad login, go back to 
nsPop3Protocol::SetUsername() and this time set m_username = m_Fullusername and 
run through it again. If this results in a good login, you could be really cool 
and write the "mail.allow_at_sign_in_username" pref to the prefs file to avoid 
this loop in the future.

Is this even reasonable? I was looking around in nspop3protocol.cpp, but I 
hardly know C. I could make sense of it a little, but it is hard to get a feel 
for how things flow. It id look like this shouldn't be too hard though.
CC'ing self
we aren't going to fix this for rtm, it's too late.

but we should continue to discuss a fix that we'll land on the trunk.

the first step will be to make this a server pref.

and jglick to the cc list, so she can help us come up with the right place and
wording for this pref.

jerry, I remember jfriend suggesting something like that in the n.p.m.mail-news
newsgroup.  let me go find his post. 
see jfriend's comment news://news.mozilla.org/37C2DEDC.2DB7FBBE@netscape.com

I still haven't found the "@" in the imap username bug, let me go find that.

(but I know I fixed it.)

If you really want to try both possibilities, then try the verbose version (with
@-sign) first, and do it only if there actually is an @-sign in the username.
I only find bug 12390 for addressing POP & IMAP for @ user name problem......
thanks karen.

following the chain of duplicates, I found the bug

http://bugzilla.mozilla.org/show_bug.cgi?id=34996

to summarize, usernames with "@" work fine on IMAP.

re-assign to me.  once I handle the migration and account manager back end, I'll
hand this off to the rightful owner.
Assignee: jefft → sspitzer
Status: REOPENED → NEW
karen also found http://bugzilla.mozilla.org/show_bug.cgi?id=34996

which relates to this.

accepting.
Status: NEW → ASSIGNED
What I mean is: Actually, this bug has been updated generating from bug 34996 
(see my 2000-10-03 15:17 comments) and timeless marked "depends on bug 34996" on 
2000-10-11 07:56.
I did verify Seth's fix bug 34996 for POP (since bug 34996 originally logged for 
POP account), but not sure for IMAP. I will verify bug 34996 on IMAP again.....

Verified again on IMAP for WinNT 10-06-09-MN6 build.
Yes!! Seth's bug 34996 workaround did fix on IMAP as well for @ user name 
account.
I am confused.

Additional Comments From timeless@mac.com 2000-10-11 00:14 in bug 34996:
> relnote: &branding; mailnews prefers not to accept account names containing
> &oddcharacters; if your account includes one of those characters please edit
> prefs.js (link explaining how to find and edit it) to include this string:
> user_pref("mail.allow_at_sign_in_user_name", true);

This *does* necessiate editing prefs.js for POP accounts with "@" in the
username, not?

all we need to say in the relnote is:

if you set up a POP account and you have a "@" in the username, add this to your
prefs.js:

user_pref("mail.allow_at_sign_in_user_name", true);

note, if the user had a pop account with a username with a "@" in 4.x, then
shouldn't have to do anything if they migrate.  That pref should already be set.

IMAP is works just fine with "@", "%", etc.
*** Bug 55142 has been marked as a duplicate of this bug. ***
With all the never-valid input which Mozilla accepts in various places, it seems 
ironic that there is a pref to deny input which might actually be valid.

This pref should go away altogether. If you have problems with people incorrectly 
entering their e-mail addresses as user names, then use `Example' text next to 
the fields (like the Internet control panel does).

I agree with mpt and what jfriend wrote in the news article Seth added a link
to.  This is showing up as a top item that users are having problems with.  I
think example text should be enough.  As Seth mentioned we'll need to come up
with a reasonable policy for migration, but for new accounts onwards, why not
just allow '@' in the user name?
Keywords: mail5 → mail3
for migration, I'll do this:

there was only pop account in 4.x, so if they needed the @ sign, they had the
pref set.  upon migration, if the pref is not set and the username has an @
sign, I'll trim the username.  otherwise, I'll leave it alone.

for any new accounts, users can enter foo or foo@bar as the username.

then, I'll remove the code in nsPop3Protocol that checks that pref and alters
the username.  note, that pref will only be used for migration purposes.

then, when I go to login I'll try the username.  if the username was "foo@bar"
and login fails, I'll try again (silently) with "foo".  if that succeeds, I'll
change the users username to "foo".  if "foo@bar" and "foo" fail, I'll leave the
username as "foo@bar", assuming it was a bad username or a bad password.

note, there will not be any additional UI.

I'll start working on this today.  it shouldn't be hard and there seems to be a
lot of demand for it.
I've got a fix, but let me clarify some problems with my previous comments.

> for migration, I'll do this:
> there was only pop account in 4.x, so if they needed the @ sign, they had the
> pref set.  upon migration, if the pref is not set and the username has an @
> sign, I'll trim the username.  otherwise, I'll leave it alone.

this is not needed, the migration code works fine no matter what the username
was.  if the user ever used 4.x to read their mail, the username set correctly.
if the entered "foo@bar" but never set the "allow at sign" pref, we would have
stripped it to "foo" in 4.x.  If they set the "allow at sign" pref, the username
would have been "foo@bar", and it will migrate over like that.

> for any new accounts, users can enter foo or foo@bar as the username.

my fix allows this to be true, since I never truncate the username.

> then, when I go to login I'll try the username.  if the username was "foo@bar"
> and login fails, I'll try again (silently) with "foo".  if that succeeds, I'll
> change the users username to "foo".  if "foo@bar" and "foo" fail, I'll leave
> the username as "foo@bar", assuming it was a bad username or a bad password.

my patch does don't this.  if you enter in your full email address for your
username, you won't be able to log in.

I'm still not sure trying to log in twice is the right solution.  And, changing
the username while running has issues, see below.

> note, there will not be any additional UI.
we need to make it so a user can change there username in the account manager.
see bug #14295.  while the fix to the account manager xul and js is trivial, the
other work that needs to be done to support being able to the username on the
fly is not trival.

until that is fixed, users will have to edit there prefs to change a username.

I'll attach the patch for what I've got.

cc'ing mscott for a sr=
adding patch keyword.
Keywords: patch
sr=mscott
fixed.  the only interesting thing now to fix is allowing the user to change the
username on the fly.  if you care about that, add yourself to #14295
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
note to qa, here is how to verify this fix:

1) 4.x migration should work when user entered username as foo@bar.com, the
correct username is foo@bar.com, and
"mail.allow_at_sign_in_user_name" was set to true.

2) 4.x migration should work when user entered username as foo@bar.com, the
correct username was foo, and 
"mail.allow_at_sign_in_user_name" was set to false.

in 4.x, if the pref is false (or not set), foo@bar.com will get stripped to foo.
when you migrate, the pop username will be set to foo, since that is what it was
in 4.x

3) entering a new pop account in 6.x with username of foo@bar.com and correct
username is foo@bar.com.  you will be able to get mail.  it doesn't matter what
the "mail.allow_at_sign_in_user_name" is set to.

4) entering a new pop account in 6.x with username of foo and correct username
is foo.  you will be able to get mail.

4) entering a new pop account in 6.x with username of foo@bar.com and correct
username is foo.  in this case, you will not be able to get mail.  this used to
work in 4.x, since we stripped the username if "mail.allow_at_sign_in_user_name"
was false (or not set.)  This is correct behaviour now.

if you have any questions, please post them in this bug report.
This bug is really taking me a while for verify......

In order to ensure this is working on POP(Migrated profile and new profile) & 
IMAP(Migrated profile and new profile) for All the platforms, I need to create 
total 12 profiles to verify this bug.

Following are the verify results:
1) Window platform w/12-20-09-Mtrunk build:
POP accounts: a) Migrated profile 
                 w/edit prefs.js on 4.x as Seth described -> Passed
              b) New profile w/o edit prefs.js -> Passed
IMAP account: a) Migrated profile 
                 w/edit prefs.js on 4.x as Seth described -> Passed
              b) New profile w/o edit prefs.js-> Passed

2) Linux platform w/12-20-08-Mtrunk build:
POP accounts: a) Migrated profile 
                 w/edit preferences.js on 4.x as Seth described -> Passed
              b) New profile 
                 w/o edit prefs.js -> Passed 
IMAP account: a) Migrated profile
                 w/edit preferences.js on 4.x as Seth described -> Passed
              b) New profile
                 w/o edit prefs.js -> Passed 

3) Mac platform w/12-20-10-Mtrunk build:
POP accounts: a) Migrated profile 
                 w/edit prefs.js on 4.x as Seth described -> Passed
              b) New profile w/o edit prefs.js -> Passed
IMAP account: a) Migrated profile 
                 w/edit prefs.js on 4.x as Seth described -> Passed
              b) New profile w/o edit prefs.js-> Passed

Marking as verified - great work, Seth.
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
Product: MailNews → Core
Product: Core → MailNews Core
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: