Эксплуатация iRedMail: бэкапы, антиспам, мониторинг и обновления — регламент, по которому мы обслуживаем почту клиентов годами

Почта — сервис, который нельзя «поставить и забыть»

Меня зовут Евгений Семёнов, я технический директор ITfresh. Это третья практическая статья серии про iRedMail: мы уже развернули сервер за вечер и переехали на него без потери писем. Сегодня — о том, о чём молчат установочные гайды: что происходит дальше. Установка — это 10% жизни почтового сервера; остальные 90% — эксплуатация, и именно на ней сыплются самостоятельные внедрения.

За годы обслуживания клиентских серверов я видел три типовые причины смерти почтовой системы, и ни одна не связана с качеством софта:

• Переполненный диск. Почта не удаляется никогда, /var/vmail растёт монотонно, и в один день Postfix начинает отвечать отправителям «4xx, попробуйте позже». Самое коварное — снаружи это выглядит как «письма стали пропадать», а не как авария.
• Протухший сертификат. Автопродление Let's Encrypt молча сломалось три месяца назад, и в понедельник утром весь офис видит ошибки подключения в Outlook.
• Взломанный ящик и блэклисты. Пароль «Лето2024» утёк, через ящик за ночь ушло сто тысяч спам-писем, IP сервера — во всех чёрных списках, и легальная почта компании больше никуда не доходит.

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

Бэкапы: что, куда и как проверяем

Слой 1: база данных — встроенные скрипты

iRedMail приносит с собой готовый скрипт /var/vmail/backup/backup_mysql.sh, который инсталлятор уже повесил в крон рута: ежедневные дампы всех служебных баз — vmail с учётками и алиасами, базы Roundcube, SOGo, amavisd. Проверьте, что задание на месте (crontab -l) и что дампы реально появляются. Важно понимать, чего этот скрипт не бэкапит: сами письма и конфигурацию сервисов. База — это «кто существует и куда пересылать», но не «что лежит в ящиках».

Слой 2: /var/vmail — инкременты наружу

Письма живут в /var/vmail, и это главный объём. Наш инструмент — borg: дедупликация, инкременты, шифрование на стороне источника. Репозиторий — только на внешнем хранилище: соседний VPS, storage-box хостера, сервер в офисе клиента. Бэкап на том же диске, что и maildir, — это не бэкап, а самообман: диск умирает вместе со «страховкой». Типовое задание из нашего крона:

#!/bin/bash
# /etc/cron.daily/backup-vmail — borg-инкремент почты на внешнее хранилище
export BORG_PASSPHRASE='из-менеджера-паролей'
borg create --compression zstd \
  ssh://backup@storage.example.net/./mail-repo::vmail-{now:%Y-%m-%d} /var/vmail \
  --exclude '*/tmp/*'
borg prune ssh://backup@storage.example.net/./mail-repo \
  --keep-daily 14 --keep-weekly 8 --keep-monthly 6

Дампы БД из слоя 1 лежат внутри /var/vmail/backup — то есть уезжают наружу этим же заданием, что удобно.

Слой 3: конфиги — в git

/etc/postfix, /etc/dovecot, /etc/nginx, /etc/amavis, /etc/fail2ban, /etc/iredapd — всё, что мы правили руками. Мы держим /etc под etckeeper: каждое изменение конфигурации — коммит с комментарием. Это не только бэкап, но и история: через год видно, что и зачем меняли, а откат неудачной правки — git revert.

Правило: бэкап без тестового восстановления не существует

Раз в квартал мы восстанавливаем один ящик из бэкапа на стенд и проверяем, что письма открываются. Звучит занудно, пока не узнаёшь, сколько компаний обнаружили пустые архивы только в день аварии. Процедура на 20 минут: borg extract нужного maildir во временный каталог, поднять на стенде Dovecot или просто проверить целостность писем. В журнал обслуживания — отметка с датой.

Сайзинг хранилища

Наша формула: объём хранилища бэкапов = 2 × текущий объём /var/vmail — этого хватает на 30 дней ежедневных инкрементов с месячной ретенцией даже с учётом роста, потому что borg дедуплицирует, а почта меняется медленно. Пересматриваем раз в полгода вместе с прогнозом роста диска самого сервера.

Антиспам под российские реалии

