Postfix postscreen на VDS: защита SMTP от ботов без лишних отказов

Если на VDS крутится собственный почтовый сервер, порт 25 почти сразу начинает видеть мир таким, какой он есть: сканеры, примитивные SMTP-боты, попытки отправить команды до приветствия, подключения с плохой репутацией, повторяющиеся сессии с одних и тех же сетей. Для маленького сервера это неприятно не только из-за спама. Каждое соединение забирает процесс smtpd, память, DNS-запросы, время на TLS и проверки. На пике это превращается в рост задержек, шумные логи и длинную mail queue, хотя реальных писем может быть немного.

postfix postscreen решает именно эту задачу: он становится лёгким фильтром перед полноценным SMTP-демоном Postfix и отсеивает клиентов, которые ведут себя не как нормальные почтовые серверы. Это не антивирус, не контентный антиспам и не замена SPF, DKIM, DMARC или Rspamd. Зато postscreen хорошо справляется с самым дешёвым уровнем защиты: не пускать мусорные SMTP-сессии глубже, чем нужно.

Главная идея postscreen проста: доверенные и уже проверенные клиенты проходят быстро, подозрительные получают протокольные проверки, а очевидные smtp bots отсекаются до запуска обычного smtpd.

В этой инструкции разберём настройку без агрессивных значений. Цель — снизить фоновую нагрузку и шум от SMTP-ботов, но не устроить случайный отказ легитимным отправителям. Особенно аккуратно подойдём к DNSBL, задержке приветствия, портам 587 и 465, логам, очереди и безопасному откату.

Когда postscreen действительно нужен

Postscreen имеет смысл включать на сервере, который принимает входящую почту напрямую из интернета по MX-записи. Типичный пример: домен указывает MX на mail.example.net, а Postfix слушает порт 25 на публичном IPv4 или IPv6-адресе VDS. В такой схеме ваш сервер общается с чужими MTA, и именно на этом участке появляются сканеры и боты.

Если Postfix используется только для исходящей отправки через relayhost или принимает почту только от локальных приложений, postscreen почти ничего не даст. Если все входящие письма сначала проходят через внешний почтовый шлюз, а ваш Postfix принимает только от него, эффективнее ограничить доступ firewall-правилами и mynetworks, чем включать протокольные проверки для всего интернета.

Важно понимать границы инструмента. Postscreen работает до SMTP-диалога с получателями и содержимым письма. Он не анализирует тело, вложения, фишинговые ссылки и DKIM-подписи. Его задача — предварительный отбор клиентов на уровне поведения и репутации IP.

Как postscreen встраивается в Postfix

В классической схеме порт 25 в master.cf обслуживает сервис smtpd. После включения postscreen порт 25 начинает обслуживать процесс postscreen, а реальный smtpd переводится в режим pass: postscreen передаёт ему только тех клиентов, которые прошли первичную проверку.

Это даёт два практических плюса. Во-первых, простые подключения не создают тяжёлую SMTP-сессию сразу. Во-вторых, postscreen ведёт кэш: если нормальный отправитель уже прошёл проверки, его последующие соединения обрабатываются быстрее. На активном почтовом домене это заметно уменьшает повторную работу.

Postscreen должен работать только на MX-порту 25. Порты отправки почты пользователями — 587 submission и 465 submissions — не нужно ставить за postscreen. Там клиенты проходят SMTP AUTH, часто используют другие сценарии подключения, а задержки и DNSBL на этом уровне могут сломать почтовые программы пользователей.

Подготовка: что проверить перед включением

Перед изменениями полезно зафиксировать текущее состояние. Так проще откатиться и понять, действительно ли postscreen улучшил картину. Проверьте версию Postfix, активные параметры, состояние очереди и наличие отдельных сервисов submission.

postconf mail_version
postconf -n
postqueue -p
systemctl status postfix

На Debian и Ubuntu почтовые логи часто лежат в /var/log/mail.log, на RHEL-based системах — в /var/log/maillog, а на современных установках часть событий удобнее смотреть через journald.

grep postfix /var/log/mail.log | tail -n 50
grep postfix /var/log/maillog | tail -n 50
journalctl -u postfix -n 80

Ещё один важный момент — DNS-резолвер на сервере. DNSBL-проверки зависят от быстрых и корректных DNS-ответов. Если резолвер VDS нестабилен, перегружен или иногда возвращает SERVFAIL, агрессивная DNSBL-настройка может дать ложные отказы. Поэтому сначала включаем мягкий режим, смотрим логи и только потом ужесточаем.

Установка и базовая проверка Postfix

Если Postfix уже установлен и принимает почту, этот раздел можно использовать только как контрольный. Команды установки различаются по семействам ОС, но сам postscreen входит в состав Postfix и обычно не требует отдельного пакета.

