Bug/Warning not sure which
Hello,
My sysadmin and I spent a couple hours trying to figure out a POP3 problem that has worked for about 20 or so years.
We run our own dns for sgeinc.com. 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. You might want to look into it or not. We chased the initial problem to, we think, ssh-keygen in /usr/local/bin/ which was Not found but is there.
Thanks
root@sge:/usr/local/bin# dovecot -n # 2.3.7.2 (3c910f64b): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.7.2 () # OS: Linux 5.4.0-172-generic x86_64 Ubuntu 20.04.6 LTS # Hostname: sge.sgeinc.com auth_mechanisms = plain login mail_location = maildir:~/Maildir namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { driver = pam } protocols = " imap lmtp pop3" service auth { unix_listener /var/spool/postfix/private/auth { mode = 0666 } unix_listener auth-userdb { group = postfix mode = 0660 user = postfix } } service pop3-login { inet_listener pop3 { port = 110 } } ssl = required ssl_cert = </etc/letsencrypt/live/sgeinc.com/fullchain.pem ssl_dh = # hidden, use -P to show it ssl_key = # hidden, use -P to show it userdb { driver = passwd }
On Sun, Mar 3, 2024 at 1:46 AM Richard Shetron <guest2@sgeinc.com> wrote:
Hello,
My sysadmin and I spent a couple hours trying to figure out a POP3 problem that has worked for about 20 or so years.
We run our own dns for sgeinc.com. 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. You might want to look into it or not. We chased the initial problem to, we think, ssh-keygen in /usr/local/bin/ which was Not found but is there.
Why would dovecot need ssh-keygen? What for?
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
On Sun, Mar 3, 2024 at 1:46 AM Richard Shetron <guest2@sgeinc.com> wrote: Hello,
My sysadmin and I spent a couple hours trying to figure out a POP3
problem that has worked for about 20 or so years.
We run our own dns for sgeinc.com.
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.
You might want to look into it or not. We chased the initial problem
to, we think, ssh-keygen in /usr/local/bin/ which was Not found but
is
there.Why would dovecot need ssh-keygen? What for?
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart- questions.html]
We finally solved the problem. For some reason dovecot stopped accepting mail.sgeinc.com but wanted sge.sgeing.com, the real name of the machine, not an alias name with the same IP address. Why it was going for ssh-keygen we don't know.
On 3/3/2024 3:28 AM, Odhiambo Washington wrote:
On Sun, Mar 3, 2024 at 1:46 AM Richard Shetron <guest2@sgeinc.com <mailto:guest2@sgeinc.com>> wrote:
Hello, My sysadmin and I spent a couple hours trying to figure out a POP3 problem that has worked for about 20 or so years. We run our own dns for sgeinc.com <http://sgeinc.com>. I've always used mail.sgeinc.com <http://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 <http://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 <http://sge.sgeinc.com>. You might want to look into it or not. We chased the initial problem to, we think, ssh-keygen in /usr/local/bin/ which was Not found but is there.Why would dovecot need ssh-keygen? What for?
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html <http://www.catb.org/~esr/faqs/smart-questions.html>]
On 03.03.24 09:28, Odhiambo Washington wrote:
On Sun, Mar 3, 2024 at 1:46 AM Richard Shetron <guest2@sgeinc.com> wrote: On the update forced on us on 2/22/24 or 2/23/24 it stopped working. [...] We chased the initial problem to, we think, ssh-keygen in /usr/local/bin/ which was Not found but is there.
Why would dovecot need ssh-keygen? What for?
And why would a forced "update" install it underneath /usr/*local* ?
Apart from that, by "Not found", I conclude that you *do* have an error message you could show us, so that we can at least poke at why dovecot would choose to fail the POP requests?
Kind regards,
Jochen Bern Systemingenieur
Binect GmbH
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
Citeren Markus Winkler <ml@irmawi.de>:
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.
That seems to be a coincidence. Looking at the history of certificates
for the sgeinc.com domain, it is almost three years ago there was a
valid certificate for mail.sgeinc.com:
https://crt.sh/?q=sgeinc.comThere doesn't seem to be a change in SAN since 2021-07-04.
As Aki wrote:
In that tune, due to a bug in mailman, some of the recent mails have failed to make it to the list, so if you have sent a mail after 3rd of March (last seen mail in the archive), you may want to send it again.
and as my mail (March 3rd) couldn't be found in the archive, here it is again - just to be safe:
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
participants (5)
-
Arjen de Korte
-
Jochen Bern
-
Markus Winkler
-
Odhiambo Washington
-
Richard Shetron