Разворачиваем iRedMail 1.8.4 на Debian 13 за вечер: пошаговый регламент, по которому мы внедряем почту клиентам

Что готовим до установки: чек-лист инфраструктуры

Меня зовут Евгений Семёнов, я технический директор ITfresh. В обзорной статье про iRedMail я разобрал, что это за система и кому она подходит. Сегодня — практика: наш внутренний регламент развёртывания, по которому мы ставим почтовые серверы клиентам. Он отточен на реальных внедрениях, и если следовать ему по шагам, к концу вечера у вас будет работающая корпоративная почта, письма с которой доходят до Gmail и Mail.ru с первого раза.

Небольшое уточнение по версии. В плане серии фигурировала 1.8.3 от 7 июля, но 22 июля 2026 года вышла iRedMail 1.8.4 — и для Debian 13 это не косметика: в 1.8.4 исправлен некорректный конфиг sieve для Dovecot 2.4, который затрагивал именно Debian 13 и Ubuntu 26.04. Так что ставим сразу 1.8.4 и не ловим чужие грабли.

Главное правило внедрения почты: 80% успеха решается до запуска инсталлятора. Вот что должно быть готово:

• VPS: 4 vCPU, 4 ГБ RAM, 100 ГБ SSD. Четыре гигабайта — не рекомендация, а фактический минимум: один ClamAV держит в памяти больше гигабайта сигнатур. На 2 ГБ инсталлятор отработает, а сервер потом задохнётся на первой проверке вложений.
• Чистый Debian 13 без панелей управления. Никаких ISPmanager, aaPanel, HestiaCP и уже установленных веб-серверов. Инсталлятор iRedMail рассчитан на голую систему и при обнаружении чужого MySQL или Nginx поведёт себя непредсказуемо. Если хостер предлагает образ «Debian 13 + LAMP» — берите просто Debian 13.
• FQDN вида mail.company.ru. Именно поддомен, а не голый company.ru: на основном домене обычно живёт сайт, и конфликт за 80/443 порты вам не нужен.
• PTR-запись (reverse DNS). Обязательно. Mail.ru и Gmail отклоняют или отправляют в спам письма с IP без обратной зоны либо с дефолтной записью вида v123456.hosted.provider.ru. PTR должен совпадать с FQDN сервера: 1.2.3.4 → mail.company.ru.
• Открытый исходящий 25-й порт. Многие хостеры блокируют его по умолчанию для новых аккаунтов как защиту от спамеров.

Про два последних пункта — подробнее, потому что это специфика российских хостеров, о которую спотыкаются чаще всего. PTR у большинства провайдеров (Timeweb, Selectel, REG.RU, VDSina) меняется самостоятельно в панели управления VPS — ищите поле «rDNS» или «обратная запись» в свойствах IP-адреса. У некоторых — только через тикет в поддержку, и ответ может идти сутки. Исходящий 25-й порт тоже нередко открывается тикетом: пишите заранее, честно указывайте «корпоративный почтовый сервер компании такой-то», обычно открывают за несколько часов. Проверить блокировку просто:

# с самого VPS: если соединение не устанавливается — порт режется
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/smtp.yandex.ru/25' && echo OPEN || echo BLOCKED

# проверка PTR
dig -x 1.2.3.4 +short   # должно вернуть mail.company.ru.

DNS до старта инсталлятора

Вторая часть подготовки — DNS-записи основного домена. Их лучше внести до установки: A-запись должна разрезолвиться к моменту выпуска сертификата Let's Encrypt, а MX с SPF пусть спокойно расходятся по кешам, пока работает инсталлятор. Вот минимальный набор для домена company.ru с сервером на IP 1.2.3.4:

По SPF пара комментариев. Запись v=spf1 mx -all означает «почту домена отправляют только серверы из MX-записей, остальное — отклонять». Это строгий и правильный вариант для случая, когда вся почта ходит через ваш новый сервер. Если сайт компании шлёт письма с хостинга (формы обратной связи, интернет-магазин), добавьте его: v=spf1 mx ip4:5.6.7.8 -all — иначе уведомления с сайта начнут падать в спам.

А вот DKIM и DMARC на этом этапе публиковать рано, и это не наша прихоть: DKIM-ключ генерирует сам инсталлятор iRedMail, селектор и публичная часть появятся только после установки. DMARC без DKIM тоже смысла не имеет. К обеим записям вернёмся через два раздела.

Установка: 15 минут работы скрипта

Hostname и /etc/hosts — классическая ошибка №1

Прежде чем скачивать дистрибутив, приводим в порядок имя сервера. Инсталлятор требует полный FQDN, и неправильный hostname — самая частая причина, по которой установка обрывается или, хуже, завершается с кривым конфигом Postfix:

hostnamectl set-hostname mail.company.ru

# /etc/hosts — FQDN обязан идти ПЕРВЫМ после IP:
# 127.0.0.1   mail.company.ru mail localhost
nano /etc/hosts

# проверяем: первая команда вернёт mail.company.ru, вторая — mail
hostname -f
hostname -s

Затем обновляем систему и ставим единственную зависимость:

apt update && apt full-upgrade -y
apt install -y gzip wget
reboot   # если обновилось ядро

Скачиваем и запускаем iRedMail 1.8.4

cd /root
wget https://github.com/iredmail/iRedMail/archive/refs/tags/1.8.4.tar.gz
tar xzf 1.8.4.tar.gz
cd iRedMail-1.8.4
bash iRedMail.sh

Дальше начинается диалог в синих ncurses-экранах. Прохожу по экранам с нашими типовыми ответами:

• Каталог хранения почты — оставляем /var/vmail. Если под почту смонтирован отдельный диск (мы так делаем на серверах с большим объёмом), указываем его точку монтирования.
• Веб-сервер — Nginx, других вариантов инсталлятор давно не предлагает.
• Бэкенд учёток — MariaDB. Выбор делается один раз и навсегда: сменить бэкенд потом малой кровью нельзя. OpenLDAP оправдан только при интеграции с существующим каталогом, PostgreSQL проигрывает MariaDB по количеству готовых рецептов вокруг iRedMail.
• Домен почты — указываем company.ru, то есть домен, который будет после @ в адресах. Не mail.company.ru — это имя сервера, а не почтовый домен.
• Пароль администратора — инсталлятор создаст ящик postmaster@company.ru, он же логин в админ-панель. Пароль — из генератора, длиной от 16 символов, сразу в менеджер паролей.
• Компоненты — отмечаем всё: Roundcube, SOGo, iRedAdmin, Fail2ban, netdata по желанию. Дисковое место копеечное, а доставлять компоненты после установки заметно муторнее.

Подтверждаем сводку, и дальше скрипт минут 10–15 сам ставит пакеты и раскладывает конфиги. В конце соглашаемся на предложенные правила фаервола и перезагружаем сервер.

Русская локаль

Чтобы даты в веб-клиентах, системные уведомления Roundcube и имена стандартных папок корректно отображались по-русски, локаль ru_RU.UTF-8 должна быть сгенерирована в системе: dpkg-reconfigure locales, отмечаем ru_RU.UTF-8. Сами Roundcube и SOGo определяют язык по браузеру пользователя и переведены полностью — сотрудникам ничего настраивать не придётся.

Файл iRedMail.tips — сохранить и удалить

После установки в каталоге инсталлятора остаются два файла: iRedMail.tips — все URL панелей, логины, пароли MariaDB, пути к конфигам — и config с ответами на вопросы установки. Это фактически паспорт сервера. Наш регламент: скопировать содержимое в менеджер паролей (мы храним в Vaultwarden в карточке клиента), после чего удалить оба файла с сервера. Оставленный в /root открытым текстом iRedMail.tips — подарок любому, кто когда-нибудь доберётся до сервера.

Let's Encrypt вместо self-signed

Из коробки iRedMail работает на самоподписанном сертификате: почта ходит, но браузеры ругаются на веб-клиенты, а Outlook и смартфоны при подключении по IMAP показывают пугающие предупреждения. Меняем на бесплатный сертификат Let's Encrypt. Ставим certbot и выпускаем сертификат через уже работающий Nginx:

apt install -y certbot python3-certbot-nginx
certbot certonly --nginx -d mail.company.ru

Дальше — фирменный приём из официальной документации iRedMail, который сильно упрощает жизнь: не править пути в конфигах Postfix, Dovecot и Nginx, а подменить символьными ссылками файлы самоподписанного сертификата, на которые все конфиги уже смотрят. На Debian это выглядит так:

mv /etc/ssl/certs/iRedMail.crt{,.bak}
mv /etc/ssl/private/iRedMail.key{,.bak}
ln -s /etc/letsencrypt/live/mail.company.ru/fullchain.pem /etc/ssl/certs/iRedMail.crt
ln -s /etc/letsencrypt/live/mail.company.ru/privkey.pem  /etc/ssl/private/iRedMail.key
systemctl restart postfix dovecot nginx

Одна операция — и сертификат подхватили сразу все сервисы: SMTP, IMAP, оба веб-клиента. Проверяем срок действия и цепочку: echo | openssl s_client -connect mail.company.ru:443 2>/dev/null | openssl x509 -noout -dates -issuer.

