После включения postscreen сотрудники перестали отправлять почту с телефонов: почему верный пароль не помогает

Утро понедельника, в чате поддержки одно и то же: «почта не отправляется с телефона», «пишет неверный пароль, хотя пароль тот же», «на компьютере в офисе всё уходит». В пятницу вы включили postscreen, чтобы прибить поток спам-ботов на MX, и он честно работает. Только заодно он выключил отправку почты у всех, кто настроен на порт 25 и сидит вне офиса. Ниже — механика отказа до буквы протокола, разбор на живом стенде с логами и цифрами, готовая раскладка портов в master.cf и план переезда людей на 587/465 без потерь. И отдельно — почему ослаблять postscreen ради сотрудников не надо ни в каком виде.

Что именно сломалось: три разных симптома одной причины

Первое, что нужно понять — жалобы будут выглядеть по-разному, и это сбивает с толку. У одного сотрудника почтовик пишет «сервер не поддерживает выбранный способ аутентификации», у второго — «не удалось отправить письмо, повторите позже», у третьего письмо висит в исходящих и уходит через полчаса само. Админ смотрит на это, лезет проверять пароль в Dovecot, видит, что пароль верный, IMAP работает, входящая почта приходит — и уходит в сторону от причины на пару часов.

Причина одна: postscreen встал на TCP 25 и теперь этот порт обслуживает не полноценный smtpd, а встроенный SMTP-движок postscreen. Он умеет ровно одно — отсеять зомби-хосты до того, как на них потратится процесс smtpd. Аутентифицировать клиента он не умеет и не собирается. В мануале postscreen(8) это сказано прямым текстом, первым же предложением раздела ограничений: «This program should not be used on SMTP ports that receive mail from end-user clients (MUAs)». То есть вы применили защиту входящего MX к порту, через который у вас отправляют почту люди.

Разделение здесь не техническая придирка, а базовая архитектура SMTP, зафиксированная в RFC 6409: порт 25 — это релей между почтовыми серверами, порт 587 — submission, отправка письма пользователем с обязательной аутентификацией. RFC 8314 добавляет к этому порт 465 (submissions) с неявным TLS и рекомендует его как предпочтительный для клиентов. Всё, что у вас годами работало «сотрудник шлёт через 25» — это была настройка по инерции с нулевых, которая держалась только потому, что на 25-м стоял обычный smtpd с включённым SASL.

• «Сервер не поддерживает аутентификацию» — postscreen не объявляет AUTH в ответ на EHLO;
• «Повторите позже» / 450 4.3.2 — клиент прошёл проверки после приветствия и получил отказ на RCPT TO;
• письмо уходит с задержкой в 15–60 минут — почтовик сам переподключился с того же IP и попал в временный список;
• «соединение разорвано» — сработал DNSBL-порог, действие drop;
• у части людей всё работает — их IP уже попал во временный список успешно проверенных.

Почему postscreen физически не может обслужить почтовый клиент

У postscreen два набора проверок, и путать их нельзя — от этого зависит, что именно у вас отвалится. Первый набор работает до приветствия 220: postscreen выдерживает паузу postscreen_greet_wait (по умолчанию 6 секунд в нормальном режиме и 2 секунды при перегрузке) и смотрит, не заговорил ли клиент раньше сервера — это тест pregreet, за него отвечает postscreen_greet_action. Сюда же относятся DNSBL-запросы. Второй набор — «тесты после приветствия 220»: pipelining, non-SMTP command, bare newline. Именно они включаются параметрами postscreen_pipelining_enable, postscreen_non_smtp_command_enable и postscreen_bare_newline_enable, по умолчанию все три равны no.

