Почтовый сервер на VPS: настройка, безопасность и диагностика

Когда собственный почтовый сервер на VPS имеет смысл, а когда лучше не начинать

Представим WordPress, который отправляет несколько уведомлений о заказах и восстановлении пароля. Нужны ли ему ради этого Dovecot, IMAP, почтовые квоты, webmail, антиспам и резервное копирование пользовательских ящиков? Обычно нет. Для такой задачи полноценный почтовый сервер может создать больше точек отказа, чем решить.

Другая ситуация — компании нужны адреса sales@example.com, support@example.com, несколько доменов, хранение переписки и подключение Outlook или Thunderbird. Здесь уже требуется серверная почтовая инфраструктура: MTA, IMAP, SMTP AUTH, TLS, фильтрация, резервное копирование и мониторинг.

Почта сайта и корпоративная почта — разные задачи

Если приложению нужно только отправлять исходящие сообщения, внешний SMTP relay часто закрывает задачу без локального хранения ящиков. Не появляется IMAP, не нужно обслуживать почтовые аккаунты сотрудников и меньше компонентов приходится мониторить.

Если сервер должен ещё и принимать письма, хранить их и отдавать пользователям, архитектура меняется. Тут уже недостаточно «поставить SMTP»: нужен полный цикл от MX до локального хранилища и обратно.

Почему установка пакетов — только начало

SMTP поднять легко. Добиться стабильной доставки во внешние ящики сложнее. Принимающий сервер видит IP, reverse DNS, имя в EHLO, SPF, DKIM, DMARC, историю отправки и характер трафика. Локальный статус active (running) ничего из этого не подтверждает.

Перед установкой полезно ответить на пять вопросов: нужна ли входящая почта, нужны ли пользовательские ящики, нужен ли IMAP, сколько доменов будет обслуживаться и нужен ли прямой исходящий SMTP. После этого уже понятно, нужен полный mail stack или только надёжный канал отправки.

Какой VPS нужен для почтового сервера и что проверить ещё до установки

Для небольшого почтового сервера на Linux VPS количество CPU-ядер обычно не первая проблема. Гораздо раньше можно упереться в заблокированный TCP/25, невозможность задать PTR, нехватку диска или в неудачную репутацию адреса. Проверять это лучше до переноса домена.

Статический IPv4 и PTR нужно проверить заранее

Для почтового сервера нужен стабильный адрес. На него будет указывать A-запись mail-hostname, с ним будет связан PTR, а внешние системы будут видеть именно этот IP при прямой доставке.

Уточните у провайдера VPS, можно ли изменить reverse DNS. PTR обычно управляется владельцем IP-подсети, а не обычной DNS-панелью домена. Если такой функции в панели нет, её иногда предоставляет поддержка.

Исходящий TCP/25 должен работать

Часть VPS-провайдеров ограничивает исходящий порт 25. Картина в таком случае очень характерная: Postfix принимает письмо от сайта или пользователя, кладёт его в очередь, а дальше доставка упирается в timeout.

Сначала найдите MX тестового домена:

dig MX example.net

Затем с самого VPS проверьте соединение с одним из полученных MX:

nc -vz mx.example.net 25

Соединение установилось — значит, сам TCP/25 по этому маршруту доступен. Теперь уже имеет смысл смотреть SMTP-ответ. Успешный тест localhost:25 доказывает только то, что локальный Postfix слушает порт.

Входящий TCP/25 тоже проверяется снаружи

Для приёма писем недостаточно увидеть локальный LISTEN. Проверку делайте с другой машины в Интернете:

nc -vz mail.example.com 25

Если Postfix слушает 0.0.0.0:25, но внешнее соединение получает timeout, проблема может быть в firewall, security group или фильтрации со стороны провайдера. Если соединение устанавливается и появляется SMTP banner, вход до MTA уже работает.

Сколько RAM и диска потребуется

Оценивать ресурсы лучше не по одной цифре «для почты нужно N ГБ RAM», а по составу стека. Postfix и Dovecot — лишь часть системы. Rspamd, ClamAV, webmail, SQL и контейнеры добавляют собственную память, процессы и I/O.

