I'm still not ready to give up my Eudora email program. But it's proving to be a bit intractable at the moment. I recently switched to a new hosting service and had a great deal of problems setting it up for the new servers. Seems TLS is broken in Eudora, at least with modern servers. I was finally able to get the bloody thing to work after playing with it for some days.
Now the provider has switched servers and Eudora will no longer send emails. Downloading emails is fine, but on sending either it times out or gives errors regarding authentication depending on the port number used. I ran wireshark but I can't say I understand the results. Only a half dozen messages are sent or received and there is 100 second wait between them. So it looks like something is timing out.
Any suggestions on how to debug this? How do email clients authenticate if TLS isn't used?
Who's the ISP? I want to check what protocols they support and expect. If you don't want to disclose this information, try the following as a starting template for an SMTP session using telnet: Use this to encrypt your password: If you still have access to your old ISP account that worked, try the same session and compare results between the old and new ISP.
Good luck.
--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
The service provider probably wants to use TLSv1.2 which did not exist when Eudora was frozen. If that is the case there is no overlap between the security options in Eudora and those that your provider supports. The only solution is to try and use no security. Eudora has an option for this ("Secure sockets when sending: Never") and many email providers have a special port that they will reluctantly allow to be used without security. John
Very strange. Before when I switched to Mightweb they did not allow email without authentication. Now it works just fine. I assume the authentication is to prevent spammers from using email servers as relays. I hope this doesn't get shut down.
The web hosting provider is Mightyweb.net. I don't think my ISP has any email support. I tried contacting them yesterday and never heard back. I looked up the possibility of using gmail or Yahoo mail and both seem to use TLS which I know Eudora does not work with.
Mightyweb says using no authentication exposes the password which sounds like a bad idea. I'm not sure using authentication actually encrypts the password. I've always used authentication, just not TLS. How then does that work?
Talk about your spartan web pages. They don't even talk about the control panel or if you can support reseller accounts. I have several people using my account to host their web pages and they need separate logins. I sent them a question about it.
There are several different forms of authentication which can work over a non-encrypted connection. The really insecure ones transmit the password in cleartext, and these can (as noted) expose your password on the net, and also require that the ISP store the password itself.
There are hash-based authentication systems which can be reasonably secure even if an encrypted connection is not used. In these, neither system ever transmits the password itself. Instead, the server says (in effect) "Here, append this randomly-chosen string to your password, compute an MD5/SHA-1/SHA-256 hash of the result, and send me back the hash." This allows your client software to "prove" that it has the password.
With this approach you still have the concern that the email itself is flowing over a non-encrypted connection and is open to being wiretapped, even if the password is not.
Not all ISPs, server packages, and client packages support all of these authentication methods such as MD5AUTH. You can still end up a situation in which "plain text" is the only method the two ends can agree upon... not good, especially in shared-public-network situations.
You can use any of these authentication methods over an encrypted connection (SSL or TLS), so that both the password phase and the actual email exchange is secured.
I'm using Eudora 6.2.5.6 for POP/SMTP on Cox cable, with encryption. No guarantee it would work for you, but I could provide my Options settings if you like.
"Last SSL Info" for POP says Port 995, TLSv1, DHE-RSA-AES256-SHA(256bits)
For SMTP it's the same, except Port 587.
Cox requires my Cox username and password.
Under Getting Started, I have Allow Authentication checked.
Under Checking Mail, I have Secure Sockets when receiving set to "Required, Alternate Port"
Under Incoming Mail, I have POP and Passwords selected.
Under Sending Mail I have Allow Autherntication and Use Submission Port (587) selected. And under Secure Sockets when sending, I have Required, STARTTLS selected.
All the Kerberos stuff is turned off.
Then you need to Google "patch QCSSL.dll". This addresses the situation where the first contact to the server takes a long time, or even times out. I think there's a version for
7.1.0.9 on dropbox which Google will take you to. or if you're using 6.2.5.6, I can send you the patch. I think in both cases, just one byte is changed in the dll.
The big problem most people have is with certificates used by the server not being considered valid by Eudora. After attempting to POP email, you can go into the Last SSL Info under Checking Mail, and open up the Certificates section at the bottom, and make sure there are no bad certs. If there are, you may need to import them. And you can only fix one at a time. There may be a whole string of them, so you nay have to repeat the process until everything is good.
I think TLSv1 may not be supported by your server. It is considered to be compromised. If so, you may be out of luck on encryption. Eudora used its own SSL dll, and I don't know how you would get a more modern version.
I notice that the two usual OPENSSL files are also in the Eudora program files folder. So it may be possible to update to newer TLS versions by updating those two files, which presumably are the 32-bit versions. However, the only references I could find to TLS in the QCSSL.dll file were to v1. So even if later TLS versions are in the OpenSSL files, they may not be called.
That reminds me that the client and server cannot be too far apart in their timestamps. The SSL/TLS handshaking passes a time-sensitive token. If one end is way off on time, the token is considered as having expired. The OP needs to make sure his date and time are current.
Seems I was mistaken. I am able to turn off authentication and send an email to one of my other email accounts on the same server, but I am still not able to send email to other servers. The reported error is "550 without authentication". My hosting provider is not being much help. They just see it as a problem of using a crappy email program.
I wish I understood the use of Stunnel better. I'm not sure if it will help with this problem or if I can even run it under Windows.
Would it make any sense to run an email server on my laptop? That seems like it would need to be the email endpoint, no? That would mean I'd have to host the domain name on my laptop, right?
When sending e-mails between accounts at the same e-mail provider, it is unlikely that SMTP is employed in the message transfer. Instead internal routing is used to link the message to other internal accounts. When you look at the Received headers for an internally routed message, you'll see it never left their domain and didn't pass out through an SMTP server. It's all internal routing. Depends on how they set up their boundary SMTP server (the one that sends outside their domain).
Been a long time but I used sTunnel on Windows XP and it worked as long as you get both the client and sTunnel proxy configured correctly. Client has to connect to sTunnel, not to the e-mail server, and the client must not use encryption when connecting to the sTunnel proxy. In the sTunnel config, you define which inbound connections go to which outbound connections, sort of like a mapping of in to out. Its config file has "name=value" pairs that map which input connect goes to what output connect.
Make sure your client doesn't encrypt its traffic for its connection to sTunnel (configured in the account you define within your client). sTunnel does the encryption to the server. Some examples are at:
formatting link
My recollection was when having multiple e-mail clients use sTunnel that you had them connect to different listening ports for sTunnel. Or maybe that was just me to keep them separate. From what I see at the examples, you really only need to define to where sTunnel will connect (the e-mail servers). No login credentials are including in the config because those get stripped (parsed out) from the non-encrypted connect by your client to sTunnel.
If you have anti-virus software configured to intercept your e-mail traffic, some use transparent proxies but some use opaque proxies. With opaque proxies (like with sTunnel), the client's config for an account defined within it points at the AV's proxy, not to the e-mail server. If you have one of those AV programs, either you disable its opaque proxy or simply reconfigure the client to point at sTunnel's opaque proxy; else, you have to figure out how to chain multiple opaque proxies together (client configured to connect to sTunnel proxy configured to connect to AV proxy, or maybe client to AV to sTunnel).
If you have a personal account with your ISP, check their terms of service. They may not allow Internet-facing servers by their customers. I know some users that ran afoul of such restrictions when running file or gaming servers on their PCs at home on a personal-use service tier.
You can run afoul of anti-spam blacklists. You won't be running your own nameserver so your SMTP server won't have an MX record showing it is authorized to send from your domain. If you don't register a domain then your SMTP server will only have an IP address which means no reverse DNS lookup. Some anti-spam filters don't like non-unique MX servers, especially when no MX server is listed at a nameserver at the domain. You will appear a rogue e-mail source. Nowadays many e-mail providers use DKIM (domain keys), SPF (sender policy framework), or DMARC to prove who sent a message an you won't have any of that (see
formatting link
You will be an unknown source and unacceptable to other SMTP servers.
Why would you add the complexity of a local SMTP server (you'll have to find one first) when the easiest solution is to change to a different e-mail client? There are plenty of free ones. Or perhaps you are a fan of the Red Green Show? Granted using sTunnel smacks of a Rube Goldberg setup but switching to another e-mail client is a lot easier.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.