В Zimbra разрешили письма до 50 МБ, а вложение на 40 МБ не отправляется: какой лимит на самом деле сработал

Если в Zimbra подняли zimbraMtaMaxMessageSize до 50 МБ, а вложение на 40 МБ всё равно не уходит — сработал не тот лимит, который вы меняли. У размера письма в Zimbra минимум три независимых потолка, а при публикации через прокси — четыре, и срабатывают они на разных этапах. Ниже — какой лимит за что отвечает, как поднимать их вместе и как я разбирал похожий случай на 40 рабочих местах.

Три места, где Zimbra считает размер письма

Когда администратор говорит «увеличил лимит вложений в Zimbra», чаще всего он поменял один атрибут — zimbraMtaMaxMessageSize. Это глобальная настройка (globalConfig), и она ограничивает не файл, а полное письмо в формате RFC 2822 после MIME-кодирования — то есть уже с учётом заголовков и base64. По справочнику атрибутов Zimbra 10 этот лимит проверяется в самом mailbox-сервере и одновременно подставляется в параметр message_size_limit Postfix; значение 0 означает «без ограничений». То есть он работает и на отправке из веб-клиента, и на приёме по SMTP, а ещё, по данным Zimbra Tech Center, ограничивает IMAP APPEND — копирование большого письма в папку из Outlook или Thunderbird. Если у вас в компании настроена корпоративная почта на своём сервере, этот атрибут — первое, что стоит проверить при жалобах на «не отправляется большое письмо», но далеко не единственное.

Отдельно от MTA существует zimbraFileUploadMaxSize — лимит размера файла, который веб-клиент разрешает загрузить в форму составления письма; по Tech Center под него попадают и файлы, загружаемые инструментами импорта. Он задаётся на уровне globalConfig и может переопределяться на сервере (serverInherited), и именно он первым обрубает загрузку, если пользователь прикрепляет файл через браузер: SMTP тут вообще ни при чём, потому что письмо ещё не сформировано. Третий рубеж — zimbraMailContentMaxSize, ограничение размера элемента <content> в SOAP-ответах mailboxd, через которые веб-клиент получает содержимое письма; по описанию атрибута содержимое сверх лимита усекается, а не отклоняется. На практике это выглядит как «письмо пришло, но показано не целиком», и Tech Center в своём примере поднимает этот атрибут вместе с двумя другими.

Три атрибута решают разные задачи и в проде почти никогда не имеют смысла порознь. У меня в проектах правило простое: если меняете лимит вложений — меняете все три атрибута одним заходом, а не по одному после каждой новой жалобы пользователей. Слишком большой SOAP-запрос с вложением, который прошёл мимо лимитов, но упёрся в память самого mailboxd, — уже другая история: про OutOfMemoryError в mailboxd я разбирал отдельно, там вложение формально укладывалось в лимит, но раздувало Java heap на обработке.

Почему 40-мегабайтный файл превращается в письмо на 55 МБ

MIME-кодирование по умолчанию использует base64, а он увеличивает объём двоичных данных примерно на треть — на кодирование каждые 3 байта уходят 4 символа, плюс переносы строк и заголовки. Официальная страница Zimbra про настройку maxmessagesize прямо предупреждает: значение zimbraMtaMaxMessageSize — это размер полного интернет-сообщения после кодирования, а не размер файла, который пользователь выбрал в проводнике. Там же сказано, что предсказуемого процента прироста нет: цифра 137 % приводится как возможное среднее, а рекомендация Zimbra — закладывать 150 %, чтобы не подкручивать атрибуты каждый месяц. Их собственный пример: политика «до 25 МБ до кодирования» превращается в значение около 38 МБ в настройках.

