Нидерландах от 390р
Если у вас уже есть Postfix и вы хотите срезать поток мусорных SMTP‑соединений до того, как их увидит smtpd, модуль postscreen — правильный инструмент. Он работает на этапе TCP‑подключения к порту 25, выполняет дешёвые проверки и может принимать решения по DNSBL (включая «backscatter»-ориентированные списки), приветственному баннеру и поведению клиента. Но с DNSBL по «backscatter» легко перестараться и потерять важную почту. Разберёмся, как включить postscreen, аккуратно задействовать такие списки, построить пороги, завести белые списки и безопасно перейти от «наблюдения» к «жёстким блокам».
Что такое backscatter и почему это больно
Backscatter — это нелегитимные уведомления о недоставке (DSN), автоответы отпуска и другие вторичные сообщения, которые отправляются на поддельный или украденный адрес отправителя. Их источник — не исходный спамер, а корректные, но неправильно настроенные почтовые серверы или автоответчики, которые принимают письмо, а затем производят отложенную «откачку» на якобы отправителя. В результате невинные домены получают лавину NDR/DSN и попадают под спам‑фильтры, а каналы транспорта засоряются.
DNSBL‑списки, специализирующиеся на backscatter, заносят в чёрный список именно те сервера, которые замечены в генерации такого шума. Это полезно, но риск ложных срабатываний выше среднего: крупные легитимные SMTP‑хосты могут временно туда попадать из‑за неверных политик NDR или аномалий.
Идея безопасной эксплуатации: «backscatter»-спискам даём малый вес, объединяем их с общими DNSBL и вводим всё через режим мониторинга. Отдельную подачу (587/465) от пользователей не пропускаем через postscreen.
Архитектура Postfix с postscreen
postscreen слушает публичный SMTP‑порт и фильтрует соединения. Клиенты, прошедшие проверки, «переводятся» к обычному smtpd (proxy‑hand‑off). Приватные и аутентифицированные каналы (порт 587 Submission/465 SMTPS) должны миновать postscreen, работая напрямую через smtpd — иначе вы будете мучить легитимных пользователей грейдилеем, баннер‑тестами и т.д. Практическая настройка Submission и TLS разобрана в материале настройка Submission/SMTP AUTH и TLS в Postfix.
Если вы только поднимаете отдельный MX, имеет смысл разместить его на изолированном хосте с выделенным IP. Для такой роли подойдёт облачный VDS.
Подготовка: включаем postscreen правильно
Начнём с того, чтобы повесить postscreen на публичный порт 25, а Submission оставить нетронутым.
# /etc/postfix/master.cf
smtp inet n - n - 1 postscreen
smtpd pass - - n - - smtpd
dnsblog unix - - n - 0 dnsblog
tlsproxy unix - - n - 0 tlsproxy
submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_client_restrictions=permit_sasl_authenticated,rejectДля каналов 465/587 заранее подготовьте актуальный серверный сертификат: для надёжного шифрования и доверия клиентам используйте SSL-сертификаты.
Зададим базовые настройки в main.cf для кэша, приветственного теста и интеграции с DNSBL:
# /etc/postfix/main.cf
# Кэш outcomes, чтобы не повторять проверки для одного клиента
postscreen_cache_map = btree:${data_directory}/postscreen_cache
postscreen_cache_retention_time = 7d
# Приветственный тест (pipelining/pregreet)
postscreen_greet_action = enforce
postscreen_greet_wait = 2s
postscreen_pipelining_action = enforce
postscreen_non_smtp_command_action = enforce
postscreen_bare_newline_action = enforce
# DNSBL базовые параметры (значения будем уточнять ниже)
postscreen_dnsbl_action = ignore
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_ttl = 1h
postscreen_dnsbl_min_ttl = 30m
postscreen_dnsbl_max_ttl = 24h
# Локальные белые/чёрные списки по IP
postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr
# Не забывайте, что правильный reject неизвестных локальных адресатов — ключ к отсутствию вашего собственного backscatter
smtpd_delay_reject = yes
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
smtpd_recipient_restrictions = reject_unauth_destination, reject_unlisted_recipientСоздадим файл для локального доступа и занесём свои доверенные IP/подсети (мониторинг, бэкап‑MX, смарт‑хосты):
# /etc/postfix/postscreen_access.cidr
# Разрешить свои сети и проверенных партнёров
192.0.2.0/24 permit
198.51.100.10 permit
203.0.113.0/25 permit
# Пример жёсткой блокировки
203.0.113.200 rejectПроверим конфигурацию и перезапустим:
postfix check
postfix reload
# или через systemd
systemctl reload postfixDNSBL и «backscatter»: как не перестараться
В postscreen DNSBL‑оценка строится по сумме весов списков. Важные моменты:
- Каждому списку задаём вес. «Агрессивные» списки — выше, «спорные» (backscatter) — ниже.
- Порог
postscreen_dnsbl_threshold— сумма, при достижении которой действие активируется. - На этапе внедрения полезен режим
postscreen_dnsbl_action = ignore— считаем очки, но никого не блокируем, только логи.
Пример настроек с весами. Имена списков условные; подставьте реально используемые DNSBL.
# /etc/postfix/main.cf (фрагмент)
# Внимательно расставим веса: общий DNSBL получает больше, backscatter — минимальный
postscreen_dnsbl_sites =
zen.example.org*2,
bl.example.net*1,
backscatter.example.org*0.5
# Порог блокировки 3: два срабатывания zen (2) + ещё один общий (1) = 3
postscreen_dnsbl_threshold = 3
# На старте не блокируем (ignore), чтобы собрать статистику
postscreen_dnsbl_action = ignoreПочему такой подход безопаснее:
- Backscatter‑лист даёт всего 0.5 очка — сам по себе он почти ничего не решает.
- Требуем подтверждение от одного или двух «более надёжных» списков.
- Порог 3 позволяет фильтровать грубый спам без потерь легитимной корреспонденции.
Никогда не делайте backscatter‑лист единственным критерием блокировки на продуктиве. Даже кратковременные заносы больших почтовых провайдеров в такой список случаются.
Белый порог для «хороших» DNSWL
Если вы добавляете положительные источники (DNSWL), используйте отрицательные веса и белый порог:
# Пример: положительный список с отрицательным весом
postscreen_dnsbl_sites =
zen.example.org*2,
bl.example.net*1,
backscatter.example.org*0.5,
dnswl.example.com*-2
# Если сумма очков <= -2, клиент попадёт в белый кэш postscreen
postscreen_dnsbl_whitelist_threshold = -1DNSWL помогает уменьшить ложные срабатывания, когда серьёзные SMTP‑пулы временно попадают в один из RBL. Но не полагайтесь на них как на универсальную «панацею».
Россия
Нидерланды
От наблюдения к блокировкам: пошаговый план
- Включите
postscreenи DNSBL в режимеignore. Собирайте логи минимум 3–7 дней с полной загрузкой. - Анализируйте попавшие под высокий рейтинг IP и коррелируйте с возможными жалобами пользователей.
- Добавляйте в
postscreen_access.cidrпроверенных корреспондентов (IP пулов партнёров, критичных отправителей), если они «цепляются» из‑за спорных списков. - Понизьте веса «шумных» списков или вовсе исключите их, если дают много ложных позитивов.
- Переключите
postscreen_dnsbl_actionнаenforce, когда доля «шумных» срабатываний станет статистически незначимой. - Оставьте режим
ignoreпри развёртывании новых списков или при больших изменениях порогов.
# Боевой режим: начинаем применять решения
postscreen_dnsbl_action = enforceТарпитинг, greet‑delay и «серая» составляющая
postscreen может намеренно замедлять плохих клиентов. Полезные элементы:
postscreen_greet_wait— заставляет ждать баннер, ловит «pipelining до приветствия».postscreen_pipelining_action,postscreen_non_smtp_command_action,postscreen_bare_newline_action— блокируют клиентов, нарушающих протокол.- Тарпитинг при
enforceзаставляет плохой трафик тратить время, а не ваши ресурсыsmtpd.
Это не серый список в классическом понимании (greylisting по 4‑tuple), но эффект схож: «плохим» и «ленивым» ботам становится дорого ретраить, а «вежливые» MTA легко проходят.
Логи и наблюдаемость
Включив postscreen, привыкните к новым сообщениям в журнале:
journalctl -u postfix -g postscreen -S -2h
# или
grep -i postscreen /var/log/maillogТиповые записи:
postscreen[1245]: CONNECT from [203.0.113.45]:42123 to [203.0.113.10]:25
postscreen[1245]: PREGREET 7 after 1.9 from [203.0.113.45]:42123: pipelined after banner
postscreen[1245]: DNSBL rank 3 for [198.51.100.77]:56789
postscreen[1245]: DISCONNECT [198.51.100.77]:56789Быстрый разбор источников блокировок за день:
grep -i "DNSBL rank" /var/log/maillog | awk -F'[][]' '{print $2}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -50Если вы используете ротацию журналов, дополните анализ через journalctl, чтобы захватить период до ротации.
Минимизация собственного backscatter
Снизить исключения в inbound — хорошо, но ещё важнее не генерировать backscatter самостоятельно:
- Отклоняйте неизвестных получателей на этапе
RCPT TO, а не после приёма письма. Для этого корректно заполнитеlocal_recipient_mapsи оставьтеsmtpd_delay_reject = yes. - Избегайте глобального «accept then bounce» для внешних доменов.
- Автоответчики и vacation‑боты должны отвечать только на валидированные, безопасные входящие сообщения и соблюдать интервалы/политику.
- Отключите или ограничьте механизмы «callout verification», которые сами по себе способны создавать нежелательный трафик.
Для повышения доставляемости проверьте обратные записи и SPF: см. проверка SPF и PTR для Postfix. Если используете форвардинг, чтобы не ломать SPF при переотправке, рассматривайте SRS: SRS для форвардинга в Postfix.
Тонкая настройка: TTL кэша и актуальность списков
Параметры TTL позволяют не переусердствовать с частотой запросов к DNSBL и одновременно быстро «прощать» IP, снятые со списков:
postscreen_dnsbl_ttl— общий TTL кэша результатов.postscreen_dnsbl_min_ttlиpostscreen_dnsbl_max_ttl— нижняя/верхняя границы.
Компромисс: 30–60 минут минимум и до 24 часов максимум. Для backscatter‑списков разумно держать меньший TTL, чтобы оперативно реагировать на очистку IP у крупных провайдеров.
Хорошая практика внедрения backscatter‑списков
- Назначайте им самый малый вес в корзине DNSBL.
- Включайте сначала в режиме наблюдения (
ignore), сравнивайте с жалобами и доставляемостью. - Сегментируйте: публичный MX под postscreen, Submission — только
smtpd. - Ведите собственный CIDR‑белый список для «хрупких» партнёров.
- Регулярно проверяйте логи на предмет новых ложных срабатываний.
Типичные проблемы и решение
Поступают жалобы: «нас не могут отправить»
Соберите детали: ошибка SMTP, время, IP отправителя. Проверьте в журнале DNSBL rank, PREGREET и сопутствующие записи. Если причиной стали только «backscatter»‑срабатывания без подтверждения другими списками — понизьте вес, добавьте отправителя в postscreen_access.cidr и вернитесь к режиму наблюдения на время.
Слишком много отказов по «pipelining»
Убедитесь, что клиенты не являются вашими аутентифицированными пользователями, попавшими на порт 25. Перенастройте MUAs на порт 587/465. Для внешних MTA, которые иногда шумят на приветствии, можно временно смягчить postscreen_greet_wait до 1s.
Падение скорости при всплесках спама
Проверьте размер кэша и его хранение: postscreen_cache_map должен находиться на локальном диске и быть доступен для записи. Пересмотрите веса DNSBL: более агрессивные списки могут ускорить отбрасывание «мусора» раньше.
Проверка конфигурации и безопасный откат
После изменений всегда:
postconf -n | grep -E '^postscreen|^smtpd_'
postfix check
postfix reloadЕсли после включения enforce вырос поток жалоб — немедленно верните postscreen_dnsbl_action = ignore, оставив логи включёнными, и разберите конкретные кейсы с последующим уточнением весов/порогов.
Итоги
Postfix postscreen — мощный фильтр первого рубежа, который разгружает smtpd и повышает доставляемость, если аккуратно настроить DNSBL. «Backscatter»-ориентированные списки полезны как вспомогательный сигнал с низким весом. Начинайте с мониторинга, анализируйте логи, держите белые списки и не забывайте базовые принципы: отклонять неподходящих адресатов на этапе RCPT и не генерировать собственный backscatter. Такой подход даст чистый входящий поток без неожиданных потерь легитимной почты.
