98664 - (+emailwizard) issues if you enter [e-mail] as the email address in the account wizard.

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Account Configuration, defect)

Description

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

comments from [e-mail] from bug #91257

[For those who don't know: Sendmail
apparently has a feature (I didn't enable it; the admin did) by which the
username portion of an email address can contain a plus after it and then
mostly-arbitrary text.  Everything then between the + and @ are (I think)
stripped out of the address, and the mail goes on its merry way, see my email
address ([e-mail]) for example].

I've been using this for a while, and have been having difficulties with it. 
Apparently, all non-alphanumeric characters [probably more; I haven't looked
into it] are translated into %xx, and a new news account is created with this
name as soon as I click on one of the newsgroups.  All messages from the
newsgroups go into this new account.  And, naturally, if I click on the
newsgroup under this *new* account, *another* account is created, but with %25
prepended to the %xx from before (the % from before), and the % is stripped out.
 This click-and-creation can go on ad infinitum.

What's more, if the news account is deleted and then another is re-created with
exactly the same server [even with a different name], then the little
expand/contract arrow appears beside the account settings, but nothing is
displayed at first.  If the account is contracted, then expanded again, <i>the
old subscribed newsgroups return</i>.  Regardless of the new email address, the
old "user%xx on server" "accounts" come back just as before, when one clicks on
the newsgroups.

Comment 1

[Håkan Waara]

If the email address of a news account contains any character such 
as '/', 'å', '&', '+' (etc.) then this mysterious behaviour will take over.

I have been having fun in the debugger for a few days and finally noticed that 
the account manager's FindServer() API wants an unescaped username. All the 
other callers gives it that. This particular call doesn't. Hence, FindServer() 
fails in this case and triggers some strange code in nsNntpService that creates 
a new account.

Fix is to unescape the username in this function. :)

Comment 2

[Håkan Waara]

Attachment: fix

Comment 3

[Håkan Waara]

By the way, this was the root cause of bug 91257 that we worked around by 
blocking some common illegal characters in the account wizard. Now we will not 
discriminate users with '+', '/' and the like in their email addresses to use 
news.

Requesting r= and sr= on the fix from bienvenu and sspitzer.

Comment 4

[Håkan Waara]

Comment on attachment 48722 [details] [diff] [review]
fix

I did some more testing and noticed that even if we now don't crash or create a new wierd account, you still can't retrieve the newsgroups from the server if you have a 'bad' email.

Investigating.

Comment 5

[Håkan Waara]

Hmm... so this the way things work:

if I have the email in my news account as '[e-mail]' then my
username when I attempt to retrieve newsgroups from the server will be
'hwaara+example'.

I am suspecting that certain other areas other than the nntpService doesn't like
this plus sign. Perhaps the servers reject it. What do we do here? Strip it away?

Bienvenu and Seth, please tell me how to cope with this problem.

Comment 6

[Håkan Waara]

Attachment: Patch -uw

Make some bad code respect FindServer()'s preference of unescaped strings. This
works very nice.  I tested it by making a news account for a valid news server
with the email "\\\///@yahoo.com" and I could subscribe and post msgs using
news just fine. :)

Comment 7

[Håkan Waara]

Seth, need review on this one as well...

Comment 8

[Håkan Waara]

Seth doesn't seem to have time to do this; bienvenu can you review the fix instead?

Comment 9

[Håkan Waara]

Attachment: Updated patch

Removed a comment and fixed an indentation issue.

Comment 10

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

reviewing and testing now...

Comment 11

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

this patch is not complete.

set your breakpoint at InternalFindServer(), I'm still getting in there with 
usernames and hostnames that are not escaped.

I tried to create a news account with the email address 
[e-mail], and during the account creation process, we call 
FindServer() two different times.  [which calls InternalFindServer()]

username is note escaped.

after the account is created, I try to use the subscribe dialog, it fails.

I assert here:

line 471, nsNNTPProtocol.cpp:
    rv = accountManager->FindServer((const char *)userName, (const char *)
hostName, "nntp",getter_AddRefs(server));

that fails, because userName is jap3003%2Bbugzilla

interesting, when I do javascript:alert(escape("jap3003+bugzilla") it shows me 
jap3003+bugzilla.

nsEscape() (the C++ version) takes two args, it might be that depending on the 
second one, we'll escape (or not escape) +.

Comment 12

[Håkan Waara]

Thanks, I'll look into this.

Comment 13

[Ninoschka Baca]

Kevin, is this important for the next release? A new News account is created if
the username has special characters. Bug# 95771 mentions a similar problem.

Comment 14

[kmurray1115]

Not sure. Nominating so it gets on our triage radar.

Comment 15

[Håkan Waara]

*** Bug 115409 has been marked as a duplicate of this bug. ***

Comment 16

[Håkan Waara]

I'll try to get to this soon. (BTW, nbaca, I suspect the bug you cited is a
duplicate of this, but we'll see...)

Comment 17

[Håkan Waara]

->0.9.9

Comment 18

[Håkan Waara]

Due to internal problems with my computer, I don't know when I'll get back to
this bug. Feel free to attach a patch -- I'll review it. 

Changing target milestone for now.

Comment 19

[scottputterman]

nsbeta1- per ADT triage. 

Comment 20

[Håkan Waara]

*** Bug 140696 has been marked as a duplicate of this bug. ***

Comment 21

[Håkan Waara]

*** Bug 142301 has been marked as a duplicate of this bug. ***

Comment 22

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 138564 has been marked as a duplicate of this bug. ***

Comment 23

[Ninoschka Baca]

*** Bug 146736 has been marked as a duplicate of this bug. ***

Comment 24

[Håkan Waara]

*** Bug 95771 has been marked as a duplicate of this bug. ***

Comment 25

[Ninoschka Baca]

*** Bug 147840 has been marked as a duplicate of this bug. ***

Comment 26

[Tuukka Tolvanen (sp3000)]

*** Bug 155758 has been marked as a duplicate of this bug. ***

Comment 27

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 157163 has been marked as a duplicate of this bug. ***

Comment 28

[Håkan Waara]

Is this still a problem

Comment 29

[Mike Cowperthwaite]

(In reply to comment #28)
> Is this still a problem

Doesn't appear to be -- I tried and can't reproduce it, and after that flurry 
of dupes in 2002 there hasn't been another for over three years.