Отсюда практическая ошибка, которую я вижу регулярно: администратор округляет «нужно слать файлы до 40 МБ» до zimbraMtaMaxMessageSize 40000000 и на этом останавливается. Уже закодированное письмо с 40-мегабайтным вложением легко перевалит за эту границу, и Postfix отклонит его на приёме — причём чаще всего с кодом 552 5.3.4 message size exceeds fixed limit, а не с понятной формулировкой про вложения. Поэтому лимит на MTA я всегда считаю с запасом: беру целевой размер вложения, умножаю на 1,5, как советует Zimbra, и только потом округляю итог до круглого числа.

Есть и обратная сторона запаса, о которой вспоминают только после аварии. Postfix перед приёмом письма проверяет, что на разделе с очередью свободно не меньше полутора лимитов message_size_limit. Tech Center прямо предупреждает: если выставить zimbraMtaMaxMessageSize слишком большим, а места под очередью мало, MTA начнёт отвечать 452 4.3.1 Insufficient system storage и перестанет принимать вообще всю почту, а не только большие письма. Поэтому гигабайтные лимиты «чтобы точно хватило» я не ставлю никогда: 50–60 МБ для офиса на 40 человек — разумный потолок, а всё крупнее лучше отдавать ссылкой на файловое хранилище.

Почему zmprov ms падает с attribute not allowed

Вторая типичная ошибка — попытка задать zimbraMtaMaxMessageSize командой modifyServer, zmprov ms mail.example.com zimbraMtaMaxMessageSize 52428800. На форуме Zimbra разбирали такой случай на NE 8.7.11 Patch 11: команда завершалась ошибкой attribute not allowed, и это не баг, а следствие того, что у атрибута только один допустимый уровень — globalConfig. Менять его нужно через modifyConfig:

zmprov mcf zimbraMtaMaxMessageSize 52428800
zmprov gcf zimbraMtaMaxMessageSize

Значение указывается в байтах, поэтому 50 МБ — это 52428800 (50 × 1024 × 1024), а не «50000000 для ровного счёта». После изменения я всегда сверяю, что оно реально дошло до Postfix, а не осталось только в LDAP-конфиге Zimbra:

su - zimbra -c 'postconf message_size_limit'

Если значение не совпало — конфигурация MTA ещё не перечитана. Значение хранится в LDAP Zimbra и переносится в postconf служебным zmmtaconfig; в инструкции Tech Center после zmprov modifyConfig выполняется обычная перезагрузка Postfix от пользователя zimbra:

su - zimbra -c 'postfix reload'

С атрибутами mailboxd сложнее: если zimbraFileUploadMaxSize и zimbraMailContentMaxSize не подхватились через некоторое время, Tech Center рекомендует полный zmcontrol restart на mailstore-серверах. Я закладываю это в окно работ сразу, а не жду, пока пользователи скажут, что «ничего не изменилось».

Кейс: разрешили 50 МБ, а 40 МБ всё равно не уходит

У условного клиента — магазина сумок «Ремень и застёжка», 40 рабочих мест — бухгалтерия жаловалась, что не может отправить поставщику прайс с фотографиями на 40 МБ, хотя за неделю до этого админ «поднял лимит писем до 50 МБ». Проверка показала: zmprov gcf zimbraMtaMaxMessageSize действительно вернул 52428800 — администратор всё сделал правильно на уровне MTA. Ошибка была не там.

В логах mailboxd (/opt/zimbra/log/mailbox.log) при попытке прикрепить файл через веб-клиент вообще не появлялось обращения к Postfix — запрос обрывался раньше, в самой Zimbra Web Client. Командой zmprov gcf zimbraFileUploadMaxSize мы получили значение по умолчанию — 10485760 байт, то есть ровно 10 МБ. Веб-клиент отклонял загрузку файла ещё до формирования письма, и лимит на MTA до этого момента просто не успевал сработать: 40-мегабайтный файл не проходил самый первый барьер.

Исправили глобально (mcf меняет globalConfig для всех серверов, а не для одного домена) и проверили результат:

zmprov mcf zimbraFileUploadMaxSize 62914560
zmprov mcf zimbraMailContentMaxSize 62914560
zmprov gcf zimbraFileUploadMaxSize zimbraMailContentMaxSize zimbraMtaMaxMessageSize