Дальше — цитата, ради которой стоит открыть POSTSCREEN_README: «postscreen(8)'s built-in SMTP engine does not implement the AUTH, XCLIENT, and XFORWARD features. If you need to make these services available on port 25, then do not enable the tests after the 220 server greeting». Читается это так: пока глубокие тесты выключены, postscreen после успешной проверки отдаёт соединение процессу smtpd, и smtpd честно объявляет AUTH — отправка с 25-го порта продолжает работать. Как только вы включили хотя бы один тест после 220, postscreen обязан сам довести SMTP-диалог до конца, а AUTH в его движке нет. Клиент видит EHLO-ответ без строки 250-AUTH и честно сообщает пользователю, что сервер не поддерживает аутентификацию.

Второй механизм добивает тех, кто до AUTH и не дошёл. Клиент, впервые прошедший тесты после 220, письмо в эту сессию не отдаёт: мануал описывает поведение однозначно — такой клиент «will receive a 4XX response to all RCPT TO commands», и только «after the client reconnects, it will be allowed to talk directly to a Postfix SMTP server process». Переподключиться нужно с того же IP-адреса. Для чужого MTA это нормальная жизнь: он поставит письмо в очередь и повторит через несколько минут, максимум вы получите задержку первого письма. Для почтового клиента на телефоне это провал операции: пользователь нажал «отправить», получил красное окно с ошибкой и пошёл писать в поддержку. Retry у мобильных MUA либо отсутствует, либо происходит тогда, когда IP уже сменился на другой — а сменившийся IP означает новую проверку с нуля.

Третий слой — временный список. postscreen ведёт кэш в postscreen_cache_map (до Postfix 3.11 по умолчанию btree:$data_directory/postscreen_cache, начиная с 3.11 — $default_cache_db_type:$data_directory/postscreen_cache), и для адреса из этого списка соединение сразу передаётся процессу smtpd, без всяких тестов. Отсюда самый вредный эффект для диагностики: часть сотрудников не жалуется вообще. Их IP попал в кэш раньше, ttl у тестов длинный — postscreen_pipelining_ttl, postscreen_non_smtp_command_ttl и postscreen_bare_newline_ttl по умолчанию 30 дней, postscreen_greet_ttl — сутки. Поэтому «у Петрова же работает» не опровергает диагноз, а подтверждает его.

• до 220: pregreet (postscreen_greet_action) и DNSBL — AUTH на 25 после них ещё жив;
• после 220: pipelining, non-SMTP command, bare newline — AUTH на 25 умирает;
• первый успешный проход глубоких тестов = 4XX на RCPT TO плюс требование переподключиться с того же IP;
• адрес во временном списке отдаётся smtpd сразу — отсюда «у половины работает».

Отдельная причина: Spamhaus PBL — это список ваших же сотрудников

Допустим, вы прочитали README, глубокие тесты не включали, AUTH на 25 формально работает. Отправка с телефонов всё равно отвалится, и вот почему. В типовой конфигурации postscreen подключают zen.spamhaus.org — это объединённая зона, в которую входит PBL, Policy Block List. PBL по определению содержит диапазоны конечных пользователей: домашние подключения провайдеров, мобильные сети операторов. Смысл списка ровно такой: с этих адресов не должно быть прямых SMTP-подключений к чужому MX, отправка должна идти через submission-сервис провайдера или своей компании.

То есть сотрудник с 4G на телефоне попадает в PBL не по ошибке и не потому, что он спамер, а потому, что он делает ровно то, что PBL призван прекратить: лезет с динамического пользовательского адреса на 25-й порт. С весом zen.spamhaus.org*2 и порогом postscreen_dnsbl_threshold = 2 этого хватает, чтобы сработал postscreen_dnsbl_action. При значении enforce клиент получит отказ, при drop — соединение будет разорвано без объяснений, и в почтовике на телефоне это выглядит как «сервер недоступен».

Мне это нравится тем, что здесь нет спорной части. Это не побочный эффект и не грубость настройки — это проектное поведение всей экосистемы, и обходить его локальными исключениями бессмысленно: те же самые мобильные IP отбиваются по PBL и на чужих серверах. Плюс чисто бытовая деталь: многие мобильные операторы и домашние провайдеры сами режут исходящий TCP 25 у абонентов. Даже если вы героически заставите postscreen пропускать этих клиентов, часть людей всё равно не подключится — трафик не выйдет из сети оператора.

