Архив, который стирал письма

Сотрудник открыл веб-почту и задал простой вопрос: почему во «Входящих» пусто? Ящик заведён три недели назад, вход работает, папки на месте — а писем нет. Ответ оказался не про этот ящик, а про все сто пять ящиков почтового сервера.

Пять писем, которых нет

Почтовый сервер ведёт журнал доставки. По нему видно: 24 августа в ящик пришло пять писем — служебные уведомления, отправленные сразу после его создания. Через веб-почту их никто не удалял: в каждой сессии счётчик удалений равен нулю. А на диске ящик пуст.

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

Проверяем вторую половину фразы.

Архив, который перезаписывал сам себя

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

flowchart TB
  subgraph R1 [" "]
    direction LR
    N1["Ночь N:<br/>упаковать ящик"] --> O1["Записать поверх<br/>единственного архива"]
    O1 --> D1["Стереть письма<br/>старше 18 дней"]
  end
  subgraph R2 [" "]
    direction LR
    N2["Ночь N+1:<br/>упаковать ящик,<br/>писем уже нет"] --> O2["Записать поверх<br/>без этих писем"]
    O2 --> L["Письма потеряны<br/>навсегда"]
  end
  R1 --> R2
  style R1 fill:none,stroke:none
  style R2 fill:none,stroke:none

Письмо, которому исполнилось 19 дней, попадает в архив ночи N и сразу стирается с диска. В ночь N+1 задача снова упаковывает ящик — письма там уже нет — и записывает архив поверх. Всё: письма нет ни на диске, ни в облаке.

«Доступ сохраняется» было правдой ровно одни сутки. И касалось это не одного ящика: у ящиков приёма обращений и голосовой почты самые старые письма на диске были ровно трёхнедельной давности.

Что изменили

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

flowchart TB
  subgraph R1 [" "]
    direction LR
    BOX["Ящик на диске"] --> SNAP["Снимок ящика<br/>с датой"]
    SNAP --> KEEP["В облаке 7<br/>последних снимков"]
  end
  subgraph R2 [" "]
    direction LR
    OLD["Письма старше<br/>срока"] --> PACK["Архив удаляемых<br/>писем"]
    PACK --> CHECK{"Выгружен и число<br/>писем совпало?"}
    CHECK -->|да| DEL["Удалить с диска<br/>ровно эти письма"]
    CHECK -->|нет| STAY["Оставить до<br/>следующей ночи"]
  end
  R1 --> R2
  style R1 fill:none,stroke:none
  style R2 fill:none,stroke:none

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

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

Как проверили

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

Что было стёрто до исправления, вернуть нельзя — копий не осталось. Это и есть главный урок: резервная копия, которая записывает себя поверх, защищает ровно до первой ночи.

Когда письмо не приходит вовсе

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

Сначала смотрят DNS и сам сервер: MX домена ведёт на почтовый сервер, приём работает, очередь пуста. Дальше проверяют порт 25 снаружи — и здесь две ловушки.

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

Правильный порядок — сначала посмотреть, какие источники дошли до антиспама, и только потом делать выводы о сети. Этот порядок теперь есть в документации раздела.

Почтовый сервер в СмИТ Биллинге

Почта провайдера живёт на своём сервере рядом с биллингом: приём и отправка, антиспам, хранение и веб-почта с календарём и контактами. Ящики, домены и роли лежат в базе биллинга, поэтому завели ящик в разделе — почтовый сервер видит его сразу, без правки настроек. Всё управление собрано в разделе «Почтовый сервер».

flowchart TB
  subgraph R1 [" "]
    direction LR
    NET["Письмо<br/>из интернета"] --> PF["Приём<br/>и отправка"]
    PF --> RS["Антиспам"]
  end
  subgraph R2 [" "]
    direction LR
    DV["Хранение<br/>ящиков"] --> WEB["Веб-почта:<br/>календарь, контакты"]
    BIL["Биллинг:<br/>ящики, домены, роли"] --> DV
  end
  R1 --> R2
  style R1 fill:none,stroke:none
  style R2 fill:none,stroke:none

На «Обзоре» — сводка: работает ли сервер, сколько доменов и ящиков у каждой организации и готов ли каждый домен к отправке. Проверяются записи MX, SPF, DKIM и DMARC: зелёная строка означает, что письма с домена примут Gmail, Mail.ru и Яндекс, а не отправят в спам.

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

Новый ящик заводится одним окном: адрес, доставка в ящик или пересылка, квота, пароль и роль. Роль сама прописывает всё нужное: назначили ящику «Приём обращений» — письма начинают превращаться в обращения поддержки.

Ящик в профиле сотрудника

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

Логин подставляется из имени пользователя, а пароль от ящика совпадает с паролем входа в биллинг и меняется вместе с ним — отдельно его помнить не нужно. Можно указать адрес пересылки: копии входящих уйдут на внешний адрес, оригинал останется в ящике. Имя отправителя, подпись с должностью и телефоном и фото подставляются из профиля.

flowchart TB
  subgraph R1 [" "]
    direction LR
    PR["Профиль сотрудника:<br/>«Создать ящик»"] --> NEW["Ящик логин@домен,<br/>один на домен"]
    NEW --> PW["Пароль = пароль<br/>входа в биллинг"]
  end
  subgraph R2 [" "]
    direction LR
    SIG["Имя, подпись, фото<br/>из профиля"] --> BELL["Письма во вкладке<br/>«Почта» уведомлений"]
    BELL --> FW["Пересылка копий<br/>на внешний адрес"]
  end
  R1 --> R2
  style R1 fill:none,stroke:none
  style R2 fill:none,stroke:none

Как это работает в СмИТ Биллинге

Резервный архив настраивается в разделе «Почтовый сервер» → «Настройки сервера»: срок хранения писем на диске и ручной запуск. Отключить сам архив нельзя — это политика безопасности. Архивы шифруются ключом, который хранится только в настройках биллинга.