Problems with Latest release (2024-11-11)
Closed this issue · 7 comments
Hello and thanks again for this great tool!
For some reason, over the last few days my use of this tool with my outlook account has stopped working as it was for many blissful months.
Upon re-authorizing, the outlook connection would work - but only one time! After that, I had to go through the re-auth process again (and again). I compared the before and after config files and there are definitely changes being made to that file. So I am really not at all sure what the issue might be - especially given that the mechanism works for one time.
I then noticed that there was an update to 2024-11-11 and I hoped it might address this issue. So I tried to download the emailproxy-2024-11-11_pyinstaller-Windows.zip file. But I am immediately told by Windows Defender that the file is a trojan:
This is obviously quite disconcerting... So I cannot install this regardless.
So I am hoping for some help getting things going again with outlook. I should mention that through all of this, the connection to gmail seems to work just fine.
Best
Please post your configuration file (these attributes) and the proxy's log in debug mode.
Repeated requests for authentication are typically because the offline_access scope is missing. But if you haven't changed anything, it's unlikely this is the case. The error message you're getting is actually a request from the server for more information, and the debug log will illuminate what this might be.
Re: virus detection – this is a false positive. It is of course up to you whether you trust this, but it is unfortunately a common issue when packaging Python applications with PyInstaller (which is what the proxy uses). The release executable is built automatically by GitHub from the source in this repository, so there's very little potential for malicious interference. But if you'd rather build it yourself, that's also possible.
Thanks Simon. Should I be worried about posting the requested info here? Should I PM it somehow?
I did check the config file for offline access and I see this:
oauth2_scope = https://outlook.office.com/IMAP.AccessAsUser.All https://outlook.office.com/POP.AccessAsUser.All https://outlook.office.com/EWS.AccessAsUser.All https://outlook.office.com/SMTP.Send offline_access
I haven't touched this (at least not recently) so I don't think this is it.
I did read that MS had some kind of big outage/problems yesterday and wonder if this is somehow related? But I have also read that this is supposedly resolved by now and my issue persists.
After posting, I did see a closed issue that addresses the PyInstaller false positive. Not sure what I will do about that. But I am presuming my issue is NOT "fixed" in the latest.
Also, I have noted that using my Firefox browser, the authorize did not work. I got an URL back in the address bar. But it did not walk me through the whole MS login process. I thought this odd and tried again using Chrome. At least the 1st time I did this, I was walked-through the login process before I got the URL back. However, now it is not doing that when I try again to authorize. Is this expected?
Thanks for all!
Here is the debug log that I have obfuscated a bit and zipped.
BTW - I submitted the latest windows installer zip to Virus Total. Here are its results. I don't know anything about most of the scanners being referenced.
VirusTotal - File - 4d9a71e7921536d131e7ea7de7dc283ec3ba4d5ed19b70fd279c24cce7f9d163.pdf
Thanks for providing the log file. There are two different providers (Gmail and Outlook) and two different protocols (POP and SMTP) in use here. When trying to debug, it's always easier if you try to isolate the account you're having issues with. Because of this, I've ignored the Gmail details given that you mention Outlook is the service you're having problems with.
The log begins with a POP login attempt, and you successfully authorise this. Login succeeds. There are then two further successful POP login attempts (with no authorisation prompt).
You then try SMTP, and there is an error decrypting the cached credentials. This leads to an authentication request (which you complete), but then another POP login attempt comes in that fails to decrypt the new cached credentials. Your client then tries other methods, and essentially the POP and SMTP connections end up in conflict over which one has the correct credentials.
The key issue here is that you're using a different password for your POP and SMTP connections. As noted in the documentation, it is essential that all protocols used with the same account use the same credentials, otherwise they will trigger constant re-authentication requests. If you'd rather these failed instead, you can set the delete_account_token_on_password_error option, which will cause attempts using the wrong password to fail rather than clearing the cached details.
Thanks for the helpful description. I am not at all sure how that had happened. I checked Thunderbird's remembered passwords for both POP and SMTP and they were identical. However, for some reason, after having re-done the authorizations, it seems to be working just fine again. About the only thing that might have influenced this is that my computer did its nightly reboot during the intervening period. Sorry to have bothered you. I still do not understand what might have caused this in the first place. But I suspect that Outlook periodically just forces its clients to re-authenticate (for no reason other than its own). Best!