• PBL входит в zen.spamhaus.org и перечисляет конечные пользовательские диапазоны;
• мобильный сотрудник на 25-м порту — ровно тот сценарий, который PBL блокирует по назначению;
• postscreen_dnsbl_action = drop даёт клиенту «сервер недоступен» без внятной ошибки;
• часть операторов режет исходящий 25 самостоятельно, независимо от вашего сервера.

Разбор: ремонтная мастерская «Умелые руки» на 48 рабочих мест, три дня на диагностику и переезд

Стенд условной ремонтной мастерской «Умелые руки»: Debian 12, Postfix 3.7 из репозитория дистрибутива, Dovecot 2.3, rspamd, 48 ящиков в одном домене, свой MX на статическом адресе. Четырнадцать человек постоянно в разъездах — выездные мастера и курьеры, которые возят технику клиентам, у всех iPhone и Android со штатным почтовым клиентом. Настройки в профилях достались по наследству от сервера, который меняли в 2019 году: IMAP 993, SMTP 25 со STARTTLS. Работало годами, потому что на 25-м стоял обычный smtpd с smtpd_sasl_auth_enable = yes.

В пятницу вечером подрядчик включил postscreen по первой попавшейся статье: раскомментировал четыре строки в master.cf и вкатил в main.cf полный набор проверок с действием enforce, включая три глубоких теста. Понедельник начался с восьми обращений. В логе всё было видно сразу, если знать, что искать — вот характерные строки, по которым я и закрыл диагноз за десять минут:

postfix/postscreen[2411]: CONNECT from [203.0.113.45]:51544 to [10.0.0.25]:25
postfix/postscreen[2411]: PASS NEW [203.0.113.45]:51544
postfix/postscreen[2411]: NOQUEUE: reject: RCPT from [203.0.113.45]:51544: 450 4.3.2 Service currently unavailable;
    from=<a.orlova@umelye-ruki.example>, to=<priemka@umelye-ruki.example>, proto=ESMTP, helo=<iPhone>
postfix/postscreen[2411]: DNSBL rank 3 for [198.51.100.77]:39914
postfix/postscreen[2411]: DISCONNECT [198.51.100.77]:39914

Смотрите на связку: PASS NEW и следом 450 на RCPT — это ровно тот сценарий «прошёл тесты, но письмо в эту сессию не отдаст». helo=<iPhone> не оставляет вопросов, кто это. Вторая пара строк — мобильный адрес оператора связи, DNSBL rank 3 при пороге 2, соединение разорвано. За сутки в логе набралось 214 таких отказов от девяти внутренних отправителей. Параллельно постскрин делал ровно то, ради чего его ставили: из 61 400 входящих соединений за сутки до процессов smtpd доходило 8 700, то есть примерно 86 % мусора отсекалось до расхода ресурсов. Отключать это было бы вредительством.

Решение заняло три дня и не потребовало трогать postscreen вообще. В первый день я поднял на сервере submission (587) и submissions (465) со включённым SASL через Dovecot, проверил AUTH и отправку с тестового мобильного профиля, открыл порты на периметре. Во второй разослал людям короткую инструкцию с двумя скриншотами и обзвонил тех пятерых, кто «не понял». На третий выдал на 25-м порту постоянный отказ на попытку аутентификации и убедился по логам, что на 25 больше не приходит ни одного внутреннего отправителя. Итог: жалобы прекратились, фильтрация входящих осталась в полном объёме, отдельным бонусом закрылась старая дыра — раньше подобранный пароль к ящику позволял слать спам через тот же 25-й порт с любого адреса мира.

• было: 25/STARTTLS с SASL для всех, включая мобильных — унаследовано с 2019 года;
• стало: 25 — только MX под postscreen, 587 STARTTLS и 465 implicit TLS — только для аутентифицированных;
• эффект postscreen сохранён: 61 400 соединений в сутки на входе, 8 700 доходит до smtpd;
• трудозатраты: примерно 6 часов работы плюс два дня на обзвон и досылку инструкций.

