Settings > Mail works fine on port 25 (without SSL/TLS) but fails when configured to use port 465 and requiring SSL:
Sending test mail failed. Error: Timeout was reached(ec=28), server response timeout
The backup server is running Windows 10 and I’m connecting to my ISP’s SMTP server. The ISP notes port 465 in their configuration instructions… have tried 587 but it fails too ( Sending test mail failed. Error: Timeout was reached(ec=28), Failed to connect to mail.internode… port 587: Timed out). Messaging from other devices on my network (e.g. NAS) via the ISP’s SMTP server on port 465 works as expected.
If I change this:
Send mails only with SSL/TLS: not checked
I just get a timeout: Sending test mail failed. Error: Timeout was reached(ec=28), server response timeout
It sounds like this was previously a known limitation/issue… was this suggested change implemented? Is sending mail on port 465 now be supported?
Looking at my server logs, I was able to make it work when I added a valid account to logon with. At least for my server, it is configured to require an authenticated connection when connecting via SSL/TLS.
Another consideration for you: Does your mail server support “START SSL/TLS” or does it require mandatory SSL/TLS from the client side?
I’m working on the assumption the account I’m using is valid because I can successfully send a test message through port 25 without any of the of SSL options checked.
Are you looking at your mail server logs or urBackup logs? This got me thinking I should dig around in the urBackup logs to see if anything jumps out!
That I don’t know… my ISP’s email configuration guides note the following (I’m not sure if any of this correlate to START SSL/TLS support):
In the Port field next to Outgoing (SMTP) email server, enter 465.
Tick the Outgoing server requires SSL box.
Tick the Outgoing server requires authentication box.
I’ve recently found a server on the Internet that seemed to be more picky about the version of Transport Layer Security (TLS) installed on my older computer. You might have Windows 10 trying to use a later, more secure TLS version and the mail server wanting a different one that Windows doesn’t accept any more. Are there any online help articles or forum messages at your mail provider that mention such difficulties?
Checking the link you provided, I see Internode mentions SSL, which is an older protocol no longer in use by default on Windows 10. See this Microsoft forum post for details.
Thanks for your response Don–this is interesting and something I wasn’t aware of. As a test, I enabled SSL 3.0 on my Windows 10 machine (also the urBackup server) and re-tested (in Chrome) with no change in behaviour.
As an aside, I can send email through the same ISP from my NAS (same network/same everything–different OS)… and it’s configured to send through SSL, not TLS, on port 465. No issues there, although sending through TLS/port 587 doesn’t work in that environment.
I only looked at my mail server logs during my testing.
This suggests to me that it requires mandatory SSL/TLS
My testing is being done on an internal mail server that I control. Both the server running UrBackup and the server running my mail have a TLS certificate bound to them.
Since port 465 is usually associated with implicit TLS, I wonder if maybe your NAS has a certificate (self-signed or public) bound to it, which would make it capable of doing the secure mail, while perhaps your Windows workstation does not.
Because my server is internal, I am using port 25 without authentication. When I tested port 465, I had to use authentication (because that’s how I have the server setup).
If you have a gmail account, you might want to try and testing sending the mail through that, as it could help you narrow down any configuration issues.
Just to add to the above, that is going to be the same as an ISP mail server is, as they will want to protect their host and IPs from being an “open relay” server, which could very easily and quickly cause issues if spam was to start being sent; using the authentication means that only authenticated/allowed senders can send through the mail relay servers…
Also adding…if, as many of us (well, I certainly do) have some form of Two Factor Authentication [TFA] on the Gmail account, and you won’t want to keep updating your system/s when you update your Gmail password, you should use the Google portal to create an “application” password to use that instead - it is separate from your normal password and is pretty long, think it was about 30 characters when I set my ones up…
If you use your Gmail account up for use on multiple systems, then you may be best to create one “app” password for each one, so if it were to get compromised, you don’t need to go off/around updating and testing everything again…
