После обновления mailcow 2026-01 адрес user+tag перестал сортировать письма: где искать регресс

Если после обновления mailcow до 2026-01 письма на user+tag@domain вдруг стали падать прямо во «Входящие» без сортировки по папке или без метки в теме — это не ошибка в ваших настройках. Это подтверждённый регресс в Lua-скрипте rspamd, закрытый только в 2026-03. Разбираю, что именно сломалось, как убедиться, что дело в этом, и что делать, пока не обновились.

Кейс: «СмартФикс» и заявки, которые перестали попадать в очередь

«СмартФикс» — сеть точек ремонта мобильных телефонов, 32 рабочих места, почта у них на собственном mailcow, который мы сопровождаем по регламенту. У диспетчерской почты через тегированные адреса вида zayavki+garantiya@domain.ru и zayavki+platno@domain.ru были настроены две подпапки: гарантийные заявки отдельно от платных, чтобы диспетчер сразу видел приоритет без чтения темы письма.

Обновление до mailcow 2026-01 прошло штатно, без ошибок в логах апдейтера. Проблему заметили не сразу — через два дня, когда выяснилось, что несколько гарантийных заявок с сайта-агрегатора пролежали во «Входящих» вперемешку с платными обращениями и их не обработали вовремя. Диспетчер не был виноват: письма физически доходили, просто больше не раскладывались.

Мы поставили себе задачу быстро отличить «это у нас что-то сломалось в конфиге» от «это баг апстрима» — потому что первое чинится за 10 минут, а второе требует либо ждать патч, либо ставить временный обходной путь.

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

Как выглядит симптом и почему это легко спутать с настройкой

Формально ничего в интерфейсе mailcow не менялось: в Mailbox → Settings у ящика zayavki@domain.ru режим сортировки по тегу («В подпапку») оставался включённым, никто его не трогал. Но письма на zayavki+garantiya@domain.ru после обновления попадали прямо в INBOX, как будто настройка была выключена.

Первая мысль — где-то в data/conf/dovecot/global_sieve_after затёрлось правило при обновлении, или порядок применения Sieve-скриптов изменился. Это разумное предположение, но неверное: правило в конфигурации осталось на месте и синтаксически было корректным, проблема лежала не в Sieve mailcow, а в Lua-скрипте rspamd: именно он (символ TAG_MOO) решает, есть ли у получателя тег, и в режиме подпапок ставит письму служебный заголовок X-Moo-Tag: YES, без которого правило в global_sieve_after просто не срабатывает.

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

Что реально сломалось: issue #7030 и rspamd.local.lua

29 января 2026 года пользователь под ником wralb открыл на GitHub issue #7030 «Issue with sub-addressing after upgrade to 2026-01»: после обновления письма на тегированные адреса перестали раскладываться по подпапкам, при этом никаких изменений в конфигурации пользователь не вносил. Проблему воспроизвёл ещё один участник, DocFraggle. Параллельно на форуме сообщества mailcow появилась тема «Issue with sub-addressing after upgrade to 2026-01?», где пользователи подтвердили, что сломались оба режима — и подпапка, и тег в теме.

# где физически лежит скрипт, в котором был баг
data/conf/rspamd/lua/rspamd.local.lua

Причина — в рефакторинге Lua-скрипта rspamd (data/conf/rspamd/lua/rspamd.local.lua) в релизе 2026-01. В версии 2026-01 символ TAG_MOO искал «+» в локальной части получателя самостоятельно, и для тегированных писем эта проверка не находила тег: в логе появлялось «no tag found», заголовок X-Moo-Tag не ставился, а тема не переписывалась. Sieve-правило Dovecot было настроено верно, но ему просто нечего было обрабатывать. Режим «тег в теме» при этом ломается целиком внутри rspamd — тему переписывает сам скрипт, Dovecot в нём не участвует.

Это принципиально важное разграничение зон ответственности: mailcow строит сортировку по тегам на связке двух компонентов — rspamd готовит и прокидывает информацию о sub-address, а Dovecot уже на её основе выполняет Sieve-правило. Пока считаешь, что вся логика — в Sieve и Dovecot, искать баг в rspamd просто не приходит в голову; в этом и была главная потеря времени на диагностике, пока issue #7030 не попался в поиске по точным симптомам.

Issue закрыли 3 марта 2026 года после того, как тот же DocFraggle подготовил исправление — Pull Request #7037 «Fix lua script sub-addressing», который правит именно этот скрипт: тег берётся из уже вычисленного символа TAGGED_RCPT, а при подстановке в тему используется значение из опций этого символа — так чинятся оба сломанных сценария.

Когда именно это починили: релиз 2026-03

PR #7037 был влит в ветку staging 2 марта 2026 года, а вошёл в официальный релиз mailcow 2026-03 («Moorch 2026»), который вышел 10 марта 2026 года. В этом же релизе обновили SOGo до 5.12.5 (собран из исходников с патчами безопасности) и Rspamd до 3.14.3-1, добавили обязательную настройку двухфакторной аутентификации и поддержку DNS-01 challenge для ACME-сертификатов — исправление sub-addressing идёт отдельным пунктом в списке изменений релиза.

Это значит, что между 2026-01 (когда баг появился) и 2026-03 (когда его закрыли) прошло больше месяца, в течение которого все, кто обновился до 2026-01 и использовал тегированные адреса, оставались с нерабочей сортировкой — без явной ошибки, без сообщения в логах, только молча не срабатывающим правилом.