Debian и Ubuntu

apt update
apt install postfix
systemctl enable --now postfix
postconf mail_version

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux и Fedora

dnf install postfix
systemctl enable --now postfix
postconf mail_version

Если в системе используется другой MTA, например Exim или Sendmail, не включайте Postfix поверх него без миграционного плана. Два почтовых сервера не смогут нормально слушать один и тот же порт 25. Сначала определите текущую роль сервера, сделайте резервную копию конфигов и только затем меняйте MTA.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Включаем postscreen в master.cf

Основное переключение выполняется в /etc/postfix/master.cf. Нужно заменить обработчик порта 25: вместо прямого smtpd порт должен вести на postscreen. Ниже минимальный блок. Важно не дублировать две активные строки smtp inet для одного и того же порта.

smtp      inet  n       -       y       -       1       postscreen
smtpd     pass  -       -       y       -       -       smtpd
dnsblog   unix  -       -       y       -       0       dnsblog
tlsproxy  unix  -       -       y       -       0       tlsproxy

Сервисы dnsblog и tlsproxy нужны postscreen для DNSBL-проверок и корректной работы с TLS в сценариях, где клиент доходит до передачи в smtpd. В большинстве стандартных конфигураций эти строки уже есть в файле, но могут быть закомментированы.

Не меняйте таким же образом submission и smtps, если они есть. Для них обычно остаётся обычный smtpd с параметрами авторизации, TLS и ограничениями для пользователей.

Безопасный старт: сначала наблюдаем, потом блокируем

Самая частая ошибка — сразу включить жёсткие DNSBL и удивиться, что часть легитимной почты начала получать отказы. Лучше запускать postscreen в два этапа. На первом этапе включаем протокольные проверки и DNSBL в режиме наблюдения. На втором, после анализа логов, переводим отдельные действия в enforce.

Для начального режима можно использовать такие параметры в /etc/postfix/main.cf:

postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action = ignore
postscreen_greet_action = ignore
postscreen_greet_wait = 6s
postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_action = ignore
postscreen_pipelining_enable = yes
postscreen_pipelining_action = ignore
postscreen_dnsbl_sites = zen.spamhaus.org*2, bl.spamcop.net
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_action = ignore
postscreen_dnsbl_whitelist_threshold = -1
postscreen_cache_map = btree:$data_directory/postscreen_cache
postscreen_cache_retention_time = 7d

Такой вариант не отказывает клиентам, но пишет в логи, кого postscreen счёл подозрительным. Это хороший режим для первых суток на рабочем сервере: вы увидите реальные источники подключений, совпадения по DNSBL, попытки раннего pipelining и не-SMTP команды.

Задать параметры можно через postconf -e, чтобы не редактировать файл вручную. Каждая команда ниже меняет один параметр.

postconf -e 'postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr'
postconf -e 'postscreen_blacklist_action = ignore'
postconf -e 'postscreen_greet_action = ignore'
postconf -e 'postscreen_greet_wait = 6s'
postconf -e 'postscreen_non_smtp_command_enable = yes'
postconf -e 'postscreen_non_smtp_command_action = ignore'
postconf -e 'postscreen_pipelining_enable = yes'
postconf -e 'postscreen_pipelining_action = ignore'
postconf -e 'postscreen_dnsbl_sites = zen.spamhaus.org*2, bl.spamcop.net'
postconf -e 'postscreen_dnsbl_threshold = 2'
postconf -e 'postscreen_dnsbl_action = ignore'
postconf -e 'postscreen_dnsbl_whitelist_threshold = -1'
postconf -e 'postscreen_cache_map = btree:$data_directory/postscreen_cache'
postconf -e 'postscreen_cache_retention_time = 7d'

После изменения конфигурации проверьте синтаксис и перезагрузите Postfix.

postfix check
systemctl reload postfix
postconf -n | grep postscreen

Белый список для своих узлов

Если у вас есть мониторинг, backup MX, внутренний шлюз, CRM или другой сервер, который регулярно отправляет почту на этот Postfix, добавьте его в отдельный список. Для postscreen удобно использовать CIDR-карту. Она не компилируется через postmap, достаточно создать файл и перезагрузить Postfix.

cat /etc/postfix/postscreen_access.cidr

192.0.2.10/32 permit
203.0.113.0/24 permit
2001:db8:100::/48 permit

Адреса выше — документационные примеры. В реальной конфигурации указывайте только свои доверенные IP и сети. Не добавляйте крупные диапазоны провайдеров целиком, если не понимаете, кто ещё может оттуда подключаться.

postfix check
systemctl reload postfix

Переход к блокировке: какие действия включать

