Письмо застряло в Zimbra: разбираю ошибки антиспама

Чтобы исправить ложные срабатывания антиспама Zimbra, я сначала выясняю судьбу конкретного письма: отказ при приёме, очередь, папка «Спам» или карантин. Затем проверяю правило и область его действия. Тестовый ящик помогает наблюдать доставку; серверные пороги проверяю в отдельной среде и меняю с готовым откатом.

Где искать письмо, которое Zimbra назвала спамом

Я начинаю с карточки обращения: кто отправил письмо, кому, когда и в каком часовом поясе, какая тема, есть ли исходник сообщения или уведомление о недоставке. Формулировка «почта пропала» для диагностики слишком щедрая: под неё подходят разные неисправности. Если письмо есть в папке «Спам», сервер уже принял его и доставил в ящик. Если отправитель получил отказ, сначала разбираю ответ принимающего узла. Если сообщение осталось в очереди, ищу причину задержки. Так я выстраиваю обслуживание корпоративной почты: от судьбы сообщения к настройке, которая на неё повлияла. Общий регулятор строгости пока не трогаю.

В штатной связке Zimbra Postfix отвечает за передачу почты, Amavisd-new связывает его с проверками содержимого, SpamAssassin оценивает спам, ClamAV проверяет вредоносные файлы. Это разные задачи. Снижение строгости антиспама само по себе не означает отключения антивируса, а остановка общего компонента может затронуть несколько проверок. Поэтому я записываю, какой механизм вынес решение и что именно предлагается изменить. Для первичного поиска событий MTA использую /var/log/zimbra.log; после централизованного сбора журнал может находиться в принятом у организации хранилище. Отсутствие строки в одном файле ещё не доказывает, что отправки не было.

В найденных событиях связываю адреса, время и идентификаторы очереди; при повторной постановке письма в очередь идентификатор может измениться. У доставленного сообщения сохраняю полный исходник с заголовками, итогом проверки и перечнем сработавших правил, если фильтр их добавил. Один красный значок в интерфейсе причину не объясняет. Отдельно проверяю, не переложил ли сообщение пользовательский фильтр после доставки. Если жалоба касается доступа к ящику, пригодится разбор журналов Zimbra; ошибку доставки я расследую по событиям доставки. У слова «спам» слишком хорошее алиби: им удобно назвать любую пропажу.

Если письмо задержано, я прошу зафиксировать время передачи на наш узел и время следующего события обработки. Затем проверяю доступность следующего получателя, работу проверки содержимого и причину повторной попытки по журналу. Рост очереди показывает симптом, но не назначает виноватым SpamAssassin. Менять спам-порог ради такой задержки имеет смысл только после доказанной связи. Иначе прежняя причина останется, а к ней добавится другое поведение фильтра. Для обращения сохраняю несколько связанных событий целиком: отдельная вырванная строка часто скрывает продолжение доставки.

Чем папка «Спам» отличается от карантина

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

Ещё одна развилка — пометка и недоставка по спам-оценке. В Zimbra параметры zimbraSpamTagPercent и zimbraSpamKillPercent имеют разное назначение: первый задаёт порог пометки, второй — порог отбрасывания. Отброшенное сообщение нельзя вернуть простым переносом из Junk. Наличие копии для разбора надо подтвердить отдельно. До изменения я выясняю, сохраняется ли исходник, сколько он хранится и что происходит при переполнении хранилища. Совет «временно складывайте всё в карантин» без проверки этих условий опасен: красивое слово легко прячет обычное удаление. Защиту от вредоносных вложений при этом сохраняю; выпуск сообщения с таким срабатыванием требует отдельной проверки.

