Как разобрать очередь Zimbra по ID и ответам доставки

Если очередь Zimbra растёт, сначала найдите последнее сообщение об ошибке у конкретного письма, проверьте его возраст и адресатов. Затем отделите сбой внешней доставки от проблемы своего сервера. Я покажу, как читать очередь и журналы, проверять DNS и подтверждать восстановление доставки, сохраняя письма до выяснения причины.

С чего начать: службы, возраст и ID письма

Когда мне говорят, что почта зависла, я сначала уточняю направление: наружу, внутрь или между сотрудниками. При диагностике корпоративной почты Zimbra это разные маршруты и разные следующие узлы. Внешняя отправка может остановиться у получателя, а локальная — на передаче в почтовое хранилище. Я записываю время жалобы, адрес отправителя, адрес получателя и время отправки контрольного сообщения. Формулировка «ничего не работает» для директора понятна; для поиска в журнале она бесполезна. Нужен хотя бы один проверяемый пример.

В типовой установке консоль администратора доступна по шаблону https://mail.example.com:7071/, где имя нужно заменить своим. Адрес и порт конкретной установки могут отличаться. В интерфейсе я открываю Monitor → Mail Queues и смотрю очередь именно нужного MTA. Active означает текущую обработку доставки, Deferred — отложенную попытку. Отдельно проверяю Hold: такие сообщения ждут решения администратора, автоматических попыток для них нет. Одно число по всем состояниям прячет эти различия. На нескольких MTA я собираю сведения с каждого узла, через который проходит проблемная почта.

В командной строке я проверяю службы штатной командой Zimbra, затем читаю очередь. Следующий пример рассчитан на установку с утилитами Postfix в /opt/zimbra/common/sbin; перед выполнением сверяю расположение с документацией своей сборки. Переход в учётную запись zimbra выполняю из административной сессии. Все три команды здесь только читают состояние:

su - zimbra
zmcontrol status
/opt/zimbra/common/sbin/postqueue -p

Системный диспетчер служб полезен для проверки ОС, но одной его общей зелёной строки недостаточно для оценки компонентов Zimbra. Из вывода очереди я сохраняю ID, время поступления, отправителя, оставшихся адресатов и последнюю причину задержки.

Снимок без времени быстро устаревает. Я повторяю измерение через выбранный интервал и сравниваю не только размер очереди, но и движение тех же сообщений: исчезают ли старые, прибывают ли новые, меняется ли причина отказа. Молодые письма не доказывают нехватку канала: похожую картину дают ограничения получателя, массовая рассылка или локальная задержка обработки. Старое письмо тоже не становится мусором от возраста. Общие причины разобраны отдельно в статье про очередь Postfix при работающем сервере; здесь я привязываю проверку к очередям и журналам Zimbra.

• Зафиксировать направление сбоя и контрольное письмо.
• Проверить компоненты через zmcontrol status.
• Снять очередь нужного MTA через postqueue -p.
• Записать ID, время поступления, адресатов и ошибку.
• Сравнить повторный снимок с исходным.

Как читать 421, 450, 452 и 550 без гадания

Я начинаю с полного ответа следующего узла. Класс 4xx означает временный отказ: отправитель сохраняет ответственность за повторную попытку. Класс 5xx означает постоянный отказ для текущей операции: механически повторять ту же команду без изменений не следует. Но один класс ответа ещё не объясняет причину. Нужны текст, этап SMTP-сеанса и адрес узла, который ответил. Если соединение оборвалось вообще без ответа, придумывать ему код 421 нельзя. Код ошибки — полезная зацепка. До диагноза ему ещё работать и работать.

Ответы читаю по RFC 5321, без народных переводов. 421 сообщает, что сервис недоступен и закрывает канал; сам по себе он не доказывает поломку сети. 450 — временная недоступность почтового ящика, в том числе из-за временного ограничения политикой; это не справка о технических работах у провайдера. 452 означает нехватку системного хранилища, но не позволяет автоматически объявить переполненной квоту конкретного пользователя. 550 означает недоступность ящика: возможны неверный адрес, отсутствие доступа или отказ по политике. Поэтому я сохраняю продолжение строки, а не выписываю голые три цифры.

Совет удалить все сообщения с 5xx я считаю технически неверным. При окончательном отказе доставки уже принятого сообщения Postfix обычно формирует отправителю уведомление о недоставке. Сообщение с несколькими адресатами может при этом сохраняться для тех, кому доставка ещё не завершена. Если отказ получен до принятия письма вашим сервером, в его очереди этого письма может вообще не быть. Я проверяю судьбу каждого адресата и уведомления, а не ищу отдельную корзину постоянных ошибок. Повторную отправку после исправления адреса или политики согласую с отправителем, чтобы не создавать дубликаты.

