543827 - Option to use same credentials for outgoing as incoming

Status: UNCONFIRMED

(Thunderbird :: Account Manager, enhancement)

Description

[Charles]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: 3.0.1 final

This should be pretty easy... see following screenshot of how the new Account Wizard UI could look.

There should be an additional field labeled 'Username' under the 'Email address' field new checkbox option next to the 'Remember Password' checkbox on the new account wizard:

[ ]"Use these credentials for Outgoing server too"... by credentials I of course mean username/password.

Lots of mail clients have had this since forever, and it is long overdue in TB.

For The AutoConfig wizard, it could check and see if an smtp server for the provided TLD of the new account email address already exists, and if so, suggest to use it.

Reproducible: Always

Comment 1

[Charles]

Attachment: Mockup of modified New Account Wizard UI

Mockup of how the New Account Wizard could be modified to meet the goals of this enhancement request

Comment 2

[Charles]

Oh - and the USername field could set itself to be the same as the email address (don't most setups now require the full email address to be used for the login username?).

Comment 3

[rsx11m]

The following preferences are already available for matching by host name or domain name, apply to all accounts:

  mail.smtp.useMatchingHostNameServer
  mail.smtp.useMatchingDomainServer

Those currently don't have any UI associated with, though.

Comment 4

[Charles]

Precisely...

The purpose of the enhancement request is to not only provide a UI interface to these options (did my mockup seem reasonable?), but to make their use very easy to access at account creation time - and imo, it should be checked by default, because 9 times out of 10, the same credentials will be used.

Comment 5

[Charles]

(In reply to comment #3)
> The following preferences are already available for matching by host name or
> domain name, apply to all accounts:
> 
>   mail.smtp.useMatchingHostNameServer
>   mail.smtp.useMatchingDomainServer

Which should make this pretty simple - just a little UI tweaking...

:)

Comment 6

[Charles]

(In reply to comment #5)
> (In reply to comment #3)
> > The following preferences are already available for matching by host name or
> > domain name, apply to all accounts:
> > 
> >   mail.smtp.useMatchingHostNameServer
> >   mail.smtp.useMatchingDomainServer
> 
> Which should make this pretty simple - just a little UI tweaking...

Oops... pressed enter before I actually read...

Those would help with the last/least important part of this enhancement request.

So, what would need to be added for the main part of this request is something like:

mail.account.account#.server.reUseCredentials

?

Comment 7

[David :Bienvenu]

For enterprise deployments, the hidden prefs are sufficient, because enterprise deployments tend to need to changes prefs as part of their deployment, even when there is UI to change the prefs. Historically, there has been reluctance to send passwords to servers that the user hasn't explicitly asked us to.

If the autoconfig wizard verified the smtp server logon, however, this issue would be much less important, because we would save the password with the smtp server when we verified the logon.

Comment 8

[Charles]

(In reply to comment #7)
> For enterprise deployments, the hidden prefs are sufficient, because
> enterprise deployments tend to need to changes prefs as part of their
> deployment, even when there is UI to change the prefs.

But the hidden prefs don't allow to use the same *username* and *password*, only the server, do they? Or if they so, their labels certainly don't reflect that, they look like they are only going to reuse the *host/domain* names.

Now that you mention it, I don't understand what those two prefs actually do - can you elaborate?

Also - without GPO/.msi support, there is no true 'enterprise support', so each organization is left to cobble together their own scripted environemnt - something that I'm not skilled enough to do.

> Historically, there has been reluctance to send passwords to servers that the
> user hasn't explicitly asked us to.

Ok, so have it unchecked by default (I disagree with the argument, but I do understand it... sortof). At least that way the option is there, so people like me can just check the box and get on wth things - and so it will be able to be easily set via GPO once GPO support is added.

> If the autoconfig wizard verified the smtp server logon, however, this issue
> would be much less important, because we would save the password with the smtp
> server when we verified the logon.

But the user would still have to add their username *and* password twice. Again, that is a lot of typing when it simply isn't necessary.

If you had the option there, unchecked, it would work the same as it does now - checking the box would *simplify* everything for most people (no prompt for username/password for sending server - hence my opinion that it should be enabled by default)...

Comment 9

[David :Bienvenu]

The automatic setup wizard only makes you enter your e-mail address and password once. I understand you want to use manual setup, and I agree that it should be easier to get to manual setup, but beyond that, we think it's better for most of our users to spend our limited development resources making automatic setup better.

Comment 10

[Charles]

(In reply to comment #9)
> The automatic setup wizard only makes you enter your e-mail address and
> password once.

Yes, but if the server name is slightly different - ie, incoming is 'imap.' and outgoing is 'smtp.', you are forced to re-enter both, there is no option to even *try* the incoming creds, and this is a total waste of the users time in 99% of cases.

> I understand you want to use manual setup, and I agree that it should be
> easier to get to manual setup, but beyond that, we think it's better
> for most of our users to spend our limited development resources making
> automatic setup better.

That's the point - this *would* make automatic setup better, for the case described above.

If the option is enabled and auth is successful for incoming but fails for outgoing, the wizard could 'assume' that the username/password combo must be different for outgoing, and 'uncheck' the option and prompt the user for the username/password.

How much time would it take, really, to simply add an option to use the same credentials? They are already there, stored for the incoming server, so all that needs to be done is add the ability to *use* them for the outgoing server, and I just can't see that being all that difficult, but maybe I'm wrong...

Oh well, I'm about blue in the face, so if you cannot see the value of such a simple option, there's not much else I can say that might change your mind, and its not the end of the world, but it sure would go a long way to making new account setup easier for the user, especially the noobs...

Comment 11

[David :Bienvenu]

(In reply to comment #10)
> (In reply to comment #9)
> > The automatic setup wizard only makes you enter your e-mail address and
> > password once.
> 
> Yes, but if the server name is slightly different - ie, incoming is 'imap.' and
> outgoing is 'smtp.', you are forced to re-enter both, there is no option to
> even *try* the incoming creds, and this is a total waste of the users time in
> 99% of cases.

No, see comment 7 - if the autoconfig wizard verified smtp server logon, using the same password, then the user wouldn't have to re-enter it. So fixing that bug in autoconfig (no smtp server logon verification), would kill two birds with one stone.

Comment 12

[Charles]

Ok - so I just don't see what's the big deal with formalizing this by simply adding a visible check-box option in the GUI. You just admitted that all of the pieces are there, so adding the GUI option should be almost an afterthought.

Comment 13

[rsx11m]

(In reply to comment #11)
> No, see comment 7 - if the autoconfig wizard verified smtp server logon, using
> the same password, then the user wouldn't have to re-enter it. So fixing that
> bug in autoconfig (no smtp server logon verification), would kill two birds
> with one stone.

This would only work though if the user actually chooses to save the password. If not, you'd still need the mail.smtp.useMatching* preferences to avoid being prompted twice every time after restart. Thus, the account wizard would also have to set either of those prefs if it is determined that the incoming and outgoing credentials are the same and either host or domain names are matched. Now, since those prefs are global, this would apply equally to all accounts, thus I don't think that this would easily be doable in a multi-domain setup...

Comment 14

[Charles]

Ouch... didn't realize these were global...

This absolutely needs to be per account (which is why I have it displayed on the new acount wizard setup page).

Account username/passwords for *inbound* servers is stored per account - so again, this is a simple UI matter combined with a way to 'point' the outgoing process to the inbound credentials.

Comment 15

[Charles]

K-9 mail on Android now has this (iPhone Mail still doesn't, unbelievable since they usually do a real good job on being 'user friendly - usually *too* good for me, in fact)...

Comment 16

[Charles]

(In reply to David :Bienvenu from comment #11)
> fixing that bug in autoconfig (no smtp server logon verification), would
> kill two birds with one stone.

But it would prompt twice if the server info ever changed...

Again... it just makes sense to have a per account option for using the same credentials - not duplicating them, using the *same* ones - for sending as receiving.

Again... 99% of the time, the username/password for sending will be the exact same as for receiving. It only makes sense to capitalize on this.

Comment 17

[disasterlistmanager]

Attachment: Use Same Credentials Dialog.gif

New mock-up of what the dialog could look like based on the new UI work being done by the new Lead UX Architect, Alessandro.

Comment 18

[disasterlistmanager]

Attachment: Use Same Credentials Dialog.gif

Updated to show default enabled

Comment 19

[Alessandro Castellani [:aleca]]

As I wrote in the email, this is not necessary and we shouldn't implement it for the following reasons:

• Showing already checked options is confusing for the users since we want those options checked by default. Why offering them on the first place?
• A "Manual Configuration" button is available, and will be available, throughout the setup process, which will allow a more tech savvy user to control those options.
• TB already tries those settings on first connect and only returns the manual configuration screen if it can't connect.

As I side not, please avoid using WIP mock-ups of non-existing sections to suggest extra features in bug reports. This is misleading for those who need to triage and organize bugs that might not be aware of external conversations or UX/UI threads.

Comment 20

[disasterlistmanager]

Hi Alessandro.

I don't understand your response. It appears to only be about the 'Use only secure settings' option. If so, please ignore that, it has nothing to do with this bug/enhancement request.

This is only about the 'Use same settings for sending mail'.

So... as I explained in my response to you:

Thunderbird has never had an option to 'Use the same credentials for outgoing as for incoming', and it is the only email client that I am aware of that still does not have this option.

I understand that during Account Creation, it does 'sort of' do this, because it has a place for both incoming and outgoing passwords - but this is absolutely not the same as having an option to always use the same credentials.

Proof: change your email password after successfully setting up an account. the next time you access the account via Thunderbird, you are prompted for it twice - once for receiving new email, then again, the first time you try to send, which may be minutes, or hours or even days later.

This was always very confusing and frustrating for our users, and a major support pain point for me - not to mention the simple pain of having to enter a super strong 20 character long random password twice.

This option would, if present and enabled, either keep a single username/password pair for both sending and receiving, or just update both whenever the password is updated (via either sending or receiving) if the devs decided they still wanted to keep two separate entities in passwords DB.