Автоответ «Я в отпуске» в Zimbra приходит только один раз: почему и как настроить повтор

Если клиент написал вам во вторник, получил автоответ про отпуск, а в четверг написал снова и ответа не дождался — это не поломка Zimbra, а штатное поведение. Автоответ одному отправителю по умолчанию уходит не чаще раза в семь дней, чтобы не заваливать переписку дублями. Разбираю, как изменить этот срок и когда автоответ не уходит вовсе.

Почему второе письмо от того же отправителя остаётся без автоответа

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

Продолжительность этого кэша задаёт атрибут zimbraPrefOutOfOfficeCacheDuration, и по умолчанию он равен семи дням (7d). Это значит: получив автоответ, конкретный адрес отправителя не получит его снова в течение недели, даже если продолжит писать. Технически кэш — это таблица zimbra.out_of_office в базе почтового хранилища: в ней хранится идентификатор ящика, адрес, которому ушёл автоответ, и время отправки. Разным отправителям автоответ уходит независимо. И полезная деталь из исходного кода Zimbra: любое изменение атрибута zimbraPrefOutOfOfficeReplyEnabled — выключение или повторное включение автоответа — очищает эту таблицу для ящика, так что новый период отсутствия начинается с чистого кэша.

Когда я настраиваю корпоративную почту для клиентов, я обязательно объясняю это поведение заранее, до того как сотрудник впервые уходит в отпуск: иначе первая же жалоба «автоответ не работает» превращается в расследование мнимой поломки там, где на самом деле всё работает по спецификации.

Как изменить длительность кэша через zmprov

Атрибут задаётся на уровне класса обслуживания (CoS) — тогда правило действует сразу для всех аккаунтов этого класса — либо точечно на конкретном аккаунте, если нужно другое поведение только для одного сотрудника.

zmprov mc default zimbraPrefOutOfOfficeCacheDuration 1d
zmprov ma ivanov@example.com zimbraPrefOutOfOfficeCacheDuration 1d

Значение 1d означает, что повторный автоответ тому же отправителю возможен уже через сутки вместо недели — разумный компромисс для сотрудников, которые ведут активную переписку с внешними клиентами и не хотят, чтобы человек забыл о временном отсутствии за неделю тишины. Значение 0 полностью отключает кэш: в этом случае каждое письмо от любого отправителя получает отдельный автоответ, включая повторные письма в тот же день — и это уже не всегда то, что нужно, потому что при активной переписке один и тот же клиент получит автоответ на каждое своё письмо, включая короткие «спасибо» и уточнения. Защита от циклов при этом остаётся: на письма с Auto-Submitted и Precedence bulk/junk/list Zimbra не отвечает, но живого собеседника поток одинаковых уведомлений раздражает.

Единицы измерения в Zimbra CLI для атрибутов длительности — стандартные: d для дней, h для часов, m для минут, s для секунд. Если нужен промежуточный вариант между сутками и неделей, ничто не мешает задать, например, 3d — это такое же валидное значение, как 1d или 7d, синтаксис атрибута не ограничен конкретным набором значений.

Когда автоответ не приходит вовсе — и это не кэш

Прежде чем менять zimbraPrefOutOfOfficeCacheDuration, стоит убедиться, что причина жалобы вообще в кэше, а не в одном из условий, при которых Zimbra автоответ не отправляет в принципе — независимо от того, писал этот отправитель раньше или нет. Часть условий связана с папкой доставки: если письмо попало не во Входящие, а в Junk или в Trash — например, из-за настроенных правил фильтрации или ложного срабатывания антиспама — автоответ на него не отправляется.

Ещё одно условие — период действия автоответа. Если у сотрудника задан диапазон дат OutOfOfficeFromDate и OutOfOfficeUntilDate, письма, пришедшие за пределами этого диапазона, автоответа не получат, даже если функция технически включена в настройках. Это логично с точки зрения задумки, но регулярно ловит людей, которые забыли обновить дату окончания после переноса отпуска на несколько дней — автоответ формально включён, но уже вышел за собственные временные рамки.

Третье условие касается того, кому вообще адресовано письмо. Автоответ не отправляется, если у сообщения пустой envelope sender (типичная ситуация для части технических уведомлений и автоматических рассылок — так исключаются циклы автоответов на автоответы) или если прямой адрес получателя отсутствует в полях To и Cc, например при массовой рассылке через скрытую копию. Любопытная деталь из KB: ради производительности проверяются только первые 10 адресов в To и Cc, так что в длинной цепочке получателей сотрудник, стоящий одиннадцатым, автоответ не «заработает». Не отвечает Zimbra и на письма с заголовком Auto-Submitted, отличным от no, с Precedence bulk, junk или list, на отчёты multipart/report и на отправителей вида owner-, -request, mailer-daemon, majordomo, listserv. Автоответ также не уходит, если аккаунт в статусе maintenance, pending или closed, или если в CoS выключена сама функция zimbraFeatureOutOfOfficeReplyEnabled. Для случаев, когда сотрудник всё же должен получать автоответы на письма, пришедшие на дополнительный адрес или псевдоним, а не на основной ящик, используется многозначный атрибут zimbraPrefOutOfOfficeDirectAddress — он перечисляет дополнительные адреса, которые Zimbra будет считать «прямыми» получателями при проверке условия.

Как отличить штатное поведение от реальной проблемы, не гадая

Самый быстрый способ проверить, действительно ли дело в кэше, — спросить у клиента или коллеги, когда именно он писал в первый и во второй раз, и сравнить разницу во времени с текущим значением zimbraPrefOutOfOfficeCacheDuration аккаунта. Если разница меньше заданного периода — это штатное поведение, и никакой технической проблемы нет, нужно просто объяснить логику или сократить кэш, если это критично для бизнеса.

zmprov ga ivanov@example.com zimbraPrefOutOfOfficeCacheDuration zimbraPrefOutOfOfficeFromDate zimbraPrefOutOfOfficeUntilDate zimbraPrefOutOfOfficeReplyEnabled zimbraFeatureOutOfOfficeReplyEnabled
grep -E 'already sent|not direct|outofoffice sent' /opt/zimbra/log/mailbox.log | tail -20

Такой запрос сразу показывает и текущую длительность кэша, и даты действия автоответа, и то, включена ли функция вообще. А mailbox.log отвечает на вопрос «почему» прямо: по KB каждая причина отказа логируется своей фразой — «already sent» для кэша, «not direct» для адреса не в To/Cc, «in spam» или «in trash» для папки, а успешная отправка пишется как «outofoffice sent». Часть этих строк может появляться только при повышенном уровне логирования — проверьте в своей версии, прежде чем делать вывод по пустому grep. Часто оказывается, что автоответ выключили после возвращения из прошлого отпуска и забыли включить заново перед следующим. Проверка занимает меньше минуты и избавляет от необходимости гадать между тремя разными причинами одного и того же симптома «клиент не получил автоответ».

Полезно также помнить, что сам автоответ отправляется с заголовками Auto-Submitted: auto-replied (zimbra; vacation) и Precedence: bulk, тему «Re: » плюс исходная тема — это сделано специально, чтобы почтовые системы получателя и антиспам-фильтры не пытались отвечать на автоответ и не запускали цепочку взаимных автоответов между двумя серверами с одинаково настроенной функцией отсутствия. Автоответ также не сохраняется в папке Отправленные (факт отправки виден только в mailbox.log) у сотрудника — это ожидаемое поведение, а не потеря письма, и объяснять это тоже приходится регулярно. Если же партнёры жалуются, что автоответы и обычные письма сотрудника попадают у них в спам, это отдельная история: письма Zimbra улетают в спам и при формально валидных SPF, DKIM и DMARC.

Как администратору включить или проверить автоответ за сотрудника

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