Через сутки-двое наблюдения можно посмотреть, какие проверки стабильно ловят мусор. Обычно безопаснее всего начать с грубых протокольных нарушений: клиент отправляет SMTP-команды до приветствия, говорит не-SMTP, не ждёт ответа сервера. Нормальные MTA так себя вести не должны.

postconf -e 'postscreen_greet_action = enforce'
postconf -e 'postscreen_non_smtp_command_action = enforce'
postconf -e 'postscreen_pipelining_action = enforce'
postfix check
systemctl reload postfix

С DNSBL лучше быть осторожнее. У разных списков разные правила использования, лимиты, качество данных и политика для коммерческой нагрузки. Для небольшого личного или корпоративного домена умеренный порог вроде postscreen_dnsbl_threshold = 2 снижает риск ложного срабатывания: один слабый сигнал ещё не становится отказом, а совпадение с весом или несколькими списками уже влияет на решение.

postconf -e 'postscreen_dnsbl_action = enforce'
postfix check
systemctl reload postfix

Если вы не уверены в DNSBL, оставьте postscreen_dnsbl_action = ignore, но сохраняйте логирование. Даже в таком режиме postscreen полезен за счёт greet, pipelining и кэша. Почта ценит предсказуемость сильнее, чем красивые проценты блокировок.

Postscreen и smtp greylisting: не путайте механики

В админских обсуждениях рядом часто встречаются postfix postscreen и smtp greylisting, но это разные вещи. Greylisting временно отклоняет письмо кодом 4xx и ждёт, что нормальный MTA повторит доставку позже. Многие спам-боты не повторяют, поэтому отваливаются. Postscreen же проверяет поведение клиента до полноценной SMTP-сессии и может пропустить, отклонить или разорвать соединение по своим правилам.

Использовать оба подхода можно, но осторожно. Если у вас уже есть greylisting в Rspamd или policy-сервисе, postscreen лучше оставить на уровне ранней фильтрации ботов. Слишком много временных задержек подряд ухудшает пользовательский опыт: письма подтверждения, одноразовые коды и уведомления могут приходить позже, чем ожидается.

Практичная стратегия для небольшого VDS: postscreen ловит грубых SMTP-ботов на входе, антиспам оценивает содержимое и репутацию дальше, а greylisting включается выборочно, только для сомнительных отправителей.

Как читать логи postscreen

После включения первые минуты стоит смотреть логи почти в реальном времени. Вас интересуют строки с postscreen, dnsblog, результатами DNSBL и сообщениями о нарушениях протокола. На Debian и Ubuntu обычно удобно так:

tail -f /var/log/mail.log | grep postscreen

На RHEL-based системах и Fedora чаще используется /var/log/maillog:

tail -f /var/log/maillog | grep postscreen

Если логи идут в journald, используйте:

journalctl -u postfix -f

Типичная картина после включения — много записей о новых подключениях, DNSBL-ранге, кэшировании результата и отказах по раннему pipelining. Если один крупный легитимный отправитель стабильно попадает под блокировку, не спешите отключать весь postscreen. Сначала выясните причину: DNSBL, greet test, неправильный HELO, проблемы DNS или действительно плохая репутация адреса.

Для дополнительного слоя защиты полезно закрывать повторяющиеся атаки на уровне firewall. Если на сервере есть Dovecot и открыты пользовательские почтовые порты, посмотрите отдельную инструкцию по jail-правилам Fail2ban для Postfix и Dovecot.

Проверка снаружи

Локальная проверка postfix check подтверждает синтаксис, но не показывает, как сервер выглядит извне. Минимально проверьте, что порт 25 доступен, приветствие появляется, STARTTLS работает, а submission-порты не оказались случайно переведены на postscreen.

nc -v mail.example.net 25

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net

При postscreen_greet_wait = 6s приветствие может появиться не мгновенно. Это нормально: часть примитивных smtp bots как раз и отсеивается тем, что не умеет дождаться корректного баннера. Но задержка не должна быть чрезмерной. Значения 5–8 секунд обычно достаточно; ставить десятки секунд ради красивой статистики не стоит.

Для нормальной доставляемости одного postscreen мало: нужны корректные MX, PTR, SPF, DKIM и DMARC. Если вы только собираете почтовый сервер, пригодится разбор про доставляемость Postfix и базовые DNS-записи. Для защищённого SMTP также проверьте сертификат: при необходимости можно подобрать SSL-сертификаты для почтового имени.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Что происходит с mail queue

Postscreen отсекает клиентов до постановки письма в очередь, поэтому он не должен напрямую создавать новые сообщения в mail queue. Если после включения postscreen очередь растёт, причина чаще всего в другом: проблемы доставки наружу, DNS, TLS, неверные маршруты, недоступные получатели, зависшие deferred-сообщения или приложение, которое генерирует слишком много исходящей почты.