Дальше группирую задержки по следующему узлу, домену получателя и одинаковому тексту ответа. Если почти все отказы относятся к одному домену, проверяю его отдельно; если разным доменам мешает одна локальная ошибка, начинаю со своего сервера. Внутренняя доставка требует проверки следующего узла и квоты соответствующего ящика, а не обещания, что любой 452 лечится увеличением лимита. При отказах по политике мне помогает отдельный разбор ошибки 550 в Zimbra. Перезапуск наугад здесь только стирает удобный момент для наблюдения.

Как проверить DNS и сеть, сохранив внутреннюю схему

Проверку DNS я запускаю с самого MTA. Ответ на ноутбуке администратора не доказывает, что почтовый процесс пользуется тем же резолвером и получает те же данные. Для проблемного домена сначала проверяю MX, затем адреса выбранного почтового узла и результат соединения с ним. Отдельно отмечаю, чем закончился запрос: ответом, отсутствием записи, ошибкой разрешения или таймаутом. Конкретную длительность задержки измеряю на этом сервере. Универсальные обещания про несколько десятков секунд на каждый DNS-запрос к диагностике отношения не имеют.

Менять /etc/resolv.conf на случайный публичный DNS я не начинаю. В экспертной базе есть полезная деталь: в Zimbra со split DNS собственное имя сервера может разрешаться во внутренний адрес для локальных запросов и во внешний для запросов из интернета. Такая схема позволяет внутреннему обмену не зависеть от лишнего прохода через маршрутизатор. Публичный резолвер внутреннюю зону не заменяет. Я сначала сохраняю текущую конфигурацию, проверяю внутренние имена и внешнее разрешение, затем исправляю конкретную неисправность в действующей схеме. Чужой DNS — не отвёртка от любой почтовой поломки.

По сети я проверяю разрешённый маршрут к следующему узлу. Для обычных запросов к DNS нужны UDP и TCP на порту 53 до используемых резолверов; для прямой межсерверной доставки SMTP — TCP 25 до принимающего MTA. Если настроен почтовый ретранслятор, проверяю его адрес и фактический порт из конфигурации. Совет открыть исходящие порты без разбора я заменяю проверкой правил, маршрута и ограничений площадки. Даже установленное соединение ещё не означает доставку: следующий узел может ответить временным ограничением уже во время SMTP-сеанса. Я записываю и сетевой результат, и ответ приложения.

SPF, DKIM, DMARC и обратная запись PTR проверяю тогда, когда ответ получателя указывает на аутентификацию, репутацию или соответствующую политику. Их отсутствие не объясняет автоматически любой таймаут DNS. Ошибка разрешения имени и отклонение письма по политике — разные наблюдения. Для актуальной ссылки на DMARC использую RFC 9989; RFC 7505 описывает Null MX, то есть явное объявление домена, что он не принимает почту. Если приходится менять DNS, я фиксирую прежнее и новое значение, время изменения и ответы используемых резолверов. Затем проверяю доставку заново, не объявляя успех по одному удачному запросу.

• Проверить MX и адрес следующего узла с MTA.
• Разделить таймаут, ошибку DNS и отказ SMTP.
• Сохранить внутреннее разрешение имён при split DNS.
• Проверить нужные направления трафика и правила доступа.
• Проверять аутентификацию по тексту отказа получателя.

Разбор «Практики плюс»: две причины в одной очереди

Возьму условный центр обучения «Практика плюс» из Подмосковья: 30 рабочих мест, почта на Zimbra. Ниже учебный сценарий, а не отчёт об инциденте с подтверждённым хронометражем. Допустим, в очереди 240 сообщений: 180 адресованы одному внешнему домену и получают 450 с текстом временного ограничения; у остальных 60 последняя ошибка связана с разрешением имён других доменов. Для простоты у каждого сообщения один получатель. Я намеренно разделяю группы: одна цифра 240 скрывает два независимых направления проверки. Рабочие места здесь описывают размер офиса, а не нормальную длину очереди.

Для первой группы я сохраняю полный ответ принимающего узла и проверяю, что остальные внешние направления доставляются. Код 450 подтверждает временный отказ; утверждать по нему, что у получателя идут плановые работы, нельзя. Уточнение причины требует ответа принимающей стороны или другого надёжного свидетельства. Во второй группе я воспроизвожу ошибку разрешения с MTA и проверяю используемый резолвер. В рамках этого сценария предположим, что обнаружен сбой внешнего разрешения на внутреннем DNS. Исправляю его, сохраняя локальную зону. Настройки Zimbra целиком и квоты всех сотрудников ради этой гипотезы не трогаю.

После исправления DNS снимаю очередь повторно. Допустим, все 60 сообщений второй группы доставились, новые письма к этим доменам тоже проходят, а 180 сообщений первой группы остались. При отсутствии новых поступлений счёт сходится: 240 минус 60 равно 180. Это проверяемый частичный результат, а не повод закрыть обращение. Первую группу продолжаю наблюдать до снятия внешнего ограничения или окончательного результата доставки. Для каждого изменения отмечаю время и подтверждение в журнале. Если часть сообщений получила окончательный отказ, считаю их отдельно от доставленных: уменьшившийся график не превращает отказ в успех.

