Eudora 7 Unable to Authorize gmail Acct

[freddy3333]

After modifying the emailproxy.config file with my gmail acct and server info, replacing the default ports with the ones I've been using in Eudora for the past few years, when I attempt to download mail from gmail, instead of an Authorization pop-up, Eudora outputs one of these errors:

SSL Negotiation Failed: Unknown Error The connection with the server has been lost.

Logging into POP Server, PASS There has been an error transferring your mail. I said: PASS and then the POP server said: ERR [AUTH] Application-specific password required: https://support.google.com/accounts/answer/185833

Since the email proxy never pops-up an Authorization prompt and the Activity Data indicates "never" next to my email address, I suspect something is still misconfigured.

Two specific things that may be relevant: 1) I'm a bit confused about how to generate or acquire the "client_id" and "client_secret"? I did follow these instructions (https://developers.google.com/identity/protocols/oauth2/native-app) to create the two client values, then I added them to the config file. But I got kind of lost on google's client generator tool, so I may've done something wrong. Still, I do have both values saved in a text file.

2) I'm also confused about which ports to use for gmail? In addition to the ports I've been using, I also tried the default gmail ports (2993, 2995 & 2465) indicated in the sample emailproxy.config as well as many others above ports 1023 and below 65536....none of which seemed to make a difference.

Screenshots of the port settings and my Eudora settings:

[simonrob]

Your POP and SMTP servers are configured to be the default Gmail ones. This needs to be changed to localhost so that your email client connects to the proxy, rather than direct to Gmail. Related to this, one thing you haven't posted is the log file showing the proxy's output. This is a key element in troubleshooting – see the proxy's readme for more details and tips.

Since you mentioned changing various settings in frustration and may just have forgotten to revert these, it's worth mentioning that I remember a previous Eudora issue that turned out to be it not respecting the ports configured in its settings screens. If you still have problems after changing the server settings it's probably worth reading through that entire issue to see whether there are any similarities. Regardless, the settings screenshot you've posted shows the standard Gmail ports, which is not what the proxy uses by default.

You also posted a screenshot of the proxy's dropdown menu, showing that you've configured new ports below 1,024. This is supported, but you need to make sure this doesn't require extra administrative permissions. It's possible for the proxy to be told by the Operating System that it has succeed in opening a port in this range when in reality it has failed due to the lack of permissions. So, it's safest to use ports above 1,024.

[freddy3333]

Thanks Simon. The only things I've changed are the ports and my account settings, all of which I took screenshots of BEFORE making any changes, so I was easily able to backtrack my work.

I just changed the ports to 2993, 2995 & 2587 and tried again, but still no go. However, when checking the SSL certificates, I see that the server setting is still pop.gmail.com & the port setting is still 995! I restarted Eudora and checked the port and server settings in Eudora's Settings and they're set correctly. So I don't know why they're still showing the old settings in the SSL section??

Attached is a zipped copy of the log. Thanks again, Simon!

emailproxy.zip

[simonrob]

See this comment in the other issue I referenced previously – it talks about oddities in settings and workarounds for them.

The zip file you posted is empty/invalid...

[freddy3333]

Not sure why the zip failed, but here's another that I just tested OK. emailproxy.zip

[freddy3333]

See this comment in the other issue I referenced previously – it talks about oddities in settings and workarounds for them.

