Bugzilla

We intentionally changed the client ID so enterprises are going to have to approve the new one, or not use Thunderbird, really. They're never going to be able to use the old one again, and it could be completely removed at any time(probably not until 102 goes out of support, though).

Given the way these client IDs/oAuth registrations work, there's going to be some turnover over time since it's not easily possible to transfer them between entities. There's even cases where you might have to create a new application ID to make certain changes.

In general, requesting to be able to customize this is reasonable but I can't say when we'll want to implement this functionality. It also encourages people to change the client ID, which is not something I'm sure we actually want them doing. Because it limits our ability to control the auth registration and is almost certain to cause additional bug reports and support burden as Microsoft change their policies and enterprises don't properly update their applications.

Having struggled with Microsoft's systems and policies with oAuth for several months, they're incredibly complicated and the documentation is borderline useless in many cases.

We intentionally changed the client ID so enterprises are going to have to approve the new one, or not use Thunderbird, really. They're never going to be able to use the old one again, and it could be completely removed at any time(probably not until 102 goes out of support, though).

Given the way these client IDs/oAuth registrations work, there's going to be some turnover over time since it's not easily possible to transfer them between entities. There's even cases where you might have to create a new application ID to make certain changes.

In general, requesting to be able to customize this is reasonable but I can't say when we'll want to implement this functionality. It also encourages people to change the client ID, which is not something I'm sure we actually want them doing. Because it limits our ability to control the auth registration and is almost certain to cause additional bug reports and support burden as Microsoft change their policies and enterprises don't properly update their applications. "What client ID do you have set?" is not a question I want to be asking people in bug reports... ever really.

Having struggled with Microsoft's systems and policies with oAuth for several months, they're incredibly complicated and the documentation is borderline useless in many cases.

We intentionally changed the client ID so enterprises are going to have to approve the new one, or not use Thunderbird, really. They're never going to be able to use the old one again, and it could be completely removed at any time(probably not until 102 goes out of support, though).

Given the way these client IDs/oAuth registrations work, there's going to be some turnover over time since it's not easily possible to transfer them between entities. There's even cases where you might have to create a new application ID to make certain changes.

In general, requesting to be able to customize this is reasonable but I can't say when we'll want to implement this functionality. It also encourages people to change the client ID, which is not something I'm sure we actually want them doing. Because it limits our ability to control the auth registration and is almost certain to cause additional bug reports and support burden as Microsoft change their policies and enterprises don't properly update their applications.

 "What client ID do you have set?" is not a question I want to be asking people in bug reports... ever really. You also have to use very specific settings for stuff to work properly, and we are absolutely 100% NOT providing free support on "how do I set up my own client ID?".

Having struggled with Microsoft's systems and policies with oAuth for several months, they're incredibly complicated and the documentation is borderline useless in many cases. So I would caution anyone who wants to opt into maintaining this themselves...

We intentionally changed the client ID so enterprises are going to have to approve the new one, or not use Thunderbird, really. They're never going to be able to use the old one again, and it could be completely removed at any time(probably not until 102 goes out of support, though).

Given the way these client IDs/oAuth registrations work, there's going to be some turnover over time since it's not easily possible to transfer them between entities. There's even cases where you might have to create a new application ID to make certain changes.

In general, requesting to be able to customize this is reasonable but I can't say when we'll want to implement this functionality. It also encourages people to change the client ID, which is not something I'm sure we actually want them doing. Because it limits our ability to control the auth registration and is almost certain to cause additional bug reports and support burden as Microsoft change their policies and enterprises don't properly update their applications.

 "What client ID do you have set?" is not a question I want to be asking people in bug reports... ever really. You also have to use very specific settings for stuff to work properly, and we are absolutely 100% NOT providing free support on "how do I set up my own client ID?". Never going to happen.

Having struggled with Microsoft's systems and policies with oAuth for several months, they're incredibly complicated and the documentation is borderline useless in many cases. So I would caution anyone who wants to opt into maintaining this themselves...