Правильная раскладка портов: master.cf, который я ставлю

Схема простая и никаких компромиссов не содержит: 25 — MX под postscreen, без AUTH вообще; 587 — submission со STARTTLS и обязательной аутентификацией; 465 — submissions с неявным TLS для тех клиентов, что умеют его лучше. Ниже — блоки из штатного sample master.cf актуальной ветки Postfix (в апстриме они идут закомментированными, нужно снять решётки). Обратите внимание на smtpd_recipient_restrictions=permit_sasl_authenticated,reject в submission-блоках: в текущем sample именно так, при пустом smtpd_relay_restrictions, — это и есть запрет пересылки для кого угодно, кроме аутентифицированных. Строка smtpd_forbid_unauth_pipelining=no тоже взята из sample: на submission она не даёт отбивать почтовые клиенты, которые шлют команды пачкой до аутентификации.

# --- MX на 25: postscreen, AUTH тут не живёт ---
smtp      inet  n       -       n       -       1       postscreen
smtpd     pass  -       -       n       -       -       smtpd
dnsblog   unix  -       -       n       -       0       dnsblog
tlsproxy  unix  -       -       n       -       0       tlsproxy

# --- отправка пользователями: 587 STARTTLS ---
submission inet n       -       n       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_forbid_unauth_pipelining=no
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_client_restrictions=
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_relay_restrictions=
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

# --- отправка пользователями: 465 implicit TLS ---
submissions inet n      -       n       -       -       smtpd
  -o syslog_name=postfix/submissions
  -o smtpd_forbid_unauth_pipelining=no
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_client_restrictions=
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_relay_restrictions=
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

Второй кусок — SASL. Аутентификацию отдаём Dovecot, чтобы пароли жили в одном месте. В main.cf глобально выключаем AUTH и включаем его только в submission-сервисах через -o (что уже сделано выше). Проверьте, что сокет Dovecot действительно лежит внутри chroot Postfix — это классическое место, где всё встаёт: путь в smtpd_sasl_path указывается относительно /var/spool/postfix.

# main.cf
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = no          # глобально выключено, включаем только в submission
smtpd_tls_security_level = may       # для MX: оппортунистический TLS

# dovecot: 10-master.conf
service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

И обязательная проверка после перезапуска. Первая команда показывает, что Postfix реально считал из master.cf (а не то, что вы думаете, что там написали), вторая — что порты слушаются, третья и четвёртая — есть ли AUTH в EHLO-ответе на 587 и на 25. На 25-м не отправляйте EHLO сразу после подключения: postscreen засчитает это как pregreet и в логе появится PREGREET вместо честной проверки. На 587 вы должны увидеть строку 250-AUTH PLAIN LOGIN, на 25 — не должны увидеть её вообще.

postconf -M | egrep '^(smtp|smtpd|submission|submissions|dnsblog|tlsproxy)'
ss -lntp | egrep ':(25|465|587)\b'

# AUTH на submission — должен быть
printf 'EHLO test\r\nQUIT\r\n' | openssl s_client -quiet -starttls smtp -connect mail.example.ru:587

# AUTH на MX — не должно быть. Ждём баннер 220 дольше postscreen_greet_wait,
# иначе мгновенный EHLO сам попадёт под тест pregreet
(sleep 8; printf 'EHLO test\r\n'; sleep 2; printf 'QUIT\r\n') | nc mail.example.ru 25

