АйТи Фреш
Главная / Статьи / Серверы и хостинг
Серверы и хостинг

Кейс: почта инжиниринговой компании на Modoboa вместо iRedMail — как мы вылечили «письма заказчикам падают в спам»

Автор: Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш» · · ~25 мин чтения
Кейс: почта инжиниринговой компании на Modoboa вместо iRedMail — как мы вылечили «письма заказчикам падают в спам»
Иллюстрация к статье «Кейс: почта инжиниринговой компании на Modoboa вместо iRedMail — как мы вылечили «письма заказчикам падают в спам»».

Инжиниринговая компания на 30 рабочих мест полгода жила с тем, что коммерческие предложения, сметы и исполнительная документация заказчикам «то доходят, то нет». Виноватыми назначали то Mail.ru, то админов заказчика, то «интернет». На деле сломан был свой почтовый сервер — точнее, не сам сервер, а обвязка вокруг него, которую никто не видел, потому что смотреть было нечем. Ниже — как я это разбирал, чем Modoboa и iRedMail отличаются по составу, лицензиям и поддерживаемым ОС, почему в итоге поставил Modoboa, какие записи в DNS чинили проблему и что показали DMARC-отчёты, встроенные прямо в панель. Со всеми командами, конфигами и цифрами.

Как выглядит «письма падают в спам» на самом деле

Ко мне это пришло формулировкой, которую слышал сто раз: «у нас почта работает через раз». Компания — инжиниринговая компания «Техническое решение»: проектирование инженерных систем, 30 рабочих мест, 36 ящиков, три домена: основной, старый (после ребрендинга) и технический под автоматические уведомления. Свой почтовый сервер, поднятый подрядчиком в 2021 году. Симптом: письма заказчикам с КП, сметами и актами в половине случаев оседают в «Спаме» у получателя, а часть адресатов на корпоративных Exchange не получает их вовсе — ни в спам, ни во входящие.

Первое, что я делаю в такой ситуации — не лезу в конфиги. Я прошу три вещи: полный заголовок письма, которое упало в спам (Received, Authentication-Results, DKIM-Signature), внешний IP отправляющего сервера и список доменов. Через двадцать минут картина была такая: Authentication-Results от Mail.ru показывал spf=permerror и отсутствие DKIM-подписи вообще. У Gmail — dkim=none, spf=softfail, dmarc=none. Это не «интернет плохой». Это отправитель, которого принимающая сторона не может опознать, и по нынешним правилам крупных провайдеров такой отправитель едет в спам по умолчанию.

Дальше — раскопки в DNS. spf=permerror почти всегда означает одно из двух: либо в зоне две TXT-записи, начинающиеся с v=spf1, либо превышен лимит в десять DNS-lookup'ов из-за нагромождения include:. Тут было первое: старая запись от прежнего хостера и новая, добавленная подрядчиком. По RFC 7208 два SPF на домен — это permanent error, и корректный получатель обязан считать проверку несостоявшейся. DKIM же не подписывался вообще: OpenDKIM был установлен, но в smtpd_milters его не было — кто-то правил main.cf руками и потерял строку при очередном апдейте.

И вишенка: у сервера не было PTR. Хостер выдал IP, обратную зону не настроил, а никто не проверил. Для Gmail валидные прямая и обратная DNS-записи входят в требования ко всем отправителям без исключения — не к «массовым», а вообще ко всем. То есть письма «Технического решения» нарушали базовые правила приёма сразу по трём пунктам.

Прежде чем менять почтовый сервер, вытащите один-единственный заголовок упавшего письма. В 80 % случаев `Authentication-Results` называет причину открытым текстом, и никакой миграции вообще не требуется — надо починить три записи в DNS.
Памятка: Как выглядит «письма падают в спам» на самом деле — схема
Памятка: Как выглядит «письма падают в спам» на самом деле. Открыть схему в полном размере