Пользовательские списки тоже проверяю отдельно. В Classic Web App путь Preferences → Mail → Spam Mail Options ведёт к разрешённым и заблокированным отправителям; в другом интерфейсе расположение может отличаться. Это не панель управления серверными порогами или журналированием. Я начинаю с точного адреса и выясняю причину попадания в список, прежде чем разрешать целый домен. Запись в пользовательском списке не следует считать способом доставить письмо, которое уже отклонено раньше по тракту. Если исключение всё же нужно, фиксирую его владельца, назначение и условие пересмотра. Иначе временное разрешение переживёт и проблему, и сотрудника, который помнил, зачем оно появилось.

• Найдите фактическое место удержания письма.
• Проверьте наличие исходника и порядок выдачи.
• Уточните срок хранения и контроль свободного места.
• Разделите спам-оценку и проверку вредоносных вложений.
• Проверьте пользовательские списки и правила сортировки.

Как проверить пороги и подготовить откат

Главная ошибка исходного подхода — считать отдельный ящик изоляцией серверной настройки. В схеме атрибутов Zimbra zimbraSpamTagPercent и zimbraSpamKillPercent относятся к globalConfig. Новый адрес этого не меняет. Он годится для контрольных отправок и наблюдения, но сам по себе не ограничивает действие глобального порога. Пробное изменение такого параметра я проверяю в отдельной среде либо на маршруте с подтверждённой независимой политикой. Если такой возможности нет, сначала разбираю сохранённые образцы и оцениваю предполагаемые последствия без изменения рабочего тракта. Лаборатория, у которой общие настройки с рабочей почтой, слишком дорого обходится при первой ошибке.

До правки я сохраняю исходные значения, версию установленной системы и сведения о внешнем шлюзе, если он участвует в доставке. Для чтения глобальной конфигурации под системной учётной записью zimbra использую команду ниже и нахожу в выводе оба атрибута. Она ничего не изменяет; полный вывод конфигурации храню во внутренней документации. Затем записываю предлагаемое значение, причину, область действия и способ возврата. Штатное применение параметра, включая необходимость перезапуска, сверяю с документацией установленной версии. Чужой набор значений без исходных писем и схемы обработки ничего не доказывает. Ручка строгости — не регулятор профессионализма.

zmprov gacf

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

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

Когда виноваты SPF, DKIM и DMARC

DNS-записи важны, но фраза «без SPF и DKIM любая почта обязательно уйдёт в спам» неверна. Отсутствие записей может ухудшить доставляемость; конкретное решение зависит от проверок и политики получателя. Кроме того, публикация записей собственного домена и проверка входящих писем решают разные задачи. Собственная запись SPF не объясняет автоматически, почему входящий счёт от другого домена оказался в Junk. Я смотрю результат проверки именно спорного сообщения и правило, которое добавило оценку. Общую настройку вынес в отдельный разбор SPF и DKIM; здесь мне нужна доказанная связь с конкретным ложным срабатыванием.

SPF проверяет право SMTP-узла использовать домен из MAIL FROM; стандарт также предусматривает проверку HELO. Это не проверка видимого имени отправителя. Отсутствие SPF-записи даёт результат none, который нельзя автоматически приравнивать к fail. С утверждением «в Zimbra входящий SPF по умолчанию выключен» тоже нужна точность: у модуля CheckSPF в CBPolicyd в справочнике указано FALSE, но состояние этого модуля не описывает все проверки в тракте. Я выясняю, где фактически проверяется SPF и как используется результат. Подключать дополнительный жёсткий отказ, не изучив уже работающую оценку, — надёжный способ получить новую проблему под видом усиления защиты.

DKIM связывает подпись с доменом подписанта и проверяет подписанные данные: выбранные заголовки и тело с учётом параметров подписи. Одна TXT-запись не включает подпись исходящей почты: нужна настройка подписания на отправляющем узле. Для DMARC достаточно успешной SPF или DKIM с согласованным доменом относительно видимого From; проходить обе проверки одновременно не требуется. При разборе я сопоставляю домены и результаты, затем проверяю их влияние на решение фильтра. Даже DMARC pass не гарантирует папку «Входящие»: содержимое и остальные правила продолжают учитываться. После смены отправляющего сервиса я повторяю проверку на реальном письме. Зелёная отметка в проверке DNS ещё не означает, что подпись появилась в отправке.

