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.
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 config
>> files. All I did was shutdown Courier services, change the one file that
>> holds the certificates, etc. And started courier again. The only thing 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 decade
>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 the
>mothership. The basic troubleshooting located the firewall rule that I forgot
>about.
>
>So, eliminate the basics, and verify that port 587 is reachable from the
>client 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 eliminated 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 incoming connection
>will log a fork and exec of courieresmtpd, which will exchange 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
>talking on the encrypted socket and the unencrypted pipe to courieresmtpd
>
>2. Which files the couriertls process opens. This will include the certificate
>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 daemon 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
>esmtpd-msa, then that would do it. strace will show it. But that's unlikely.
>If an 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.
_______________________________________________
Courier-imap mailing list
Courier-imap@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