Почему я не стал переставлять iRedMail

У «Технического решения» стоял iRedMail на Ubuntu 20.04. Я к iRedMail отношусь спокойно — это добротный установщик, он жив и развивается: на момент написания стабильной значится версия 1.8.8 от 08.09.2026 (перед ней 1.8.7 от 30.08.2026 — релизы идут часто, в основном из-за security-обновлений Roundcube). Поддерживаются CentOS Stream, Rocky и Alma Linux 9/10, Debian 12/13, Ubuntu 22.04/24.04/26.04 (рекомендуемая — 24.04), FreeBSD 14.x и OpenBSD 7.8. Ubuntu 20.04 клиента из списка давно выпала. Претензий к качеству у меня нет. Претензия к модели.

Состав у двух проектов похож только на первый взгляд. iRedMail ставит Postfix и Dovecot, антиспам на связке Amavisd + SpamAssassin + ClamAV, собственный policy-сервер iRedAPD, Fail2ban, мониторинг netdata, веб-почту Roundcube и опционально SOGo (веб-почта, CalDAV/CardDAV, задачи и ActiveSync; на EL 10 и на ARM SOGo недоступен), админку iRedAdmin. Modoboa-installer ставит Postfix и Dovecot, PostgreSQL или MySQL, Nginx с uWSGI, антиспам на выбор — Amavis со SpamAssassin и ClamAV или Rspamd, — OpenDKIM и Radicale для календарей и контактов; веб-почта и админка — собственные, в одном интерфейсе. ActiveSync из коробки у Modoboa нет — если сотрудникам он принципиален, это аргумент в пользу iRedMail с SOGo.

Теперь лицензии. Modoboa целиком распространяется под лицензией ISC — всё, что есть в репозитории, бесплатно и без ограничений. У iRedMail сам установщик открытый, открытая и базовая админка iRedAdmin: она умеет домены, ящики, списки рассылки и администраторов без ограничений по количеству, плюс самообслуживание пользователей. Но RESTful API, алиас-домены, per-domain и per-user relay, BCC, резервный MX, ограничения входа по IP, экспорт учётных записей, интеграция с Fail2ban и учёт последнего входа — это iRedAdmin-Pro, платная лицензия с продлением. Плюс проект сейчас активно продвигает для новых установок коммерческую iRedMail Enterprise Edition.

Мне для клиента до 50 рабочих мест нужна другая вещь: чтобы штатный «айтишник» или офис-менеджер мог сам завести ящик, поставить автоответчик уходящему в отпуск инженеру, посмотреть, почему письмо не ушло, и не залезть при этом ни в один конфиг. Чтобы ящик нового сотрудника можно было завести скриптом через API, не покупая лицензию. И чтобы у меня был инструмент, который покажет состояние домена не «на глазок», а по отчётам от самих получателей. Здесь Modoboa выигрывает у бесплатной части iRedMail — и выигрывает именно открытой версией.

Скажу честно, где Modoboa проигрывает: экосистема iRedMail старше, форумов и готовых рецептов по ней в разы больше, а RHEL-клоны, FreeBSD и OpenBSD установщик Modoboa не поддерживает — он тестируется только на Debian 12+ и Ubuntu 20.04+. Если у вас уже работающий iRedMail на поддерживаемой ОС и он вас устраивает — переезжать ради переезда не надо. Я переезжал, потому что у «Технического решения» всё равно менялась площадка, а ОС была за пределами поддержки.

Это не «iRedMail плохой». Это разные модели монетизации. Считайте не лицензию, а стоимость эксплуатации: сколько раз в год вам придётся руками лезть в базу, потому что нужной кнопки нет в бесплатной панели.
Кейс: почта инжиниринговой компании на Modoboa вместо iRedMail — как мы вылечили «письма заказчикам падают в спам» — схема
Схема к статье. Открыть схему в полном размере

Что такое Modoboa и что в неё реально входит

