Обновление саморазмещённого почтового сервера после изменения корневого сертификата Let's Encrypt

Поддержка Самостоятельное хостинг
,
1

Это объявление касается только тех, кто самостоятельно размещает свои сайты и использует Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. Клиенты с управляемым хостингом, а также пользователи, использующие POP3 для входящей почты, не затронуты.

Как вам, вероятно, известно, Let’s Encrypt недавно изменили свой корневой сертификат. Старый корневой сертификат истёк сегодня, что вызвало ряд проблем у устаревших клиентов по всему интернету. Все наши системы в CDCK обновлены и не пострадали от сегодняшнего истечения срока действия. К сожалению, мы упустили общедоступный образ Docker для получения почты, который не обновлялся несколько месяцев.

Это означает, что существующие установки почтового получателя с самостоятельным размещением не смогут доставлять почту на сайты, защищённые Let’s Encrypt.

Мы только что загрузили обновлённую версию в DockerHub, которая включает новый корневой сертификат. Если вы следовали официальным инструкциям по установке, вы можете обновить свою установку, выполнив:

docker pull discourse/mail-receiver:release
cd /var/discourse
./launcher rebuild mail-receiver

Письма, полученные неработающими установками, были временно помещены в очередь на отправляющем сервере. Эти серверы должны периодически пытаться повторно доставить почту, поэтому любые пропущенные письма должны скоро прибыть после обновления образа.

Если после выполнения этих шагов проблемы всё ещё сохраняются, убедитесь, что вы используете версию release почтового получателя. Информацию об этом можно найти в этой теме.

Приносим извинения за возникшие неудобства! Огромная благодарность @wlandgraf за первоначальное сообщение о проблеме и помощь в тестировании исправления :heart:

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
3

Что произойдет, если вы выполните

cd /var/discourse
git diff

Покажет ли это какие-либо различия в файле web.letsencrypt.ssl.template.yml?

Если да, вы можете сбросить их с помощью команды git reset --hard.

4

Ах, я и правда что-то изменил :innocent: Теперь обновление прошло, спасибо!

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, то это новая версия.

6

@david, не могли бы вы взглянуть на проблемы ниже? Последнее обновление mail-receiver устранило возможность внедрения дополнительных мер защиты от спама, которые отлично работали в предыдущей версии, и мой форум снова подвергается всё возрастающему спам-давлению из-за последнего изменения.

Я попытался выяснить корневую причину, но у меня недостаточно глубоких знаний о postfix, чтобы разобраться в этом. Я нашёл похожие сообщения (client=unknown, даже если PTR-запись существует в DNS), касающиеся postfix в chroot-окружении, так что это может быть связано с этим. Кроме того, в новом образе Debian для mail-receiver, похоже, отсутствуют утилиты dnsutils, но их установка всё равно не решает проблему?

Эту проблему, вероятно, можно легко исправить:

7

@david Спасибо за это исправление! Я только что его запустил, и вижу, что всё работает. :+1:

Есть ли способ увидеть, какие письма не удалось доставить с 1 октября?

Я пробовал это сделать, но вижу только 5 запросов (самый ранний получен 26 ноября):

/var/discourse/launcher enter mail-receiver
mailq

Также я попытался посмотреть логи, но получил только предупреждение, о котором сообщается здесь:

8

Я думаю, что всё, что ещё не находится в очереди, должно было быть возвращено отправителю. Боюсь, я не уверен, есть ли в контейнере логи, которые охватывают период раньше того, что вы уже нашли.

9

Поможет ли простое добавление pull_image после строки 657 устранить необходимость явного скачивания образа перед пересборкой? То есть:

  # Если образ, который собирается, не является базовым образом Discourse
  if [[ ! X"" = X"$base_image" ]]; then
    image=$base_image
    # Пытаемся обновить образ до актуальной версии
    pull_image
  fi

Это приведёт к тому, что docker pull $image всегда будет выполняться во время начальной настройки/пересборки контейнера, если в его YAML-файле задан параметр base_image. Я не думаю, что это нанесёт вред для mail-receiver, если образ уже актуален, но не уверен, нет ли других ситуаций, где это может стать проблемой.

10

Да, безусловный pull, вероятно, имеет смысл в данном случае. Немного странно, что сейчас это применяется только к нашему базовому основному образу. Что ты думаешь, @Falco?

11

Мне было бы интересно услышать четкий ответ на этот вопрос :slight_smile:

12

Думаю, вы можете увидеть это, выполнив запрос к таблице incoming_emails в PostgreSQL

13

К сожалению, в указанный период (с октября 2021 по февраль 2022 года) там ничего не отображается.

Могут ли быть какие-либо логи в самом контейнере mail-receiver?