-
-
Notifications
You must be signed in to change notification settings - Fork 111
Eudora 7 Unable to Authorize gmail Acct #252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Your POP and SMTP servers are configured to be the default Gmail ones. This needs to be changed to 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. |
Thanks Simon. 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. |
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... |
Not sure why the zip failed, but here's another that I just tested OK. |
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)? |
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 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. |
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. |
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! |
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: |
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..
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??? |
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: |
Here's a new log file (checked/working).. |
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:
Here's the contents of the new emailproxy.log: 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??? |
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: [SMTP-465] 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! 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.. |
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! |
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 I'll close this issue for now because it sounds like everything has been resolved, but feel free to reopen if things change. |
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. |
Simon wrote: 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 receiving outlook mail using POP: 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. |
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? |
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:
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.
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:

The text was updated successfully, but these errors were encountered: