После перехода на Zimbra 10 не прикрепляются Word и Excel: где настраивается блокировка типов файлов

После обновления до Zimbra 10 сотрудники не могут прикрепить к письму обычный договор в .docx или прайс в .xlsx — веб-клиент просто отклоняет загрузку. Расширения не поменялись, антивирус ни при чём. В Zimbra за блокировку вложений отвечают минимум три независимых механизма, и после мажорного обновления чаще всего срабатывает не тот, который администратор проверяет в первую очередь.

Три разных механизма блокировки вложений в Zimbra

Первый — zimbraMtaBlockedExtension, глобальный атрибут уровня MTA. Он хранит список расширений вложений, которые блокируются при прохождении письма через MTA Zimbra, независимо от того, через какой клиент оно ушло; в справочнике атрибутов Zimbra 10 он отнесён к антиспам-подсистеме, то есть проверку выполняет контент-фильтр на MTA, а не веб-клиент. По умолчанию он пуст, а стандартный набор «опасных» расширений лежит в соседнем атрибуте zimbraMtaCommonBlockedExtension (asd, bat, cmd, exe, js, scr, vbs и другие). Настраивается в консоли администратора в Global Settings → Attachments или через zmprov mcf +zimbraMtaBlockedExtension <ext>. Это самый старый и самый грубый механизм: он смотрит на расширение в имени вложения, а не на содержимое.

Второй — zimbraFileUploadBlockedFileTypes, атрибут уровня CoS и аккаунта, появившийся только в Zimbra 10.0.0. Он работает в mailboxd и блокирует загрузку файла в веб-клиенте, причём его список смешанный: в нём и расширения, и MIME-типы с масками. Включается он отдельным переключателем zimbraFeatureFileTypeUploadRestrictionsEnabled. Главное отличие от MTA — блокировать можно по типу файла независимо от расширения, и именно маски по типу дают неожиданные срабатывания. Если у вашей компании настроена корпоративная почта на своей инфраструктуре, оба механизма стоит держать в голове как отдельные слои, а не один общий «фильтр вложений».

Третий, отдельно стоящий — zimbraAttachmentsBlocked, булев атрибут на уровне account/CoS/globalConfig. Он не имеет отношения к загрузке новых файлов: включённый в TRUE, он запрещает скачивание уже полученных вложений целиком, для всех писем сразу. Симптомы у всех трёх механизмов разные, но администратор, который не в курсе структуры, часто проверяет не тот атрибут — например, ищет расширение .docx в блок-листе MTA, хотя реальная проблема на уровне CoS.

Что изменилось в Zimbra 10 и почему проблема не была видна раньше

В решённом обсуждении на форуме Zimbra «Zimbra 10 — Can't Upload Microsoft Office Documents» (январь 2024 года) после rolling upgrade пользователи начали получать отказ при загрузке офисных документов именно через веб-клиент, хотя раньше на той же версии CoS всё работало. Причина была найдена в zimbraFileUploadBlockedFileTypes: в списке блокировки на CoS присутствовали значения-шаблоны вида application/x-ms* и application/x-dosexec, явно предназначенные для блокировки исполняемых файлов Windows. И это не чья-то давняя самодеятельность: по справочнику атрибутов Zimbra 10.0.0 именно application/x-ms* и application/x-dosexec входят в значение zimbraFileUploadBlockedFileTypes по умолчанию — вместе со списком расширений asd, bat, chm, cmd, com, dll, exe, js, lnk, scr, vbs и другими. Атрибута до 10-й версии не существовало, поэтому он и «появился» ровно в момент обновления.

Проблема в том, что application/x-ms* — это маска, а не точное совпадение с одним типом. По выводам из того же обсуждения, под неё попали и типы, которые на той инсталляции присваивались файлам Microsoft Office, поэтому легитимные .docx и .xlsx начали блокироваться вместе с исполняемыми файлами. Какой именно MIME-тип получит файл при загрузке, зависит от браузера и системы пользователя, поэтому один сотрудник может жаловаться, а у соседа тот же документ прикрепляется, — я бы не пытался угадывать и просто проверял бы фактический список на своём CoS. Практический вывод: после перехода на 10-ю версию список zimbraFileUploadBlockedFileTypes нужно посмотреть глазами, даже если вы его никогда не настраивали. Если апгрейд ещё только предстоит, заодно сверьтесь с матрицей апгрейд-путей Zimbra: в тот же чек-лист после обновления стоит вписать и этот атрибут.

Как проверить, что заблокировано именно так

Смотреть список блокировки для действующего CoS можно так:

zmprov gc default zimbraFileUploadBlockedFileTypes

(вместо default — имя вашего CoS, если используется не стандартный класс обслуживания). Если в выводе присутствуют шаблоны вроде application/x-ms* — это кандидат номер один, особенно если проблема появилась синхронно с обновлением, а не с конкретной датой изменения настроек администратором.

Стоит также проверить, включена ли сама проверка — за это отвечает булев атрибут zimbraFeatureFileTypeUploadRestrictionsEnabled (CoS или аккаунт). В справочнике 10.0.0 по умолчанию указано FALSE, но в описанном на форуме случае ограничение действовало, поэтому смотрите фактическое значение, а не справочное. Если он выключен, содержимое zimbraFileUploadBlockedFileTypes ни на что не влияет и искать проблему нужно в другом месте — например, в zimbraMtaBlockedExtension на стороне MTA или в антивирусной проверке вложений, если она настроена отдельно.

