Hi Richard,
On 24.02.24 22:38, Richard Shetron wrote:
I've always used mail.sgeinc.com as my incoming and outgoing server. At various times mail has been an alias for another machine. It's currently on the same address as sge.sgeinc.com. On the update forced on us on 2/22/24 or 2/23/24 it stopped working. It still works as an outgoing server but incoming POP3 it stopped working. It started working when I changed my incoming server to sge.sgeinc.com.
unfortunately you didn't send the Dovecot logs.
But anyway - I did the following tests:
(1) $ host mail.sgeinc.com mail.sgeinc.com has address 159.89.179.40
$ host sge.sgeinc.com sge.sgeinc.com has address 159.89.179.40
$ host 159.89.179.40 40.179.89.159.in-addr.arpa domain name pointer sge.sgeinc.com.
BTW: the latter is relevant for outgoing mails from this machine, as correct configured receiving servers should do this reverse lookup.
(2) $ telnet mail.sgeinc.com 110 Trying 159.89.179.40... Connected to mail.sgeinc.com. Escape character is '^]'. +OK Dovecot (Ubuntu) ready.
--> works (at least the POP3 daemon listens)
(3) $ telnet sge.sgeinc.com 110 Trying 159.89.179.40... Connected to sge.sgeinc.com. Escape character is '^]'. +OK Dovecot (Ubuntu) ready.
--> as expected: works too (at least the POP3 daemon listens)
Now the same with STARTTLS:
(4) $ openssl s_client -connect mail.sgeinc.com:110 -starttls pop3 CONNECTED(00000003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = sgeinc.com verify return:1
Certificate chain 0 s:CN = sgeinc.com i:C = US, O = Let's Encrypt, CN = R3 a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256 v:NotBefore: Feb 22 14:45:49 2024 GMT; NotAfter: May 22 14:45:48 2024 GMT 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT [...]
(5) $ openssl s_client -connect sge.sgeinc.com:110 -starttls pop3 CONNECTED(00000003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = sgeinc.com verify return:1
Certificate chain 0 s:CN = sgeinc.com i:C = US, O = Let's Encrypt, CN = R3 a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256 v:NotBefore: Feb 22 14:45:49 2024 GMT; NotAfter: May 22 14:45:48 2024 GMT 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT [...]
As you can see in (4) and (5): in both cases your server is also answering correctly if I'm using POP3 with STARTTLS.
And the server has a valid certificate. But IMHO here could be the reason for your problem (unfortunately too: you didn't tell anything regarding your mail client / MUA and how it's configured):
Look at the CN and the SANs:
--- snip --- Certificate: Data: Version: 3 (0x2) Serial Number: 04:1e:b2:84:50:b3:3f:21:f5:06:37:aa:89:8d:4e:77:3e:3e Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Let's Encrypt, CN = R3 Validity Not Before: Feb 22 14:45:49 2024 GMT Not After : May 22 14:45:48 2024 GMT Subject: CN = sgeinc.com [...] X509v3 Subject Alternative Name: DNS:sge.sgeinc.com, DNS:sgeinc.com, DNS:www.sgeinc.com [...] --- snip ---
There's nothing for mail.sgeinc.com. And if your mail client ist strictly checking this cert, then maybe it refuses the communication with your server. Did you get any error messages on your mail client, if yes: which?
And the cert could also be the reason for:
It started working when I changed my incoming server to sge.sgeinc.com.
because then the server name is one of it's SANs.
Also the time is important. Your wrote:
on 2/22/24 or 2/23/24 it stopped working
Have a look at the cert's validity:
--> Not Before: Feb 22 14:45:49 2024 GMT
All these details seems to be matching IMHO.
So I would suggest: create a new LE cert with an additional domain 'mail.sgeinc.com' and I'm quite sure that you can receive mails using 'mail.sgeinc.com' as your incoming server again after that. This could be made quickly, so please give it a try. ;-)
HTH and regards, Markus