После запуска базовую картину можно получить за пару минут:

free -h
df -h
df -ih

free -h показывает, не живёт ли сервер постоянно на границе памяти и swap. df -h контролирует свободное место, а df -ih особенно полезен для Maildir: иногда свободные гигабайты ещё есть, но заканчиваются inode из-за огромного количества отдельных файлов.

Размер почтового хранилища смотрите именно там, где оно находится в вашей архитектуре:

du -sh /path/to/mail-storage

Расчёт диска должен учитывать не только текущие квоты пользователей, но и прирост почты, срок хранения, индексы, журналы и резервные копии. Если ящики растут месяцами, именно диск часто становится первым реальным ограничением.

Если Postfix отправляет через IPv6, маршрутов становится два

IPv4 может быть настроен идеально, но MTA выберет IPv6, у которого другой PTR, проблемы с маршрутом или слабая репутация. Тогда тест на IPv4 проходит, а реальное письмо уходит совсем другим путём.

Проверьте, какие адреса есть на сервере:

ip addr

Если IPv6 используется для SMTP, для него нужно отдельно проверить reverse DNS, прямой DNS и фактическую доставку. IPv6 не обязательно отключать. Но считать его «неважным запасным адресом» нельзя, если Postfix реально отправляет через него.

Какой почтовый стек выбрать: Postfix + Dovecot или готовую почтовую платформу

Проблемный почтовый сервер нередко начинается с трёх хороших инструкций: Postfix настроили по одной, Dovecot по другой, DKIM по третьей. Потом выясняется, что в одной схеме пользователи системные, во второй виртуальные, а третья вообще предполагает SQL и другой путь к ключам.

Сначала выбирают архитектуру. Потом уже конфиги.

Что реально нужно каждому сценарию

Postfix и Dovecot решают разные задачи

Postfix работает как MTA: принимает SMTP-соединения, маршрутизирует сообщения, управляет очередью и передаёт почту дальше. Dovecot обычно отвечает за пользовательский доступ по IMAP или POP3, а в некоторых схемах участвует в локальной доставке и аутентификации.

Отдельно могут работать Rspamd или SpamAssassin, DKIM-подписывание, webmail, SQL-база виртуальных пользователей и защита от перебора паролей. Чем больше независимых компонентов, тем важнее понимать, где проходит граница каждого сервиса.

Когда ручной стек удобнее

Postfix + Dovecot хорошо подходят, когда доменов немного, администратор уверенно работает с Linux и нужна прозрачная диагностика. При сбое можно отдельно смотреть Postfix, Dovecot, DNS, фильтр и базу пользователей.

Цена такого контроля — обслуживание. Обновление одного компонента не гарантирует совместимость всей связки, а структура пользователей и путей должна быть задокументирована.

Какие проблемы почтовая панель всё равно не решит

Панель может автоматизировать создание доменов, ящиков, DKIM и сертификатов. Но она не исправит заблокированный TCP/25, плохой PTR, репутацию IP, внешний SMTP reject или ошибочную сетевую маршрутизацию.

После выбора архитектуры администратор должен уметь ответить на простой вопрос: какой компонент отвечает за SMTP, submission, IMAP, DKIM, фильтрацию и базу пользователей. Если это непонятно, первый же сбой превращается в перебор настроек наугад.

Как настроить hostname, A, MX и PTR и проверить имя Postfix в EHLO

A и MX могут выглядеть правильно, а удалённый сервер всё равно увидит VPS как server123.provider.net. Такое бывает после миграции, клонирования VPS или частичной смены hostname. Поэтому проверять нужно не только DNS, но и имя, которым сам Postfix представляется наружу.

Возьмём условный сервер mail.example.com с IPv4 203.0.113.10:

example.com       MX 10 mail.example.com
mail.example.com  A     203.0.113.10
203.0.113.10      PTR   mail.example.com

Проверяем прямой DNS

dig A mail.example.com
dig MX example.com

A-запись должна возвращать IP почтового VPS. MX должен указывать на hostname почтового сервера, а не непосредственно на IP.

Если у домена несколько MX, проверяйте каждый. Один доступный сервер не компенсирует второй, который указывает на старую машину или недоступен по сети.

Проверяем reverse DNS

dig -x 203.0.113.10

Ожидаемый ответ — mail.example.com. Затем имя из PTR разрешаем обратно:

dig A mail.example.com

Если оно возвращает исходный IP, прямое и обратное разрешение согласовано. Это не гарантирует доставляемость само по себе, но убирает одну из типичных причин подозрительного SMTP-профиля.

Проверяем hostname ОС и Postfix отдельно

Сначала смотрим полное имя системы:

hostname -f

Затем активное имя Postfix:

postconf myhostname

И имя, которое SMTP-клиентская часть Postfix может использовать в EHLO:

postconf smtp_helo_name

Если smtp_helo_name явно не задан, это само по себе не ошибка: Postfix может использовать myhostname. Нас интересует итог — наружу должно уходить ожидаемое полное доменное имя, а не старый hostname провайдера.

Типичная картина после миграции: A и PTR уже показывают mail.example.com, а в SMTP-диалоге сервер всё ещё представляется старым именем. Здесь DNS уже почти ни при чём. Проверять нужно конфигурацию MTA.

После смены MX часть почты может идти на старый сервер

DNS меняется не мгновенно для всех resolver. Если миграция выполнена недавно, часть отправителей может ещё использовать старое значение, сохранённое в кеше до истечения TTL.

Поэтому на период миграции старый сервер лучше не выключать сразу, если это допускает схема переноса. Проверяйте MX через несколько независимых resolver и следите за журналами обоих серверов, пока трафик окончательно не перейдёт на новый узел.

Как настроить SPF, DKIM и DMARC и проверить аутентификацию письма

SPF, DKIM и DMARC решают разные задачи. Просто добавить три TXT-записи недостаточно: проверять нужно то, какой результат получает принимающий сервер при обработке конкретного письма.

SPF ограничивает допустимые источники отправки

SPF описывает, какие серверы имеют право отправлять почту для соответствующего envelope sender. Для условного домена, который отправляет только с одного IPv4, структура может выглядеть так:

v=spf1 ip4:203.0.113.10 -all

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

Проверяем опубликованную запись:

dig TXT example.com

Несколько независимых TXT-записей, начинающихся с v=spf1, публиковать не нужно. Такая конфигурация может привести к SPF PermError.

DKIM подтверждает подпись сообщения

Отправляющий сервер подписывает сообщение приватным ключом, а получатель получает публичный ключ из DNS по selector. Схематично запись находится здесь:

selector1._domainkey.example.com

и содержит данные примерно такой структуры:

v=DKIM1; k=rsa; p=PUBLIC_KEY...

Полный публичный ключ здесь не нужен: у каждого сервера он свой.

Проверяем публикацию:

dig TXT selector1._domainkey.example.com

Если selector в DNS существует, но получатель показывает dkim=none, проблема уже может быть не в DNS. Посмотрите исходное письмо: присутствует ли вообще заголовок DKIM-Signature. Если его нет, сообщение не было подписано.

При dkim=fail проверяйте selector, домен d=, опубликованный ключ и то, не меняется ли подписанная часть письма после DKIM-подписи.

DMARC связывает SPF или DKIM с видимым From

DMARC оценивает alignment, а не просто наличие отдельных pass. Базовая мониторинговая запись может иметь такую структуру:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Это тоже пример, а не универсальная политика для копирования. Перед переходом к более строгим quarantine или reject нужно убедиться, что все легитимные источники почты проходят проверку ожидаемым способом.

Запись проверяем так:

dig TXT _dmarc.example.com

Почему SPF=pass и DKIM=pass всё равно могут дать DMARC=fail

Такое возможно, если успешно проверены не те домены, которые должны быть выровнены с видимым From.

Условный сценарий:

From: user@example.com
SPF: pass for bounce@mailer.example.net
DKIM: pass for d=mailer.example.net
DMARC: fail for example.com

