My employer switched to Office 365 with OAUTH2 and i needed to actually patch claws-mail to get things to work. Claws-mail does support the "official" "MS Outlook" OAUTH2AUTH_OUTLOOK and "MS Exchange" OAUTH2AUTH_EXCHANGE but none of the two worked for the specific setup i am facing. Which is a specific variant of one of the two, with various of the hardcoded values in need of modification. Here is a list of things i need to do to OAUTH2AUTH_EXCHANGE 1. OA2_AUTH_RESOURCE, OA2_ACCESS_RESOURCE, OA2_REFRESH_RESOURCE s/common/<tenant-id>>/ When not using the "public O365" you get your own "tenant" with a corresponding "tenant-id" and you have to use that instead of "common", claws-mail does not allow to specify that, it is a UUID 2. OA2_SCOPE_FOR_AUTH -= https://outlook.office.com/POP.AccessAsUser.All In my case only IMAP and SMTP are allowed, POP is _not_. And i also did not configure POP anywhere. Still claws-mail is trying to request POP alongside with the other two, which in my case will fail and none of the capabilities will be granted. 3. OA2_TENANT "common" -> "" Very likely related to 1. just setting this to nothing worked 4. OA2_SCOPE_FOR_ACCESS -= https://outlook.office.com/POP.AccessAsUser.All see 2.
If i wanted to appear to be "thunderbird" i would also need to change OA2_REDIRECT_URI to "http://localhost"
can you attach your patch?
I think what would need to happen is the following: - make OA2_SCOPE_FOR_AUTH = OA2_SCOPE_FOR_ACCESS - only add actually used protocols to OA2_SCOPE_FOR_ACCESS ... do not add POP when not used - or make OA2_SCOPE_FOR_ACCESS customizable in the GUI, maybe with its current defaults - use OA2_TENANT in OA2_AUTH_RESOURCE, OA2_ACCESS_RESOURCE, OA2_REFRESH_RESOURCE instead of hardcoded "common" - allow customization of OA2_TENANT in GUI - allow customization of OA2_REDIRECT_URI in GUI
(In reply to Paul from comment #2) i do have a patch that maybe does a bit too much and does not actually do the GUI bits, but only changes hardcoded values in OAUTH2info[OAUTH2AUTH_EXCHANGE] Let me reduce that down to a minimum. But i am afraid it would not be of any use for anyone else, except for being a rewrite of my comment in C language. And i would not reveal the tenant id ... But i guess it will serve as a good starting point to illustrate which fields need to be customizable in the GUI to serve setups like mine, or very likely any corporate O365 setup.
Created attachment 2277 [details] connect as client "thunderbird" uses the "client id" 08162f7c-0fd2-4200-a84a-f25a4db0b584 but needs a custom redirect URL and other capabilities, tenant can stay "common"
Created attachment 2278 [details] part one of tenant-specific client here i use a made up tenant, the one i really have to use stays secret, would not be useful to others anyway my employer created their own "application" "client-id", in order to use that i need to talk to /<tenant-id>/ instead of /common/
Created attachment 2279 [details] part two of custom tenant application my employer does not allow POP for any application / client-id the oauth2 link should not try to request it, or the return will be an error and not the code we need
I attached 3 patches where the last two belong together and turn "OAUTH2AUTH_EXCHANGE" into something that works for a tenant specific client-id, reachable under a custom tenant endpoint and only allowing SMTP and IMAP. These two let me in, via one of the two "applications" that are allowed for my account. The first patch is changing "OAUTH2AUTH_OUTLOOK" to let me in pretending to be "thunderbird". Here the redirect uri needs to be thunderbird (client-id) - specific. And which capabilities are allowed POP/SMTP/IMAP again needs to change according to what my employer allowed that application. This one lets me in via the second application ... "thunderbird". All patches should only do what is needed (for me) and are based on latest "master".
I might even try to come up with a patch implementing https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4579#c3 But for now i will let it rest. Because i am not really looking forward to getting into GUI modifications and maybe someone will have better suggestions or be able to propose patches before i dig into gtk hacking.
Anyone up to help here? I would really appreciate someone else writing the actual GUI patches and making those fields customizable and/or deriving the protocol caps from the actually used protocols. Being a gentoo user i do not mind too much having to carry local patches (not doing GUI but just hacking static strings to work for me). I might change my mind once those patches do not apply any longer. Fixing this might have great value to many, but i lack the skills to propose generic patches.
maybe https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4669 can actually serve as an example if all the values where customizable and a new "provider" could be created in some dialog that guides a bit and has some sane defaults ... not only custom tenants on M365 but also entirely new providers could just be configured without having to change code
A user configurable OAUTH2 option in addition to the built in ones would be a way to handle this. That would allow people to explore new OAUTH2 provider configuration where the developers don't have access to the account type (e.g. for AOL requested in bug 4669), or for the bespoke Microsoft case at the origin of this report. Maybe a dialogue to enter a customised set of these data is needed? The data entered would need to be stored somewhere, e.g. within the account configuration data. So that would be a config file format change. Alternatively maybe these are config options that are handled if they appear in the account config file, but don't have their own dialogue box. If someone needs them they can be entered by editing the config file direct via a text editor. That could be a balance between providing the flexibility but avoiding overwhelming most users with too many options. Things to be decided - dialogue or direct config file edit as a preferred route? Are people happy that this will be a config file change since this user configurable data doesn't currently exist to be stored.
*** Bug 4669 has been marked as a duplicate of this bug. ***
I think people will want a GUI. IMHO the idea behind the current implementation "we know and maintain all OAUTH2 providers in the codebase" is wrong and can not scale. The feature is becoming more and more common and people probably already use it on their personal domains. If claws-mail can not handle it on any domain, it disqualifies as a MUA people can use in the future. For the time being people can also use various proxies to deal with oauth2 where the MUA does not yet support it natively.