Damm I made a massive post last night replying to this thread but it does not seem to have stuck.
Lets try again.
How are you testing your connection to your host?
I also noted you are using port 443 not 25 and upgrading the connection to TLS.
Try running the following
openssl s_client -connect 91.238.161.174:25 -starttls smtp -crlf -servername cp161174.hpdns.netWhen you are logged in execute the following
EHLO cp161174.hpdns.net
Which will start your SMTP session
You will see something like the following
CONNECTED(...)
...
SSL-Session:
Protocol : TLSv1.3
Cipher : ...
then test the connection executing the harmless
EHLO test.example
Typing quit will then exit the session and bring you back to the command line
If this all executes fine then the connection to port 25 SMTP/ESMTP is working.
If ikt fails then try using a tool like wireshark to see what is coming from your host. a filter command like the following will capture your stream
ip.addr == 91.238.161.174 && tcp.port == 25
This will enable you to see if you are just getting a RST (Reset) or if ikt tries to setup a connection (SYN, SYN-ACK, ACK, ...)
If you are getting RST thaty would point to a firewall rule somewhere.
Hope this helps/. I had lots more last night but i forgot what i tyoed and i dont have access to my systems to address it Now.
Thanks so much - and so sorry you lost your original - this is clearly a spooked scenario!
I ran your SMTP test:
openssl s_client -connect 91.238.161.174:25 -starttls smtp -crlf -servername cp161174.hpdns.net
and got:
connect: Connection refused
connect:errno=61
So port 25 is refused as well.
We've also established that .174:443 and .174:2083 are refused, whereas .173:443, .173:2083 and .173:993 all connect successfully from the same Mac/BT connection.
Ecohosting have concluded it's a BT problem, but as BT refuse to engage, Ecohosting have offered to migrate me to another server, so hopefully today. I'll update as and when.
OK, everyone out there who cared: Big Thanks! Ecohosting just migrated me to an adjacent server and I have email via computer for the first time in 7 days. They can find nothing in their logs to explain why the refusal occurred last Friday, and the assumption remains it was a quirky BT fault. I just wish someone within BT had engaged with the issue instead of saying "No fault is showing so we can't do anything." Anyone any ideas about how I get a full explanation of this hugely disabling and inconvenient event?
The issue is at the 91.238.161.174 end.
You are getting a SYN - RST, before hitting the SMTP server.
Probably a host firewall/firewall close to the device.
if you still has access to the box (did you ever have ssh login) you could have run the following to ensure that the email service was running on the internet available interface and not localhost (127.0.0.1)
sudo ss -ltnp '( sport = :25 or sport = :443 or sport = :2083 )'
this will show whether the ports are tied to the local IP or an internet routable one.
Good luck with your new server.
Remember to secure it.
This is all way above my tech grade, but I'm being forced to learn!
The fact that my EE 4G could reach .174 means .174 wasn't simply universally refusing connection. And the fact that another BT Community member could apparently reach .174 means it wasn't simply "BT blocks .174." So the most precise description remains: My particular BT-to-.174 path was producing an active TCP refusal.
I've asked Ecohosting if they can establish whether the SYN from my BT connection was reaching their network edge, and if so, where the RST was being generated? Not holding my breath, though.
I really want the precise cause to be located so no-one else goes through the kind of week I've just had!
I'm clearly still a Beginner because I don't even know why my non-italic post was italicised!