Modoboa — это панель управления почтовым хостингом на Python/Django поверх обычных Postfix и Dovecot. Ключевое слово — «поверх»: она не заменяет MTA своим велосипедом, а хранит домены, ящики, алиасы и лимиты в SQL и отдаёт их Postfix через обычные *_maps-запросы, а Dovecot — через SQL-драйвер аутентификации. То есть под капотом у вас остаётся ровно тот стек, который вы и так умеете чинить, а панель — это административный слой и веб-интерфейс поверх него. Мне это принципиально важно: если завтра Modoboa умрёт, почта останется работать, я просто потеряю удобную морду.

Проект живой и релизится часто. Линейка 2.8 вышла весной 2026 — 2.8.0 от 23.03.2026, 2.8.1 от 31.03.2026, 2.8.2 от 08.04.2026. Дальше 2.9.0 (29.05.2026), 2.9.1–2.9.3 в июле-августе и текущая 2.10.0 от 06.09.2026. Требуется Python 3.10 и новее (в классификаторах PyPI заявлены версии вплоть до 3.14), под капотом Django 5.2. Новая админка переехала на Vue 3 ещё в 2.3.0 — старый интерфейс на Django-шаблонах постепенно уходит. Если в статьях годичной давности вы читали про 2.6 или 2.7 как про «свежак» — сверьтесь с историей релизов, темп у проекта высокий.

Что даёт коробка без единой доплаты: административная панель с доменами, ящиками, алиасами, доменными администраторами и квотами; веб-почта; календарь и адресная книга (Radicale, CalDAV/CardDAV); per-user Sieve-фильтры; автоответчики; графики трафика; проверка своих IP и доменов по DNSBL; и то, ради чего я её, собственно, и люблю — встроенный просмотр агрегированных DMARC-отчётов. Ограничений на число доменов, ящиков и алиасов нет.

Про DNSBL-модуль отдельно: он честный, но не всесильный. В 2.3.0 из списка провайдеров выкинули SORBS — она просто прекратила существование. Не удивляйтесь, если ваш любимый чёрный список в панели не найдётся: держатели RBL закрываются регулярно, и это нормально.

Modoboa не изобретает MTA. Postfix и Dovecot остаются обычными, конфиги на месте, `postconf -n` и `doveadm` работают как всегда. Панель — административный слой, а не чёрный ящик.

Разворачиваю: инсталлятор, грабли и порядок действий

Я взял чистую ВМ с Debian 12, 4 vCPU, 8 ГБ RAM и 400 ГБ диска — у инженеров в почте много тяжёлых вложений с чертежами. Минимум по документации — 2 ГБ RAM (нужны на компиляцию зависимостей во время установки), но с Amavis, ClamAV и SpamAssassin в двух гигабайтах вы будете жить плохо: clamd один съедает под гигабайт резидентной памяти. Мой практический минимум для 30–40 ящиков — 4 ГБ, комфорт — 8.

Обязательные предусловия, которые ломают установку чаще всего: у хоста должен быть корректно настроен FQDN (hostname -f обязан вернуть mail.example.ru, а не localhost), раздел /tmp не должен быть смонтирован с noexec, и в паролях, которые вы задаёте, лучше не использовать спецсимволы — установщик прокидывает их в конфиги нескольких сервисов, и на экзотике это регулярно рвётся. Проверяю до запуска:

hostnamectl set-hostname mail.example.ru
hostname -f            # должно вернуть mail.example.ru
mount | grep ' /tmp '   # noexec быть не должно
free -m; python3 -V     # RAM и Python 3.10+

Сама установка — три команды. Установщик поднимает базу (PostgreSQL или MySQL), Nginx с uWSGI, Postfix, Dovecot, антиспам (Amavis со SpamAssassin и ClamAV либо Rspamd — выбирается в конфиге), OpenDKIM и Radicale. На моём стенде полный проход занял около 12 минут:

git clone https://github.com/modoboa/modoboa-installer
cd modoboa-installer
sudo python3 run.py mail.example.ru

Главная тонкость — installer.cfg. Он генерируется автоматически при первом запуске, и в README отдельно просят не копировать шаблон руками. Если нужно поменять антиспам-движок, СУБД или отключить какой-то компонент до установки, есть штатный ключ: run.py --stop-after-configfile-check создаёт и проверяет конфиг, но ничего не ставит. Правите сгенерированный installer.cfg и запускаете run.py уже без ключа. Я для «Технического решения» переключился с Amavis на Rspamd: он легче, у него человеческий веб-интерфейс и нормальная работа с DKIM.

sudo python3 run.py --stop-after-configfile-check mail.example.ru
nano installer.cfg                     # движок антиспама, СУБД, ClamAV
sudo python3 run.py mail.example.ru
# позже, для обновления существующей установки:
sudo python3 run.py --upgrade mail.example.ru

После установки — обязательно перезапустить и проверить, что milter'ы действительно подключены. Ровно на этом месте была сломана старая инсталляция клиента, поэтому теперь я это проверяю всегда, даже на свежей:

postconf -n | grep -E 'milter|_maps'
systemctl status postfix dovecot nginx uwsgi rspamd
doveadm auth test admin@example.ru
Не ставьте Modoboa на сервер, где уже что-то живёт — панель, веб-сервер, Bitrix, что угодно. Установщик хозяйничает в Nginx, Postfix и Dovecot по-крупному. Отдельная машина или отдельная ВМ, и никак иначе.
Порядок действий: Разворачиваю: инсталлятор, грабли и порядок действий — схема
Порядок действий: Разворачиваю: инсталлятор, грабли и порядок действий. Открыть схему в полном размере

DNS-обвязка: то, из-за чего письма и падали

Сервер поднялся за вечер. Доставляемость чинилась потом, и заняла она в разы больше времени, потому что чинится она не на сервере, а в зоне домена и у хостера. Разбираю по пунктам то, что мы сделали для «Технического решения» — этот же список я даю всем клиентам как чек-лист.

SPF — ровно одна TXT-запись на домен, без исключений. Старую от предыдущего хостера удалили. Никаких +all и ?all, только ~all на период наблюдения и -all после того, как DMARC-отчёты подтвердят, что все легитимные отправители учтены. Держите в голове лимит: не больше десяти DNS-запросов при раскрытии всех include:, иначе снова permerror.

example.ru.        IN TXT "v=spf1 mx a:mail.example.ru ~all"
_dmarc.example.ru. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.ru; fo=1; adkim=r; aspf=r"

DKIM — генерируем в панели, ключ 2048 бит. У Google в требованиях к отправителям минимум 1024, рекомендация — 2048; 1024 сегодня ставить смысла нет. Селектор берите осмысленный и с датой, чтобы через год суметь провести ротацию без гадания: s2026a, s2026b. Публичную часть кладём в <селектор>._domainkey.<домен>, проверяем, что запись реально отдаётся резолвером снаружи, и только потом включаем подпись.

PTR — задача хостера, но требовать её ваша. Прямая и обратная записи должны сходиться: mail.example.ru резолвится в IP, IP резолвится обратно в mail.example.ru. Это прямое требование Gmail ко всем без исключения отправителям, наравне с TLS на соединении и соответствием формату RFC 5322. У «Технического решения» PTR не было полгода, и это была самая дешёвая в починке и самая дорогая по последствиям строчка.

DMARC — начинаем с p=none и обязательным rua. Никогда не ставьте сразу p=reject: пока вы не собрали отчёты, вы не знаете, кто ещё шлёт от вашего домена. Спойлер: шлёт, и обычно это ваша же 1С, CRM или сервис рассылок. Через месяц наблюдения переводим в p=quarantine, ещё через месяц — в p=reject, если картина чистая.

Отдельно про массовые рассылки. Google с февраля 2024 требует от отправителей более 5000 писем в день на свои домены SPF и DKIM одновременно, настроенный DMARC, выравнивание домена в From с доменом SPF или DKIM, one-click unsubscribe (заголовки List-Unsubscribe и List-Unsubscribe-Post) в маркетинговых письмах. Долю спама по Postmaster Tools Google просит держать ниже 0,1 % и никогда не доводить до 0,3 %. Microsoft объявляла аналогичный набор требований для Outlook.com с тем же порогом в 5000 писем в сутки — точные формулировки лучше сверять на их странице, они их правят. Даже если вы не «массовый отправитель», выполнить этот список стоит: он ровно про то, чтобы вас опознавали.

`p=reject` на второй день после настройки — самая частая самодиверсия. Сначала месяц отчётов, потом ужесточение. Иначе вы своими руками зарежете уведомления из 1С и приглашения из календаря.

DMARC-отчёты в панели: чем это лучше, чем кажется

Вот теперь про фичу, ради которой я и выбрал Modoboa. Агрегированные DMARC-отчёты — это XML-файлы, которые Google, Microsoft, Mail.ru, Yandex и прочие присылают вам ежесуточно на адрес из тега rua. В них написано: с каких IP шли письма от вашего домена, сколько их было, прошли ли SPF и DKIM, совпали ли домены. Это единственный способ увидеть свою почту глазами получателя. Обычно эти XML либо игнорируют, либо заливают в сторонний SaaS за деньги. Modoboa парсит их сама и рисует картинку прямо в панели.

Схема простая: заводите адрес dmarc@, прописываете его в rua, а в Postfix направляете почту на этот адрес в отдельный pipe-транспорт, который вызывает management-команду Modoboa import_aggregated_report --pipe и складывает отчёт в базу. Отчёты приходят раз в сутки, поэтому первая осмысленная картинка появляется примерно через трое суток, а полная — через неделю-две, когда отпишутся все крупные приёмники. Пути к virtualenv и экземпляру ниже — типовые для установщика, сверьте со своими:

# /etc/postfix/master.cf
dmarc-rua-parser unix  -  n  n  -  -  pipe
  flags= user=vmail:vmail argv=/srv/modoboa/env/bin/python /srv/modoboa/instance/manage.py import_aggregated_report --pipe

# /etc/postfix/transport (подключается через transport_maps)
dmarc@example.ru  dmarc-rua-parser:

Что мы увидели у «Технического решения» на десятый день. Из 4 170 писем за отчётный период 96,4 % прошли и SPF, и DKIM — это уже был хороший результат после починки. Но 3,6 % шли с IP офисного провайдера, а не с почтового сервера. Мы полезли смотреть — и нашли: сервер 1С отправлял заказчикам счета и акты напрямую, через встроенную отправку, со своим SMTP наружу и от адреса вида buh@example.ru. Для получателя это было письмо от компании с чужого IP: SPF fail, DKIM none. Именно эти письма и терялись чаще всего — то есть самая болезненная часть проблемы вообще не относилась к почтовому серверу, и без DMARC-отчётов мы бы её не нашли никогда.

Лечение заняло полчаса: 1С перенастроили на отправку через свой же почтовый сервер с аутентификацией по учётной записи ящика. Заодно вскрылось, что облачная система документооборота проектного отдела тоже слала уведомления от клиентского домена со своих серверов — её добавили в SPF и включили для неё DKIM. После этого доля выровненных писем встала на 99,8 %, и через месяц мы спокойно перевели домены в p=quarantine, а ещё через месяц — в p=reject.

DMARC-отчёты — это не «для безопасников». Это инвентаризация всего, что шлёт почту от вашего имени. За первый месяц у любой компании на 30–50 мест находится минимум один неучтённый отправитель, и обычно это 1С или облачный сервис.
Цифры и версии: DMARC-отчёты в панели: чем это лучше, чем кажется — схема
Цифры и версии: DMARC-отчёты в панели: чем это лучше, чем кажется. Открыть схему в полном размере

