Поднял message_size_limit в mailcow, а большие вложения всё равно не проходят: пять мест, где ещё стоит лимит

Администратор поднял message_size_limit в Postfix до 84 МБ, перезапустил контейнер — и письмо с файлом на 45 МБ всё равно отклоняется. Дело не в опечатке: в mailcow за максимальный размер письма отвечает не один параметр, а минимум пять, разбросанных по конфигурациям четырёх разных сервисов. Пока не согласованы все — работает самый строгий из них. Разбираю, где какая настройка живёт, в каких единицах и что нужно перезапустить, чтобы изменения реально применились.

Кейс: увеличили лимит, а вложения всё равно режутся

Школа вокала «Голос и дыхание» (19 рабочих мест) держит на корпоративной почте на mailcow переписку с концертными площадками: договоры аренды залов, райдеры, афиши в высоком разрешении, иногда видеофрагменты выступлений для промо. Площадка требовала присылать афиши в оригинальном качестве одним письмом, без архивов и облачных ссылок, — файлы до 60 МБ. Администратор школы нашёл в extra.cf строку message_size_limit = 26214400 (25 МБ), которую когда-то перенёс со старого сервера прежний подрядчик, и поднял её до 84 МБ. Для справки: из коробки mailcow держит в main.cf значение 104857600 байт, то есть 100 МБ, — так что Postfix сам по себе в этой истории был виноват только наполовину.

После правки Postfix и перезапуска контейнера тестовое письмо с файлом на 45 МБ (а это около 62 МБ на проводе после base64) всё равно отклонилось — но не с ошибкой Postfix про размер, а глубже в цепочке, на этапе фильтрации. Администратор был уверен, что настройка завершена: он поменял именно тот параметр, который называется в документации «message size limit», и именно там, где его обычно ищут — в Postfix. Проблема в том, что письмо в mailcow проходит не через один сервис, а последовательно через несколько, и у каждого — собственный потолок.

Мы разбирали этот кейс дистанционно: попросили прислать точный текст ошибки из журнала, и оказалось, что письмо упало не в Postfix, а в Rspamd — на лимите, который администратор вообще не трогал, потому что не знал о его существовании.

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

Пять мест, где стоит лимит размера в mailcow

Первый и самый очевидный — Postfix. Параметр message_size_limit задаётся в байтах в файле data/conf/postfix/extra.cf (это файл для собственных дополнений поверх генерируемого main.cf, он не перезаписывается при обновлениях mailcow). Единицы — именно байты, не мегабайты: для лимита в 80 МБ нужно писать что-то вроде message_size_limit = 83886080 (80 × 1024 × 1024), а не «80M» — Postfix в этом файле ожидает число байт.

Второй — Rspamd, система фильтрации, через которую проходит каждое письмо после Postfix. За максимальный размер сканируемого сообщения отвечает параметр max_message в data/conf/rspamd/local.d/options.inc. По умолчанию в Rspamd это 50 МБ (документация задаёт его в формате 50Mb, то есть здесь единицы измерения — мегабайты, в отличие от Postfix). В штатном options.inc mailcow параметра max_message нет вовсе, поэтому действует именно этот дефолт Rspamd — и письмо в 62 МБ на проводе в него не влезает. Если этот параметр меньше, чем message_size_limit в Postfix, письмо пройдёт Postfix, но упрётся именно здесь.