I'm not sure I understand how chupocro's post relates to solving my issue?? Is my problem related to IMAP (which I don't use)?

[simonrob]

Thanks for the fixed log file. This shows some strange connection behaviour – lots of failures that are ignored by the proxy due to one of the errors caught in this method. If you're happy modifying the code, it would be worth making that method raise the exceptions instead of handling them just so you can see a bit more about what is actually happening. (Since it is in the asyncore package, you may need to override it in the proxy instead).

Re: the older issue – I know very little about Eudora, but wondered whether the same settings idiosyncrasies applied to POP/SMTP. The other thing is that (as discussed in that issue) Eudora is very old software, and could simply not be compatible – this may be the reason for the connection failures. But there are various workarounds discussed there that may well be useful.

[freddy3333]

Simon, I'm sorry, but I've no idea what asyncore is (I'm not a developer), but I'd give it a go if there are specific instructions (for non-developers) somewhere.

Older issue? The only issue I have is getting Eudora to work with gmail's OAuth2.

[GAllen27]

Eudora works fine with this proxy. I've been using the Windows compiled version with O365 email OAuth2 requirement for almost a year now. A huge thank-you to Simon!!!

[freddy3333]

Eudora works fine with this proxy. I've been using the Windows compiled version with O365 email OAuth2 requirement for almost a year now. A huge thank-you to Simon!!!

Thanks for your input! Based on what I've read, it seems you're not alone in getting it to work with Eudora. Any tips on how you got it to work? Or, did it work out-of-the-box after configuring your O365 login credentials?

[GAllen27]

It's all in the config, for both OAuth2Proxy and Eudora. There is a Eudora OAuth2 Proxy howto writeup for O365 that is long; I posted it here: https://drive.google.com/file/d/1mrZIyz34WD3UmyvnrOvXovt0blXlzSTa/view?usp=sharing GMail would be a bit different, but I can't help you there.

[freddy3333]

Many thanks for this! While the puzzle's not been solved yet, I feel like we're nailing down some of the variables I've been concerned/confused about..

It's all in the config, for both OAuth2Proxy and Eudora. There is a Eudora OAuth2 Proxy howto writeup for O365 that is long; I posted it here: https://drive.google.com/file/d/1mrZIyz34WD3UmyvnrOvXovt0blXlzSTa/view?usp=sharing GMail would be a bit different, but I can't help you there.

I see you used the same ports I'd originally used—995 and 587 (and deleted the IMAP section, which I've never used, so I deleted it as well), but set the bracketed numbers as [POP-1995] and [SMTP-1587]. So I reset both Eudora and my emailproxy.config to match your ports (which were the ones I started with and've been using to access gmail for years).

I already had set SSL "Secure Sockets = never", so I'm good there. Otherwise, other than those settings that're particular to O365 vs gmail and my unique "client" codes (which I'm still a bit confused about....so that may be an issue by itself??), I think my Eudora and emailproxy.config settings now match yours. But I'm still NOT getting the authorization prompt and continue to get these bloody connection errors when attempting to login/download email from gmail. Because the error cites "localhost" (with similar results when I change that to "128.0.0.1"), I'm guessing the bottleneck is occurring between Eudora and Simon's proxy???

[freddy3333]

It's all in the config, for both OAuth2Proxy and Eudora. There is a Eudora OAuth2 Proxy howto writeup for O365 that is long; I posted it here: https://drive.google.com/file/d/1mrZIyz34WD3UmyvnrOvXovt0blXlzSTa/view?usp=sharing GMail would be a bit different, but I can't help you there.

I just noticed that, rather than "localhost" as the Eudora POP server setting, you used the outlook.office365.com POP server, which is what I'd originally used (tho', in my case, it was pop.gmail.com). So I tried resetting that back as well...

Unfortunately, it still fails, but Eudora's yin/yang activity icon spun for much longer before popping-up a new/different error:

[freddy3333]

Still not prompted to Authorize or able to access gmail, but I clicked 'Yes' to the SSL Certificate and got another new error that contains "PASS". Headway??

[freddy3333]

Here's a new log file (checked/working).. emailproxy.zip

[freddy3333]

I apologize for being that guy who keeps posting, but since the author of the article GAllen27 posted got Eudora working, I started over and followed the entire procedure in the section "HOW TO CONFIGURE EMAIL-OAUTH2-PROXY AND EUDORA" from the "Eudora OAuth2 Proxy howto writeup for O365" that GAllen27 posted above.

After following those steps, here's what I did: 1) Configured the emailproxy.config as per the defaults for gmail—SMTP 465, POP 995 2) Configured Eudora as per the section "HOW TO CONFIGURE EMAIL-OAUTH2-PROXY AND EUDORA", with the same port assignments 3) I configured my local Windows firewall to TRUST and permit unfettered network access for "emailproxy.exe" 4) I renamed the original emailproxy.log (so the next run will create a new/shorter log reflecting my result following GAllen27's posted guide) 5) I ran emailproxy.exe as Adminstrator (to eliminate any Windows user permission issue) and enabled Debug mode 6) I opened Eudora and attempted to Check for mail...."localhost" connection refused. 6a) On a hunch, I closed both emailproxy and Eudora....then, I opened ONLY Eudora and attempted to Check for mail—same error I got with the proxy running: "localhost" connection refused.

