Eudora 7: Could not connect to "localhost"

[freddy3333]

I've got 2 Windows PCs using Eudora 7 that I'm running email-oauth2 on--1 PC uses gmail & the other PC uses our company email server running freebsd/apache. oauth2 runs great on the gmail account, but I can't connect to the freebsd email server. Here's the error:
"Could not connect to "localhost" ... Cause: connection refused (10061)

I've got the same POP/SMTP ports configured in the oauth2 proxy that worked in the standard Eudora setup (masked text is correct)

When I change Eudora's server settings from "localhost" to our email server's domain or IP, downloads work perfectly....but I'm guessing that's because it's bypassing the oauth2 proxy, which is obviously defeating the purpose. But that tells me the bottleneck's related to something I've misconfigured in the Eudora settings rather than the emailproxy.config.

I'm usually pretty good at troubleshooting these things, but I'm stuck..

[freddy3333]

Could the problem be that I got the client_id/secret via my gmail account, but I'm using them to authorize for a non-gmail email server?
Here's the account info from the emailproxy.config file:
permission_url = https://accounts.google.com/o/oauth2/auth
token_url = https://oauth2.googleapis.com/token
oauth2_scope = https://mail.google.com/
redirect_uri = http://localhost
client_id = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com
client_secret = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The instructions said the client_id and client_secret values can be "reused from an existing source (such as another email client that supports OAuth 2.0)" -- I created a new set via my gmail account. But I'm wondering if the connection issue is due to everything above pointing to google.com, while the proxy is being used to connect to our (non-gmail) email server?

Also, when I check for new emails on the gmail PC, 15 or so new lines get added to its emailproxy.log--handshakes, etc. But on the PC I'm using for our email server, checking for new emails results in 0 new lines getting added to its emailproxy.log.....but if I attempt to Send an email, 4 lines get added:
2025-10-03 22:51:55,846: New incoming connection to SMTP server at 127.0.0.1:58900 (unsecured) proxying xx.xx.xx.xxx:58900 (STARTTLS)
2025-10-03 22:51:55,847: Accepting new connection from 127.0.0.1:60824 to SMTP server at 127.0.0.1:58900 (unsecured) proxying xx.xx.xx.xxx:58900 (STARTTLS)
2025-10-03 22:51:58,008: SMTP (127.0.0.1:60824-{127.0.0.1:58900}-xx.xx.xx.xxx:58900) <-- [ Server disconnected ]
2025-10-03 22:51:58,009: SMTP (127.0.0.1:60824-{127.0.0.1:58900}-xx.xx.xx.xxx:58900) --> [ Client disconnected ]

Does this indicate that the proxy's communicating with Eudora, but not with our server?

[simonrob]

OAuth client ID and secret values can indeed be used in multiple applications, but will only work with the same email provider. A Gmail client will only work with Gmail, not Outlook, for example.

There have been quite a few people trying to get the proxy working with Eudora - it is definitely worth searching the previous issues on here. Alternatively, I believe the proxy's sponsor, Auth-Email.com has figured out a way to support it: https://auth-email.com/documentation/using-eudora-with-oauth-email-providers

[freddy3333]

No, after your last couple of comments, it sounds like OAuth is neither the problem nor required for our freebsd/apache email server. Correct?

Any idea what might be causing most of our outgoing emails to bounce recently? We've had the domain, email server, Eudora and user accounts for > 25 years (with nothing changing at our end) and never had a single bounce. Now, 90% of outgoing mails bounce. Weird, huh?

[simonrob]

If you haven't set up DKIM and SPF records then that could be at least part of the issue. Other than that, you'd probably need to look closely at the logs to see what's going on.

[freddy3333]

We did setup SPF and DMARC via our domain name provider (Network Solutions/Internic) many years ago, but I'm not sure about DKIM? I seem to recall DKIM being alot more complicated to configure and the folks at Network Solutions saying that as long as we had SPF and DMARC, DKIM wasn't required since DMARC provides that final pass/fail that most email systems use. Does that sound correct to you? Or is DKIM required now?

Re DMARC: Whenever we (successfully) send emails to, say, a google email address, within 24 hours, we receive a DMARC email from [email protected] containing some variation of this:
<source_ip>xx.xx.xx.xxx</source_ip>
fail
pass
</policy_evaluated>
<header_from>ourdomain.com</header_from>
-<auth_results>
-
ourdomain.com
pass

In very rare instances (once/year), we're receive a DMARC email indicating a forged source_ip or header_from with a "fail" as the result. So that appears to be working.

[simonrob]

I'm by no means an expert here, but I'd definitely recommend setting up DKIM. Either way, you'll probably find the answer in the bounce details. Anything I'm suggesting is purely guesswork!

[freddy3333]

Interestingly, I just checked our DNS settings and we do have DKIM set. So there must be something else going on that's causing most of our recent emails to bounce. If you have any further ideas of where the problem may lie, please feel free to let me know.
In the meantime, many thanks for your help and guidance.....not to mention the wonderful proxy!