Третий и четвёртый — проверка вложений: max_size для oletools (разбор офисных документов на макросы) в data/conf/rspamd/local.d/external_services.conf, и отдельно max_size для ClamAV в data/conf/rspamd/local.d/antivirus.conf. Плюс у самого ClamAV в data/conf/clamav/clamd.conf есть собственные MaxScanSize (общий объём данных, который антивирус готов просканировать в одном файле, включая вложенные архивы) и MaxFileSize (размер одного файла). Если хотя бы один из них ниже нужного лимита, письмо либо потеряет проверку вложения, либо будет отклонено как «слишком большое для сканирования» в зависимости от настроенной политики отказа. Дефолты у mailcow скромные: в antivirus.conf стоит max_size = 20971520 — это байты, 20 МБ; в clamd.conf — MaxScanSize 50M и MaxFileSize 25M. Файла external_services.conf в свежих версиях в репозитории нет: контейнер rspamd-mailcow создаёт его при старте с max_size = 3145728 (3 МБ) для oletools, если олефи не отключён через SKIP_OLEFY=y. Письма крупнее max_size Rspamd просто не отдаёт на этот сканер — отказа нет, но и проверки тоже.

Хуже всего то, что несогласованный лимит фильтра не всегда выглядит как понятное «письмо слишком большое». Postfix к этому моменту письмо уже принимает и передаёт в Rspamd через milter, а отказ или временная ошибка приходит оттуда — и в клиенте отправителя это может выглядеть как сбой сервера, а не как превышение размера. Поэтому при любой жалобе на большое вложение я смотрю два журнала сразу: docker compose logs --tail=300 postfix-mailcow и docker compose logs --tail=300 rspamd-mailcow, сопоставляя их по времени и queue ID.

• Postfix: message_size_limit в data/conf/postfix/extra.cf, в байтах
• Rspamd: max_message в data/conf/rspamd/local.d/options.inc, в мегабайтах (формат 50Mb)
• oletools: max_size в data/conf/rspamd/local.d/external_services.conf
• ClamAV через Rspamd: max_size в data/conf/rspamd/local.d/antivirus.conf
• ClamAV напрямую: MaxScanSize и MaxFileSize в data/conf/clamav/clamd.conf

Пятый лимит — в веб-клиенте SOGo, а не в Postfix

Даже если все четыре серверных лимита согласованы, письмо можно «упереть» ещё на одном рубеже — если пользователь прикрепляет вложение через веб-интерфейс SOGo (это штатный веб-клиент mailcow, не Roundcube — важно не путать конфигурации, если гуглите чужие инструкции для других почтовых систем). За это отвечают два параметра SOGo, оба в килобайтах: WOMaxUploadSize ограничивает объём данных, которые сервер вообще примет по HTTP PUT/POST (то есть саму загрузку файла в браузере до того, как письмо сформировано), а SOGoMaximumMessageSizeLimit — итоговый размер собираемого письма при отправке.

По умолчанию оба параметра равны 0, что в терминологии SOGo означает «лимит отключён», а не «лимит нулевой» — это стоит знать заранее, чтобы не спутать «отключено» с «запрещено». Если администратор задал жёсткий Postfix-лимит, но не тронул SOGo, у сотрудников, работающих через веб-почту, ограничения фактически нет — а вот если, наоборот, кто-то когда-то давно проставил в SOGo консервативное значение «для скорости работы интерфейса», оно тихо режет вложения, даже когда все остальные лимиты подняты правильно.

Для «Голоса и дыхания» именно так и оказалось на втором круге диагностики: Postfix, Rspamd и ClamAV после правок пропускали письмо с файлом на 45 МБ без проблем, но администраторы, ранее занимавшиеся системой, оставили в SOGo ограничение в 25 МБ «по старой памяти» — видимо, перенесённое с предыдущего почтового сервера. Сотрудники, которые прикрепляли афиши через Outlook по IMAP, лимита не замечали вовсе — он касается только пути через веб-интерфейс.

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

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

Практическое правило, которое мы применяем у клиентов: выставлять лимиты не одинаковыми по всей цепочке, а с небольшим запасом сверху вниз, начиная с транспортного уровня. Если нужный «полезный» размер вложения — 60 МБ, то message_size_limit в Postfix должен быть заметно выше: 60 × 1,37 ≈ 82 МБ, поэтому я ставлю 84 МБ — так учитываются накладные расходы MIME-кодирования (вложения в письме передаются в base64, что увеличивает объём данных примерно на треть от исходного файла — это отдельная тема, разобранная в статье про лимит вложения в Postfix, но здесь важно помнить только один вывод: конечный файл на диске у пользователя всегда меньше, чем размер письма, который считает Postfix).

