Архив почты компании: требования и решения

MAATRIX

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

Чем архив отличается от обычных ящиков сотрудников

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

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

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

Практический пример: сотрудник вёл переписку с поставщиком по условиям контракта, потом уволился, ящик закрыли через месяц после увольнения (как принято в большинстве компаний). Через год возникает спор по условиям поставки. Если архива нет — переписка потеряна безвозвратно. Если архив есть — вы поднимаете её за пять минут независимо от того, что случилось с личным ящиком автора письма.

Регуляторные требования: общая картина

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

• Финансовый сектор — банки, брокеры, страховые компании во многих юрисдикциях обязаны хранить переписку с клиентами и переписку по сделкам годами (в некоторых регуляторных режимах — 5-7 лет и больше).
• Бухгалтерский и налоговый учёт — переписка, подтверждающая условия сделки, часто входит в объём документов, которые нужно предъявить при налоговой проверке, и хранится вместе с первичными документами (подробнее про сроки хранения именно бухгалтерских данных — в отдельной статье о хранении бухгалтерских данных, общий принцип соразмерности сроков там разобран подробно).
• Госзакупки и регулируемые тендеры — переписка по конкурсным процедурам нередко подлежит хранению отдельным списком требований.
• Отрасли с обязательным комплаенсом (фарма, медицина, некоторые виды страхования) — там свои сроки и свои перечни того, что считается «деловой документацией».

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

Внутренняя польза архива — не только про закон

Даже если бы никаких регуляторных требований не существовало, у формального архива почты есть чисто деловая ценность, и часто именно она перевешивает на практике.

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

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

Третье, и это стоит выделить отдельно — независимость от судьбы личных ящиков. Обычная практика — закрывать или архивировать личный ящик уволенного сотрудника через какой-то срок (недели, редко больше квартала). Это разумно с точки зрения лицензий на почтовые аккаунты и безопасности, но означает, что вся переписка этого сотрудника исчезает вместе с ящиком, если не была скопирована отдельно. Формальный архив снимает эту проблему: копия письма в архиве существует независимо от того, жив ли ещё личный ящик автора.

Ключевое требование: неизменяемость архива

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

Неизменяемость (immutability) означает: после того как письмо попало в архив, никто из рядовых пользователей — включая отправителя, получателя и даже большинство системных администраторов — не может его изменить или удалить раньше истечения установленного срока хранения. Это принципиально отличается от обычного ящика, где владелец волен удалить любое письмо в любой момент.

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

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

• Storage с поддержкой object lock / WORM (write once, read many) — объектное хранилище, где для бакета или конкретного объекта включается режим «нельзя удалить или перезаписать до такой-то даты» на уровне самого хранилища, а не приложения поверх него.
• Файловая система с неизменяемым атрибутом — например, chattr +i на файлах архива в Linux (защищает от простого rm даже от root без снятия атрибута отдельной привилегированной командой) или снапшоты ZFS с zfs hold, которые нельзя удалить, пока хук не снят явно.
• Отдельная учётная запись/роль для записи в архив, у которой в принципе нет прав на удаление — только на добавление. Это проще реализовать программно, чем физическую неизменяемость диска, но требует строгого разделения ролей (see ниже).

На практике разумно комбинировать: даже если роль записи технически получит право удаления по ошибке конфигурации, физическое ограничение на уровне хранилища не даст это сделать при любом раскладе.

Как организовать копирование почты на уровне сервера

Технически основа архива — не перемещение писем, а их автоматическое копирование в момент прохождения через почтовый сервер, независимо от того, что дальше делает сотрудник со своим личным ящиком.

Если у вас Postfix, самый простой встроенный механизм — always_bcc (для входящей и исходящей почты раздельно):

# /etc/postfix/main.cf
always_bcc = archive@archive.example.com
sender_bcc_maps = hash:/etc/postfix/sender_bcc
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc

Более гибкий вариант — journaling через milter: он получает копию каждого письма на этапе SMTP-обработки, до попадания в конкретный ящик, и параллельно кладёт её в архивное хранилище. Это надёжнее always_bcc, потому что не зависит от логики доставки и ловит письмо даже при настроенных у получателя фильтрах или пересылке.

Для контейнерных решений вроде Mailcow или iRedMail journaling обычно настраивается похожим образом — через отдельный псевдо-ящик или milter-хук, который вы указываете в конфигурации почтового сервера (детали настройки конкретного сервера — в статьях про Postfix и переход на свой сервер).

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

Технически архивный поток стоит направлять в отдельную систему хранения — не в такой же почтовый ящик IMAP, а в специализированное хранилище (объектное хранилище с индексацией по метаданным, или специализированное ПО email-архивирования), где для каждого письма сохраняются заголовки, тело, вложения и метаданные (дата, отправитель, получатели, ID сообщения) в структуре, удобной для поиска спустя годы.

Хранилище архива: кто имеет право на удаление

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

Практическая модель ролей:

Ключевая идея — удаление отделено от повседневного администрирования. Даже администраторы, которые управляют самим почтовым сервером и имеют root на инфраструктуре, не должны иметь бытового доступа на удаление записей архива. Право на удаление (обычно — только записей, у которых истёк установленный срок хранения, и только через регламентированную процедуру) должно быть у узкого круга ответственных лиц, официально назначенных внутренним документом компании как отвечающие за архивную политику.

Технически это можно реализовать так:

• Учётная запись, которая пишет в архив (например, от milter-процесса), имеет только права PutObject, но не DeleteObject — на уровне IAM-политики объектного хранилища.
• Административная учётная запись для управления жизненным циклом (удаление по истечении срока) — отдельная, с MFA, выдаётся ограниченному кругу лиц.
• Любое удаление из архива логируется в отдельный неизменяемый лог с указанием, кто, когда и на основании какого регламента удалил запись — это тот аудиторский след, который делает архив доказательным.

Срок хранения: регуляторные требования плюс здравый смысл

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

Общий принцип соразмерности здесь тот же, что применяется и к техническим логам (подробнее — в статье сколько хранить логи): хранить нужно не бесконечно «на всякий случай», а тот срок, который реально покрывает и регуляторные обязательства, и разумное окно, в течение которого компании может понадобиться поднять переписку по спору или для восстановления истории решения. Бессрочное хранение без обоснования — тоже не всегда правильный выбор: это и лишние расходы на хранилище, и лишний риск при утечке (чем больше данных хранится, тем больше потенциальный объём компрометации).

Практический подход к определению срока:

1. Выясните у юриста, есть ли в вашей отрасли/юрисдикции прямое регуляторное требование к сроку хранения деловой переписки — и если да, какой это срок.
2. Если требования нет или оно покрывает не всю переписку — определите внутренний срок исходя из типичного «окна» споров и вопросов по сделкам в вашем бизнесе (ориентир для многих B2B-компаний — срок, соотносимый со сроками исковой давности по договорным спорам в вашей юрисдикции, но это вопрос к юристу, не общее правило).
3. Возьмите больший из двух сроков как итоговый срок хранения.
4. Зафиксируйте срок во внутреннем документе компании (политика архивирования почты), а не только в технической конфигурации — так его проще предъявить при аудите.

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

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