email-oath2-proxy Began Failing Today with Microsoft Exchange

[w5pny]

I had posted a new issue about this earlier this morning, but then it started working again. An hour or so later it began failing in a different way.

I am using fetchmail via pop3 or imap with email-oath2-proxy. The current issue now is that when Exchange gets the password, it never responds and fetchmail times out after 5 minutes. Below are the fetchmail debug outputs for pop3 and iamp in each case. I'm not sure what to do next because no one else seems to be having problems.

fetchmail: 6.4.37 querying 127.0.0.1 (protocol POP3) at Sat, 24 Jun 2023 15:24:36 -0600 (MDT): poll started Trying to connect to 127.0.0.1/1995...connected. fetchmail: POP3< +OK The Microsoft Exchange POP3 service is ready. [UwBBADkAUABSADEAMwBDAEEAMAAwADgAOQAuAG4AYQBtAHAAcgBkADEAMwAuAHAAcgBvAGQALgBvAHUAdABsAG8AbwBrAC4AYwBvAG0A] fetchmail: POP3> CAPA fetchmail: POP3< +OK fetchmail: POP3< TOP fetchmail: POP3< UIDL fetchmail: POP3< SASL PLAIN fetchmail: POP3< USER fetchmail: POP3< . fetchmail: POP3> USER xxxxy@xxxxx.xxx fetchmail: POP3< +OK fetchmail: POP3> PASS *

fetchmail: 6.4.37 querying 127.0.0.1 (protocol IMAP) at Sat, 24 Jun 2023 15:24:55 -0600 (MDT): poll started Trying to connect to 127.0.0.1/1993...connected. fetchmail: IMAP< OK The Microsoft Exchange IMAP4 service is ready. [UwBBADEAUAAyADIAMgBDAEEAMAAxADQAMgAuAE4AQQBNAFAAMgAyADIALgBQAFIATwBEAC4ATwBVAFQATABPAE8ASwAuAEMATwBNAA==] fetchmail: IMAP> A0001 CAPABILITY fetchmail: IMAP< CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN SASL-IR UIDPLUS ID UNSELECT CHILDREN IDLE NAMESPACE LITERAL+ fetchmail: Protocol identified as IMAP4 rev 1 fetchmail: will idle after poll fetchmail: IMAP< A0001 OK CAPABILITY completed. fetchmail: IMAP> A0002 LOGIN "xxxxy@xxxxx.xxx" *

If I change the fetchmailrc file to have a null password, I get the appropriate authentication failure messages, but any other string for the password even if it is the correct password just results in a server not responding.

Suggesgtions anyone???

[simonrob]

Whenever anything like this occurs, I'd always try identifying the issue by connecting directly to the proxy rather than via a client/fetchmail/script etc.

See the end of the troubleshooting section of the readme – what happens when you use telnet to connect directly to the proxy and log in?

[w5pny]

I get:

telnet 127.0.0.1 1993 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'.

• OK The Microsoft Exchange IMAP4 service is ready. [UwBOADEAUABSADEAMgBDAEEAMAAwADUANQAuAG4AYQBtAHAAcgBkADEAMgAuAHAAcgBvAGQALgBvAHUAdABsAG8AbwBrAC4AYwBvAG0A] a1 login xxxx@xxxx.xxx xxxxxxxx

and then it hangs there and never responds.

( I changed the email and password to xxx's)

[w5pny]

I did use the real e-mail address and password, but changed it to xxx' s for the report here --

[w5pny]

The last thing in the email proxy log when I do the above telnet is:

Jun 24 16:54:32 maui Email OAuth 2.0 Proxy: Authorisation request received for xxxx@xxxx.xxx (interactive mode)

So I'm guessing I have to reauthorize. I can't seem to get the browser window to show. If I use the proxy internal window I don't get any content except the GoDaddy logo at the top. Using --external-authorization never seems to get me the URL I need... When I first installled the email proxy a few weeks back, this process seemed cleaner. But maybe reauthorization is not needed here.

Suggestions?

[w5pny]

I finally succeeded in reauthorizing and that seems to have fixed the hanging issue.

However -- reauthorizing was not straight-forward. Even though I ran

emailproxy.py --external-auth

from the same directory where the config file is in a terminal window. I then did the telnet login to localhost and then when I clicked on the taskbar icon to do the authorize the authorize submenu came up with "external auuthorisation" and my email-address as choices. Picking "external authorisation" never worked -- I had to pick my email address which brings up a window (call it X) the a long URL for me to put into a local browser tab. When I do that my local web page comes up with a LONG URL in the tab address bar that resulted in my local webpage. I had to copy that LONG URL into the paste into the window X above near the submit button on that window. Then clicking on the submit button succeeded in the authorization.

I'm puzzled that the "external authorisation" option never worked even though emailproxy.py had that option specified.

I made notes on this in case I ever have to do this again --

It would be nice if this were more automatic than it is...

[simonrob]

The copying URLs between windows is exactly the process that is expected in external auth mode.

When you have the proxy's GUI enabled, external auth mode can be enabled from the menu bar. It sounds like you were clicking this toggle rather than the email address.

I'll think about ways to make this more obvious in a future version.

[w5pny]

One confusing thing was that I had invoked:

emailproxy.py --external-auth

in the directory where emailproxy was installed.

I would have thought external auth mode would be enabled by default at that point. But when I brought up the pull down for authorisation from the menu bar there were two choices -- "external auth" and my e-mail address. The "external auth" is the default one as I would have expected, but clicking on it didn't bring up anything that worked. I had to click on my e-mail address to get it to work.

That is what you are saying, below but it certainly seems counter-intuitive to me. Why isn't my e-mail address the default if that is what's needed? Do I need the --external-auth option when invoking emailproxy.py in order to do authorization when the emailproxy built-in web window doesn't show what's needed? I thought that when that was the case one was supposed to specify that option ---

On Sat, 2023-06-24 at 23:10 -0700, Simon Robinson wrote:

The copying URLs between windows is exactly the process that is expected in external auth mode.

When you have the proxy's GUI enabled, external auth mode can be enabled from the menu bar. It sounds like you were clicking this toggle rather than the email address.

I'll think about ways to make this more obvious in a future version.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.

[simonrob]

When you start the proxy with --external-auth, that option in the menu should show as pre-selected, but you can disable/enable it via the menu if needed (e.g., if you have multiple accounts with different authentication environments). There are definitely improvements that can be made to the interface, though.