CAPABILITY in wellcome-string from outlook.office365.com

Good evening Simon Robinson, I would appreciate your reply.

An error occurs when trying to connect a proprietary IMAP-client to email-oauth2-proxy.

2022-12-14 20:12:55,130: IMAP (localhost:1993; 127.0.0.1:53924->outlook.office365.com:993)     <-- b'* OK The Microsoft Exchange IMAP4 service is ready. [RgBSADIAUAAyADgAMQBDAEEAMAAxADIAMgAuAEQARQBVAFAAMgA4ADEALgBQAFIATwBEAC4ATwBVAFQATABPAE8ASwAuAEMATwBNAA==]\r\n'
2022-12-14 20:12:55,130: IMAP (localhost:1993; 127.0.0.1:53924->outlook.office365.com:993) <-- b'* OK The Microsoft Exchange IMAP4 service is ready. [RgBSADIAUAAyADgAMQBDAEEAMAAxADIAMgAuAEQARQBVAFAAMgA4ADEALgBQAFIATwBEAC4ATwBVAFQATABPAE8ASwAuAEMATwBNAA==]\r\n'
2022-12-14 20:12:55,132: IMAP (localhost:1993; 127.0.0.1:53924->outlook.office365.com:993) --> b'0001 LOGOUT\r\n'

The following wellcome-string comes from the outlook.office365.com server, after which the client immediately drops the connection (by LOGOUT command). I see in the client’s logs that it cannot find a suitable authentication method

> fail to login: No supported authentication schemes available: Server supports (), client supports ['PLAIN', 'LOGIN']

By analysing the behaviour, I found that the client expects CAPABILITY in the welcome string from the IMAP server, e.g. > * OK The Microsoft Exchange IMAP4 service is ready. [CAPABILITY IMAP4REV1 AUTH=PLAIN]\r\n

The thing is, this IMAP client, works correctly directly with outlook.office365.com via IMAP with authentication method LOGIN/PLAIN through SSL, so I think the error lies exactly in the blind transmission of the welcome-string from outlook.office365.com to the client.

Unfortunately, I have not found in the documentation how wellcome-string can be affected. It is not possible to make changes to the wellcome-string using the receive_from_client, receive_from_server plugin methods because these methods work after authentication. The only solution I’ve found is to change the byte_data in the handle_read function of the OAuth2ServerConnection class, but this is too messy! Also I cannot understand according to rfc when connecting without SSL, the wellcome string must contain CAPABILITY indicating authentication methods, e.g. AUTH=PLAIN, but I would like to be able to force CAPABILITY to be added to the wellcome-string for such IMAP-clients.

P.S. For example, DavMail does not pass the uplink IMAP-server string, but welcomes its own: > * OK [CAPABILITY IMAP4REV1 AUTH=LOGIN MOVE SPECIAL-USE] IMAP4rev1 DavMail 6.0.1-trunk server ready

[warlin1]

Thank you for the new functionality. You are a very responsive developer, very nice.

[simonrob]

I’ve just added the capability to intercept server messages before authentication, which enables more sophisticated plugins (e.g., the new examples in the plugins branch), including the ability to use them to address the use-case you suggested above. Thanks for the prompt to look at this!