Назад | Перейти на главную страницу

Эффекты ограничений в Postfix

Мой вопрос похож на вот этот, но я использую более новую версию Postfix, и ответы на мой вопрос не дали ответа.

Я использую сервер Debian Jessie с Postfix 2.11.

Пока я понял, что у Postfix есть такие проверки:

smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_relay_restrictions
smtpd_recipient_restrictions

От чего я читать, Postfix обработает их в указанном порядке.

Теперь мой вопрос: что происходит, когда запись в любом ограничении совпадает с OK? Означает ли это, что Postfix пропустит оставшиеся проверки из этот конкретный *_restriction или он пропустит все *_restrictions все вместе?
Могут ли быть какие-либо другие результаты помимо OK и REJECT или каковы правильные значения для этих проверок?
Какие другие _restrictions используется для, если в большинстве руководств упоминается только smtpd_client_restrictions или smtpd_recipient_restrictions?

Я хочу добиться этого:

Заблокируйте клиентов MTA, которые, как известно, рассылают спам (например, динамические IP-адреса или другие клиенты, перечисленные в черных списках) и / или не соответствуют RFC (например, адрес без FQDN и т. Д.).
В то же время разрешите некоторым клиентам обходить это на основе белого списка
Разрешить только SASL-аутентифицированным клиентам ретранслировать почту на другие серверы и не каждый домен из белого списка
Блокировать клиентов, которые олицетворяют другие серверы (то есть SPF), включая тех, которые ранее были внесены в белый список (другими словами, разрешить серверам из белого списка доставлять только их почту)
Добавьте задержку на новые серверы, чтобы еще больше усилить защиту от спама (Postgrey). Это уже работает достаточно хорошо, и я также создал для этого необходимые белые списки.

Теперь, если вы ответите на вопрос 1 в любом случае, поместив все чеки в одну из *_restrictions упомянутое выше, скорее всего, не поможет, так как белый список, например, переопределит проверку SPF.

Поэтому моя конфигурация выглядит примерно так:

# basic configuration (myorigin, mydomain, etc.)

smtpd_helo_required = yes

smtpd_client_restrictions = check_client_access hash:/etc/postfix/blackwhitelists/whitelisted_client_addresses, 
    check_reverse_client_hostname_access hash:/etc/postfix/blackwhitelists/blacklisted_reverse_hostnames, 
    reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net,
    reject_rbl_client dnsbl.sorbs.net, reject_unknown_client

smtpd_helo_restrictions = permit_sasl_authenticated, permit_mynetworks,
    reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname,
    reject_unknown_helo_hostname, reject_unauth_pipelining

smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks,
    check_sender_access hash:/etc/postfix/blackwhitelists/blacklisted_sender_addresses

smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks,
    reject_unauth_destination

smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks,
    reject_unauth_destination, reject_unauth_pipelining, 
    check_sender_access hash:/etc/postfix/blackwhitelists/whitelisted_sender_addresses, reject_non_fqdn_sender,
    reject_unknown_sender_domain, check_policy_service unix:private/policyd-spf, 
    check_policy_service unix:/var/spool/postfix/postgrey/socket

smtpd_etrn_restrictions = permit_sasl_authenticated, permit_mynetworks, reject

# more basic configuration

Как видите, сейчас многие варианты повторяются, потому что я не уверен, нужны ли они мне и в других ограничениях. В общем, я бы тоже счел это беспорядком.

Я также использую SpamAssassin для почты, которая проходит все эти проверки.

Эти _restrictions применяются к информации, доступной на определенной фазе диалога SMTP, а именно:

smtpd_client_restrictions применяются к начальному подключению (IP / FQDN)
smtpd_helo_restrictions применяются к клиентской команде HELO / EHLO
smtpd_sender_restrictions применяются к команде MAIL FROM
smtpd_recipient_restrictions применяются к команде RCPT TO

smtpd_relay_restrictions контролировать ретрансляцию на сторонние домены.

Все элементы в рамках каждого из этих ограничений оцениваются в том порядке, в котором они указаны, и, если какой-либо элемент соответствует, обработка этой последовательности ограничений останавливается и выполняется указанное действие. Полный список возможных действий доступен в access(5) справочная страница.

Если действие - ПРИНЯТЬ или какой-либо из его синонимов, оценка переходит к набору правил следующего этапа. Если действие - REJECT (или его братья), отправителю возвращается ошибка и дальнейшая обработка не выполняется.

Ваш набор правил выглядит хорошо, но он слишком строгий и подвержен ошибкам - например, DNS-сервер отправителя отключен, и от него не будет приниматься почта, ограничения HELO / EHLO будут запрещать плохо настроенные серверы Exchange и некоторые другие эзотерические почтовые программы и т. д.

Исходя из моего опыта, я бы рекомендовал вместо этого установить его на минимум и заменить все RBL, проверки HELO и обратные проверки демоном службы политики оценки, например postfwd2. Там вы можете точно настроить свою политику, применяемую ко всем этим мелочам, и выполнять различные действия, основанные на комплексе параметров, а не на единственном ударе.