自托管邮件接收器在 Let's Encrypt 根证书变更后更新

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:

28 个赞

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
1 个赞

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

3 个赞

Ah, I did make a change :innocent: I got it to upgrade now, thanks!

2 个赞

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.

7 个赞

@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, 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?

This one should be fixed easily:

4 个赞

@david 感谢您的修复!我刚运行了它,可以看到它正在工作。:+1:

有没有办法查看自 10 月 1 日以来哪些电子邮件未能送达?

我尝试了以下方法,但只看到 5 个请求(最早的请求是在 11 月 26 日收到的):

/var/discourse/launcher enter mail-receiver
mailq

我还尝试查看日志,但只收到了这里报告的警告:

3 个赞

我认为任何尚未进入队列的东西都应该被退回给发件人。恐怕我不确定该容器是否有比您找到的更早的日志。

4 个赞

在第 657 行之后简单地添加 pull_image 是否可以解决在重建之前显式拉取镜像的需要?即:

  # 如果正在引导的镜像不是基础 Discourse 镜像
  if [[ ! X"" = X"$base_image" ]]; then
    image=$base_image
    # 尝试使镜像保持最新
    pull_image
  fi

这将导致在引导/重建具有在其 yml 文件中设置了 base_image 的容器时,始终发生 docker pull $image。我不认为这对 mail-receiver 有什么坏处,即使它碰巧已经是最新的了,但我也不确定是否存在其他可能出现问题的情况。

2 个赞

是的,无条件的 pull 在这里可能是有意义的。目前它只适用于我们的主基础镜像,这有点奇怪。你怎么看 @Falco

2 个赞

我也很想知道这个问题的确切答案 :slight_smile:

1 个赞

我认为您可以通过查询 incoming_emails PostgreSQL 表来查看它。

2 个赞

不幸的是,在相关时间段(2021 年 10 月至 2022 年 2 月)内没有显示任何内容。

邮件接收器容器本身会有任何日志吗?

1 个赞