Authentication problem starting from today with IMAP/office365

[M4tDR]

Good morning,
due to recent modification of Microsoft that doesn't support basic auth for IMAP we succesfully installed the proxy on a linux machine and configure it to run as a service.
Everything works fine till today (start to work at september 22).
Now authentication doen't work. I think that probably Microsoft really close basic authentication today (the announce was for october 1st).
Attach some log (I replace username/password)
Any idea if it is something that can be fixed prom proxy side?
emailproxy.log.log

[simonrob]

Thanks for reporting this, and for providing the log.

I haven't seen any clients use the string literal part of the IMAP protocol for the login itself, so this is not currently supported by the proxy. Clearly the one you are using does this, though.

I suspect that the proxy has never actually been adding OAuth to this client's connections, and it is only now that you are noticing this because basic auth has been disabled.

Supporting this mechanism will require a small update to the proxy. To help with this please could you let me know what client application you are using so that its behaviour can be properly tested?

[M4tDR]

Hello Simon,
thank you very much for quick reply.

We are using SuiteCRM (version 7.12.5)
SuiteCRM still use basic authentication to retrieve email via IMAP. Change the code to use Oauth was very time consuming, almost for the testing all the cases, cause application is written in php and at the moment php doesn't have a standard library to provide Oauth via IMAP.
There are other libraries developed from communitiy that do this, but at the moment SuiteCRM use a lot of IMAP function from standard library, not only authentication. This means that if we change the IMAP library we have to change the code in many parts, not only authentication.
That's the reason that drive me to search for a proxy solution, that was probably the only option we have without changing source code of SuiteCRM. We spent some time to correctly have the proxy working and we supposed that everything was working great, we don't imagin that the proxy was not really using Oauth.
This is how we set the client config (proxy is in the same linux machine of SuiteCRM)

Let me know if I can help you in any way for testing in case you try to do some modification to the proxy and you're not able to test it by yourself.

King Regards

[simonrob]

It might be surprising to hear that the proxy was not actually having any effect, especially since I expect you've been using it since we previously discussed issue #48, but to be clear: unless SuiteCRM has changed its behaviour (or has a fallback to a different authentication approach), the login method it is using in the log file you provided has never been supported by the proxy. If you've kept log files, you'll be able to confirm by looking for [ Successfully authenticated IMAP connection - removing proxy ], which is only ever outputted when OAuth is successful.

Regardless, the literals branch adds support for IMAP string literals, so you should now be able to use this to log in. Please let me know if this works?

[M4tDR]

Hello Simon,
as told in the previuos comment we are succesfully using the proxy from 22 of september till 14 of october. We take some times to correctly configure it from the issue #48.
After the problem started at october 14th at the end we call Microsot supplier asking him to enable again (but is only a temporary situation) basic auth for IMAP. The strange thing is that, once he enable again plain auth also the proxy start to work again. or at least it seems to work cause the autentication test from the client (SuiteCRM) completed correctly. This is what probably happen from september 22th till two days ago. Just a note. We are using for authentication a username and an alias name (in the form user@domain.com\alias), cause we have one user that has delegate access to different email box (not different user, but really different mailbox, cause in Office, for what I understand, we can create mailbox that doesn't need a user licence but that can be accessed from a particular user, probably a sort of delegation)
In master_branch.zip you will see the log file (both with successfull authentication) using the master branch version of proxy and having plain authentication still enable for IMAP. The two filles use one the simple user (without delegation) and in the other the "\alias" in username to address a particolar mailbox always using the same user.

I also try to use the literal branch (see attached file branch_literal.zip) and in this case if I try to test authentication it works for the user itself but not when I try, with the same user, to address the alias mailbox (using \alias at the end)

The log I sent two days ago, where auth doesn't work, was instead created when IMAP plain text was disablesby Microsoft.
If it's not clear please fell free to send me direct email at matteo"dot"daru"at"gmail.com
master_branch.zip
literal_branch.zip

Thank you very much

[simonrob]

Thanks for following up with this further detail.

The logs in master_branch.zip do indeed show a successful proxy login sequence in user_1.txt, but user_alias_1.txt, although successfully logging in, is not doing so using the proxy. This branch of the proxy does not detect the string literal, and just passes the commands straight through to the O365 server, which is still set up to accept basic auth, so succeeds.

In the literal_branch.zip logs, the user_2.txt similarly shows a successful login, but in user_alias_2.txt it gives an error message: Proxy config file entry missing [...] - aborting login. Here the actual message text exposes a minor bug in the proxy's handling of unsuccessful string literal logins (fixed in a0da4d4), but the underlying issue that is causing a failed login is now more linked to #48, and is related to a change in O365 behaviour when OAuth was introduced.

As noted in Microsoft's documentation, when using OAuth 2.0 with shared mailboxes, the username required is that of the full shared mailbox address only, and it should not contain the authenticated username.

For example in the emailproxy.log.log submitted with this issue, you had a configuration file entry of user@domain.com\folder.alias – this should be set as folder.alias@domain.com in the proxy's configuration file (which is what is used for the OAuth 2.0 username), but when asked by the proxy to authenticate, log in as user@domain.com.

[M4tDR]

Hi,
I understood, so probably what made me confusion was that with previous version of the proxy I saw that test seems to be ok but indeed he was usingh basic auth.
With new version (literal branch) I have excplity error for the case (when using alias).
Now I configure correctly the alias folder in client and in config and, at least for one folder I tested, authentication is ok. We will check further aslo for effective emails download and so on.
I will give you final feedback so you can close the issue.
Thanks againg

Kind Regards