Closed Bug 93452 Opened 23 years ago Closed 21 years ago

redundant password entry for mail

Categories

(MailNews Core :: Security, defect)

x86
Windows 2000
defect
Not set
normal

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
Keywords: nsenterprise
I'm not sure who should take this...Networking?
Assignee: mstoltz → mscott
Component: Security: General → Networking - General
QA Contact: junruh → huang
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?
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
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 → ---
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.
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.
Qa > esther. Not an SSL issue.
QA Contact: junruh → esther
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.
taking.
Assignee: mscott → bienvenu
Status: REOPENED → NEW
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 ago21 years ago
Resolution: --- → DUPLICATE
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.