Получатель почты теряет разрешение IP-адреса на имя хоста после недавнего обновления, что мешает работе анти-спам мер

Поддержка
1

Похоже, что последнее обновление mail-receiver (Self-hosted mail-receiver update following Let's Encrypt root certificate change) больше не преобразует IP-адреса в имена хостов. Это вызывает проблемы с ранее работавшими ограничениями доступа клиента Postfix, которые были включены добавлением следующей строки в файл mail-receiver.yml:

  POSTCONF_smtpd_client_restrictions: 'regexp:/etc/postfix/shared/client_access_regex'

Ниже приведён фрагмент лога mail-receiver, показывающий входящее соединение:

Oct 01 17:38:11 discourse-mail-receiver postfix/master[1]: reload -- version 3.5.6, configuration /etc/postfix
Oct 01 17:41:58 discourse-mail-receiver postfix/smtpd[151]: connect from unknown[167.71.160.115]
Oct 01 17:41:59 discourse-mail-receiver postfix/smtpd[151]: disconnect from unknown[167.71.160.115] ehlo=2 starttls=1 mail=1 quit=1 commands=5

Раньше адрес преобразовывался в имя хоста исходного клиента www11-do.checktls.com[167.71.160.115], теперь же он не разрешается и помечается как unknown[167.71.160.115].

Это вступает в конфликт с записями регулярных выражений в файле client_access_regex, который предназначен для отклонения всех хостов без корректной PTR-записи (это в основном все ретрансляторы спама), а также всех хостов из диапазонов динамических IP (в основном виртуальные хосты и также практически все ретрансляторы спама).

Поскольку ни один IP не преобразуется в имя хоста, ни одно из правил больше не работает. Более того, строка /unknown/ REJECT теперь блокирует все входящие письма. Мне пришлось временно отключить это правило, чтобы вообще возможно было принимать входящие соединения, а все остальные правила стали неактивными из-за проблемы с разрешением. В результате сервер снова стал уязвим для спама (мой форум был залит спамом до внедрения этих правил, а после их включения я больше не помню, чтобы получал спам).

Я не могу вернуться к старой версии как к временному решению (из-за проблем с Let’s Encrypt), а новая версия снова открывает шлюзы для спама. Поэтому я был бы очень благодарен за исправление (я пытался разобраться, как вручную включить разрешение DNS внутри образа Docker, но безуспешно).

Ниже приведён файл client_access_regex для справки, если у кого-то возникают те же повторяющиеся проблемы со спамом и он хочет попробовать его (используйте Customize direct-delivery Postfix configuration для настройки /etc/postfix/shared и mail-receiver.yml):

#  regex dns: ([a-zA-Z0-9]+(-[a-zA-Z0-9]+)*\.)+[a-zA-Z]{2,}
#  regex ip: ((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)
#
#  dyn-ip-dns:
/((\.|-|x)(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){2}((\.|-)[a-zA-Z0-9]+)+\.[a-zA-Z]{2,}/        REJECT
/unknown/                               REJECT
/sample-spam\.domain\.com/              REJECT
2

Я решил эту проблему для другого контейнера. Нужно закомментировать некорректный сертификат, и всё заработает, но я не до конца понимаю, как запустить старый контейнер.

Решение заключается в том, чтобы зайти в новый контейнер и устранить проблему.

3

https://github.com/discourse/mail-receiver/pull/12

@david Это должно исправить обе проблемы, упомянутые в Self-hosted mail-receiver update following Let's Encrypt root certificate change - #6 by md-misko

Пожалуйста, оцените, не создаёт ли вывод postfix из chroot-окружения никаких проблем с безопасностью (по моему мнению, их быть не должно, так как postfix уже изолирован внутри отдельного образа Docker).