Postfix: исключение из reject_unknown_helo_hostname, когда сервер соответствует регулярному выражению

Содержание

Вопрос или проблема
Ответ или решение
Анализ текущей конфигурации
Решение
Заключение

Вопрос или проблема

Я использую Postfix 3.5.8 и хочу, чтобы определенные серверы, соответствующие регулярному выражению (из их обратного DNS-запроса), были освобождены от проверки неизвестных хостов в их команде HELO.

В данный момент у меня есть этот (упрощенный) набор правил в main.cf:

smtpd_recipient_restrictions = permit_mynetworks,
    reject_non_fqdn_recipient,
    check_recipient_mx_access cidr:/etc/postfix/mx_access.cf,

smtpd_sender_restrictions = permit_mynetworks,
    check_sender_access regexp:/etc/postfix/senderchecks.regexp,
    reject_unknown_helo_hostname,
    reject_unknown_recipient_domain,
    reject_unknown_sender_domain

smtpd_client_restrictions = permit_mynetworks,
    check_client_access cidr:/etc/postfix/allowed_clients.cidr,
    check_client_access regexp:/etc/postfix/locarbl.regexp,
    reject_unknown_client_hostname

Таким образом, глядя только на правила, я вижу, что smtpd_sender_restrictions разрешает отказ в передаче электронной почты от данного сервера с помощью

NOQUEUE: reject: RCPT from mx1.domain.com[20.4.18.2]: 450 4.7.1 <SSVBR0369.invalid.host>: Helo command rejected: Host not found; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<SSVBR0369.invalid.host>

Надеюсь, маскировка IP-адресов и реальных хостов выше не повлияет на интерпретацию результата. В этом случае mx1.domain.com и domain.com являются действительными хостами, но SSVBR0369.invalid.host является недействительным хостом.

Я не хочу добавлять IP-адрес 20.4.18.2 (гипотетический) в свой список mynetworks, так как это открыло бы релей, кроме того, я хотел бы сопоставить сервер по его обратному адресу (например, /.*\.domain\.com$/).

Первое, что я подумал, это добавить это регулярное выражение в /etc/postfix/locarbl.regexp, и это должно было помочь. Не сработало. Правило регулярного выражения, которое проверяет имя хоста, находится в smtpd_client_restrictions, и явное OK там, похоже, не влияет на smtpd_sender_restrictions, возможно, потому что они просто независимы или потому, что последнее ограничение оценивается раньше первого.

Что я пробовал в locarbl.regexp:

/.*\.domain\.com$/ OK

Затем я подумал, что мог бы просто добавить еще одно правило прямо перед reject_unknown_helo_hostname. Ищя альтернативы в smtpd_sender_restrictions документации, я вижу, что все проверки выполняются по команде/заголовку MAIL FROM. Хотя это решило бы актуальную проблему, не было бы гарантии, что кто-то из, скажем, amazonses.aws.com, не сможет использовать это правило. Я не думаю, что это было бы безопасно.

Таким образом, в кратком изложении, что я хотел, это:

Могу ли я освободить данный клиент, подключающийся к моему серверу smptd, от правила smtpd_sender_restrictions > reject_unknown_helo_hostname по совпадению регулярного выражения с его обратным именем хоста?

Ответ или решение

Для решения вашей задачи, связанной с конфигурацией Postfix, необходимо тщательно настроить правила обработки и проверок на входящих соединениях SMTP. Ваша цель – исключить определённые серверы из проверки reject_unknown_helo_hostname, если они соответствуют заданному регулярному выражению (regexp) для их обратного DNS. Давайте разберёмся, как это можно осуществить.

Анализ текущей конфигурации

На основе предоставленной конфигурации вы используете следующие параметры:

smtpd_sender_restrictions: Здесь выполняется проверка отправителей, включая правило reject_unknown_helo_hostname, которое блокирует подключения с недопустимыми значениями HELO.
smtpd_client_restrictions: Здесь вы проверяете клиентов на соответствие определённым правилам.

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

Решение

Для достижения вашей цели можно использовать более гибкий подход, объединив проверки в одном месте. Наиболее подходящим способом будет добавление проверок в секцию smtpd_client_restrictions и использование этой секции для контроля правил smtpd_sender_restrictions.

Добавление проверки в smtpd_client_restrictions:
Включите регулярное выражение, которое будет позволять исключить сервера, соответствующие определённому паттерну. Например:
```
smtpd_client_restrictions = permit_mynetworks,
   check_client_access regexp:/etc/postfix/locarbl.regexp,
   check_client_access regexp:/etc/postfix/client_exempt.regexp,
   reject_unknown_client_hostname
```
В файле client_exempt.regexp добавьте следующее правило:
```
/.*\.domain\.com$/ OK
```
Изменение порядка ограничений:
Несмотря на то, что вы начали с правильного понимания, что smtpd_sender_restrictions блокирует по reject_unknown_helo_hostname, вы можете изменить порядок проверок. Поместите проверку на соответствие вашему регулярному выражению также и в smtpd_sender_restrictions. Это может выглядеть так:
```
smtpd_sender_restrictions = permit_mynetworks,
   check_sender_access regexp:/etc/postfix/senderchecks.regexp,
   reject_unknown_helo_hostname,
   check_sender_access regexp:/etc/postfix/client_exempt.regexp,
   reject_unknown_recipient_domain,
   reject_unknown_sender_domain
```
Перемещение проверок:
Вы можете также рассмотреть возможность переноса проверок reject_unknown_helo_hostname после ваших условий на разрешение по регулярным выражениям. Это позволит сначала отфильтровывать тех клиентов, которые стоит пропустить:
```
smtpd_sender_restrictions = permit_mynetworks,
   check_sender_access regexp:/etc/postfix/senderchecks.regexp,
   check_sender_access regexp:/etc/postfix/client_exempt.regexp,
   reject_unknown_helo_hostname,
   reject_unknown_recipient_domain,
   reject_unknown_sender_domain
```

Заключение

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

Если у вас возникнут дополнительные вопросы по этой настройке, убедительно прошу не стесняться их задавать.