"J. P. Gilliver (John)" wrote:
My blind friends have been using the "Eudora" email client for many
years, and it still works; however, it is beginning to have problems,
for example with security certificates. (It ceased development in 2006,
so it's not doing bad!)
Changing software is difficult for many of us, but more so for the blind
- they have learnt how to navigate round the software using keyboard
only. I was aware that Eudora was having problems, so was pleased to
read about Pandora, which was claimed to be very usable by those used to
Eudora, and still being supported/developed (it claims to work on at
least XP to 10, and I think some other OSs [Julia uses 7-64]); however,
I just told my friends about it, to let them if they wanted have a look
and decide. (We've been burned by a claimed replacement before.)
Julia has downloaded, installed, and configured it (she's quite computer
literate), and quite likes it; however, she can't get it to _send_
emails - and neither could I, in a Teamviewer session. (_Receiving_ is
working fine.)
I think the problem is that Pandora is more versatile, to cater for the
authentication requirements ISPs use these days. But we _think_ we've
tried all the permutations!
http://255soft.uk/temp/Clipboard01.jpg shows the configuration window,
as well as one of the error messages we get, in the log window at the
bottom.
There _seem_ to be three areas to play with, giving in theory 18
permutations:
"Authentication", which can be Basic, MD5-something, or OAuth2;
"Secure Sockets when Sending", which can be Never, If Available
(STARTTLS), or Always;
and "Include on global send", which is a tickbox.
Unticking the last seemed to prevent Pandora even trying to send when
told to (nothing appeared in the log window). I'm pretty sure I tried
all 9 combinations with it ticked.
Selecting OAuth2 generated an error message something like "unrecognised
authentication method".
TalkTalk's setting page at
https://community.talktalk.co.uk/t5/...3/ta-p/2204399
says don't use MD5, but I tried it anyway - I forget what error message
we got, but it didn't work.
Looking at what Julia had set in Eudora, "If Available" was set. As you
can see, that - with "Basic" - generated "5.7.0.7garbage
Authentication Credentials Invalid (TT300) [535]".
Some of the other combinations generated "Invalid Command" (I think with
"504").
You'd think the meaning of "credentials invalid" is obvious - username
or password are wrong; but (a) the same ones work in Eudora, (b) they're
working for _sending_.
Any thoughts? (Especially if you use Pandora with TalkTalk!)
(The above settings page just says "Outgoing START/TLS: Yes, Outgoing
Authentication: Yes" - nothing about which _type_ of authentication. But
the text below the table says don't use MD5, and selecting OAuth2 gave a
message implying that wasn't recognised, so Basic seems the most
likely.)
"If available, use StartTLS" means the client will use TLS if the server
reports back StartTLS in its keyword status response. This is a
drop-down list of choices which could be:
- Don't use a secure connection.
- Use TLS/SSL if available.
- Force use of SSL/TLS.
TLS 1.0 was no more secure than SSL 3.0 the latter of which got
deprecated because it was vulnerable. However, TLS 1.0 and SSL 3.0 are
incompatible because the handshaking changed. Then servers moved to TLS
1.1 and 1.2. Now they're moving to TLS 1.3. TLS 1.3 was not ratified
until 2018 although sometimes clients start supporting an RFC standard
before it gets ratified; however, TLS 1.3 came out long after Eudora got
abandoned.
In the past, there were also weak ciphers that got removed from
operating systems. Some were just deprecated, but that meant they were
headed to the chopping block. As I recall, the server will request a
cipher but will allow fallback at the client, but may still not support
what the client fallbacks to. It is still the choice by the server as
to which cipher it will allow.
https://www.acunetix.com/blog/articl...her-hardening/
https://electricenergyonline.com/ene...ak-Ciphers.htm
Been too long since I used Windows XP to remember just when Microsoft
pushed some Windows updates that removed only some of the weakest
ciphers. When the problem was discovered, their first recommendation
was registry edits to disable them. However, just because a weak cipher
remains defined in an OS doesn't mean a server will grant their use in a
session between client and that server.
You might have to use sTunnel as a local proxy through which you make
your secure connections with your clients that are too old to support
the later encryption schemes. Unlike Eudora, sTunnel is still
supported, and includes covering TLS 1.3. It operates as a local proxy:
you configure your client to locally connect to it using non-encrypted
connections, you configure sTunnel to listen on the ports the client
uses to it, and configure sTunnel to connect to the server. Hopefully,
once you get it setup, it runs fine; however, if they proxy becomes
unresponsive, all traffic through it is stoppped, and you won't get
anymore e-mail until you fix the setup. You're adding another link in
the chain between client and server.
https://www.stunnel.org/
If you don't want to go through all that hassle then you'll need to
consider if you really need encryption connections with an old e-mail
client. You could the other settings to see if those work. "If
available" means the client tries to detect and match what the server
reports it supports, but you might try "Force SSL/TLS" instead to always
have the client use TLS. If that doesn't work, you're stuck using no
encryption; however, some e-mail servers demand encrypted connections to
prevent sending login credentials in the clear.
As for OAUTH2 authentication, that uses tokens (refresh and access) from
the server. Once you get a token, the login credentials are no longer
used. However, the access token expires, and the refresh token (with a
far longer expiration) is used to get another access token from the
server supposedly without any user intervention. While this is supposed
to be transparent to the user when getting (refreshing) a new access
token, some clients don't perform an automatic and non-interruptive
refresh. Also, OAUTH2 was in its infancy back in 2006, and it was a
framework (OAUTH1 was a protocol), so different places implemented it
differently. Unless the client has a mean to allow the user to manually
initiate a refresh to get a new access token, the user has to delete the
account and recreate it in the client to force getting a new access
token. If the client isn't doing an automatic refresh to get a new
access token to replace the old expired one, or the refresh token itself
has expired and the client doesn't initiate a new request for them,
you'll have to see what, if any, means there are in the client to make
it get new tokens. You might have to delete the account in the client
(to eradicate the old tokens) and recreate the account and login to get
new tokens.
I just checked. OAUTH2 didn't come out until 2013. So, your client
must be using OAUTH1 although that didn't show up until 2009. Could be
the e-mail provider no longer support OAUTH1 (circa 2009). That your
client supports OAUTH any version means it must've gotten some
maintenance since 2006. If Eudora did indeed stop getting maintained
around 2006, I wouldn't trust its OAUTH to be reliable. Hopefully your
e-mail provider doesn't demand use of OAUTH, and they support just the
simple login schemes.
Presumably you already matched the settings in the client to those
specified by the e-mail provider at:
https://community.talktalk.co.uk/t5/...3/ta-p/2204399
Be sure to use the correct port for SMTP (sending). Port 25 was never
to be used by MUAs (Mail User Agents aka clients), and only between MTAs
(Mail Transfer Agents aka servers), but it got used anyway by clients.
Many e-mail providers moved to port 587, and that's what MUAs are to
use. There was a period where they allowed both during a rather long
grace period, but many have now completed switch to 587 for client
connections.
It's been a long time since it's happened to me again, but in the past
the provider wanted to ensure a human was using their e-mail service.
When using their webmail client, they would interrupt the login with an
interstitial page asking for validationg a human was using the service.
If validated, the login completed, and the webmail client showed the
e-mail page(s). Local e-mail clients aren't web browsers, so they
couldn't show the interstitial web page. The user had to use a web
browser to visit their account to login, get past the interstitial
security page, complete the login, and thereafter the local e-mail
client would start working again ... until later when the service
decided again it wanted to verify a human was using the service. Login
using the webmail client to see if the local client starts working
again.
Oh, did you ever try disabling e-mail interrogation by whatever
anti-malware software that is installed on the computer? That uses a
transparent proxy to interrogate the e-mail traffic. If that proxy
becomes unresponsive, you won't get or send any e-mails. If the proxy
takes a long time to interrogate the e-mail traffic, it will cause
timeouts at the client (on receive) or server (on send). Usually you
can just disable e-mail inspection in the AV to test if that is causing
the problem. However, likely the e-mail traffic still goes through the
proxy but without interrogation, and if there is a problem with the
proxy then there will be a problem with your e-mails. You could try
disabling e-mail scanning in the AV and reboot. If that doesn't work,
reconfigure the AV to *not* inspect the e-mail traffic (which is
superfluous, anyway, and provides no additional protection), reboot, and
retest without their proxy linked into the path for your e-mail traffic.