Теперь автопродление — и здесь грабля из нашей практики, на которую наступают почти все. Сертификат Let's Encrypt живёт 90 дней, certbot ставит системный таймер продления, но есть два подводных камня. Первый: после продления сервисы должны перечитать сертификат, сами они этого не делают. Второй, коварный: renewal-конфиг в /etc/letsencrypt/renewal/ запоминает, каким методом выпускался сертификат. Если вы выпускали его до установки iRedMail методом standalone (когда 80-й порт был свободен), то через 90 дней certbot попытается сам занять :80, упрётся в работающий Nginx — и сертификат молча протухнет. Правильная конфигурация продления:

# /etc/cron.d/certbot-renew — продление с перезапуском сервисов
15 3 * * * root certbot renew --nginx \
  --post-hook "systemctl restart postfix dovecot nginx"

# репетиция без реального выпуска — обязана пройти без ошибок:
certbot renew --dry-run

Если --dry-run прошёл — про сертификат можно забыть. В наш мониторинг мы всё равно добавляем проверку срока действия за 14 дней до истечения: бесплатная страховка от любых сюрпризов.

Пост-установка: DKIM, DMARC и проверка доставляемости

Сервер работает, но чтобы Gmail и Mail.ru принимали ваши письма во «Входящие», нужно допубликовать DKIM и DMARC. DKIM-подписью в iRedMail заведует Amavisd — ключ уже сгенерирован инсталлятором, осталось вытащить публичную часть:

amavisd-new showkeys

Команда выведет готовую TXT-запись вида dkim._domainkey.company.ru со значением v=DKIM1; p=MIIBIjANBg.... Публикуем её у DNS-провайдера как есть: имя — dkim._domainkey, тип — TXT, значение — строка из p=... (кавычки и переносы, которые печатает amavisd, при вставке в веб-панель DNS убираем — нужна одна слитная строка). Через 10–15 минут проверяем, что подпись валидна:

amavisd-new testkeys
# ожидаем: TESTING#1 dkim._domainkey.company.ru => pass

Теперь DMARC — политика, которая говорит чужим серверам, что делать с письмами, не прошедшими SPF/DKIM. Начинать сразу с жёсткой политики нельзя: сначала копим статистику. Публикуем мягкий вариант с отчётами:

_dmarc.company.ru  TXT  "v=DMARC1; p=none; rua=mailto:postmaster@company.ru; fo=1"

p=none означает «ничего не отклонять, только присылать отчёты» на ящик postmaster. Через две-три недели, когда по отчётам видно, что вся легитимная почта проходит проверки, ужесточаем до p=quarantine, а ещё через месяц — до p=reject. Это наш стандартный график для клиентских доменов.

Финальный аккорд — проверка доставляемости. Идём на mail-tester.com, копируем одноразовый адрес, отправляем на него письмо из Roundcube с осмысленной темой и парой абзацев текста (пустые письма занижают оценку) и смотрим разбор. Целевой результат — 10/10: с корректными PTR, SPF, DKIM и DMARC он достигается сразу. Всё, что ниже 9, — повод читать детализацию: чаще всего виноваты незакрытые пункты из этой статьи. Параллельно регистрируем домен в постмастерах Mail.ru и Яндекса — там видна репутация домена и статистика попадания в спам у самых популярных в РФ получателей.

Создаём домен и ящики

Через iRedAdmin

Админ-панель живёт на https://mail.company.ru/iredadmin/, логин — postmaster@company.ru. Бесплатная версия умеет базу: добавить почтовый домен, создать ящик с паролем, назначить администратора домена, деактивировать учётку. Почтовый домен company.ru инсталлятор уже создал; ящики сотрудников заводятся в два клика — этого хватает для повседневной жизни.

Честно про ограничения free-версии

Квоты ящиков, алиасы, списки рассылки в бесплатной iRedAdmin через интерфейс недоступны — это функции платной iRedAdmin-Pro. Но всё это спокойно делается SQL-запросами к базе vmail, и запросы шаблонные. Два самых ходовых из нашей шпаргалки:

mysql vmail

-- квота ящика 10 ГБ (значение в МБ)
UPDATE mailbox SET quota = 10240 WHERE username = 'buh@company.ru';

-- алиас info@ -> два реальных получателя
REPLACE INTO forwardings (address, forwarding, domain, dest_domain, is_list, active)
VALUES ('info@company.ru', 'director@company.ru', 'company.ru', 'company.ru', 1, 1),
       ('info@company.ru', 'manager@company.ru',  'company.ru', 'company.ru', 1, 1);

Массовое создание ящиков скриптом

Заводить 30 сотрудников по одному через веб-форму — тоска. В комплекте iRedMail есть готовый инструмент tools/create_mail_user_SQL.sh: готовим CSV со списком адресов и паролей, скрипт генерирует корректные SQL-запросы с правильными хэшами паролей и путями maildir:

cd /root/iRedMail-1.8.4/tools
# users.csv: domain name password
# company.ru ivanov Passw0rd-Iv
# company.ru petrova Passw0rd-Pe
bash create_mail_user_SQL.sh users.csv > users.sql
mysql vmail < users.sql

Тридцать ящиков заводятся за пять минут. Пароли раздаём сотрудникам через менеджер паролей или одноразовые ссылки — но не в общем чате, пожалуйста.

Подключаем клиентов

Параметры подключения одинаковы для всех программ:

Thunderbird и современный Outlook при вводе адреса и пароля находят настройки автоматически. Смартфоны удобнее всего подключать через ActiveSync-совместимую синхронизацию SOGo: в стандартном почтовом приложении выбираем тип учётки «Exchange», сервер — mail.company.ru; вместе с почтой приезжают календарь и контакты.

Типовые ошибки пользователей при первом входе — короткий список, который мы отдаём вместе с паролями: логин — всегда полный адрес, а не «ivanov»; для исходящей почты порт 587, а не 25 или 465; если клиент предлагает «без шифрования» — отказаться; после трёх неверных паролей подряд IP банится Fail2ban на несколько минут — не долбить кнопку «Войти», а проверить раскладку.

Первичная защита сразу после установки

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

fail2ban-client status
# ожидаем jail-ы: dovecot, postfix, roundcube, sogo, sshd...

fail2ban-client status dovecot
# через сутки в Banned IP list будут десятки адресов — это норма

Дальше — три обязательных действия нашего регламента:

• Закрыть iRedAdmin с внешки. Админ-панель не нужна всему интернету. В конфиге Nginx (/etc/nginx/templates/iredadmin.tmpl или сайт-конфиг) в location iredadmin добавляем allow для офисного IP и VPN, затем deny all, и systemctl reload nginx. Если офисный IP динамический — закрываем панель целиком и заходим через SSH-туннель.
• Отключить POP3, если им никто не пользуется. В 2026 году POP3 нужен исчезающе редко, а поверхность атаки увеличивает. В /etc/dovecot/dovecot.conf убираем pop3 из protocols, перезапускаем Dovecot и закрываем порты 110/995 на фаерволе.
• SSH — только по ключам. К почте это относится косвенно, но сервер с root-паролем и открытым 22-м портом — вопрос времени, а не вероятности.

Смоук-тест внедрения: наш приёмочный чек-лист из 12 пунктов

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

1. Письмо на адрес Gmail уходит и попадает во «Входящие», не в спам.
2. Письмо на адрес Mail.ru — во «Входящих» (Mail.ru строже Gmail к новым IP).
3. Ответ с Gmail и с Mail.ru доставляется в ящик на сервере.
4. В заголовках полученного на Gmail письма: SPF: PASS, DKIM: PASS, DMARC: PASS («Показать оригинал»).
5. dig -x IP возвращает FQDN сервера — PTR на месте.
6. mail-tester.com даёт 10/10.
7. Вход в Roundcube и SOGo по HTTPS без предупреждений о сертификате.
8. certbot renew --dry-run проходит без ошибок.
9. IMAP-подключение с телефона и из десктоп-клиента работает.
10. Отправка через 587 с аутентификацией работает, без аутентификации — отклоняется.
11. Fail2ban банит: три неверных пароля подряд — IP в бан-листе (проверяем с телефона через мобильный интернет, чтобы не забанить себя в офисе).
12. IP сервера чист в блэклистах — проверка на mxtoolbox.com/blacklists.aspx.

Пункт 11 многих удивляет: мы специально «ломимся» с неправильным паролем и смотрим fail2ban-client status dovecot. Защита, которую никто не проверил, — это надежда, а не защита.

Сколько времени это заняло и что дальше

Честный тайминг нашего типового внедрения. Подготовка — заказ VPS, тикеты на PTR и 25-й порт, DNS-записи — полчаса работы и до суток ожидания ответов хостера, поэтому делается накануне. Сама установка: hostname и обновление системы — 15 минут, работа инсталлятора — 15 минут, Let's Encrypt — 15 минут, DKIM и DMARC с ожиданием DNS — полчаса, ящики и проверка клиентов — час, смоук-тест — полчаса. Итого 2,5–4 часа чистой работы — это действительно один вечер, если подготовка сделана заранее.

Что дальше? Установка — самая простая часть жизни почтового сервера. В следующих статьях серии — миграция существующей почты на iRedMail без потери писем (imapsync, двойная доставка, переезд с Яндекса и Exchange) и регламент эксплуатации: бэкапы, антиспам, мониторинг, обновления.

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