Здесь обе отдельные проверки успешны, но они относятся к mailer.example.net. Для диагностики DMARC нужно смотреть, какие именно домены указаны в SPF identity, DKIM d= и видимом From.

Смотрим Authentication-Results, а не только DNS-панель

После отправки тестового письма откройте полные заголовки у получателя. Нас интересуют как минимум Authentication-Results, Received-SPF и DKIM-Signature.

Authentication-Results:
    spf=pass
    dkim=pass
    dmarc=pass

Смотрим не на то, что записано в панели, а на то, что реально получил и проверил внешний сервер. После миграции, смены selector или подключения дополнительного SMTP-провайдера это особенно полезно.

Какие SMTP, submission и IMAP-порты должны быть открыты и зачем нужен TLS

Работа SMTP на порту 25 не означает, что пользователь сможет подключить Outlook или Thunderbird. Межсерверная доставка, отправка авторизованным пользователем и чтение почты обслуживаются разными сервисами.

Сначала смотрим, что сервер действительно слушает:

ss -lntp

Если Dovecot виден только на 127.0.0.1:993, внешний клиент к нему не подключится, даже если firewall разрешает 993. Если нужного порта нет вообще, сетевые правила пока можно не трогать — сначала должен появиться слушающий сервис.

Проверяем сертификат на IMAPS

openssl s_client -connect mail.example.com:993 -servername mail.example.com

Проверьте имя сертификата, срок действия, цепочку и результат верификации. Сертификат должен соответствовать hostname, который пользователи вводят в почтовом клиенте.

Проверяем submission через STARTTLS

openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com

Для implicit TLS на 465:

openssl s_client -connect mail.example.com:465 -servername mail.example.com

Если TLS работает на 993, это ещё не доказывает, что сертификат правильно подключён к Postfix на 587. Каждый сервис проверяется отдельно.

Рабочее правило простое: 25-й порт нужен прежде всего серверу для общения с другими MTA, а пользовательскую отправку лучше отделять на submission. Так проще контролировать AUTH и разбирать проблемы клиентов.

Как проверить, что почтовый VPS не является open relay

Неавторизованный внешний клиент не должен использовать ваш VPS как промежуточный SMTP-сервер между двумя чужими доменами. Если сервер принимает такой relay, его довольно быстро начнут использовать для спама. Отдельно стоит продумать блокировку спама на почтовом сервере.

Сначала смотрим активные relay-настройки Postfix

postconf mynetworks
postconf mydestination
postconf smtpd_relay_restrictions

В зависимости от конфигурации также имеет смысл посмотреть параметры, связанные с разрешением авторизованной отправки и отклонением чужих получателей:

postconf -n | grep -E 'mynetworks|mydestination|smtpd_relay_restrictions|permit_sasl_authenticated|reject_unauth_destination'

Эти строки нельзя заменять на «правильный шаблон» вслепую. Сначала нужно понять текущую схему: какие сети доверенные, какие домены сервер считает своими и где разрешается отправка после SMTP AUTH.

Практический тест open relay выполняется с внешней машины

Проверять нужно хост, который не входит в доверенные сети вашего Postfix. Для собственного сервера можно использовать swaks:

swaks --server mail.example.com \
  --from test@external-one.example \
  --to test@external-two.example

Оба домена в таком тесте должны быть внешними для проверяемого VPS. Ожидаемый результат — отказ в relay до фактической передачи сообщения. Если сервер готов принять чужого отправителя и передать письмо на другой чужой домен без авторизации, конфигурацию нужно исправлять.

Open relay и украденный SMTP-пароль — две разные проблемы

Сервер может идеально отклонять анонимный relay, но всё равно рассылать спам через легальную учётную запись. Если злоумышленник знает пароль пользователя и проходит SMTP AUTH, для Postfix такая сессия выглядит разрешённой.

Поэтому при подозрительной рассылке проверяйте не только relay restrictions, но и sasl_username, IP клиента, отправителя и Queue ID.

Firewall здесь не спасёт. Соединение на разрешённый 587 с правильным паролем выглядит как обычная пользовательская работа.