Дальше max_message в Rspamd и оба max_size (oletools и ClamAV) выставляются на уровень не ниже, чем Postfix, иначе именно они станут новым узким местом, как это и произошло у «Голоса и дыхания» на первом заходе. MaxScanSize и MaxFileSize в самом ClamAV — туда же, вровень или с запасом, особенно если вложения бывают заархивированы: MaxScanSize считает суммарный объём данных после распаковки архива, и для ZIP с несколькими крупными файлами внутри этот показатель может оказаться неожиданно высоким даже при небольшом весе самого архива.

И только после серверной цепочки — SOGo, если сотрудники пользуются веб-почтой: WOMaxUploadSize и SOGoMaximumMessageSizeLimit выставляются на тот же порог. Мы обычно рекомендуем именно такую последовательность проверки, а не правку всех пяти мест одновременно вслепую — потому что при одновременной правке сложно понять, какой из параметров реально был узким местом, если что-то пойдёт не так и потребуется откат.

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

После правки extra.cf, options.inc, external_services.conf и antivirus.conf документация mailcow рекомендует перезапустить три контейнера, которые читают эти конфигурации при старте:

Команда из документации:

docker compose restart postfix-mailcow rspamd-mailcow clamd-mailcow

ClamAV читает clamd.conf при собственном рестарте, поэтому clamd-mailcow в списке обязателен, если менялись MaxScanSize/MaxFileSize; при этом docker compose up -d здесь не поможет: он пересоздаёт только контейнеры, у которых изменилось описание в compose-файле или образ, а правка смонтированных конфигов к этому не относится, и контейнеры продолжат работать со старыми значениями.

Если правили SOGo — там перезапуск отдельный: docker compose restart sogo-mailcow. Мы рекомендуем после любого из этих рестартов подождать 15–30 секунд и проверить состояние контейнеров командой docker compose ps, прежде чем гнать тестовое письмо — контейнер rspamd-mailcow при старте прогревает правила некоторое время, и тест «слишком рано» может дать ложный результат.

• Postfix/Rspamd/ClamAV: docker compose restart postfix-mailcow rspamd-mailcow clamd-mailcow
• SOGo: docker compose restart sogo-mailcow отдельной командой
• после рестарта — пауза 15-30 секунд, затем docker compose ps для проверки состояния
• тестовое письмо посылать только после того, как контейнеры вернулись в статус running/healthy

Итог по «Голосу и дыханию»: 80 МБ там, где нужно

Финальная конфигурация после согласования: message_size_limit 88080384 байт (84 МБ — файл до 60 МБ плюс base64) в Postfix, max_message = 84Mb в Rspamd, max_size = 88080384 у oletools и ClamAV в конфигурации Rspamd (там тоже байты — суффикс 84m в UCL означает 84 миллиона, то есть меньше, чем у Postfix), MaxScanSize и MaxFileSize по 90M в clamd.conf (чуть выше остальных, чтобы архивы с несколькими вложениями не упирались в сканирование), и WOMaxUploadSize/SOGoMaximumMessageSizeLimit по 86016 КБ в SOGo. Афиши до 60 МБ стали проходить и через Outlook, и через веб-почту одинаково.

Диагностика заняла у нас около двух часов вместе с проверкой каждого сервиса по отдельности — дольше, чем сама правка конфигурации, которая укладывается в пятнадцать минут. Основной урок для клиента: в mailcow «поднять лимит вложений» — это не одна настройка, а согласование пяти, и при жалобе на отклонённое письмо первым делом стоит смотреть не в Postfix, где искать интуитивно проще всего, а в журнал Rspamd — именно там чаще всего обнаруживается реальная причина отказа.

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

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