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
_______________________________________________
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org