Почему Gmail, Outlook и другие серверы отклоняют письма или отправляют их в спам

Успешная передача сообщения и попадание во «Входящие» — разные этапы. Сначала удалённый MTA решает, принять ли письмо на SMTP-уровне. После приёма сообщение проходит внутреннюю фильтрацию получателя и может попасть в Inbox, Spam или другую категорию.

Первым делом ищем полный SMTP-ответ

Фраза «Gmail не принимает письма» почти ничего не диагностирует. Нужно выяснить фактический этап: сообщение осталось в локальной очереди, удалённый сервер дал временный отказ, письмо отклонено окончательно или уже принято.

Условные примеры хорошо показывают разницу:

connect to mx.example.net[203.0.113.20]:25: Connection timed out

451 4.7.1 Temporary server error, please try again later

550 5.7.1 Message rejected due to policy

550 5.1.1 Recipient address rejected: User unknown

Timeout ведёт к проверке сети, маршрута и доступности конкретного MX. Ответ 451 обычно оставит письмо в очереди для повторной попытки. Policy reject требует читать именно текст политики, а User unknown указывает уже на проблему адреса получателя, а не PTR вашего VPS.

Один только код 550 почти бесполезен. Текст после него и есть диагностическая часть ответа.

Если у домена несколько MX, проверяйте не один

Домен может публиковать несколько серверов с разными приоритетами. Один MX доступен, второй получает timeout, третий отвечает временной ошибкой. Postfix будет учитывать эту картину при доставке.

Получите полный список:

dig MX example.net

Если проблема воспроизводится только на одном маршруте, это уже совсем другая диагностика, чем полный запрет исходящего TCP/25.

SPF, DKIM и DMARC не гарантируют Inbox

Результаты spf=pass, dkim=pass и dmarc=pass подтверждают доменную аутентификацию, но не дают обязательства положить письмо во «Входящие». Получатель также учитывает репутацию IP и домена, историю отправки, жалобы, характер трафика и само сообщение.

status=sent есть, но письма нет во «Входящих»

status=sent для прямой доставки на MX обычно означает: удалённый SMTP-сервер сообщение принял. Всё. Здесь Postfix свою часть уже выполнил.

Дальше проверяйте:

1. есть ли письмо в Spam;
2. что показывает Authentication-Results;
3. какой envelope sender использовался;
4. совпадает ли ожидаемый домен в From;
5. какой путь виден в заголовках Received;
6. нет ли в сообщении подозрительных URL или доменов;
7. не изменилась ли резко история и интенсивность отправки.

Сравнение двух писем часто полезнее десятка догадок: одного, которое попало в Inbox, и одного, которое ушло в Spam. Сопоставьте Authentication-Results, From, envelope sender, маршрут и текст.

Отсутствие IP в публичном blacklist ничего не гарантирует

RBL полезен как отдельный сигнал. Но крупные принимающие системы используют и собственные репутационные данные. Поэтому «IP нигде не найден, значит с репутацией всё хорошо» — слишком сильный вывод.

Не гадаем по папке Spam. Сначала SMTP-ответ и заголовки, затем уже гипотезы о репутации.

Что делать, если письма застряли в очереди Postfix и не уходят с VPS

Если почтовый клиент показал «Отправлено», это может означать лишь то, что локальный Postfix принял сообщение. До получателя письмо ещё не дошло.

Первый диагностический шаг:

postqueue -p

Альтернатива:

mailq

Для сообщений в очереди видны Queue ID, отправитель, получатели и причины отложенной доставки.

Deferred — состояние, а не диагноз

deferred означает, что Postfix пока не смог завершить доставку и попробует снова. Причины могут быть совершенно разными: DNS lookup failure, timeout, временный 4xx, недоступность relayhost или ошибка аутентификации на внешнем relay.

Поэтому от команды просмотра очереди нужны два ответа: какое сообщение застряло и почему.

Если напрямую не работает, а через relayhost работает

Такой сценарий сильно сужает поиск. Если приложение передаёт письмо локальному Postfix, а Postfix успешно отправляет через внешний relayhost, значит локальный submission и формирование сообщения, скорее всего, работают. Проблема прямой доставки может находиться в TCP/25, DNS-маршруте, исходящем IP или политике получателя.

