Closed
Bug 93452
Opened 23 years ago
Closed 21 years ago
redundant password entry for mail
Categories
(MailNews Core :: Security, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 219200
People
(Reporter: mitch, Assigned: Bienvenu)
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 BuildID: Netscape 6.1 PR 1 After starting mail client, you must enter a password to read mail. You must also enter a password to send mail. When sending, the req'd password should default to the same passwd used to read mail. Reproducible: Always Steps to Reproduce: 1. select "tasks | mail" menu 2. enter password to read mail 3. create and send mail Actual Results: you are required to enter a password again Expected Results: should default to previous password
Reporter | ||
Updated•23 years ago
|
Keywords: nsenterprise
Comment 1•23 years ago
|
||
I'm not sure who should take this...Networking?
Assignee: mstoltz → mscott
Component: Security: General → Networking - General
QA Contact: junruh → huang
Updated•23 years ago
|
Keywords: nsenterprise → nsenterprise-
Comment 2•23 years ago
|
||
Are you using multiple accounts? We shouldn't authenticate for sending....reassign QA to Ninoschka.
Component: Networking - General → Networking - SMTP
QA Contact: huang → nbaca
I'm using win32 BuildID 2002010703 on win2k Pro SP2 and having the same problem. I use the same server for IMAP and SMTP so perhaps mozilla assumes that these might be different servers and so asks for the password again instead of checking to see if it already has it?
Comment 4•23 years ago
|
||
If your smtp server is a secure server and in Account Settings/Outgoing SMTP Server panel if you have "User Secure Connection (SSL)" set to When Available or Always then you will be prompted to enter a password when sending messages. Reassigning to junruh because this sounds like a secure server issue.
Component: Networking - SMTP → Security: General
QA Contact: nbaca → junruh
Comment 5•23 years ago
|
||
WFM. This is working as expected for me. I don't get asked for a password againg when sending email as long as I have entered my password already to receive email. The exception to this behavior is described in the comment right above.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
I'm using build 2002021203 on win2k sp2, I use the same server for receiving e-mail (IMAP) as I do for sending (SMTP). My SMTP server is set with SSL on Never. When I first start mail i get asked for a password to retreve my e-mail and then asked again the first time I need to send an e-mail. So this is not resolved, so can someone reopen this.
well the exception is what the bug is about.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 8•23 years ago
|
||
With the 2/20/02 build, I am not asked for a password to send mail if I have already received mail. SMTP setting is on Always. Please try today's build.
For receiving SSL is unticked, for sending SSL is set to never. I will try the 20020220 build later today.
Comment 10•23 years ago
|
||
Okay tested build ID 2002022009. For incoming server (adm1) SSL is unticked, it's an IMAP server and is configured to check for mail on startup. For outgoing server (adm1), use name and password is ticked and SSL is set to never. When I first start up mail I'm asked for a password and when I first send an e-mail I'm asked for a password too.
Comment 12•21 years ago
|
||
This behavior exists in Mozilla 1.5b1 downloaded 28-aug-2003. It also existed in Mozilla 1.3. I am running RedHat Linux version 9 (redhat-release-9-3), kernel 2.4.20-19.9, FWIW. I manage 3 IMAP mail accounts from Mozilla. The incoming servers are all SSL/IMAP. For the outgoing server, one is IMAP, but the other two are SMTP - all outgoing servers use SSH as well. For each account, I use the outgoing server that "belongs to" that mail account, so that messages have an origination path that matches the claimed domain name of my account. When I fire up the mail client, it prompts me for the passwords for each of the three incoming servers. (This is because I wish to view messages on startup.) I can then commit multiple reads without further password prompts. However, the first time I go to send a message from each account, it prompts me for a password. Of course, the password is the same on the outbound server as it is on the inbound server. This is an inconvenience, not a show stopper or critical failure. Intuitively, it makes sense that the password is the same on the inbound as well as outbound server for each account. Now, you can get into the situation where a different server is used for outbound than inbound. Perhaps some folks have 3 mail accounts, but use a single default outbound SMTP server for all of them. In that case, there is no connection between the inbound and outbound server. IMHO, what should be implemented is a domain-based "same password" hash table to remember passwords. What follows is hopefully the starting point for a design dialog, so please read and comment, especially concerning the security of the approach. Same Password would work like this. The hash table contains a list of servers each having a single password field that stores passwords temporarily but that can also remember long-term which servers share passwords. The table is indexed by server name, and contains a password field and a link field that holds a logical "same as" link that refers to another server in the table. As an example, smtp.foo.net "" "" (empty, because it doesn't link to anybody) smtp.bar.net "" "@smtp.foo.net" (same password as foo.net) At configuration time, the software establishes the table based on all server names given it by the user, all incoming and outgoing and LDAP and etc servers, and blanks the password field. It stores this table to disk. [Optionally, the GUI can be enhanced to let the user set up the password relationships manually.] At startup, the server loads the password table. For each entry that is not a password link, it blanks it out. When the user accesses a server, password is obtained by find_first_server(current server name) given below. If find_first_server returns null, then prompt the user for the password and fill it into the current server field. On the GUI prompt, give a "same as" dropdown which lets the user say that this password is the same as for some other server. The find_first_server algorithm is: find_first_server(s) Go to entry "s" in the table, and check the password. If the password exists, then return index to the entry, else continue on. Else if the password field is marked "CHECKING", then return null, else continue on. Else if the link field contains a link to another server, then mark the current password as "CHECKING", obtain tmp index = find_first_server(the other server), set current password = server at tmp index's password, return tmp index. Else return null. [The part about CHECKING is to avoid cycles.] Continuing on, if the user specifies a "same password as", then set up the link in the table to the index and write that table out to disk (everything except the passwords themselves). If a password fails on server s, then prompt the user for the password on s and put up the "same as" dropdown. Let us consider the condition of two servers, B, A, where B's password is linked to A which has a bad password. User accesses B, and then accesses A, and links B to A. Now in the future, the password on A changes, and the user tries to access B. He gets a "bad password," and is prompted for the link, which he says is A. Now, he will eventually try to access A and have to change the password. If not, he will get frustrated and unlink the servers, then access A, and link it to B. Easy, no? My point is to sketch one approach that would work, and provide a really helpful feature.
Assignee | ||
Comment 14•21 years ago
|
||
see bug 219200 for what pref(s) to set to get this to work. *** This bug has been marked as a duplicate of 219200 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•