can users just be allowed to choose it, regardless of the domain? That is what is done for POP and IMAP, right?

For instance, many EDU domains are using google apps for education - you would never be able to list them all. I have to use some voodoo badness to be even able to put OAUTH2 in the options list - I have to tell thunderbird that I am matt@gmail.com then pick oauth2, then I have to go back and change the account later to use matt@uw.edu so I can use apps for education gmail with the UW domain. There must be a better way

(In reply to Matt Weatherford from comment #2)

can users just be allowed to choose it, regardless of the domain?

I believe this would be the best solution.

In fact, the setup wizard is not consistent here:

• it always lists all other authentication methods (even though they're not supported in autoconfig file).
• but for Oauth, the procedure is completely different - it's listed in setup wizard only when autoconfig file includes support for it.

Nothing bad happens when user incorrectly chooses Oauth for unsupported domain - there's clear error message that he has to choose other authentication method since this one is not supported by the server.

I got the same issue, my situation is quite the same beside I am from a company domain.

my mail account is from G-suite with company domain as postfix and need to login using OAuth2 from Okta, and the setup never worked for me.
Thunderbird reported no error , but obvious no mail got retrieved.

please help.

thanks

Its worth noting that there are unicorn entities out there that use a single mail domain, but internally may have several different (hosted or internal) delivery endpoints..... the UW in particular has person@uw.edu email addresses but internally routes those either to gmail or o365 depending on each individual user's preferences.

May you live in a world of more choices, even when that means the mail endpoint is not computable from an entity outside of the organization's network

I had the same problem with a G-suite account, and agree that a user option 'this is G-Suite' or 'this is a Google account' would be an ideal solution.

I think we should be doing what the mobile apps have been doing and asking the user to nominate an oAuth provider if they manually select the option.

But I filed bug 1591782 two years ago requesting the simple change and it was suggested it be duped here. The issue is the developers can never be accross all of the murky details of who hosts what. Giving the users the ability to say sure this is a "whatever" domain, but I want to call it Google for oAUth is the simplest and most logical solution.

What happens if the user chooses the wrong one? It does not work. How is that different to normal password,Encrypted password, kerebos, NTLM or TLS certificate? (does the average user even know what kerebos is?)
It is time to loosen the reigns on OAuth a little and let the user choose. The worst it can do is fail.

Is this still an issue after version 102?

I would guess it is, to run into this you have to be trying to use a custom domain for your MX records specifically that's hiding gsuite behind it. I would guess it's more common to just use MX records that point at gmail.com, that's what all the Mozilla corporate domains do. And oAuth works perfectly fine with them. Seems less problematic in general.

(In reply to Andrei Hajdukewycz [:sancus] from comment #11)

I would guess it is, to run into this you have to be trying to use a custom domain for your MX records specifically that's hiding gsuite behind it.

And that is exceedingly common, especially as most folk are using their email address to invoke the account setup wizard We should not be relying on an MX records to configure accounts as the internal network name of a server may in no way resemble it's MX record. I find myself using dns toolbox all the time in support as well as whois because our users register domains and have expectation, but little skill in many cases.

I would guess it's more common to just use MX records that point at gmail.com, that's what all the Mozilla corporate domains do. And oAuth works perfectly fine with them. Seems less problematic in general.

Perhaps, but we are dealing with folk that struggle to comprehend they need an mx record at all. I have dealt with a number in support in recent years that have registered a domain, created no MX records and complained Thunderbird was broken because the email address did not work.

Thunderbird needs to cater for the lowest common denominator and assume no skills.

(In reply to Matt from comment #12)

(In reply to Andrei Hajdukewycz [:sancus] from comment #11)

I would guess it is, to run into this you have to be trying to use a custom domain for your MX records specifically that's hiding gsuite behind it.

And that is exceedingly common, especially as most folk are using their email address to invoke the account setup wizard We should not be relying on an MX records to configure accounts as the internal network name of a server may in no way resemble it's MX record. I find myself using dns toolbox all the time in support as well as whois because our users register domains and have expectation, but little skill in many cases.
Thunderbird needs to cater for the lowest common denominator and assume no skills.

Either people are setting up mail servers, or they lack any technical skills. If it's both, there's not much Thunderbird can do about that unfortunate situation. The idea that adding a setting for the user to select oAuth type independent of their mail server domains is going to make things EASIER for technically unskilled users doesn't hold up to scrutiny.

I'm not saying we shouldn't support this -- there are clearly some organizations doing this -- but I don't see any evidence that it's a very common configuration. So I'm not convinced this is worth addressing at this time.

Remember that every fix has the direct cost of another fix that will not happen.

Andrei,

I think your comment is spot on

The idea that adding a setting for the user to select oAuth type independent of their mail server domains is going to make things EASIER for technically unskilled users doesn't hold up to scrutiny.

I had not thought through how this would work if the oauth2 provider couldnt be auto-determined - I agree that it wont be easier for the user who may not even know what an OAUTH2 provider is. Time to call their friendly (or possibly mood disordered) local IT person

Im also suspecting that this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1565708
was the fix i needed for my particular case

So I will suggest a wontfix close here

thank you,
Matt

My employer gives me a GSuite account with a custom domain. I'd like to use Thunderbird for email/calendar/contacts/tasks. I wasn't able to figure out how to set this up. With a gmail address, it would all have happened by magic. I don't mind if the procedure is a bit complicated, but it would be great to have some way to set this up. And to me, having a single extra check-box somewhere that says 'provided by Google' or similar would be the easiest way to do that, and entirely harmless for everyone else.

Or how about an about:config setting (defaulting false) to force an OAuth2 check for every new account? That would solve my problem, and would definitely not confuse the rest of the world.

Given that all the automated setup machinery exists, it seems a shame not to be able to make use of it in more situations.

It should work with a custom domain if the MX records of the domain point to google.