После 2026-03 вышли ещё два патч-релиза — 2026-03a (13 марта, фикс LDAP/Keycloak-аутентификации и проблем с ACME DNS-01) и 2026-03b (31 марта, усиление валидации входных данных). Ни один из патчей не касается повторно sub-addressing — фикс из #7037 в них не менялся.

Для тех, кто следит за релизами mailcow не постоянно, а обновляется раз в квартал или реже, это значит одно: если вы сейчас всё ещё на 2026-01 (промежуточных релизов 2026-02 не было), обновление сразу закроет и накопившиеся с тех пор изменения безопасности, и именно этот баг — отдельно накатывать patch только ради sub-addressing не нужно и невозможно, фикс идёт исключительно в составе полного релиза.

Как быстро убедиться, что у вас именно этот баг

Первое, что я проверяю — версию mailcow. Если вы обновились на 2026-01 и раньше сортировка по тегу работала, а после обновления перестала без изменений в настройках — это почти наверняка issue #7030, а не ошибка конфигурации.

cd /opt/mailcow-dockerized
# версия, которую update.sh записал в веб-интерфейс
grep MAILCOW_GIT_VERSION data/web/inc/app_info.inc.php
# или последний тег в локальном git-репозитории mailcow
git describe --tags

Второе — проверить, что сама настройка в Mailbox → Settings осталась включённой и Sieve-скрипт в data/conf/dovecot/global_sieve_after синтаксически корректен. Если правило на месте, а письма всё равно не сортируются — это уже не вопрос к вашей конфигурации, а подтверждение, что проблема в rspamd.

Третье — посмотреть, что говорит сам скрипт. Пошлите себе письмо на test+debug@domain.ru и найдите строки TAG_MOO в логе rspamd: docker compose logs --since 30m rspamd-mailcow | grep TAG_MOO. Если для адреса с «+» там стоит «no tag found in recipient», а в заголовках доставленного письма нет X-Moo-Tag, — это ровно регресс 2026-01. Заодно исключите штатные ограничения TAG_MOO: тег обрабатывается только при одном SMTP-получателе и только если rspamd вынес действие «no action» или «greylist».

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

Что делать, пока вы ещё не обновились до 2026-03

Самый надёжный вариант — обновиться сразу до 2026-03 или новее: фикс входит в базовый релиз, никаких дополнительных действий после обновления не требуется, сортировка по тегам начинает работать заново с уже существующими настройками ящиков.

cd /opt/mailcow-dockerized
# проверить, есть ли обновление (код 0 — есть, 3 — нет)
./update.sh --check
# само обновление: update.sh сам подтягивает код и образы
./update.sh

Если обновление откладывается по внутренним причинам (например, заморозка изменений на время отчётного периода, как это часто бывает у бухгалтерских или ремонтных сетей), временный обходной путь — личный Sieve-фильтр в самом ящике (SOGo → Настройки → Фильтры или Mailbox → Filters в панели mailcow) с проверкой envelope :detail "to". Он работает в Dovecot и от сломанного скрипта rspamd не зависит: адрес с тегом по-прежнему доходит до LMTP-доставки, просто без заголовка X-Moo-Tag. Минус — правило на каждый тег надо написать руками, то есть возвращается часть той рутины, от которой тегированные адреса как раз избавляют.

Для «СмартФикс» мы выбрали этот путь на три недели: в ящике zayavki@domain.ru завели фильтр из двух условий — envelope :detail "to" "garantiya" → fileinto "INBOX/Garantiya" и такое же для «platno», в те же папки, что создавал встроенный режим. Агрегатору ничего менять не пришлось. После планового обновления до 2026-03 фильтр отключили и оставили работать штатный механизм. Перед самим обновлением, как обычно, сняли резервную копию сервера и проверили, что бэкап действительно непустой — регрессы, ломающие не саму почту, а её обработку, случаются в апстриме не в первый раз.

Итог: 21 день простоя сортировки, ноль потерянных заявок

От момента, когда диспетчер заметил проблему, до включения временного Sieve-фильтра прошло меньше суток — потому что мы сразу нашли issue #7030 и не тратили время на перебор собственных настроек. Ещё три недели «СмартФикс» проработали на временном фильтре, дожидаясь планового обновления, — за это время ни одна заявка не потерялась.

После обновления до 2026-03 мы проверили сортировку тестовыми письмами на оба тега прежде, чем вернуть боевую схему, и только после этого отключили временный фильтр. Небольшая, но важная деталь регламента эксплуатации mailcow, по которому мы обслуживаем клиентские серверы: любое обновление mailcow с версии до 2026-03 на клиенте, где используются тегированные адреса, мы теперь сопровождаем отдельным пунктом «проверить sub-addressing тестовым письмом» — этот баг был не единственным подобным случаем за последние релизы, и повторная ручная проверка стоит десяти минут против нескольких дней потерянных заявок.

Если у вас похожая схема на mailcow ниже версии 2026-03 — я советую не ждать жалоб пользователей, а обновиться или проверить сортировку заранее, тестовым письмом на реальный тег. Пять минут на такую проверку после любого крупного обновления обходятся кратно дешевле, чем разбор потерянных или задержанных заявок постфактум.

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