Re: XOAUTH2 on O365

Dear Colleagues,

The present discussion a great demonstration of the properties
of monopoly-oriented (and typically proprietary) communication
protocols.

If you want things to work, you should use freedom-respecting software
communicating with broadly accepted protocols.

If you want to keep yourself busy, to maintain customers' need for new
services, to demonstrate how innovative you are, or simply to maintain
your own job security, you should prefer methods that are both
fashionable and poorly understood. It helps for things to be under
proprietary licenses; if they have free licenses, they should instead
have proprietary documentation only, and they should have a complex
implementation, and their features should change frequently.

I invite you to consider not trying to support Google or Microsoft
services-as-software-substitutes. Instead, set up your email so you
can follow accepted conventions. For example, you could forward your
mail to a provider that uses established protocols and free software.



Nevertheless, in case you do choose to use getmail with Microsoft's 365
platform and you find the Microsoft documentation to be lacking, I can
propose methods for determining the protocol.

One approach is unreliable but could work if you are lucky. Contact
Microsoft Azure sales saying that you are writing a serverless app
in Azure Functions with Python and you need to check an email box
on the Microsoft 365 platform from within the serverless compute
platform. (I think they are more likely to take you seriously if you say
all of these fancy words.) If you're lucky, Microsoft Azure sales
engineers have already written an example of this.

The remaining approaches are reverse-engineering.

Connect to the platform with a client that does work, perhaps a
proprietary Microsoft client. Review the client's debugging log. This of
course relies on the client having such a log. I personally would start
with any web email client offered by Microsoft, as I am already familiar
with web browser network inspector features and it is possible Microsoft
uses the same authentication mechanism in the web mail.

Another option is to inspect the messages between the client and the
server. I expect you will need to decrypt the messages in this case,
but you should be able to decrypt enough of them with the client keys.

Another option is to configure your network (probably just your hosts
file or DNS server, maybe also IP routing) to so that the proprietary
client connects to a server that you control. This tells you the first
set of requests, and then you can work through the protocol by making
different responses from the server.



With great honor,
Thomas