zmprov ma ivanov@example.com zimbraPrefOutOfOfficeReplyEnabled TRUE
zmprov ma ivanov@example.com zimbraPrefOutOfOfficeFromDate 20260701000000Z
zmprov ma ivanov@example.com zimbraPrefOutOfOfficeUntilDate 20260715235900Z
zmprov ma ivanov@example.com zimbraPrefOutOfOfficeReply 'Здравствуйте! Я в отпуске до 15 июля, вернусь и отвечу на письмо лично. По срочным вопросам — Петров И. В., ivanov-zamena@example.com.'

Даты задаются в формате zulu-времени (UTC) вида ГГГГММДДЧЧММССZ — это тот же формат, что использует Zimbra для остальных временных атрибутов LDAP, и ошибка в формате даты — частая причина, почему автоответ не срабатывает вообще, хотя zimbraPrefOutOfOfficeReplyEnabled стоит в TRUE. Быстрее всего сверить, что реально записалось, той же командой zmprov ga ivanov@example.com zimbraPrefOutOfOfficeFromDate zimbraPrefOutOfOfficeUntilDate, которую я уже показывал выше для диагностики.

Для компании, где отпуска планируются заранее и фиксируются в общем графике, имеет смысл превратить эти три-четыре команды в короткий скрипт, который HR или руководитель отдела запускает сам через тикет, не дожидаясь, пока администратор вручную наберёт команды в консоли. Это не только экономит время, но и снижает риск, что автоответ забудут выключить вовремя — дата окончания в скрипте задаётся сразу вместе с датой начала, а не добавляется отдельным шагом, который легко упустить.

Отдельно стоит проговорить с сотрудниками разницу между обычным автоответом и внешним. У функции есть отдельная пара атрибутов для внешних отправителей — zimbraPrefOutOfOfficeExternalReply и zimbraPrefOutOfOfficeExternalReplyEnabled, — внешних отправителей Zimbra определяет по zimbraInternalSendersDomain и zimbraPrefExternalSendersType; пара позволяет показывать более общий текст людям за пределами компании и более подробный, с контактами замещающего сотрудника, — коллегам внутри домена. Для клиентского бизнеса вроде автосервиса или мастерской это удобно: партнёрам и поставщикам можно не раскрывать внутреннюю структуру замещения, ограничившись общей фразой про возвращение к такой-то дате.

Кейс: автосервис «АвтоТочность», 18 рабочих мест

Условный клиент — автосервис «АвтоТочность», 18 рабочих мест: приёмка заказов, три поста ремонта, отдел снабжения запчастями. Менеджер по работе с поставщиками ушла в отпуск на две недели, включила автоответ через веб-клиент, указала даты начала и окончания. В первый день несколько поставщиков получили автоответ и временно переключились на замещающего сотрудника, всё работало как задумано.

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

Проверка zmprov ga менеджер@example.com zimbraPrefOutOfOfficeCacheDuration показала стандартное значение 7d — значит, дело было именно в штатном кэше: поставщик написал повторно на шестой день после первого письма, автоответ по спецификации ему повторно не полагался. Технической поломки не было вообще, письма доходили и читались замещающим сотрудником, просто автоматическое уведомление не дублировалось.

Обсудили с руководством, что для сотрудников, которые активно ведут переписку с внешними поставщиками и клиентами во время отсутствия, недельный кэш слишком длинный — решили сократить его для соответствующей группы аккаунтов до одних суток: zmprov mc supply-cos zimbraPrefOutOfOfficeCacheDuration 1d. Дополнительно завели короткую памятку для сотрудников: при уходе в отпуск проверять корректность дат начала и окончания автоответа и предупреждать ключевых партнёров лично, а не полагаться только на автоматику — особенно если период отсутствия дольше недели, когда штатный кэш и так почти наверняка даст повторный автоответ, но лишняя ясность не помешает. В ту же памятку мы вписали и не почтовые вещи — например, как не оставить компанию без подписи, если в отпуск уходит директор: про УКЭП директора на Рутокене у меня есть отдельный разбор.

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

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