Напротив, ошибка вида authentication failed у relayhost уже направляет диагностику к учётным данным и конфигурации SMTP-клиента Postfix.

После исправления можно повторить доставку

postqueue -f

Если первичная причина устранена, Postfix повторно обработает очередь. Например, DNS снова разрешается или снята временная сетевая проблема.

Удалять deferred первым действием не нужно. Очередь — симптом, а не причина. Если её очистить, а источник проблемы оставить, она заполнится снова.

Где искать журнал

На Debian/Ubuntu часто используется journal:

journalctl -u postfix

Также может присутствовать:

/var/log/mail.log

На RHEL-подобных системах события могут находиться в journal или:

/var/log/maillog

Путь зависит от дистрибутива и конфигурации журналирования. Сначала найдите реальный источник логов вашего сервера, а затем уже стройте grep-команды.

Как читать логи почтового сервера и проследить одно письмо от приёма до доставки

Самый удобный способ разбирать конкретное письмо в Postfix — идти по Queue ID. Поиск только по адресу отправителя быстро превращается в шум, если с него отправляются десятки сообщений.

Маршрут диагностики одного письма

1. Найдите отправителя или получателя.
2. Определите Queue ID сообщения.
3. Найдите все строки с этим Queue ID.
4. Посмотрите, на какой relay Postfix передавал письмо.
5. Найдите финальный status.
6. Прочитайте полный SMTP-ответ.

Для journal:

journalctl -u postfix

Для текстового журнала:

grep 'QUEUE_ID' /var/log/mail.log

Для уже сжатых ротированных журналов пригодится zgrep.

Что означают status=sent, deferred и bounced

status=sent говорит, что следующий узел доставки вернул успешный результат. Для прямой отправки на MX это обычно означает, что удалённый SMTP принял сообщение.

Но status=sent не означает Inbox. После SMTP-приёма начинается собственная фильтрация получателя.

status=deferred говорит о временной невозможности доставки. Читаем причину и устраняем её либо ждём следующей попытки.

status=bounced означает окончательный отказ для соответствующей доставки.

Условный пример цепочки

postfix/submission/smtpd: ABC123: client=unknown[198.51.100.25], sasl_username=user@example.com
postfix/cleanup: ABC123: message-id=<test@example.com>
postfix/qmgr: ABC123: from=<user@example.com>, nrcpt=1
postfix/smtp: ABC123: to=<recipient@example.net>, relay=mx.example.net[203.0.113.20]:25
postfix/smtp: ABC123: status=sent (250 2.0.0 message accepted)
postfix/qmgr: ABC123: removed

По этим строкам видно, кто авторизовался, какой Queue ID получило сообщение, куда Postfix его передавал и какой итог вернул следующий SMTP-сервер.

У письма должен быть след. Находим Queue ID и идём по нему.

Dovecot проверяем отдельно

journalctl -u dovecot

Для проблем IMAP нас интересуют login failures, пользователь, IP источника и TLS-ошибки. Сам статус active не подтверждает, что конкретный аккаунт может войти в ящик.

Почему Outlook, Thunderbird или телефон не отправляет или не получает почту

Сначала нужно назвать сломанный сервис. Входящая межсерверная доставка может работать идеально, пока Dovecot не принимает логин пользователя. Или наоборот: IMAP работает, а submission на 587 закрыт firewall.

Письма приходят на сервер, но пользователь не может войти

Если MX работает и входящие сообщения появляются в ящике на сервере, DNS приёма уже выполнил свою задачу. Проверяйте IMAP:

ss -lntp
openssl s_client -connect mail.example.com:993 -servername mail.example.com
journalctl -u dovecot

Если TCP и TLS устанавливаются, а Dovecot пишет authentication failed, здесь DNS уже ни при чём. Проверяем логин, пароль и backend, в котором хранятся пользователи.

Почту можно читать, но нельзя отправить

IMAP в этом сценарии работает. Переходим к submission:

openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com