• 25/tcp: smtp inet → postscreen, плюс служебные smtpd pass, dnsblog и tlsproxy; AUTH глобально выключен;
• 587/tcp: submission, smtpd_tls_security_level=encrypt, smtpd_tls_auth_only=yes, smtpd_sasl_auth_enable=yes;
• 465/tcp: submissions, smtpd_tls_wrappermode=yes, smtpd_sasl_auth_enable=yes;
• в обоих submission-блоках smtpd_recipient_restrictions=permit_sasl_authenticated,reject;
• Dovecot auth-сокет в /var/spool/postfix/private/auth с владельцем postfix;
• проверка: postconf -M, ss -lntp и EHLO на 587 (AUTH есть) и на 25 (AUTH нет).

Как перевести людей на 587 и 465 без крика в чате

Порядок действий у меня всегда один и тот же, и он важнее, чем сама конфигурация. Сначала поднимаем новые порты параллельно со старым — пусть неделю работают оба. Потом переводим людей. И только потом закрываем отправку через 25. Если сделать наоборот, вы получите день простоя отдела продаж и репутацию человека, который «сломал почту», а дальше вам ещё год не дадут ничего менять.

Что раздать людям: адрес сервера, порт 587 с шифрованием STARTTLS или 465 с SSL/TLS, логин — полный адрес ящика, пароль прежний. На iOS путь короткий: Настройки → Приложения → Почта → Учётные записи → нужный ящик → SMTP → Первичный сервер. На Android в Gmail и в родном клиенте — Настройки аккаунта → Настройки сервера исходящей почты. Скриншоты снимите один раз, они экономят половину звонков. Если у вас есть MDM или хотя бы корпоративные профили Apple Configurator — раскатайте новый профиль централизованно, это пять минут вместо двух дней обзвона.

Не забудьте про периметр и про всё, что шлёт почту само: МФУ со сканированием в почту, 1С с рассылкой актов, мониторинг, старый скрипт бэкапа на sendmail, CRM. Эти клиенты жалуются не в чат, а никуда — вы узнаете об их поломке через месяц, когда кто-то спросит, почему не приходят отчёты. Перед закрытием 25-го порта для аутентифицированной отправки прогоните лог за две недели и выпишите все внутренние IP и все адреса отправителей, которые ходили на 25 — список всегда длиннее, чем вы ожидаете.

Финальный шаг: убедиться, что на 25-м порту действительно нельзя отправить письмо наружу с паролем. Это не формальность — пока такая возможность есть, скомпрометированный пароль одного бухгалтера превращает ваш сервер в открытый релей для спама, и вы это заметите по массовому попаданию корпоративной почты в спам у Mail.ru и Яндекса.

• неделя параллельной работы 25 и 587/465 — обязательна;
• инструкция со скриншотами под iOS и Android, а не текст «поменяйте порт»;
• инвентаризация неодушевлённых отправителей: МФУ, 1С, мониторинг, скрипты, CRM;
• выгрузка из лога всех, кто за две недели аутентифицировался на 25;
• закрытие 25-го для отправки — только последним шагом.

Чего делать не надо, и один законный костыль

Самый частый способ «починить» — выключить глубокие тесты после 220, оставив postscreen формально включённым. Формально это работает: AUTH на 25 возвращается. Фактически вы оставляете от postscreen только pregreet и DNSBL, отказываетесь от проверок, которые ловят часть ботов, прошедших мимо чёрных списков, и всё равно упираетесь в PBL. Второй способ — снизить postscreen_dnsbl_threshold до заведомо недостижимого значения или убрать zen.spamhaus.org из postscreen_dnsbl_sites. Это уже прямое вредительство: вы не почините отправку, но потеряете основной фильтр.

Третий способ — повесить postscreen на 587. Не делайте: у его движка нет AUTH ни на каком порту, а поведение «4XX и переподключитесь» для почтового клиента разрушительно, потому что MUA не MTA и очереди у него нет. Четвёртый — занести мобильные подсети операторов в postscreen_access_list. Диапазоны у операторов огромные, динамические и общие с абонентами, чьи телефоны заражены; вы белите ботнет.

