Greg Pfister writes:
« HTML content follows »Ok, I see where you're going, and I guess I did neglect to give you more info. From the client ip, I can connect and check the certificate on port 587. I'm also connected to the imap via 993 (working). Further, when I attempt to send an email via 587, the mail.log shows my ip connecting, with my login. But then the client connection hangs until timeout.If a firewall rule existed then I would think it would block my attempt of openssl to look at the certificate.
This proves that the new certificate is unrelated.The next step would be as I outlined: using strace on courieresmtpd to capture the unencrypted SMTP.
And with your own manual connection to port 587 you can always send EHLO/MAIL FROM/RCPT TO/DATA with a short message and see what happens.
This narrows down to two possibilities.Reverse DNS lookup/validation is enabled for the MAIL FROM domain, and the DNS lookup is stalling.
A local mail filter is installed, and it's getting stick (no response from DATA).
On July 24, 2022 10:46:56 PM EDT, Sam Varshavchik <mr...@courier-mta.com> wrote:Greg Pfister writes: Hi Sam, This was a working server right up until the point that the certificate expired on Friday. Have made no changes to the firewall, routes, or conf ig files. All I did was shutdown Courier services, change the one file t hat holds the certificates, etc. And started courier again. The only thi ng I had to do manually is the 10 or so couriertls running, had to kill those. Again, no firewall changes made, nor any courier configuration files. It never hurts to start from step 1 with basic troubleshooting. It wasn't too long ago I forgot about a firewall rule I put in nearly a de cade ago after I caught various I- gizmos flooding my upstream bandwidth uploading some garbage to 17.0.0.0/8 . Now, the same meatbags that polluted my network with their I- gizmos had a baulky I-gizmo that I was obligated to factory- reset (as the only available nerd in the family), and it couldn't reach th e mothership. The basic troubleshooting located the firewall rule that I f orgot about. So, eliminate the basics, and verify that port 587 is reachable from the c lient IPs. Once it's confirmed that port 587 answers a connection request and you get an SMTP banner (since it starts in cleartext) you've eliminate d that part of the network stack, and can move on to the next layer in the software stack. The next troubleshooting step is to attach strace with the -s 256 - f flags to the couriettcpd process that's listening on port 587. An incomi ng connection will log a fork and exec of courieresmtpd, which will exchan ge a few pleasantries before forking and running couriertls. couriertls's strace log will show: 1. Both encrypted and unencrypted traffic, since it'll be simultaneously t alking on the encrypted socket and the unencrypted pipe to courieresmtpd 2. Which files the couriertls process opens. This will include the certifi cate files that it loads, for the connection. esmtpd- msa has its own config file. It's not in the default config file but it's theoretically possible to overwrite TLS_CERTFILE and have the port 587 dae mon load its certificate from a different file. If, instead of overwriting the expired cert file the new one was loaded and the esmtpd file updated, but not esmt pd- msa, then that would do it. strace will show it. But that's unlikely. If a n expired cert is still being served I would expect the client to complain instead of hanging. Alternatively, the new cert file's permissions could be wrong, couriertls complains but its error message gets lost, but strace will show it. Still, that should also result in a closed connection instead of a hang. A hang strongly suggests a firewall issue. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
pgpKlAvRQi9vX.pgp
Description: PGP signature
_______________________________________________ Courier-imap mailing list Courier-imap@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
