Closed Bug 108912 Opened 19 years ago Closed 19 years ago

Cannot send a message after adding a second account

Categories

(SeaMonkey :: MailNews: Account Configuration, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.6

People

(Reporter: nbaca, Assigned: racham)

References

Details

(Whiteboard: 0.9.4ec only)

Attachments

(5 files)

Trunk build 2001-11-06-12: WinMe, Linux RH 7.1
haven't tried mac yet.

Overview: Cannot send a message after adding a second account

Steps to reproduce:
1. Migrated an account and I am able to send/receive a message (IMAP in this case)
2. Exit/Restart
3. Add a second account
4. Check the Outgoing SMTP, Advance dialog

Actual Results: 
a. Check the Outgoing SMTP, Advanced dialog and instead of referencing
'nsmail-1' the entry looks like a pref "mail.identity.id1.organization (Default)"
b. try to send a message from the 1st or 2nd account and it reports An error
"Sending of message failed...Unable to connect to SMTP Server...". 
c. Checked Outgoing SMTP, Advanced dialog again and it now states "nsmail-1
(Default)" as it should.
d. Exit/Restart
e. Still having problems sending a message from either account
f. Go to Outgoing SMTP, Advanced dialog again and it now displays a blank entry
followed by "nsmail-1 (Default)". If the blank entry is deleted then it displays
duplicate "null(Default" entries.

Workaround: Add another "nsmail-1" server. Go to the Identity panels for each
account, select the Advanced button, select the new "nsmail-1" entry. Now I am
able to send/receive messages from both accounts.
Oops, the previous statement should have referenced "f" in the list of Actual
Results.
Marking nsbeta1 since adding accounts makes the send/receive experience too
complicated.
Keywords: nsbeta1
Bug 108892 is probably a dup of this bug.  The sending error seems to be the 
same in both cases.  Ninoschka has used a later build from yesterday so this 
problem could have been there since yesterday. 
Update on Workaround: 
After adding the second account and being unable to send a message, I go into
Account Setting's, Identity, Advanced dialog and change the setting from using
the default server to a specific entry (i.e. nsmail-1) and now I'm able to send
messages. 
The action that triggers the problem is opening the Account Settings dialog and
selecting the OK button.

Steps to reproduce:
1. Use a new or migrated profile configured for an IMAP account (although the
problem also occurs with POP)
2. Login to the account
3. Send a message, it should send successfully
4. Select Edit|Mail & Newsgroup Account Settings (just open the Account Settings
dialog don't switch to another panel)
5. Select the OK button
6. Send another message

Actual Results: It reports that it can't send.
Note: In step #5 if I select the Cancel button I am still able to send a message
so the problem occurs when the OK button is selected.

Additional Information:
- With a POP account I always had a problem sending because in a new profile I
always cancel the login and go into Account Settings to Leave Messages On Server. 

*** Bug 108892 has been marked as a duplicate of this bug. ***
Bhuvan, can you look into this.  This is pretty high priority.
Keywords: nsbeta1nsbeta1+
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6
Sure. Taking the bug.

Status: NEW → ASSIGNED
Ninoschka, good report. Problem became pretty evident.

So, if the we accountcentral today to create, we will never run into the
problem as we are not opening the accountmanager window. Then when you open the
accountmanager window (either the first or second account), the smtpServer
value at identity level is set to an empty string. SmtpService tries to
generate a server out of this empty string and we essentially fail. If the user
clicks on Advanced button and picks a outgoing server, then right things will
happen as we have a smtpServerKey with a value.

So, with the patch, if the serverKey is empty, we fall back on default server.
At the same time, if user manually chooses a outgoing server, we will honor
that as expected.
Ninoschka, good report. Problem became pretty evident.

So, if the we use accountcentral today to create, we will never run into the
problem as we are not opening the accountmanager window. Then when you open the
accountmanager window (either the first or second account), the smtpServer
value at identity level is set to an empty string. SmtpService tries to
generate a server out of this empty string and we essentially fail. If the user
clicks on Advanced button and picks a outgoing server, then right things will
happen as we have a smtpServerKey with a value.

So, with the patch, if the serverKey is empty, we fall back on default server.
At the same time, if user manually chooses a outgoing server, we will honor
that as expected.
ducarroz, can you review. thanks.
ducarroz, can you review? thanks.
cc'ing myself
Severity: major → critical
Comment on attachment 57038 [details] [diff] [review]
patch, v1 - check the validity of smtpserverkey

sr=sspitzer

how are we getting into that state, where the server key is empty?
Attachment #57038 - Flags: superreview+
There are 2 ways we can get into this state.

1. You open the accountmanager window. Don't do anything. Just click OK.
Function checkUserServerChanges kicks off and writes the smtpServerKey pref to
be "".

2. On the accountmanager window, click on the Advanced buton. This will open the
smtpserver list dialog. Previously, if it were set to the a valid server and now
if you select 'Always use the default server' that sets the smtpServerKey pref
value for that identity to be "".

Those are the 2 cases I have noticed. So, even if there are any other chances of
getting into this state, it will be more accurate if we check to see if the key
has any contents in it and then prevent proceeding further in that path.

thanks for the review.
bhuvan
I'm chiming in here as I posted to bug 106772.

I'm seeing this problem on 2001110803 on win2Kpro-sp2 simply by changing the
text of the single outbound server seting.  The diff of the prefs file:

157a158
> user_pref("mail.identity.id2.smtpServer", "");
238c239
< user_pref("mail.smtpserver.smtp1.auth_method", 1);
---
> user_pref("mail.smtpserver.smtp1.auth_method", 0);
241c242
< user_pref("mail.smtpserver.smtp1.username", "null");
---
> user_pref("mail.smtpserver.smtp1.username", "");

The real offender is the dummy entry:
user_pref("mail.identity.id2.smtpServer", "")

remove that and it works.
Comment on attachment 57038 [details] [diff] [review]
patch, v1 - check the validity of smtpserverkey

R=ducarroz
Attachment #57038 - Flags: review+
a=asa (on behalf of drivers) for checkin to 0.9.6
Keywords: mozilla0.9.6+
Bug 109115 is a dup of thia (I stated there otherwise but now I retract). The
way I can always reproduce this is just to change the Use Secure Connection
(SSL). If I touch this setting nothing helps (including obviously setting it
back). The only solution is to use an October build (I used 10/29) to touch the
SMTP settings. This restores SMTP functionality of the new builds which have
this bug.

I wonder if the patch will help in the case I described.
Fix checked in. Marking fixed.

Please try to reproduce if any of the problems that are connected with opening
the AccountManager window (for any tasks listed there) with the build that
contains this patch (or you can apply the patch if you build the tree).
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 109185 has been marked as a duplicate of this bug. ***
WFM with fresh CVS build on WindowsME. I tried every way described here to cause
the SMTP horkage, both with one and two SMTP servers. To no avail. As my
symptoms before the patch were closer to bug 109115, I'll mark it a dup of this bug.
*** Bug 109115 has been marked as a duplicate of this bug. ***
-> All/All as duped bug 109115 was originally a Mac bug.
OS: Windows ME → All
it appears that mozilla new account wizard change is not adding the
smtp.netscape. com (net?) as the default smtp server for newsgroup wizard now
like it used to in earlier milestones and trunks before the wizard code changed.
 Could this be related to the breakage?  Dont know about the ISP or Email wizard
though.  
Trunk build 2001-11-09-08: WinMe, Linux RH 7.1, Mac 9.1
Verified Fixed.

Scenarios performed:
1. With one account, opened Account Settings, select OK= send ok
2. Open Account Settings, select the Advanced button from first panel and
changed it from using the default to a specific server = send ok
3. Open Account Settings, select the Advanced button from first panel and
changed it from the specific server back to using the default = send ok
4. Added a second account = send ok
5. Selected the SMTP SSL option = send ok
Status: RESOLVED → VERIFIED
I cannot use that trunk. I get bunch of -621 errors on all .xpi files.
I filed bug 109409

*** Bug 102316 has been marked as a duplicate of this bug. ***
this is present on 0.9.4ec builds. 
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Whiteboard: 0.9.4ec only
Ninoschka,

Can you verify to see if this is happening..? 

Tracy, can you give the BUILD id..? Also, can yuo provide the following pref
from the presf.js of troubled profile.

"mail.smtp.defaultserver".

thanks,
bhuvan.
Whiteboard: 0.9.4ec only
I didn't realize that I removed '0.9.4ec only' from status whiteboard (in the
last update). Adding it back.
Whiteboard: 0.9.4ec only
I tried build 2001-11-14-22-0.9.4ec: WinM

I am able to send/received messages after performing some basics tests.

1. Adding one account, going into Account Settings, selecting the OK button,
then successfully sent/received a messsage.
- Checked Outgoing SMTP, Advanced button and it displayed
null
nsmail-1(Default)

2. Adding a second account, and still able to send/receive a message.
- Checked Outgoing SMTP, Advanced button and it displayed
null
nsmail-1
nsmail-1(Default)

Does it matter if this is on 0.9.4ec?  First, I didn't think mail mattered for
that branch.  Second, the change we think caused the problem (being able to edit
the server name) didn't land until after the 0.9.4 branch.  Assuming all I said
is true, I think we should leave this bug fixed.
is this moot for 0.9.4ec??

is mail moot for ec builds??
If ec stands for what I think it stands for then as far as I know testing mail
is unnecessary.  Adding Marek for confirmation.
not important in 0.9.4ec (i.e., we don't need to track it as such). The only
thing you need to answer is to check if the fix for this is important to add to
Jaime's tracking bug (in eMojo++).
What is the bug number of emojo++ metabug..? Is there one..?
The fix in here is imporatnt to be considered for all releases with a plan
active mailnewe component usage.

Anyway, I am marking this fixed per discussions.
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
*** Bug 109615 has been marked as a duplicate of this bug. ***
No need to add this one to Jaime's tracking bug.
*** Bug 118595 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.