This announcement only affects self-hosters who are running Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. Managed hosting customers, and self-hosters using POP3 for incoming mail are not affected. As you may be aware, Let’s Encrypt recently changed their root certificate. The old root certificate expired today, and has caused a number of issues for out-of-date clients across the web. All of our systems at CDCK are up-to-date, and were not affected by today’s expiration. Unfortunately we missed the public mail-receiver docker image, which has not been updated for a few months. This means that existing self-hosted mail-receiver installations will be unable to deliver mail to letsencrypt-secured sites. We just pushed an updated version to DockerHub, which includes the new root certificate. Assuming you followed the official installation instructions, you can update your installation by running docker pull discourse/mail-receiver:release cd /var/discourse ./launcher rebuild mail-receiver Mails received by broken installations will have been temporarily queued on the sending server. Those servers should attempt to redeliver the mail periodically, so any missed mails should arrive soon after you update the image. If you’re still seeing issues after following these steps, make sure you’re running the release version of mail-receiver. You can find information on that in this topic. Sorry for the disruption here! Big thanks to @wlandgraf for initially reporting the issue, and helping us test the fix :heart:

Thanks for the fix! My update got stuck with the following error message. I haven’t made any changes to this template, so I’m not sure what to do? root@ba /var/discourse # ./launcher rebuild mail-receiver Ensuring launcher is up to date Fetching origin Updating Launcher... Updating 46d899f..990519e error: Your local changes to the following files would be overwritten by merge: templates/web.letsencrypt.ssl.template.yml Please commit your changes or stash them before you merge. Aborting failed to update

[image] david: git diff Ah, I did make a change :innocent: I got it to upgrade now, thanks!

You can test whether you’re running the old mail-receiver like this. docker exec mail-receiver bash -c "cat /etc/issue|grep Alpine" If it’s Alpine, it’s the old one. docker exec mail-receiver bash -c "cat /etc/issue|grep 'Debian GNU/Linux 11'" If it’s Debian, it’s the new one.

@david Thanks for this fix! I just ran it and I can see it’s working. :+1: Is there a way to see which emails were not able to be delivered since October 1st? I’ve tried this, but I only see 5 requests (the earliest was received on Nov 26): /var/discourse/launcher enter mail-receiver mailq I also tried looking at the logs, but I only got the warning reported here: [image] Mail-receiver log errors after letsencrypt update Support Continuing the discussion from Self-hosted mail-receiver update following Let's Encrypt root certificate change: After updating mail-receiver to latest ./launcher logs mail-receiver errors out after postfix/postfix-script: warning: symlink leaves directory: /etc/postfix/./makedefs.out Oct 1 06:10:33 postfix/postfix-script[86]: warning: symlink leaves directory: /etc/postfix/./makedefs.outStarting Postfix and doesn’t show any other events (incoming emails, rejected emails, …). I’ve encou…

I think anything which isn’t still in the queue should have been bounced back to the sender. I’m afraid I’m not sure whether the container has any logs which would go back further than what you’ve found.

launcher 7c9b93a9c run_bootstrap() { # Is the image available? # If not, pull it here so the user is aware what's happening. $docker_path history $image >/dev/null 2>&1 || pull_image set_template_info base_image=`cat $config_file | $docker_path run $user_args --rm -i -a stdin -a stdout $image ruby -e \ "require 'yaml'; puts YAML.load(STDIN.readlines.join)['base_image']"` update_pups=`cat $config_file | $docker_path run $user_args --rm -i -a stdin -a stdout $image ruby -e \ "require 'yaml'; puts YAML.load(STDIN.readlines.join)['update_pups']"` if [[ ! X"" = X"$base_image" ]]; then image=$base_image fi Would simply adding pull_image after line 657 resolve the need for explicitly pulling the image before the rebuild? I.e. # If the image being bootstrapped is not the base Discourse image if [[ ! X"" = X"$base_image" ]]; then image=$base_image # Attempt to bring the image up to date pull_image fi This will cause a docker pull $image to always happen during a bootstrap/rebuild of a container with base_image set in its yml file. I don’t think that hurts for mail-receiver if it happens to already be up to date but I’m not sure if there are other situations where that could be a problem.

Yeah, an unconditional pull probably makes sense here. It’s a little strange that it only applies to our main base image at the moment. What do you think @Falco?

Nacho Caballero: Is there a way to see which emails were not able to be delivered since October 1st? I’d be interested to hear a definitive answer to this question :slight_smile:

Self-hosted mail-receiver update following Let's Encrypt root certificate change

Product Support Self-hosting

david (David Taylor) October 1, 2021, 11:55am 3

What happens if you

cd /var/discourse
git diff

Does it show any differences in the web.letsencrypt.ssl.template.yml file?

If so, you can reset them using git reset --hard

Topic		Replies	Views
Let's Encrypt X3 nightmare Product Support	12	1754	October 1, 2021
Mail-receiver log errors after letsencrypt update Product Support	12	1745	December 8, 2021
Mail-receiver loses IP to hostname resolution after recent upgrade and prevents anti-spam measures from working Product Support	2	1048	December 7, 2021
Direct-delivery email certificate error Product Support	6	1155	February 8, 2022
Discourse/mail-receiver:release Docker image appears to be outdated Bug mail-receiver	5	284	September 7, 2026

Self-hosted mail-receiver update following Let's Encrypt root certificate change

Related topics