Re: oauth2 support for Emacs email clients

[Tim Cross <theophilusx@gmail.com>]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> David Engster <deng@randomsample.de> writes:
>
>>> David Engster <deng@randomsample.de> writes:
>>>
>>>>>   Others have mentioned "officially" registering Emacs as IMAP/SMTP
>>>>>   clients for Office365 (and possibly Gmail), similar to what seems
>>>>>   to be the case for Thunderbird.  I am wondering how davmail is
>>>>>   doing this.
>>>>
>>>> Microsoft has actually recognized that it does not make sense for
>>>> desktop applications to embed secrets into their code, so they
>>>> distinguish between "public" and "confidential" client applications:
>>>>
>>>> https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-client-applications
>>>>
>>>> Public client applications do not have a client secret but only an ID
>>>> which can simply be embedded into the application, which is how DavMail
>>>> does it. Public client applications are only allowed to access web APIs
>>>> on behalf of the user, but this is usually enough.
>>>
>>> Interesting, but are public client applications allowed to use
>>> IMAP/SMTP?  Or must public client applications use WebDAV to communicate
>>> with Microsoft servers, like DavMail does?
>>
>> As I've written: Public client applications are only allowed to access
>> web APIs, so no IMAP/SMTP.
>
> OK; I wasn't sure if by "web APIs" you meant only "OAuth-related web
> APIs".  Thanks for confirming.
>
> I wonder why Microsoft does not allow public client applications to use
> IMAP/SMTP.
>

MS doesn't like people using IMAP/SMTP mainly because email is really
only just a part of their 'environment'. Office 365 and Exchange are not
mail servers - they are a 'unified communication stack', which includes
email, calendaring, chat, document sharing, etc.

The other reason they don't want direct access to IMAP and even SMTP is
because they are also adding lots of other 'enterprise' and security
features - for example, not allowing attachments which have not got the
right policy classification, preventing 'sensitive' data being sent to
external parties and adding features like read receipts, ability to
recall messages and even have emails which 'auto destruct' or timeout.

They cannot add these features to IMAP or SMTP and if they allow these
protocols, then all these other 'features' can be bypassed. MS will
advise organisations not to enable IMAP or external direct SMTP access
and the C level execs will follow that advice because if they don't and
something goes wrong (even if unrelated), they will be blamed. Things
will still go wrong, but at least they can say they were following the
'experts' advice and 'best practice'. 

I wouldn't be at all surprised if MS didn't remove IMAP support
altogether at some point in the future. There is even a growing
resistance to Email in the corporate sector and try talking to young
people about Email - most of them only deal with it under sufferance. My
plumber actually told me last week that they no longer send invoices via
email - instead, they send an SMS with a link to the invoice on a
server. If they weren't such good and reliable plumbers, I would
consider changing companies.

>> I usually use DavMail to get my mail downloaded to a locally running
>> IMAP server.
>>
>> So yes, simply registering Gnus as a public client is not enough, one
>> would also need a new backend specifically for Exchange.
>
> Hmm, yeah.  I'd prefer to keep using IMAP/SMTP, standards designed for
> email.  Excorporate does some email operations via EWS, but it seems
> strange to extend Excorporate (and make a Gnus backend for it) to handle
> all of email just to avoid application registration issues with a new
> IMAP/SMTP authentication method.
>
> IMAP/SMTP are already implemented and work fine for other email
> services, and they can authenticate via OAuth (assuming registration is
> sorted out).
>
>>> It seems like Thunderbird could act as a public client application,
>>> however I believe it is currently acting as a confidential client
>>> application.  I wonder why.
>>
>> Because they want to use IMAP/SMTP.
>
> Maybe the FSF could request that Emacs be registered as a public client
> application and also be allowed to use IMAP/SMTP.  That would solve the
> "embedding a secret in Free Software" part of the OAuth registration
> issue, at least for Microsoft servers.
>

I think this is unlikely due to the reason outlined above. MS isn't
really that interested in either the 'individual' or simply providing
email. They are selling a much bigger picture with a focus on the
'enterprise' and selling snake oil to those C level executives who are
worried about security and PR who think the solution is to manage and
restrict what users can do.

It is likely that if you have to use Office 365/Outlook, then davmail
may be the best solution. At least it is GPL'd software.