Законный костыль ровно один, и он временный. Если переезд занимает несколько дней, а у вас есть сотрудники со статическими адресами (шлюз второго приёмного пункта, домашний статик директора), их можно занести в постоянный разрешающий список. Параметр postscreen_access_list по умолчанию равен permit_mynetworks, добавляем к нему cidr-таблицу. И держите в голове дату, когда вы её удалите.

# main.cf
postscreen_access_list = permit_mynetworks
    cidr:/etc/postfix/postscreen_access.cidr

# /etc/postfix/postscreen_access.cidr — ТОЛЬКО статические адреса, с датой снятия
# до 2026-10-01, второй приёмный пункт мастерской
203.0.113.72/29    permit
# до 2026-10-01, статик директора
198.51.100.40/32    permit

Есть ещё один инструмент, про который мало кто знает: postscreen_allowlist_interfaces (по умолчанию static:all). Он ограничивает список локальных адресов сервера, на которых клиент может получить временный «пропуск». Если у вас MX и submission живут на разных IP одной машины, имеет смысл сузить его до адреса MX, чтобы прохождение проверок на одном интерфейсе не давало автоматического пропуска на другом. В Postfix 3.6 и новее часть параметров переименована в нейтральную терминологию — postscreen_dnsbl_whitelist_threshold стал postscreen_dnsbl_allowlist_threshold, postscreen_blacklist_action — postscreen_denylist_action, старые имена сохранены как синонимы; на актуальной ветке 3.11 (7 сентября 2026 вышла 3.11.7) пишите новые.

И напоследок — конфигурация postscreen, которую я оставляю в бою после того, как отправка людей уехала на submission. Здесь глубокие тесты включены, потому что мешать они уже никому не могут, а порог DNSBL поднят до 3 с весами: одного попадания в spamcop для отказа недостаточно, а zen.spamhaus.org весит 3 и решает сам. Отрицательные веса на dnswl страхуют от ложных срабатываний по крупным легитимным отправителям. Одна оговорка про DNS: публичные зеркала Spamhaus не отвечают на запросы через открытые резолверы вроде 8.8.8.8 и 1.1.1.1, а коммерческое использование сверх лимитов требует бесплатной регистрации в Data Query Service. Если сервер резолвит через публичный DNS, zen молча вернёт код ошибки вместо листинга — ставьте локальный кэширующий резолвер (unbound) прямо на почтовом сервере.

# main.cf — postscreen на MX (25), после переезда клиентов на 587/465
postscreen_access_list = permit_mynetworks
postscreen_denylist_action = drop

postscreen_greet_action = enforce

postscreen_dnsbl_threshold = 3
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites =
    zen.spamhaus.org*3
    bl.spamcop.net*2
    b.barracudacentral.org*2
    list.dnswl.org=127.0.[0..255].1*-2
    list.dnswl.org=127.0.[0..255].2*-4
    list.dnswl.org=127.0.[0..255].3*-6
postscreen_dnsbl_allowlist_threshold = -1

postscreen_pipelining_enable = yes
postscreen_pipelining_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_action = enforce
postscreen_bare_newline_enable = yes
postscreen_bare_newline_action = enforce

Разворачивать это всё лучше поэтапно: сначала все действия в ignore на два-три дня, читаем лог, смотрим, кого бы оно отбило, и только потом переводим в enforce. Команда для быстрой оценки последствий — обычный grep по почтовому логу с группировкой по причинам отказа; если в списке вдруг оказался ваш контрагент или платёжный шлюз, лучше узнать об этом в режиме ignore, а не по звонку директора.

• нельзя: выключать тесты после 220 ради AUTH на 25 — минус часть фильтрации, а PBL никуда не делся;
• нельзя: убирать zen.spamhaus.org или задирать порог — отправку не починит, фильтр убьёт;
• нельзя: вешать postscreen на 587 — там нет и не будет AUTH;
• нельзя: белить мобильные подсети операторов;
• можно временно: cidr-список статических адресов в postscreen_access_list с датой снятия;
• стоит знать: postscreen_allowlist_interfaces сужает интерфейсы, где выдаётся временный пропуск.

Частые вопросы