Let's Encrypt ルート証明書変更後のセルフホスト型メールレシーバーアップデート

david · 2021 年 10 月 1 日午前 12:10

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

bartv · 2021 年 10 月 1 日午前 11:31

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

david · 2021 年 10 月 1 日午前 11:55

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

bartv · 2021 年 10 月 1 日午後 12:04

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

pfaffman · 2021 年 10 月 1 日午後 12:43

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.

md-misko · 2021 年 10 月 11 日午後 1:51

@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:

Nacho_Caballero · 2021 年 11 月 30 日午前 7:59

@david この修正をありがとうございます！実行したところ、動作していることが確認できました。

10月1日以降に配信できなかったメールを確認する方法はありますか？

これを試しましたが、5件のリクエストしか表示されません（最も古いものは11月26日に受信されました）：

/var/discourse/launcher enter mail-receiver
mailq

ログも確認しましたが、ここで報告されている警告しか得られませんでした：

david · 2021 年 11 月 30 日午後 1:06

キューに残っていないものはすべて送信者にバウンスバックされているはずだと思います。コンテナに、見つかったものよりも古いログがあるかどうかはわかりません。

Simon_Manning · 2022 年 1 月 13 日午前 12:02

github.com/discourse/discourse_docker

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

pull_image を 657 行の後に単純に追加するだけで、再構築の前に明示的にイメージをプルする必要がなくなりますか？つまり、

  # ブートストラップ中のイメージがベースの Discourse イメージではない場合
  if [[ ! X"" = X"$base_image" ]]; then
    image=$base_image
    # イメージを最新の状態にしようと試みる
    pull_image
  fi

これにより、base_image が YAML ファイルで設定されているコンテナのブートストラップ/再構築中に、常に docker pull $image が実行されます。mail-receiver がすでに最新の状態である場合に問題が発生するとは思いませんが、他の状況で問題が発生する可能性があるかどうかはわかりません。

david · 2022 年 1 月 13 日午前 12:49

はい、無条件のpullはおそらくここで理にかなっています。現時点では、私たちのメインベースイメージにのみ適用されるのは少し奇妙です。@Falcoさんはどう思いますか？

Jonathan5 · 2022 年 2 月 8 日午後 6:33

この質問に対する確定的な回答を聞いてみたいです

Nacho_Caballero · 2022 年 2 月 8 日午後 7:32

incoming_emails postgres テーブルをクエリすることで確認できると思います。

Jonathan5 · 2022 年 2 月 10 日午後 3:09

残念ながら、関連する期間（2021年10月から2022年2月）には何も表示されません。

mail-receiver コンテナ自体にログはありますか？

トピック		返信	表示
Let's Encrypt X3 nightmare Support	13	1476	2021 年 10 月 2 日
Mail-receiver log errors after letsencrypt update Support	13	1486	2021 年 12 月 8 日
Mail-receiver loses IP to hostname resolution after recent upgrade and prevents anti-spam measures from working Support	3	930	2021 年 12 月 7 日
Direct-delivery email certificate error Support	7	969	2022 年 3 月 10 日
Update mail-receiver to the release version Sysadmins how-to	8	2971	2020 年 1 月 1 日

Let's Encrypt ルート証明書変更後のセルフホスト型メールレシーバーアップデート

関連トピック