Как обучать SpamAssassin и проверять результат

Когда я убедился, что письмо настоящее и безопасное, использую действие «Не спам» в веб-интерфейсе. В штатной схеме Zimbra обратная связь поступает в служебные ящики spam и ham, а её обработкой занимается zmtrainsa. Наличие кнопки ещё не подтверждает, что эта цепочка работает на конкретной установке. Я проверяю журнал /opt/zimbra/log/spamtrain.log и фактическое выполнение задания, особенно после переноса MTA. Простое возвращение письма во «Входящие» нельзя без проверки интеграции считать ни гарантированным обучением, ни заведомо бесполезным действием. Для инструкции пользователю выбираю явную команду интерфейса, а техническую проверку оставляю администратору.

Есть полезная конкретика из базы знаний: в руководстве Zimbra 10 для накопления данных перед байесовской оценкой указаны как минимум 200 подтверждённых спам-сообщений и 200 обычных. Я сверяю пороги и включение этого механизма в установленной конфигурации. Это ориентир запуска оценки, а не обещание точности после четырёхсот писем. Один исправленный счёт не переучит всю систему мгновенно. Учебные подборки я очищаю от дублей и спорных образцов, а письма с вредоносными вложениями не открываю ради наполнения коллекции. Для проверки качества откладываю отдельные примеры, которые не использовались при обучении: иначе получится красивый ответ на уже знакомое задание.

Обучение не отменяет разбор правила. Если легитимное сообщение получает большую добавку от конкретной проверки, я отдельно выясняю её основание. Там, где виноваты неверный маршрут, повреждение подписи или ошибочное правило, исправляю причину. Если требуется узкое исключение, описываю проверяемые условия его применения; одного знакомого имени в поле отправителя недостаточно. После правки смотрю обе стороны: вернулась ли деловая переписка и не вырос ли пропуск нежелательной. Отчёт «пользователь больше не жалуется» оставляю для разговора, в журнал изменений заношу результат повторного теста. Белый список размером с адресную книгу — коллекция надежд с очень удобным интерфейсом.

• Подтвердите подлинность спорного письма.
• Используйте действие «Не спам» для обратной связи.
• Проверьте выполнение zmtrainsa и журнал обработки.
• Отделите учебные образцы от проверочных.
• Повторите доставку и проверьте нежелательную почту.

Как принять работу на примере «Схемы дела»

Покажу порядок приёмки на условном инженерном центре «Схема дела» из Подмосковья: 27 рабочих мест. Это учебный сценарий, численность не означает такое же число ящиков. Допустим, среди обращений есть счета в Junk и отдельная жалоба на задержку сообщения. Я завожу для них разные карточки: письмо в ящике уже прошло доставку, задержанное надо найти в очереди или на предыдущем узле. Ответственный со стороны центра подтверждает, какие сообщения действительно ожидались. В результате стартового разбора у каждого обращения должны появиться исходник либо подтверждение отправки, этап остановки и проверяемая причина. Условные проценты улучшения без такой выборки я в отчёт не рисую.

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

После внедрения я оставляю владельцу системы журнал: что изменили, почему, кто отвечает за наблюдение и как вернуть исходное состояние. Считаю подтверждённые ложные срабатывания отдельно от общего числа сообщений в Junk. Если их доля нужна для отчёта, делю число ошибочно отфильтрованных легитимных писем на число проверенных легитимных писем и указываю объём выборки. Дополнительно наблюдаю очередь, возраст задержанных сообщений и состояние места хранения удержанной почты. Порядок регулярных работ связан с тем, что входит в обслуживание. На выходе мне нужны воспроизводимая доставка, проверенные действия при ошибке и ответственный за разбор. Тишина в чате сама по себе почтовым мониторингом не становится.

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

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