Базовые команды для очереди:

mailq
postqueue -p
postqueue -f

postqueue -f заставляет Postfix повторить доставку отложенных писем. Это не лечение причины, а ручной толчок. Если очередь большая, не запускайте его каждые несколько секунд: вы только добавите нагрузки.

Чтобы посмотреть причину задержки конкретного письма, используйте идентификатор из очереди и логи Postfix. Удалять всю очередь массовой очисткой стоит только после полного понимания, что в ней мусор. В рабочей почтовой системе слепая очистка очереди может потерять легитимные письма.

Настройки для разных уровней строгости

Для небольшого домена, где важнее не потерять письма, подойдёт мягкий профиль. Он включает greet и протокольные проверки, а DNSBL оставляет в наблюдении или с высоким порогом.

postscreen_greet_action = enforce
postscreen_greet_wait = 6s
postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_action = enforce
postscreen_pipelining_enable = yes
postscreen_pipelining_action = enforce
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_action = ignore

Для сервера, который регулярно находится под фоновым SMTP-сканированием, можно включить DNSBL-отказы, но только после наблюдения и проверки резолвера. В этом профиле важно иметь белый список для своих шлюзов и мониторинга.

postscreen_greet_action = enforce
postscreen_non_smtp_command_action = enforce
postscreen_pipelining_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*2, bl.spamcop.net
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_action = enforce

Для сервера с чувствительной входящей почтой, например где много клиентов, заявок и регистрационных писем, я бы не начинал с жёсткого DNSBL. Лучше собрать статистику за неделю, посмотреть, какие отправители чаще всего попадают в подозрительные, и уже потом принимать решение.

Частые ошибки при настройке

• Postscreen включили на 587 или 465. Пользовательская отправка должна идти через smtpd с SMTP AUTH, а не через MX-фильтр.
• Сразу поставили агрессивный DNSBL. Один список с ложным срабатыванием может заблокировать важного отправителя. Начинайте с ignore и логов.
• Забыли про backup MX или внутренний шлюз. Свои доверенные узлы лучше явно добавить в postscreen_access_list.
• Путают postscreen с антиспамом по содержимому. Если письма проходят postscreen, это ещё не значит, что они чистые. Дальше нужны обычные проверки SMTP и контента.
• Не смотрят очередь. После любых изменений в почтовом сервере полезно проверить mail queue, но рост очереди не всегда связан с postscreen.
• Нет плана отката. Перед правкой master.cf и main.cf сделайте копию, чтобы вернуть порт 25 к обычному smtpd за минуту.

Быстрый откат, если что-то пошло не так

Если после включения начались массовые жалобы на недоставку, действуйте спокойно. Сначала переведите спорные действия в ignore, перезагрузите Postfix и проверьте логи. Это мягче, чем полностью отключать postscreen.

postconf -e 'postscreen_greet_action = ignore'
postconf -e 'postscreen_non_smtp_command_action = ignore'
postconf -e 'postscreen_pipelining_action = ignore'
postconf -e 'postscreen_dnsbl_action = ignore'
postfix check
systemctl reload postfix

Если нужно полностью вернуть прежнюю схему, восстановите строку smtp inet в master.cf, чтобы порт 25 снова обслуживал smtpd, а строки postscreen-схемы закомментируйте или верните из резервной копии. Затем выполните проверку и reload.

cp /etc/postfix/master.cf.bak /etc/postfix/master.cf
postfix check
systemctl reload postfix

Резервную копию лучше сделать до начала работ:

cp /etc/postfix/master.cf /etc/postfix/master.cf.bak
cp /etc/postfix/main.cf /etc/postfix/main.cf.bak

Мини-чеклист для рабочего VDS

• Postscreen включён только на порту 25, submission-порты остались на обычном smtpd.
• Есть резервные копии main.cf и master.cf.
• Сначала использовался режим наблюдения ignore, затем включались точечные enforce.
• DNSBL настроены с умеренным порогом, а не как единственный безусловный критерий отказа.
• Доверенные шлюзы и мониторинг добавлены в postscreen_access_list.
• После reload проверены логи, порт 25, STARTTLS и mail queue.

Postfix postscreen — один из тех инструментов, которые лучше настраивать не как стену с максимальной высотой, а как аккуратный шлюз. Он снижает шум от smtp bots на VDS, экономит ресурсы и делает логи чище. Но хорошая почтовая система строится слоями: корректные DNS-записи, PTR, SPF, DKIM, DMARC, TLS, антиспам, мониторинг очереди и понятный план отката. Тогда postscreen становится не источником неожиданных отказов, а спокойным первым фильтром на входе.