Authentication Failure with Office 365

[MatthewJWalters]

Hello. We're running the proxy on a Linux server with the no-gui parameter. The oauth token and refresh token are being stored in emailproxy.config but when we use fetchmail (or telnet) to connect to the pop3 account we are getting:

2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995) --> [ Client connected ]
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995)     <-- b'+OK The Microsoft Exchange POP3 service is ready. []\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995) <-- b'+OK The Microsoft Exchange POP3 service is ready. []\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995) --> b'CAPA\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995)     --> b'CAPA\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995)     <-- b'+OK\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995)     <-- b'TOP\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995)     <-- b'UIDL\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995)     <-- b'SASL PLAIN XOAUTH2\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995)     <-- b'USER\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995)     <-- b'.\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995) <-- b'+OK\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995) <-- b'TOP\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995) <-- b'UIDL\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995) <-- b'SASL PLAIN\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995) <-- b'USER\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995) <-- b'.\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995) --> b'USER [redacted]\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995) <-- b'+OK\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995) --> b'PASS [[ Credentials removed from proxy log ]]\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995)     --> b'AUTH XOAUTH2\r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995)     <-- b'+ \r\n'
2022-09-13 12:00:48: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995)     --> b'[[ Credentials removed from proxy log ]]'
2022-09-13 12:00:49: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995; [redacted])     <-- b'-ERR Authentication failure: unknown user name or bad password.\r\n'
2022-09-13 12:00:49: POP (localhost:1995; 127.0.0.1:52886->outlook.office365.com:995; [redacted]) <-- b'-ERR Authentication failure: unknown user name or bad password.\r\n'

Just wondered if you have any thoughts on what this may be?

Incidentally, is it possible to have a no-gui option with an official 'paste the access code' option? We edited the script to timeout after 5s and prompt for the user to enter the access code. This is because the redirect server address isn't accessible from a browser, probably due to internal firewall rules.

Thanks

[simonrob]

Thanks for the report. Do you also encounter this with the IMAP or SMTP servers? If so, are you using your own client ID and secret, and they definitely set up with the correct scope etc?

Re: entering the code in the terminal, the problem with this is that the script would need to block and wait for input. Each connection runs in its own thread, so it could be set up to ensure blocking just affected that one connection rather than the whole proxy. However, there is also the issue that other output lines (from other threads) would overwrite the input prompt, which makes it much easier to miss the instruction. There are solutions to this involving readline etc, but they would either be overly complex or involve extra dependencies and make the proxy more like a terminal-based GUI. Perhaps a compromise would be to use this prompt_toolkit approach and make sure inputs time out, and are cancelled if other requests arrive.

For these reasons, until the sort of approaches discussed in #33 are undertaken, I think it's probably best to stick to the local server option (though I may look at the prompt_toolkit option in the meantime). I'm a little puzzled about the need for this, though – is http://localhost really blocked by your firewall? What happens if you use wget instead?

[MatthewJWalters]

Hi Simon, thanks for coming back to me. We've tried with IMAP and get a similar response:

fetchmail: IMAP< A0003 BAD User is authenticated but not connected.
fetchmail: mailbox selection failed
fetchmail: IMAP> A0004 LOGOUT
fetchmail: IMAP< * BYE Microsoft Exchange Server IMAP4 server signing off.
fetchmail: IMAP< A0004 OK LOGOUT completed.

Some sources suggest this also means that the password is incorrect.

I'll check the secret and ID, but I guess this is more likely to be Azure/Exchange than the proxy.

Fully understand the points re prompting for the authorisation code - it works OK for testing but can see that it would not work in production. It seems as though the lack of connection to localhost was a tunelling issue.

Thanks for your help (and providing the proxy).

[simonrob]

I had a look just now at whether the prompt_toolkit approach mentioned previously might work with the proxy. I've committed support for this to the terminal-auth branch.

To use this feature you'll need to either update the proxy's requirements (python -m pip install -r requirements-no-gui.txt) or install prompt_toolkit: python -m pip install prompt_toolkit. Enable it by using the --external-auth flag in --no-gui mode.

Feedback very welcome!

[MatthewJWalters]

Hi Simon Thanks for the update. I probably won't get a chance to test until the new year, but will let you know how I get on. Kind regards Matthew Walters

[Jonher937]

I had a look just now at whether the prompt_toolkit approach mentioned previously might work with the proxy. I've committed support for this to the terminal-auth branch.

To use this feature you'll need to either update the proxy's requirements (python -m pip install -r requirements-no-gui.txt) or install prompt_toolkit: python -m pip install prompt_toolkit. Enable it by using the --external-auth flag in --no-gui mode.

Feedback very welcome!

I tried this branch and it worked for me.
You should probably remove the trailing . on this line though:

email-oauth2-proxy/emailproxy.py

Line 2547 in d7efd59

prompt_text = 'Press enter or copy+paste to visit the following URL and authenticate account %s: %s. ' \

which would be the URL you are supposed to copy and visit on another system.

[simonrob]

Thanks for testing this, and for the good suggestion to avoid the potentially error-prone .

I'll go ahead and merge this branch now.