Применение ограничений в Postfix

Сохраняю себе выдержки из документации, ибо эта часть значительно улучшила понимание работы ограничений (smtpd_*_restrictions) работающих на уровне smtpd. В этой заметке не будет правил которые входят в каждый блок ограничений, их достаточно много да и в оригинальной документации, можно быстро найти.

Вот все ограничения в порядке их отработки postfix’ом со значениями по умолчанию и входными данными для проверки:

1. smtpd_client_restrictions (empty) – IP-адрес и (если возможно) доменное имя клиентского компьютера (или другого почт.сервера), который соединяется с сервером postfix для отправки письма.
2. smtpd_helo_restrictions (empty) – имя компьютера и (если возможно) его IP-адрес по имени, переданному в команде HELO/EHLO hostname.
3. smtpd_etrn_restrictions (empty) – то же, что и для 1), 2).
4. smtpd_sender_restrictions (empty) – адрес отправителя, указанный в команде MAIL FROM:.
5. smtpd_recipient_restrictions (permit_mynetworks, reject_unauth_destination) – адрес получателя, указанный в команде RCPT TO:.
6. smtpd_data_restrictions (empty) – то же, что и для 1)…5) +специальные правила (см.далее).
7. smtpd_end_of_data_restrictions (empty) – то же, что и для 1)…6).

Именно так они и срабатывают: (1)->(2)->(3)->…->(7). Каждое ограничение может состоять из набора правил, либо относящихся ТОЛЬКО к данному ограничению, либо ОБЩИХ ПРАВИЛ (generic), либо правил, относящихся к ограничению, стоящему СЛЕВА (ВЫШЕ) в порядке их обработки. Например, в ограничении sender_restrictions допускается использовать правила, предназначенные как собственно для ограничения sender_restrictions, так и, например, для client_restrictions, и helo_restrictions.

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

Все правила по результатам проверки (за исключением правил вида check_.*_access, которые могут и больше – (см.далее!) возвращают либо REJECT, либо OK, либо DUNNO.
Если правило вернуло REJECT, никаких проверок в данном ограничении больше не проводится, и, более того, никаких других проверок в последующих ограничениях не проводится также. Письмо отбрасывается! На самом деле, происходит рассоединение с клиентским компьютером или другим почтовым сервером с выдачей ему соответствующего кода завершения).

Если правило вернуло OK, проверка считается успешной, и все остальные правила В ДАННОМ ОГРАНИЧЕНИИ не проверяются. Происходит переход на следующее ограничение.

Если правило вернуло DUNNO, проверка продолжается в следующем правиле для данного ограничения. Если ВСЕ правила пройдены с результатом DUNNO, считается, что проверка для данного ограничения завершилась УСПЕШНО, и происходит переход на следующее ограничение.

Postfix позволяет полностью контролировать весь сеанс соединения, начиная от момента подключения (smtpd_client_restrictions), вплоть до окончания соединения (smtpd_end_of_data_restrictions, v2.2).

Логично было бы обрывать сеанс чем раньше, тем лучше, экономя входящий трафик. Скажем, сразу после того, как IP-адрес клиентского компьютера (или другого почтового сервера) был вычислен как спамерский (например, через базы rbl). Но… как считают разработчики postfix, существует достаточно большое количество клиентских программ, которые не обращают внимания на сообщения почтового сервера до команды RCPT TO.

Поэтому разработчики предусмотрели специальный параметр, smtpd_delay_reject, включение которого указывает postfix’у отрабатывать весь сеанс, от установления соединения до RCPT TO включительно НЕ ГЛЯДЯ НИ НА КАКИЕ ОГРАНИЧЕНИЯ, и лишь после этого запускать проверки (1)->…->(5).

Побочным эффектом такого поведения является возможность (все таки!:)) в ограничениях, находящихся ЛЕВЕЕ, использовать правила из ограничений, находящихся ПРАВЕЕ, в порядке следования. Однако, сам ПОРЯДОК обработки ограничений при этом ОСТАЕТСЯ ПРЕЖНИМ!
Источник

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.