Значение 62914560 байт (60 МБ) для загрузки и SOAP-контента выбрали с запасом сверх лимита MTA в 50 МБ — чтобы узким местом при похожих запросах в будущем снова не оказался забытый атрибут. Поскольку атрибуты mailboxd сразу не подхватились, вечером после закрытия магазина сделали zmcontrol restart — простой занял около пяти минут. После этого тестовое письмо с вложением 40 МБ ушло с первой попытки, а бухгалтерия перестала обходить лимит через архиваторы и облачные ссылки в подписи.

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

Как проверить, какой лимит сработал на самом деле

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

Если письмо формально дошло, но в веб-клиенте его содержимое показано не целиком, — это уже про zimbraMailContentMaxSize, а не про закрытую дверь на входе. А если большое письмо не копируется в папку из Outlook или Thunderbird по IMAP, вспомните, что IMAP APPEND ограничен тем же zimbraMtaMaxMessageSize. Полезно проверять три значения одной командой и сравнивать их между собой, а не гадать:

zmprov gcf zimbraMtaMaxMessageSize zimbraFileUploadMaxSize zimbraMailContentMaxSize

Для входящей почты удобно проверить лимит снаружи: подключиться к MTA по порту 25 и посмотреть, что сервер объявляет в ответ на EHLO в строке SIZE. Если отказ пришёл от чужого шлюза с текстом вроде 552 5.3.4 Error: message file too big, дело уже не в вашей Zimbra — это лимит получателя, и поднимать свои атрибуты бесполезно.

Отдельно стоит держать в голове, что у меня уже был похожий разговор про Postfix и запас в message_size_limit — там разбирался тот же принцип запаса на кодирование, но без слоя Zimbra Web Client поверх MTA. В Zimbra веб-клиент добавляет ещё один независимый барьер, которого нет в голом Postfix, и про него часто забывают именно потому, что он не имеет отношения к почтовому протоколу.

Что менять вместе, если поднимаете лимит вложений

Чтобы не возвращаться к теме через неделю после первой жалобы, я поднимаю лимиты пакетом, а не по одному атрибуту за раз. Порядок значений такой: сначала считаю целевой размер вложения, которое реально нужно бизнесу — не «на всякий случай побольше», а исходя из типовых файлов (прайсы, сканы, видео с камер). Затем закладываю запас на MIME-кодирование для MTA и только потом привожу веб-загрузку и SOAP-контент к значению не меньше лимита MTA.

Стоит помнить и о встречной стороне: если вы принимаете большие вложения, но у получателя стоит собственный лимит на 25 МБ (частая настройка у бесплатных почтовых сервисов), письмо всё равно вернётся отказом — уже не по вашей вине. Поэтому вместе с изменением лимитов я обычно советую клиенту завести отдельную инструкцию для сотрудников: что делать с файлами больше 25–30 МБ при отправке во внешние домены, чтобы не тратить время на разбор одинаковых обращений.

Если веб-клиент Zimbra у вас опубликован не напрямую, а через отдельный reverse-proxy, к трём внутренним лимитам добавляется ещё один независимый барьер снаружи. Логика там та же, что я разбирал в статье о том, почему nginx отдаёт 413 при уже поднятых внутренних лимитах: client_max_body_size у nginx нужно поднимать отдельно и согласованно с zimbraFileUploadMaxSize, иначе прокси отклонит запрос ещё до того, как он вообще дойдёт до mailboxd.

• zmprov gcf zimbraMtaMaxMessageSize — лимит письма в mailboxd и Postfix, байты, только globalConfig
• zmprov mcf zimbraFileUploadMaxSize — лимит загрузки файла в веб-клиенте (можно переопределить на сервере)
• zmprov mcf zimbraMailContentMaxSize — лимит элемента content в SOAP
• postconf message_size_limit — проверка, что значение реально дошло до Postfix
• postfix reload от zimbra — применить лимит MTA; zmcontrol restart — если не подхватились атрибуты mailboxd

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