Если соединение и STARTTLS проходят, следующий слой — SMTP AUTH. В журнале Postfix нужно увидеть попытку конкретного пользователя и её результат.

Типичная картина: на 587 пользователь успешно авторизовался, письмо появилось в очереди, но дальше растёт deferred. Значит, проблема уже после submission — смотрим маршрут к MX и SMTP-ответ.

Сертификат правильный, а клиент всё равно ругается

Проверьте, какое имя пользователь указал в настройках. Если сертификат выдан для mail.example.com, а клиент подключается к IP или server.example.com, сертификат может быть полностью валиден, но проверка имени всё равно завершится ошибкой.

Сначала определяем сервис. Потом порт. Потом журнал. Это гораздо быстрее, чем одновременно менять MX, пароль, firewall и TLS.

Как защитить почтовые ящики и найти источник спама на VPS

Одна скомпрометированная учётная запись может за короткое время создать огромную очередь исходящих сообщений, хотя Postfix не будет open relay. Пользователь успешно проходит SMTP AUTH — для сервера это разрешённая отправка.

Какие признаки стоит контролировать

• размер очереди Postfix;
• количество ошибок SMTP AUTH;
• успешные авторизации с необычных IP;
• скорость исходящей отправки;
• число получателей;
• свободное место на диске;
• резкий рост отдельных ящиков.

Главное — смотреть не только абсолютные числа, но и изменение обычного поведения. Для одного ящика сотни сообщений могут быть нормальной рабочей нагрузкой, для другого — очевидной аномалией.

Как понять, какой пользователь начал рассылку

Если очередь внезапно заполнена незнакомыми письмами, сначала сохраните её текущее состояние:

postqueue -p

Берём один Queue ID и ищем его в почтовом журнале:

grep 'QUEUE_ID' /var/log/mail.log

Путь к журналу может быть другим. Нас интересуют строки, где видны sasl_username, client IP, envelope sender и дальнейшее движение этого сообщения.

Условный фрагмент:

postfix/submission/smtpd: XYZ789: client=unknown[198.51.100.77], sasl_username=user@example.com
postfix/qmgr: XYZ789: from=<user@example.com>, nrcpt=35

Теперь уже есть конкретная точка: какая учётная запись авторизовалась, с какого IP и какое сообщение попало в очередь.

Что делать при внезапном росте очереди

1. Не очищать queue сразу.
2. Сохранить текущее состояние очереди и нужные журналы.
3. Взять несколько подозрительных Queue ID.
4. Определить sender и sasl_username.
5. Проверить IP авторизации.
6. Временно заблокировать скомпрометированную учётную запись или её отправку.
7. Сменить пароль и выяснить источник компрометации.
8. Проверить, прекратился ли рост очереди.
9. Только после этого решать, какие накопившиеся сообщения удалять или повторно доставлять.

Очередь очистили, а через пять минут она снова заполнена? Источник рассылки никуда не исчез. Не лечим queue удалением queue.

Rate limits ограничивают ущерб, но не заменяют расследование

Лимитирование числа сообщений или получателей помогает не дать одной учётке мгновенно выдать большой объём трафика. Конкретные лимиты должны соответствовать рабочей модели сервера: почтовый ящик сотрудника и автоматическая система уведомлений ведут себя по-разному.

Fail2ban закрывает только перебор

Fail2ban полезен при повторяющихся неудачных входах. Но правильный пароль создаёт успешную авторизацию, которую нельзя отличить от нормальной работы только по факту входа.

Поэтому защита строится слоями: сложные пароли, ограничение перебора, контроль успешных авторизаций, rate limits и наблюдение за исходящим трафиком.

Репутацию IP потерять легче, чем потом вернуть стабильную доставку. Мониторинг лучше настроить до первого такого инцидента.

Что нужно резервировать на почтовом VPS и как проверить восстановление

После аварии мало вернуть каталог с письмами. Mail server должен снова знать свои домены, пользователей, DKIM-ключи, правила маршрутизации и способ аутентификации. Поэтому резервировать нужно архитектуру, а не один Maildir.