Итог такого разбора я оформляю двумя строками ответственности: локальное разрешение восстановлено и проверено; внешнее ограничение подтверждено ответом следующего узла и остаётся под наблюдением. Срок окончательной доставки заранее не выдумываю. Точную версию и сборку Zimbra в рабочем обращении записываю с обслуживаемого сервера; в условный пример номер ради солидности не вставляю. Владелец бизнеса получает список задержанных сообщений, понятную причину по каждой группе и условие следующей проверки. Это полезнее рассказа, что после большого перезапуска «вроде всё ожило». Вроде — плохой статус для отправленного счёта.

Где искать письмо и сколько ещё можно ждать

Основной журнал транспортной части Zimbra — /var/log/zimbra.log. Для проблем на стороне почтового приложения я дополнительно проверяю /opt/zimbra/log/mailbox.log. Наличие /var/log/maillog зависит от настройки системного журналирования, поэтому обязательным вторым журналом Zimbra я его не называю. Я ищу события по ID письма, затем сверяю отправителя, адресатов и время. Если обработка создала новый ID, продолжаю цепочку по связанным записям. Старый ID нельзя считать вечным паспортом письма: важно сопоставление с его реквизитами. При передаче через несколько MTA проверяю последовательность на всех участвующих узлах.

Ещё один факт из базы, который нельзя упускать: повторные попытки не бесконечны. В Postfix параметр maximal_queue_lifetime ограничивает время, после которого недоставленное сообщение считается недоставимым; штатное значение Postfix — 5d, то есть пять дней. Это значение по умолчанию, а не обещание для любой Zimbra: действующую настройку я читаю на конкретном MTA. Для установки с указанным выше расположением утилит выполняю под zimbra:

/opt/zimbra/common/sbin/postconf maximal_queue_lifetime

Уведомления о недоставке имеют собственные настройки, а сообщения в Hold требуют отдельного разбора. Увеличивать срок хранения только ради спокойного графика я не предлагаю.

После устранения причины я наблюдаю обычные повторные попытки. При необходимости запускаю контролируемую попытку для выбранного сообщения штатным средством своей версии, предварительно сверив его реквизиты. Многократный общий Flush не ускоряет ремонт недоступного DNS или снятие чужого ограничения и способен добавить нагрузку. Перед любым удалением мне нужны установленная причина, проверенное содержимое, согласованное решение о судьбе переписки и сохранённые диагностические сведения. Файлы очереди вручную не правлю. Если очередь заполняет нежелательная рассылка, сначала ограничиваю её источник, затем отдельно решаю судьбу уже принятых сообщений.

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

Что контролировать после восстановления доставки

Для постоянного наблюдения я выбираю несколько связанных показателей: размер очереди по состояниям, возраст старейших ожидающих сообщений, скорость поступления и завершения доставки, основные причины задержки. Один порог вроде тысячи писем для любого офиса не годится. У небольшой организации десятки застрявших счетов могут быть важнее большой штатной рассылки. Порог задаю по обычной нагрузке, допустимой задержке бизнеса и фактическому сроку хранения в очереди. Отдельно отслеживаю отсутствие новых данных: молчащий сборщик не должен рисовать здоровый ноль. Красивая панель умеет успокаивать лучше валерьянки; доставлять письма она пока не научилась.

Сигнал о росте очереди связываю с конкретным действием дежурного: определить проблемное направление, взять примеры сообщений, прочитать последнюю ошибку и проверить следующий узел. Уведомление должно уходить по независимому каналу, иначе его задержит та же почта. Доступность веб-интерфейса проверяю отдельно от доставки: работающий вход в ящик не подтверждает исправность внешней отправки. В рабочий регламент включаю контрольное письмо и проверку результата по обе стороны маршрута. При изменении DNS или сетевых правил повторяю этот контроль. Изменения без записи предыдущих значений делают следующую аварию дороже, даже если текущая случайно закончилась.

Резервную копию я тоже проверяю предметно. Одной базы данных и конфигурационных файлов недостаточно для восстановления всей переписки: нужны согласованные данные сообщений и необходимые компоненты Zimbra в рамках выбранного способа копирования. Состав и процедуру восстановления сверяю с документацией установленной редакции. Затем восстанавливаю тестовый ящик в отдельной среде и проверяю доступность писем и вложений. Наличие копии пользовательских ящиков само по себе не означает, что в неё попали сообщения, ожидающие доставки в очереди MTA. Поэтому текущую очередь не воспринимаю как материал, который можно бездумно удалить и потом достать из любого бэкапа.

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

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