Here's the contents of the new emailproxy.log: 2024-05-30 00:50:58,734: Running in a packaged/frozen environment - imported SSL certificates from certifi 2024-05-30 00:50:58,844: Initialising Email OAuth 2.0 Proxy (version 2024-05-25) from config file C:\Users\dt\Desktop\emailproxy-2024-05-25_pyinstaller-Windows\emailproxy.config 2024-05-30 00:50:58,844: Starting POP server at 127.0.0.1:2995 (unsecured) proxying pop.gmail.com:995 (SSL/TLS) 2024-05-30 00:50:58,859: Starting SMTP server at 127.0.0.1:2465 (unsecured) proxying smtp.gmail.com:465 (SSL/TLS) 2024-05-30 00:50:58,859: Initialised Email OAuth 2.0 Proxy - listening for authentication requests. Connect your email client to begin 2024-05-30 00:51:03,907: Setting debug mode: True 2024-05-30 00:51:43,849: Stopping Email OAuth 2.0 Proxy 2024-05-30 00:51:43,958: Stopping POP server at 127.0.0.1:2995 (unsecured) proxying pop.gmail.com:995 (SSL/TLS) 2024-05-30 00:51:43,958: Stopping SMTP server at 127.0.0.1:2465 (unsecured) proxying smtp.gmail.com:465 (SSL/TLS)

So, since Eudora's "localhost" connection is refused regardless of whether the emailproxy is running or not, my gut says the problem is that Eudora's NOT communicating either with "localhost" or the emailproxy. Does that spark any thoughts???

[freddy3333]

Last Update for tonight..(promise!) 1) I changed the ports in both Eudora and the emailproxy.config to 2995 & 2465 and closed both Eudora and the emailproxy. 2) Then, I ran the emailproxy and enabled the Debug log 3) Opened Eudora and attempted to Check for mail...

Here's the debug log: 2024-05-30 01:10:35,750: Running in a packaged/frozen environment - imported SSL certificates from certifi 2024-05-30 01:10:35,859: Initialising Email OAuth 2.0 Proxy (version 2024-05-25) from config file C:\Users\dt\Desktop\emailproxy-2024-05-25_pyinstaller-Windows\emailproxy.config 2024-05-30 01:10:35,861: Starting POP server at 127.0.0.1:2995 (unsecured) proxying pop.gmail.com:2995 (SSL/TLS) 2024-05-30 01:10:35,869: Starting SMTP server at 127.0.0.1:2465 (unsecured) proxying smtp.gmail.com:2465 (SSL/TLS) 2024-05-30 01:10:35,875: Initialised Email OAuth 2.0 Proxy - listening for authentication requests. Connect your email client to begin 2024-05-30 01:10:39,552: Setting debug mode: True 2024-05-30 01:10:54,261: New incoming connection to POP server at 127.0.0.1:2995 (unsecured) proxying pop.gmail.com:2995 (SSL/TLS) 2024-05-30 01:10:54,261: Accepting new connection from 127.0.0.1:57280 to POP server at 127.0.0.1:2995 (unsecured) proxying pop.gmail.com:2995 (SSL/TLS) 2024-05-30 01:11:15,299: POP (127.0.0.1:57280-{127.0.0.1:2995}-pop.gmail.com:2995) <-- [ Server disconnected ] 2024-05-30 01:11:15,300: POP (127.0.0.1:57280-{127.0.0.1:2995}-pop.gmail.com:2995) --> [ Client disconnected ]