Конфигурация Postfix и Dovecot

Для классической установки как минимум рассматриваются:

/etc/postfix/
/etc/dovecot/

Если используются Rspamd, OpenDKIM или другие отдельные компоненты, их конфигурация тоже должна входить в план резервирования.

Пути могут отличаться в комплексной или контейнерной платформе. Поэтому полезнее не слепо копировать список каталогов из статьи, а один раз задокументировать расположение данных именно своего mail stack.

Почтовое хранилище зависит от выбранной архитектуры

Maildir может находиться в пользовательских home-каталогах, /var/vmail или другом месте, заданном в Dovecot. Сначала определите фактический путь, потом включайте его в backup.

Для Dovecot полезно посмотреть активную конфигурацию:

doveconf -n

Не нужно резервировать случайный /var/mail только потому, что он встречался в старой инструкции, если ваш сервер хранит виртуальные ящики совсем в другом месте.

База пользователей тоже часть почтового сервера

В одном стеке пользователи могут быть системными, в другом — храниться в SQL, LDAP или passwd-file. Если потерять этот backend, сами файлы Maildir ещё не вернут работоспособную почтовую систему.

Для SQL-базы резервную копию создают штатными средствами соответствующей СУБД. Простое копирование живых файлов базы во время работы не стоит считать надёжным логическим backup.

DKIM private key нельзя восстановить из DNS

В DNS опубликован публичный ключ. Приватный DKIM key остаётся на сервере и должен резервироваться безопасно. Если он потерян, можно выпустить новую пару и сменить selector, но старую конфигурацию «вытащить обратно» из TXT-записи нельзя.

По приоритету это отличается от автоматически выпускаемого TLS-сертификата: TLS во многих схемах можно перевыпустить, а DKIM identity после потери приватного ключа придётся менять.

Snapshot VPS и файловый backup решают разные задачи

Snapshot удобен для быстрого отката всей машины. Но восстановить один случайно удалённый ящик из полного snapshot часто неудобно. Файловый или прикладной backup даёт больше точности, но требует понимать связи между Maildir, пользователями и конфигурацией.

Если восстановление ни разу не проверяли, backup completed ещё ничего не доказывает

Минимальный тест восстановления выглядит так:

1. Развернуть копию в отдельной среде.
2. Вернуть конфигурацию Postfix и Dovecot.
3. Восстановить backend пользователей.
4. Найти тестовый ящик и несколько сообщений.
5. Проверить наличие нужного DKIM private key.
6. Запустить сервисы с восстановленной конфигурацией.
7. Проверить IMAP и тестовую доставку без вмешательства в рабочий сервер.

После этого уже можно утверждать, что существует не только резервная копия, но и понятная процедура восстановления.

Как понять, что почтовый сервер на VPS готов к рабочей эксплуатации

Одно доставленное тестовое письмо не подтверждает готовность всей системы. Перед переносом рабочего домена лучше пройти сквозную проверку сети, DNS, SMTP, IMAP, TLS, аутентификации домена, безопасности и резервирования.

Последняя проверка — пройти путь одного письма целиком

Отправьте сообщение через обычный пользовательский сценарий, а не напрямую командой из Postfix. Подключите почтовый клиент к submission, выполните SMTP AUTH и отправьте письмо на внешний домен.

Дальше проверяйте по цепочке:

1. Пользователь успешно подключился к submission.
2. SMTP AUTH прошёл под ожидаемой учётной записью.
3. Postfix принял сообщение и присвоил Queue ID.
4. Postfix разрешил MX домена получателя.
5. VPS установил соединение с удалённым сервером по TCP/25.
6. Удалённый MTA вернул успешный SMTP-ответ.
7. В журнале появился status=sent.
8. У получателя видны ожидаемые SPF, DKIM и DMARC results.
9. Проверено фактическое размещение письма — Inbox или Spam.
10. Ответ на письмо успешно приходит обратно на ваш MX.

Такой тест проверяет не одну службу, а весь маршрут с позиции реального пользователя: submission, аутентификацию, очередь, DNS, сеть, внешний MX и обратную доставку.