IMAP is not working correctly on Outlook Office365. Error: "User is authenticated but not connected"

Hi All,

In case anybody has trouble with the same problem. I share my results.

First of all the Microsoft payed support was not really willing to help although one of they payed services is not working correctly. I had to constantly prove that the problem is on server side. They were also not willing to give much information.

However after a couple of escalation rounds I find the following:

There is an IMAP Policy in place, which banns or restricts users if they behave "badly". What they check and what are the limits is for some insane reasons not public. However I managed to get the information that they check something similar -- but not fully the same -- as "Set-ThrottlingPolicy" function (which is on on-premise servers)

https://docs.microsoft.com/en-us/powershell/module/exchange/server-health-and-performance/set-throttlingpolicy

In my case IMAPMaxConcurrency limit was hit according to the support. Based on my measurements this limit is 15. My clients use only 1-1 connection which means I could not have reached the limit.

As further testing on my side, I have found that the server does not have dead connection detection. Which results that if I am using mobile internet and the phone switches between cells, it gets a new IP address, the old TCP connections are on server side open, but otherwise dead (half open connection). So the server thinks that I have reached the limit.

The Idle Timeout for the TCP connections is around 20 minutes. So I can do nothing till 20 minutes if I hit the limit.

Usually all industrial standard IMAP servers have "dead connection detection" which means that the server sends a NOOP (no operation) every ~2 minutes down to client, and if it does arrives it closes the dead connection.

Unfortunately Microsoft Exchange Server does not have such feature according to the support.

Workaround possibilities:

• You should reduce the number of connections to the server in you client. (This can be done in Thunderbird, and in most clients). This helps to reach the limit later, or not reach the limit at all.
• If you are using mobile internet as I do, you can try what I am doing. I have created an IMAP Proxy server on my own server, which is on a fixed internet line, and implemented a dead connection detection algorithm. So basically the functionality what is missing from Microsoft...(there are a couple of such proxies available on the internet, but I tried an own solution in our company)

I hope that helps.

Regards,

Robert

Hi Karl,

Sorry for the slow answer. No it is not "one login per time" it is a little bit more complicated.

I did a test with Thunderbird, where I cut the internet line several time, to produce the broken connections. I get the same error message.

I would say the conclusion is that Gmail produces more broken TCP connections, and so you reach earlier the given limit and get the error message. The root cause for that is party because it uses 4 connections (instead of the Thunderbird which we have already set to 1), and this Android sleep thing might causes also some extra broken connections (but that is not confirmed, just a guess).

Regards the "first comes first severs". You have a limit of 15 connections. If you reach this limit new connects get this "BAD User is authenticated but not connected" error, however if there are before opened working TCP connections, those are still working.

So if you connect with Thunderbird, and it works, then Gmail creates enough broken connections and you reach the limit, and run the test site, you will see there "BAD User is authenticated but not connected", however your Thunderbird is still working.

I hope I can finally do some measurements with the IMAP proxy and then see how the Gmail app opens new connects, and how much broken TCP connections it produces.

Regards,

Robert

Hi,

Sorry for spamming, it just came into my mind: there is also a page by Microsoft where you can check the IMAP interface:

https://testconnectivity.microsoft.com/

You can select IMAP connection, set the server address, login name and password.

It tries to create a simple IMAP communication. Prints also the details of that communication.

You get a detailed test log of your run.

If you get the same error message here, that means that the problem is on the backend side.

Regards,

Robert

Hi Artur,

The problem has still not been solved.

I was told to create a service request via Office 365 admin center.

This ticket is currently in the system, but did not received any answer.

I will post back if there is any information.

Regards,

Robert

Hello Rick,

Yes I do. Please help to solve the problem that is caused by the cloud.

I have stress tested the test accounts, and loaded them with around 200-300 test emails, and 7-10 IMAP folders.

In this situation the problem did occurred in every account. That means that your test account also produces this problem.

I have checked the Thunderbird logs, and found everything OK from client side.

I have tested the IMAP interface without the client, based on the RFC 3501 standard.

I managed to get a working connection:

> openssl s_client -connect outlook.office365.com:993 -crlf -quiet

depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA

verify return:1

depth=1 C = US, O = DigiCert Inc, CN = DigiCert Cloud Services CA-1

verify return:1

depth=0 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = outlook.com

verify return:1

* OK The Microsoft Exchange IMAP4 service is ready. [VgBJADEAUAAxADkANQBDAEEAMAAwADcAOQAuAEUAVQBSAFAAMQA5ADUALgBQAFIATwBEAC4ATwBVAFQATABPAE8ASwAuAEMATwBNAA==]

1 capability

* CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=XOAUTH2 SASL-IR UIDPLUS ID UNSELECT CHILDREN IDLE NAMESPACE LITERAL+

1 OK CAPABILITY completed.

2 authenticate PLAIN

+ 

<base64stringwithauthenticationdata>

2 OK AUTHENTICATE completed.

3 namespace

* NAMESPACE (("" "/")) NIL NIL

3 OK NAMESPACE completed.

And also to reproduce the given problem with the same commands:

openssl s_client -connect outlook.office365.com:993 -crlf -quiet

depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA

verify return:1

depth=1 C = US, O = DigiCert Inc, CN = DigiCert Cloud Services CA-1

verify return:1

depth=0 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = outlook.com

verify return:1

* OK The Microsoft Exchange IMAP4 service is ready. [VgBJADEAUABSADAAOQBDAEEAMAAwADgANQAuAGUAdQByAHAAcgBkADAAOQAuAHAAcgBvAGQALgBvAHUAdABsAG8AbwBrAC4AYwBvAG0A]

1 capability

* CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=XOAUTH2 SASL-IR UIDPLUS ID UNSELECT CHILDREN IDLE NAMESPACE LITERAL+

1 OK CAPABILITY completed.

2 authenticate PLAIN

+ 

<base64stringwithauthenticationdata>

2 OK AUTHENTICATE completed.

3 namespace

3 BAD User is authenticated but not connected.

3 namespace

3 BAD User is authenticated but not connected.

* BYE Connection closed. 14

read:errno=0

As you can see the cloud is sometimes answering correctly and sometimes returning "User is authenticated but not connected".

Could you please resolve the problem in the IMAP interface, or at least tell me why this is happening to avoid the problem?

My guess is that the cloud does puts me on some kind of a black list if a connection is broken, or I do connect too often in a certain time period. (The "chatty client" case)

Can you confirm or add any information about the mechanism run in the cloud that produces this problem for me?

Thank you in advance.

Regards,

Robert