If I'm reading the debug log correctly, it looks like all goes well until the emailproxy attempts to connect to gmail, at which point it (and Eudora) gets "disconnected". Does that point to the source of the problem....or the fix?

Sorry for mucking about so much...and thanks for your input!

[freddy3333]

Update: Good & Not so good news.

The Good: Receiving fixed by setting BOTH POP ports in the emailproxy.config and the ports in Eudora to 995.

For others having the same issue: The problem is that, in the instructions, the ports in brackets in emailproxy.config are 4-digit (e.g., 2995), whilst the ports in the body of the config are 3-digit (e.g., 995). The key is that all of the ports MUST be exactly the same: [POP-995] server_address = pop.gmail.com server_port = 995 local_address = 127.0.0.1

[SMTP-465] server_address = smtp.gmail.com server_port = 465 local_address = 127.0.0.1

Once matched, when I attempted to Check for email, the Authorization screen popped-up instantly, I entered my login password and code (texted to me as per gmail's 2-part authentication) and my email downloaded just like normal! Receiving problem solved!

The Not so good: Unfortunately, although I did the same for BOTH SMTP ports (tried 465, 587, 1465, 1587, 2465 & 2587), sending returns a new error (tho' the proxy status screen now indicates my successful account authentication a few minutes ago!):

In tandem with this error, The Send button in Eudora has been replaced with a Queue for delivery button and clicking the button just adds another copy of the same [unsent] message to the queue:

Here's a new (zipped and checked OK) debug log.. emailproxy.zip

[freddy3333]

Solved—Pilot Error!

In my general confusion (I've been beating on this thing since last night!) and mucking around, I unticked (disabled) the Eudora options to Authenticate allowed and Immediate Send. Once I ticked both options, the queued emails got Sent.

All appears to be working 100% now. But, from experience, I reckon it prudent to run Eudora and the emailproxy for a coupla days before I declare this case solved (and Close the thread). So, if anything pops-up, I'll report back. Otherwise, I'll close the thread on Saturday.

In the meantime, MANY THANKS TO ALL OF YOU, especially Simon, whose brilliant proxy [tentatively] MADE MY DAY!

[simonrob]

Thanks for following up, and for the kind words. Once you have things working, they will continue to work unless something in your configuration changes. But either way it sounds like you now know how to set this up. It's also useful to have this here for others, so thanks for documenting so thoroughly the various things you tried.

Just to follow up on your point above about the proxy's configuration instructions: the sample file is indeed correct in stating 1995 rather than 995 for the local port, for all of the reasons explained in its documentation. But it does sound like this is something Eudora can't cope with, so I'll point back to this issue in future if other people mention issues with that client.

I'll close this issue for now because it sounds like everything has been resolved, but feel free to reopen if things change.

[freddy3333]

Simon, since installing the proxy, my Windows User temp folder's filling with a growing number of _MEIXXXXX (X=numbers) folders containing more folders/files that appear to be Microsoft Runtime and/or python-related. I was unable to delete them, so I engaged an Unlocker utility that identified the files/folders with emailproxy before deleting them.....which appeared to cause the proxy to close (i.e., the icon vanished from the Windows taskbar!).

Two questions: 1) What're the _MEI folders for? 2) Is there a way to run the emailproxy without creating all of these _MEI folders?

Here's a screenshot of the _MEI folders:

Here's the contents of one _MEI folder:

Here's some of the many files in on _MEI folder:

Here's the Unlocker utility identifying the _MEI folders with the emailproxy. As soon as I had it delete the folders, the proxy icon in the Windows taskbar vanished:

[simonrob]

These folders are not created by the proxy itself, but are related to PyInstaller, which is used to bundle the proxy script into an executable app for people who can't/won't run it directly with Python. If you use the bundled Windows (or macOS) app, it is not possible to prevent these files/folders being created.

I'm not sure why you're concerned about this – after all, they're in a temporary folder that the Operating System manages. But if it's an issue (for example, they're not being cleaned up), you can raise it on the PyInstaller project.

[GAllen27]

Simon wrote: <<Just to follow up on your point above about the proxy's configuration instructions: the sample file is indeed correct in stating 1995 rather than 995 for the local port, for all of the reasons [explained in its documentation]. But it does sound like this is something Eudora can't cope with, so I'll point back to this issue in future if other people mention issues with that client.>>

Eudora has no problem with port 1995 and the OAuth2 proxy. Here is my Eudora.ini port setup for O365 email with the proxy [I use the compiled Windows version, no Python installation):

[Settings] ;For sending outlook mail: SmtpAuthAllowed=1 SMTPServer=localhost SMTPPort=1587 SSLSendUse=0

;For receiving outlook mail using POP: UsesPOP=1 PopServer=localhost POPPort=1995 SSLReceiveUse=0 AuthenticatePassword=1

UseSubmissionPort=0

---

So as freddy3333 said, it is pilot error, not problems with the proxy. Setup can be complicated however ... the nature of the beast.

[freddy3333]

Simon wrote: <<Just to follow up on your point above about the proxy's configuration instructions: the sample file is indeed correct in stating 1995 rather than 995 for the local port, for all of the reasons [explained in its documentation]. But it does sound like this is something Eudora can't cope with, so I'll point back to this issue in future if other people mention issues with that client.>>

Eudora has no problem with port 1995 and the OAuth2 proxy. Here is my Eudora.ini port setup for O365 email with the proxy [I use the compiled Windows version, no Python installation):

[Settings] ;For sending outlook mail: SmtpAuthAllowed=1 SMTPServer=localhost SMTPPort=1587 SSLSendUse=0

;For receiving outlook mail using POP: UsesPOP=1 PopServer=localhost POPPort=1995 SSLReceiveUse=0 AuthenticatePassword=1

UseSubmissionPort=0

So as freddy3333 said, it is pilot error, not problems with the proxy. Setup can be complicated however ... the nature of the beast.

The pilot error was related to the two Eudora settings in my previous post, not the overall problems I've had getting the proxy to work. The port issue, at least in my (gmail?) case was due to having a four-digit port assignment in the [] section and a three-digit port assignment below that. Since the proxy's working with all three-digit port assignments, I've no reason to experiment further with all four-digit ports, but I reckon they'd work as long as both the [] port and the one below that are exactly the same—both either three- or four-digit. But, again, I appreciate your input!

[freddy3333]

These folders are not created by the proxy itself, but are related to PyInstaller, which is used to bundle the proxy script into an executable app for people who can't/won't run it directly with Python. If you use the bundled Windows (or macOS) app, it is not possible to prevent these files/folders being created.

I'm not sure why you're concerned about this – after all, they're in a temporary folder that the Operating System manages. But if it's an issue (for example, they're not being cleaned up), you can raise it on the PyInstaller project.

For security (and space) reasons, I've always had Windows clear its temp files/folders when rebooting/shutting down. Prior to installing the emailproxy, that process never took more than a handful of seconds to complete. Now, it takes several minutes....and it was in the process of diagnosing the unusually slow shutdowns that I discovered those folders, It may not technically be a problem, per se, but I don't think I've ever seen another Windows process that regularly generates that much temp data.

Re the PyInstaller project: A current thread, Regression with delete _MEI in 6.7.0 (working 5.3), looks to be addressing this very issue. However, it looks like they're all developers and I don't really follow what they're doing?