# Self-hosted mail-receiver update following Let's Encrypt root certificate change
**URL:** https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924
**Category:** Self-hosting
**Tags:** mail-receiver, letsencrypt
**Created:** [October 1, 2021, 12:10am UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924 "2021-10-01T00:10:43Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [October 1, 2021, 12:10am UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/1 "2021-10-01T00:10:43Z")
This announcement only affects self-hosters who are running [Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver](https://meta.discourse.org/t/direct-delivery-incoming-email-for-self-hosted-sites/49487). 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](https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/). 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
```plaintext
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](https://meta.discourse.org/t/how-to-update-mail-receiver-to-the-release-version/133491).
Sorry for the disruption here! Big thanks to @wlandgraf for initially reporting the issue, and helping us test the fix ❤
---
### Author:  [@bartv](https://meta.discourse.org/u/bartv)
#### Post date: [October 1, 2021, 11:31am UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/2 "2021-10-01T11:31:35Z")
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?
```plaintext
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
```
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [October 1, 2021, 11:55am UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/3 "2021-10-01T11:55:40Z")
What happens if you
```plaintext
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`
---
### Author:  [@bartv](https://meta.discourse.org/u/bartv)
#### Post date: [October 1, 2021, 12:04pm UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/4 "2021-10-01T12:04:33Z")
> [@david](#):
>
> `git diff`
Ah, I _did_ make a change 😇 I got it to upgrade now, thanks!
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [October 1, 2021, 12:43pm UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/5 "2021-10-01T12:43:58Z")
You can test whether you’re running the old `mail-receiver` like this.
```plaintext
docker exec mail-receiver bash -c "cat /etc/issue|grep Alpine"
```
If it’s Alpine, it’s the old one.
```plaintext
docker exec mail-receiver bash -c "cat /etc/issue|grep 'Debian GNU/Linux 11'"
```
If it’s Debian, it’s the new one.
---
### Author:  [@md-misko](https://meta.discourse.org/u/md-misko)
#### Post date: [October 11, 2021, 1:51pm UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/6 "2021-10-11T13:51:45Z")
@david, would you mind having a look at the issues below, the latest update to the mail-receiver removed the ability to implement additional anti-spam measures, which worked wonders in the previous version, and my forum is under increasing spam pressure again due to the last change.
I tried to figure out what the root issue is, but I don’t have deep enough knowledge of postfix to figure it out. I found similar reports (`client=unknown` even when PTR record exists in DNS) regarding [postfix in a chroot jail](https://wiki.archlinux.org/title/Postfix#Postfix_in_a_chroot_jail), so this might have something to do with it. Also, dnsutils seem to be missing from the new mail-receiver Debian image, but installing them still doesn’t fix the issue?
> [@Mail-receiver loses IP to hostname resolution after recent upgrade and prevents anti-spam measures from working](https://meta.discourse.org/t/mail-receiver-loses-ip-to-hostname-resolution-after-recent-upgrade-and-prevents-anti-spam-measures-from-working/205003/1):
>
> It seems that latest [Self-hosted mail-receiver update following Let's Encrypt root certificate change](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/1) mail-receiver update doesn’t resolve IPs to hostnames any more. This causes issues with previously working postfix client access restrictions, enabled by adding the following line to mail-receiver.yml: POSTCONF\_smtpd\_client\_restrictions: 'regexp:/etc/postfix/shared/client\_access\_regex' This is a snippet from the mail-receiver log, showing an inbound connection: Oct 01 17:38:11 discourse-mai…
This one should be fixed easily:
> [@Mail-receiver log errors after letsencrypt update](https://meta.discourse.org/t/mail-receiver-log-errors-after-letsencrypt-update/204938/6):
>
> I believe I figured this one out, there is a maillog\_file line missing in the Dockerfile. Temp fix: added POSTCONF\_maillog\_file: '/dev/stdout' to mail-receiver.yml and rebuilt, but this should probably be fixed in the docker image RUN \>/etc/postfix/main.cf \ + && postconf -e maillog\_file=/dev/stdout \ && postconf -e smtputf8\_enable=no \ ...
---
### Author:  [@Nacho\_Caballero](https://meta.discourse.org/u/Nacho_Caballero)
#### Post date: [November 30, 2021, 7:59am UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/7 "2021-11-30T07:59:50Z")
@david Thanks for this fix! I just ran it and I can see it’s working. 👍
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):
```plaintext
/var/discourse/launcher enter mail-receiver
mailq
```
I also tried looking at the logs, but I only got the warning reported here:
> [@Mail-receiver log errors after letsencrypt update](https://meta.discourse.org/t/mail-receiver-log-errors-after-letsencrypt-update/204938/1):
>
> Continuing the discussion from [Self-hosted mail-receiver update following Let's Encrypt root certificate change](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924): After updating mail-receiver to latest ./launcher logs mail-receiver errors out after postfix/postfix-script: warning: symlink leaves directory: /etc/postfix/./makedefs.out \<20\>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…
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [November 30, 2021, 1:06pm UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/8 "2021-11-30T13:06:18Z")
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.
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [January 13, 2022, 12:02am UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/9 "2022-01-13T00:02:12Z")
>
Would simply adding `pull_image` after line 657 resolve the need for explicitly pulling the image before the rebuild? I.e.
```plaintext
# 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.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [January 13, 2022, 12:49am UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/10 "2022-01-13T00:49:13Z")
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?
---
### Author:  [@Jonathan5](https://meta.discourse.org/u/Jonathan5)
#### Post date: [February 8, 2022, 6:33pm UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/11 "2022-02-08T18:33:44Z")
> [@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 🙂
---
### Author:  [@Nacho\_Caballero](https://meta.discourse.org/u/Nacho_Caballero)
#### Post date: [February 8, 2022, 7:32pm UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/12 "2022-02-08T19:32:51Z")
I think you can see it by querying the incoming\_emails postgres table
---
### Author:  [@Jonathan5](https://meta.discourse.org/u/Jonathan5)
#### Post date: [February 10, 2022, 3:09pm UTC](https://meta.discourse.org/t/self-hosted-mail-receiver-update-following-lets-encrypt-root-certificate-change/204924/13 "2022-02-10T15:09:26Z")
> [@Nacho\_Caballero](#):
>
> incoming\_emails postgres table
Unfortunately that doesn’t show anything in the relevant time period (October 2021 to February 2022).
Would there be any logs in the mail-receiver container itself?