И не забывайте, что оба атрибута задаются не только на CoS, но и на аккаунте, а значение на аккаунте перекрывает значение класса обслуживания. Если жалуется один сотрудник, а у остальных всё прикрепляется, я первым делом смотрю zmprov ga user@example.com zimbraFileUploadBlockedFileTypes zimbraFeatureFileTypeUploadRestrictionsEnabled — это показывает итоговые значения для конкретного человека. Атрибуты помечены как доступные делегированному администратору домена, поэтому индивидуальную настройку мог оставить кто угодно из тех, у кого были права в консоли.

Отдельно от CoS стоит свериться с глобальным списком расширений:

zmprov gcf zimbraMtaBlockedExtension

Это разные списки на разных уровнях, и совпадение расширения в одном ничего не говорит о содержимом другого. Если оба списка чисты, а файл всё равно не загружается, переходите к содержимому вложения: возможно, сработал не блок-лист вовсе, а антивирусная или DLP-надстройка, которая в этой статье не рассматривается.

Кейс: книжный магазин и договор, который отказывался прикрепляться

У условного клиента — книжного магазина «Страница за страницей», 24 рабочих места — после планового перехода на Zimbra 10 бухгалтер пожаловалась, что не может прикрепить к письму поставщику подписанный договор в .docx. Ошибка в веб-клиенте была общей — «файл не может быть загружен», без конкретики про блокировку по типу. Расширения .docx не было ни в одном привычном списке запрещённых вложений, и приходящий администратор сначала грешил на браузер.

Проверка zmprov gcf zimbraMtaBlockedExtension ничего подозрительного не показала — на уровне MTA .docx никогда не блокировался. Дальше проверили CoS: zmprov gc default zimbraFileUploadBlockedFileTypes вернул список с двумя шаблонами — application/x-ms* и application/x-dosexec, — это значения по умолчанию, которые пришли вместе с Zimbra 10, а zmprov gc default zimbraFeatureFileTypeUploadRestrictionsEnabled вернул TRUE: проверка на этом CoS была включена. Именно первый шаблон и зацепил тип, который браузеры в магазине присваивали документам Word и Excel.

Убрали проблемный шаблон точечно, не затрагивая остальной список:

zmprov mc default -zimbraFileUploadBlockedFileTypes 'application/x-ms*'

Знак минус перед именем атрибута в zmprov убирает конкретное значение из многозначного списка, а не весь атрибут целиком — это важно, потому что остальные шаблоны (в том числе application/x-dosexec) остались в силе и продолжили блокировать реальные исполняемые файлы. В нашем случае перезапускать службы не пришлось — пользователям хватило перезайти в веб-клиент. После правки договор в .docx и прайс-лист в .xlsx прикрепились без ошибок, а способность блокировать .exe-вложения никуда не делась.

Почему нельзя просто отключить блокировку целиком

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

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

Держать список блокировки в порядке — это ещё и часть базовой защищённости самого почтового сервера, а не только удобство сотрудников. У меня отдельно разобран случай SQL-инъекции и SSRF в Zimbra — он про другой класс уязвимостей, но общий принцип тот же: закрывать нужно точечно уязвимое место, а не выключать сразу весь защитный механизм ради быстрого решения одной жалобы.

Чек-лист после мажорного обновления Zimbra

После любого перехода на новую мажорную версию Zimbra я прохожу по спискам блокировки вложений отдельным пунктом чек-листа, не дожидаясь первой жалобы пользователей. Особенно это касается компаний, где CoS настраивался много лет назад и с тех пор не пересматривался — шаблоны в таких списках почти всегда унаследованы «по умолчанию» и никем не документированы, а новые атрибуты вроде zimbraFileUploadBlockedFileTypes приходят со своими значениями по умолчанию, о которых никто не знает, пока не пожалуется бухгалтерия.

Полезно сохранять текущее состояние списков перед обновлением и после него, чтобы сравнить разницу, а не полагаться на память:

zmprov gc default zimbraFileUploadBlockedFileTypes > cos-blocked-before.txt
zmprov gcf zimbraMtaBlockedExtension > mta-blocked-before.txt

Если после обновления пользователи жалуются на конкретные типы файлов — сравнение списков до и после сразу показывает, что изменилось на стороне конфигурации, а что — в логике самой Zimbra. Откладывать обновление до последнего тоже не выход: я подробно писал, что происходит с сервером, который остаётся на версии Zimbra после окончания поддержки — там риски накапливаются заметно быстрее, чем один неверный шаблон блокировки в CoS.

• zmprov gc default zimbraFileUploadBlockedFileTypes — блокировка по content type на уровне CoS
• zmprov gcf zimbraMtaBlockedExtension — блокировка по расширению на уровне MTA
• zmprov gc default zimbraFeatureFileTypeUploadRestrictionsEnabled — включена ли проверка вообще
• zmprov gc default zimbraAttachmentsBlocked — блокировка не загрузки, а скачивания вложений
• zmprov mc default -zimbraFileUploadBlockedFileTypes '<шаблон>' — точечное удаление одного значения

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