david
2021 年 10 月 1 日午前 12:10
1
このアナウンスは、Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver を実行している自己ホスト環境のみが対象となります。マネージドホスティングの顧客や、受信メールに POP3 を使用している自己ホスト環境は影響を受けません。
ご存知の通り、Let’s Encrypt は最近 ルート証明書を切り替えました 。古いルート証明書は本日有効期限切れとなり、ウェブ上の多くの古いクライアントで問題を引き起こしました。CDCK のすべてのシステムは最新の状態にあり、本日の有効期限切れの影響を受けませんでした。残念ながら、数ヶ月間更新されていなかったパブリックのメール受信用 Docker イメージを見落としていました。
つまり、既存の自己ホスト型 mail-receiver インストールでは、Let’s Encrypt によって保護されたサイトへのメール配信ができなくなります 。
DockerHub に新しいルート証明書を含む更新版をプッシュしました。公式のインストール手順に従っている場合、以下のコマンドを実行することでインストールを更新できます。
docker pull discourse/mail-receiver:release
cd /var/discourse
./launcher rebuild mail-receiver
動作不全のインストールで受信されたメールは、送信サーバーで一時的にキューイングされています。これらのサーバーは定期的に再配送を試みるため、更新後に届かなかったメールもすぐに到着するはずです。
これらの手順を実行しても問題が解決しない場合は、release バージョンの mail-receiver を実行しているか確認してください。詳細については、このトピック をご覧ください。
ご迷惑をおかけして申し訳ありません！この問題を最初に報告し、修正のテストにご協力いただいた @wlandgraf さんに心から感謝します
「いいね！」 28
bartv
2021 年 10 月 1 日午前 11:31
2
修正ありがとうございます！私のアップデートが以下のエラーメッセージで停止してしまいました。このテンプレートに変更を加えていないため、どうすればよいのか分かりません。
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
david
2021 年 10 月 1 日午前 11:55
3
もし以下のコマンドを実行した場合、
cd /var/discourse
git diff
web.letsencrypt.ssl.template.yml ファイルに変更が表示されますか？
表示される場合は、git reset --hard を使用してリセットできます。
「いいね！」 3
bartv
2021 年 10 月 1 日午後 12:04
4
david:
git diff
ああ、確かに変更を加えましたね
「いいね！」 2
pfaffman
2021 年 10 月 1 日午後 12:43
5
mail-receiverが古いバージョンかどうかをテストするには、以下のように実行してください。
docker exec mail-receiver bash -c "cat /etc/issue|grep Alpine"
Alpineが表示されれば、それは古いバージョンです。
docker exec mail-receiver bash -c "cat /etc/issue|grep 'Debian GNU/Linux 11'"
Debianが表示されれば、それは新しいバージョンです。
「いいね！」 7
@david 、以下の問題をご確認いただけますでしょうか。メール受信機能の最新アップデートにより、以前のバージョンで非常に効果的だった追加のスパム対策を実装する機能が削除され、その変更により私のフォーラムが再びスパムの圧力にさらされるようになっています。
根本的な問題を特定しようと試みましたが、Postfixについての深い知識が不足しており、特定できませんでした。類似の報告（DNSにPTRレコードが存在していても client=unknown となるケース）が Postfix の chroot ジェイル に関するものとして見つかっており、これが関連している可能性があります。また、新しいメール受信機能の Debian イメージから dnsutils が欠落しているようですが、それをインストールしても問題は解決しません。
It seems that latest Self-hosted mail-receiver update following Let's Encrypt root certificate change 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…
こちらは容易に修正できるはずです：
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 \
...
「いいね！」 4
@david この修正をありがとうございます！実行したところ、動作していることが確認できました。
10月1日以降に配信できなかったメールを確認する方法はありますか？
これを試しましたが、5件のリクエストしか表示されません（最も古いものは11月26日に受信されました）：
/var/discourse/launcher enter mail-receiver
mailq
ログも確認しましたが、ここで報告されている警告しか得られませんでした：
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
<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…
「いいね！」 3
david
2021 年 11 月 30 日午後 1:06
8
キューに残っていないものはすべて送信者にバウンスバックされているはずだと思います。コンテナに、見つかったものよりも古いログがあるかどうかはわかりません。
「いいね！」 4
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 がすでに最新の状態である場合に問題が発生するとは思いませんが、他の状況で問題が発生する可能性があるかどうかはわかりません。
「いいね！」 2
david
2022 年 1 月 13 日午前 12:49
10
はい、無条件のpullはおそらくここで理にかなっています。現時点では、私たちのメインベースイメージにのみ適用されるのは少し奇妙です。@Falcoさんはどう思いますか ？
「いいね！」 2
incoming_emails postgres テーブルをクエリすることで確認できると思います。
「いいね！」 2
残念ながら、関連する期間（2021年10月から2022年2月）には何も表示されません。
mail-receiver コンテナ自体にログはありますか？
「いいね！」 1
無事にアップグレードできました。ありがとうございます！