Миграция и что было дальше

Переезд 36 ящиков и 230 ГБ почты я делал в два слоя. Сначала учётные записи: Modoboa умеет импортировать домены, алиас-домены, ящики и алиасы из CSV командой manage.py modo import. Готового конвертера из iRedMail нет (есть только для PostfixAdmin), поэтому выгрузку из таблиц mailbox, alias и domain базы vmail iRedMail я собрал в CSV скриптом. Порядок строк важен: сначала домены, потом ящики, потом алиасы. Хэши паролей у iRedMail и Modoboa могут быть в разных схемах — проверьте опции через modo import -h на своей версии; нам оказалось проще выдать сотрудникам новые пароли в день переезда.

domain; example.ru; 0; 5120; true
account; ivanov@example.ru; <пароль>; Иван; Иванов; true; SimpleUsers; ivanov@example.ru; 5120
alias; info@example.ru; true; ivanov@example.ru
sudo -u modoboa -i bash
source /srv/modoboa/env/bin/activate
cd /srv/modoboa/instance
python manage.py modo import /tmp/identities.csv

Потом содержимое: imapsync на предварительный прогон за две недели до часа Х, потом дельта в окне выходного дня, потом переключение MX. Предварительный прогон — обязательный этап, он забирает 95 % объёма и превращает «окно на все выходные» в «окно на пару часов». Реальный простой у клиента вышел 40 минут, из которых половина — ожидание обновления DNS-кэшей у пары провайдеров заказчиков. Пароли в командной строке не держу — только в файлах с правами 600:

imapsync --host1 old.example.ru --user1 user@example.ru --passfile1 /root/p1 \
         --host2 mail.example.ru --user2 user@example.ru --passfile2 /root/p2 \
         --ssl1 --ssl2 --automap --skipcrossduplicates --useheader Message-Id

TTL на MX я снижаю до 300 секунд за сутки до переезда и возвращаю обратно через неделю. Старый сервер не выключаю ещё две недели — он продолжает принимать почту от тех, у кого залип кэш, и я раз в сутки догоняю дельту тем же imapsync. Это дешёвая страховка, а вот выключение старого сервера «сразу, чего его держать» — источник классической потери писем, которую потом не докажешь.

Про эксплуатацию. Modoboa релизится часто: минорные версии выходят раз в месяц-полтора, патч-релизы — ещё чаще, 2.8.1 вышла через восемь дней после 2.8.0. Обновляться надо, и обновление у Modoboa штатное — run.py --upgrade из каталога установщика. Я ставлю себе напоминание раз в месяц: посмотреть историю релизов, прочитать changelog, обновиться на стенде, потом на бою. Перед обновлением — снапшот ВМ и дамп базы, всегда.

Бэкап у почтового сервера — это две несвязанные вещи: дамп SQL (домены, ящики, алиасы, настройки, история DMARC) и сам Maildir. Дамп маленький и делается ежедневно, Maildir — раз в сутки инкрементально на отдельное хранилище, желательно вне того же гипервизора. Проверьте восстановление хотя бы одного ящика прежде, чем считать бэкап рабочим: у «Технического решения» на старой площадке «бэкап был», но это была копия каталога, снятая с работающего Dovecot без остановки индексов, и половина папок восстанавливалась с ошибками.

Честный итог. Modoboa не сделала письма волшебно доставляемыми — доставляемость починили DNS и перенастройка 1С. Но она дала три вещи, которых у клиента не было: понятную админку, куда штатный сотрудник заходит сам, встроенные DMARC-отчёты, которые нашли скрытого отправителя, и обновляемый стек на актуальной ОС вместо законсервированной сборки 2021 года. Для компании до 50 рабочих мест этого достаточно, чтобы почта перестала быть источником сюрпризов.

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

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

