Bug/Warning not sure which

newer
High number of folders, Low sink...

Richard Shetron

24 Feb 2024 24 Feb '24

11:38 p.m.

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 =

Show replies by date

Odhiambo Washington

3 Mar 3 Mar

10:28 a.m.

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?

Richard Shetron

5:51 p.m.

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 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]

Jochen Bern

4 Mar 4 Mar

11:31 a.m.

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

Markus Winkler

3 Mar 3 Mar

12:13 p.m.

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

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

Arjen de Korte

10:58 p.m.

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.com

There doesn't seem to be a change in SAN since 2021-07-04.