Небольшая поправка к распространённому заблуждению: в отличие от mailcow с его Rspamd, iRedMail в стандартной поставке использует классическую связку Amavisd + SpamAssassin + ClamAV. Проект обсуждает переход на Rspamd не первый год, но по состоянию на версию 1.8.4 его в поставке нет. Так что тюнингуем то, что есть, — и оно, к слову, после настройки работает достойно.

Обучение байесовского фильтра

SpamAssassin из коробки ловит очевидный спам по правилам, но по-настоящему точным становится после обучения на реальной почте конкретной компании. Ручное обучение — команды sa-learn --spam и sa-learn --ham по каталогам с образцами. Наша схема — автоматизация через папку «Спам»: пользователи перетаскивают мусор в Junk, ночной крон скармливает содержимое Junk-папок в sa-learn как спам, а свежие письма из «Входящих» давно живущих ящиков — как ham. Через две-три недели такого цикла процент ложных срабатываний падает до единичных случаев в месяц. Ключевой момент — обучать нужно на своей почте: русскоязычный деловой спам («коммерческое предложение», «сверка взаиморасчётов» с трояном) сильно отличается от англоязычных выборок, на которых росли стандартные правила.

Пороги: бухгалтерия важнее чистоты

Решения принимает Amavisd по баллам SpamAssassin, и пороги настраиваются в /etc/amavis/conf.d/50-user (переменные $sa_tag2_level_deflt — с какого балла письмо помечается как спам, и $sa_kill_level_deflt — с какого отклоняется). Здесь у нас принципиальная позиция для клиентского сегмента: ложноположительное срабатывание хуже пропущенного спама. Бухгалтерия ждёт письма от контрагентов, чьи почтовые серверы настроены криво — без SPF, с битым DKIM, с IP из динамических диапазонов. Поэтому порог «пометить как спам» держим умеренным (письмо уедет в Junk, но останется доступным), а порог жёсткого отклонения — высоким, чтобы сервер молча не выбрасывал деньги клиента. Раз в неделю на новых серверах просматриваем кварантин и Junk на предмет ложных срабатываний — это входит в регламент.

Белые списки: по серверу, а не по From

Когда важный контрагент стабильно падает в спам, соблазн — «внести его адрес в белый список». Вносить по заголовку From нельзя: этот заголовок подделывается одной строкой, и вайтлист по From превращается в приглашение для фишинга «от имени вашего же контрагента» — ровно те письма, которые обязаны проверяться строже всех. Правильные варианты: белый список по IP отправляющего сервера в политиках Amavisd, либо снижение балла для писем, прошедших SPF+DKIM конкретного домена. А лучший вариант — честно сказать контрагенту, что у его почтовика нет SPF-записи: пару раз такие письма от нас реально приводили чужую почту в порядок.

Защита от брутфорса и взлома ящиков

Fail2ban в iRedMail работает из коробки: jail-ы postfix (SASL-аутентификация SMTP), dovecot (IMAP/POP3), roundcube и sogo (веб-входы) банят IP после нескольких неверных паролей. Дефолты мы ужесточаем: maxretry снижаем до 3–4, bantime поднимаем до часов — легитимный пользователь ошибается пароль дважды, боты — сотни раз. После правок в /etc/fail2ban/jail.d — systemctl restart fail2ban и контроль: fail2ban-client status dovecot на типовом сервере показывает десятки забаненных IP ежедневно, и это норма.

Но Fail2ban не спасает от главного сценария — утёкшего пароля: фишинговая страница «войдите в почту заново», пароль из слитой базы другого сервиса, стикер на мониторе. Признаки взлома, которые видно в мониторинге раньше, чем прилетят жалобы: резкий рост очереди (mailq показывает сотни писем на чужие домены), всплеск исходящего трафика ночью, жалобы «нам вернулось письмо, которое мы не отправляли». Наш регламент реакции — по минутам, потому что каждая минута спама стоит репутации IP:

1. Заблокировать ящик (в iRedAdmin или UPDATE mailbox SET active=0 ...) и сменить пароль.
2. Вычистить очередь от спама: посмотреть postqueue -p, снести залежи postsuper -d ALL deferred (если легитимных писем в очереди нет) или выборочно по ID.
3. Проверить, не включена ли в ящике пересылка на внешний адрес — злоумышленники любят оставлять её «на память».
4. Проверить IP по основным DNSBL и запустить delisting: у Spamhaus и Barracuda есть формы запроса на исключение, обычно сутки-двое.
5. Разобрать, откуда утёк пароль, и рассказать команде клиента — без этого пункт 1 повторится через месяц.

Профилактика дешевле: политика паролей от 12 символов из генератора, и — наша фирменная страховка — лимит исходящих для новых и рядовых ящиков через throttling-политики iRedAPD (например, не больше 200–500 писем в сутки с ящика). Легитимному сотруднику лимита не заметить, а взломанный ящик упрётся в потолок на первой сотне писем вместо ста тысяч — и вы узнаете о взломе из алерта, а не из блэклиста.

Мониторинг: что мы алертим

Минимальный набор метрик, без которых почтовый сервер живёт «до первого сюрприза»:

Проверка DNSBL — это простой крон с dig: перевёрнутый IP запрашивается в зонах zen.spamhaus.org и b.barracudacentral.org, любой ответ — повод для алерта:

#!/bin/bash
# ip 1.2.3.4 -> 4.3.2.1; ответ из зоны = IP в списке
REV=4.3.2.1
for bl in zen.spamhaus.org b.barracudacentral.org; do
  dig +short ${REV}.${bl} | grep -q '^127\.' && echo "ALERT: listed in ${bl}"
done

Во что заворачивать проверки — вопрос масштаба. Для клиентов, где мы обслуживаем всю инфраструктуру, почтовый сервер подключается к общему Zabbix со стандартным шаблоном Linux плюс перечисленные пользовательские проверки. Для одиночного сервера городить систему мониторинга избыточно — хватает крон-скриптов с отправкой алертов в Telegram-бота: полчаса на настройку, годы спокойствия. Важен не инструмент, а принцип: о каждой из шести строк таблицы вы должны узнавать из алерта, а не от пользователей.

Обновления: ОС, компоненты, сам iRedMail

Security-патчи ОС — автоматом

На Debian ставим unattended-upgrades с профилем security: ночные обновления безопасности прилетают сами, и это безопасно — в стабильном Debian security-патчи не меняют поведение пакетов. Единственная тонкость: обновления ядра требуют перезагрузки, поэтому раз в месяц смотрим на наличие /var/run/reboot-required и планово перезагружаем сервер в нерабочее время.

Минорные обновления компонентов — спокойно

Postfix, Dovecot, Amavisd, Nginx обновляются штатным apt upgrade в рамках релиза Debian — конфиги iRedMail это переживают без проблем, мы делаем это ежемесячно в план-графике.

Апгрейд iRedMail между версиями — только руками

А вот сам iRedMail командой «обновить всё» не обновляется — и это осознанная позиция проекта. Для каждого перехода (1.8.3 → 1.8.4 и т.д.) публикуется официальный upgrade-туториал: пошаговый список правок конфигов и SQL-миграций. Пропускать версии нельзя — с 1.7 на 1.8.4 идём последовательно через каждый промежуточный туториал. Наш регламент апгрейда: снапшот VPS → прогон процедуры на стенде-клоне → окно в выходной день → апгрейд на проде по своему же конспекту → смоук-тест (отправка/приём, DKIM, вход в веб-клиенты). Звучит тяжеловесно, но реальная трудоёмкость перехода на соседнюю версию — час-полтора, а снапшот превращает худший сценарий из аварии в «откатились и думаем».

Апгрейд дистрибутива — иногда проще переехать

Когда до конца поддержки Debian остаётся полгода, есть два пути: официальная процедура апгрейда ОС под iRedMail (она существует и работает) — или свежий сервер на актуальном Debian с переносом почты через imapsync по нашему же регламенту миграции. Для серверов, которые прожили 4–5 лет и накопили слой ручных правок, мы чаще выбираем переезд: получаем чистую актуальную систему, а заодно — генеральную уборку от «временных» костылей, которые пережили трёх админов.

Квоты и дисковое хозяйство

Диск — единственный ресурс почтового сервера, который заканчивается гарантированно. Контроль роста — в еженедельном регламенте: df -h /var/vmail плюс поиск самых тяжёлых ящиков средствами Dovecot:

# топ-10 ящиков по занятому месту
doveadm quota get -A 2>/dev/null | sort -k3 -n -r | head

# либо по факту на диске:
du -sh /var/vmail/vmail1/company.ru/*/*/* 2>/dev/null | sort -h -r | head

Квоты в бесплатной iRedAdmin через интерфейс не выставляются — но прекрасно живут в SQL (значение в мегабайтах, 0 — безлимит):

UPDATE vmail.mailbox SET quota = 10240 WHERE username = 'buh@company.ru';
UPDATE vmail.mailbox SET quota = 5120  WHERE domain = 'company.ru' AND quota = 0;

Dovecot предупредит пользователя письмом при заполнении ящика — сотрудник сам почистит рассылки, и это работает лучше любых напоминаний от админа. Для ящиков-архивов («сюда падают копии всех счетов с 2019 года») наша политика: переписка старше трёх лет выгружается в архивные файлы на файловый сервер клиента и удаляется с почтового — почтовый сервер не файловая помойка, и его бэкап не обязан весить терабайт.

Типовые инциденты и наши нормативы

Таблица, которую мы даём молодым инженерам на сопровождении почты, — «симптом → вероятная причина → куда смотреть → норматив решения»:

Реальный кейс в тему: у клиента «пропали письма от банка». В maillog — банк честно стучится, но его сервер не проходит проверку, потому что на стороне банка DKIM-подпись била по несуществующему селектору. Письмо с разбором ушло в техподдержку банка, через два дня селектор починили. Мораль: maillog отвечает почти на любой вопрос «где письмо», надо только уметь его спросить — grep адрес /var/log/mail.log покрывает 90% обращений.

Безопасность по периметру

Финальный слой регламента — то, что настраивается один раз и проверяется при каждом квартальном аудите:

• Фаервол-минимум. Наружу открыты только 25, 587, 993, 443 (и 80 для продления сертификата). Всё служебное — админ-панель iRedAdmin, netdata, phpMyAdmin, если ставили, — закрыто на офисные IP или доступно только через SSH-туннель. Порт 110/995 (POP3) закрыт, если протокол не используется.
• SSH только по ключам, PasswordAuthentication no, root-вход по ключу или через sudo-пользователя. Банально, но именно SSH с паролем — второй по популярности вектор после утёкших почтовых паролей.
• TLS-политики. Проверяем, что Postfix и Dovecot не принимают TLS ниже 1.2 — старые протоколы нужны только древним МФУ, а для них есть локальный relay (писал об этом в статье про миграцию). Грейды проверяем внешними сканерами типа testssl.sh при аудите.
• Приватность заголовков. Postfix по умолчанию вписывает в Received IP-адрес отправившего клиента — то есть внешний IP офиса или домашний адрес директора путешествует в каждом письме. Для клиентов, которым это важно, настраиваем очистку клиентских заголовков для аутентифицированных отправок через smtp_header_checks.
• Выборочный greylisting. Политика iRedAPD «подожди и приди снова» отсекает примитивных спам-ботов почти бесплатно, но задерживает первое письмо от нового отправителя на минуты. Мы держим его включённым по умолчанию и отключаем точечно для доменов, где задержки критичны (заявки с сайта, OTP-подобные уведомления сервисов).

Итог: годовой календарь обслуживания почтового сервера

Весь регламент одной таблицей — фактически наш внутренний план-график, по которому строится сопровождение. Можете забирать и вешать рядом с сервером:

Суммарно это 3–5 часов работы инженера в месяц на сервер — цена, за которую self-hosted почта живёт годами без драм и внезапных выходных на «спасение сервера». Собственно, это и есть ответ на вопрос «сложно ли содержать свою почту»: несложно, если делать понемногу и по расписанию, и мучительно — если вспоминать о сервере только когда он уже лежит.

Если своих рук на регламент нет — это ровно то, что мы в ITfresh делаем как сервис: берём почтовый сервер на сопровождение с бэкапами, мониторингом 24/7 и нормативами реакции из этой статьи. Свои серверы в дата-центре МТС, 15+ лет практики. Напишите мне в Telegram @ITfresh_Boss или позвоните: +7 903 729-62-41 — расскажу, как это устроено, на примере вашей инфраструктуры.