Modoboa бесплатная? В чём подвох?

Да: Modoboa распространяется под лицензией ISC и не ограничивает число доменов, ящиков и алиасов. Разработчики зарабатывают на Modoboa Pro и платных услугах — установке, обновлении, разборе проблем и годовом сопровождении, — но всё, что описано в статье (админка, веб-почта, календарь, адресная книга, Sieve-фильтры, автоответчики, DNSBL, DMARC-отчёты, REST API), работает в открытой версии. Подвох один: если не покупать сопровождение, отвечать за апдейты и бэкапы будете вы.

На какую ОС ставить и сколько нужно ресурсов?

Установщик тестируется на Debian 12 и новее и на Ubuntu 20.04 и новее, нужен Python 3.10+. Формальный минимум — 2 ГБ RAM, но с ClamAV и Amavis это мучение. Для 30–40 ящиков берите 4 vCPU и 8 ГБ RAM, диск считайте по объёму почты с запасом в два раза. RHEL-клоны, FreeBSD и OpenBSD установщик не поддерживает — для них смотрите iRedMail.

Можно поставить Modoboa на сервер, где уже крутится сайт или 1С-публикация?

Технически можно, практически — не надо. Установщик переписывает конфигурацию Nginx, Postfix и Dovecot под себя. Любое соседство закончится тем, что вы будете разбирать конфликты вручную при каждом обновлении. Отдельная виртуалка стоит дешевле одного такого разбора.

Мы не делаем рассылок, зачем нам DMARC?

DMARC нужен не для рассылок, а чтобы видеть, кто шлёт почту от вашего домена, и чтобы получатели вам верили. Даже на 30 ящиках первый же месяц отчётов почти всегда вскрывает неучтённого отправителя — чаще всего 1С или CRM, которая шлёт документы напрямую мимо почтового сервера. Именно такие письма и падают в спам.

Стоит ли сразу ставить p=reject?

Нет. Начинайте с p=none и обязательным rua, соберите отчёты минимум за месяц, убедитесь, что список отправляющих IP предсказуем, потом p=quarantine, ещё через месяц p=reject. Быстрое ужесточение — самый популярный способ своими руками отрезать себе уведомления из внутренних систем.

Переезжать ли с работающего iRedMail на Modoboa?

Если iRedMail работает, ОС в поддержке (для 1.8.x это Debian 12/13, Ubuntu 22.04–26.04, EL 9/10, FreeBSD 14, OpenBSD 7.8) и вам хватает бесплатной админки — не трогайте, риск переезда больше выигрыша. Менять стек имеет смысл, когда вы всё равно переезжаете на новую площадку, когда кончилась поддержка ОС или когда упираетесь в платные функции iRedAdmin-Pro — API, алиас-домены, relay. Учётки переносятся CSV-импортом Modoboa, почта — imapsync.

Нужен ли ActiveSync, и есть ли он в Modoboa?

В Modoboa ActiveSync из коробки нет: почта по IMAP/SMTP, календари и контакты — по CalDAV/CardDAV через Radicale, что штатно работает на iOS, macOS и в Thunderbird, а на Android — через приложение-синхронизатор. iRedMail с SOGo даёт ActiveSync, но SOGo недоступен на EL 10 и ARM. Если половина компании сидит на Outlook с общими календарями, это весомый аргумент при выборе.

Как понять, что письма падают в спам именно из-за нас?

Попросите у получателя полный заголовок письма и посмотрите строку Authentication-Results: там будет написано spf, dkim и dmarc с результатом. permerror, none или fail — проблема на вашей стороне и чинится в DNS. Если всё pass, а письмо всё равно в спаме — дело в репутации IP или в содержимом, и это уже другой разговор.

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

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

📞 +7 903 729-62-41 💬 MAX: +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Источники

© ООО «АйТи-Фреш» · Москва · Все статьи