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

Ниже — разбор того, почему папка «Отправленные» сама по себе не доказывает отправку, какие цифровые следы действительно важны и как сохранить переписку так, чтобы её можно было исследовать, а также — разбор реального кейса из практики судебной экспертизы.

Преамбула: почему суды «теряются» при оценке достоверности email?

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

В суде случается, что одна сторона утверждает — «ничего не получала», а вторая показывает — «да вот, же, смотрите». И все предъявляют нотариальные осмотры почтовых ящиков или заключения специалистов, подтверждающие позицию каждой стороны. Что делает суд в таких случаях? Правильно, назначает компьютерно‑техническую экспертизу. Но не всегда обстоятельства экспертизы идеальны и истина лежит на поверхности…

Описание технологии е‑мail

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

Скрытый текст

Ключевые компоненты системы:

a) Почтовые клиенты (MUA — Mail Transfer Agent) — программы для создания, отправки и чтения писем. Примеры:

• веб‑клиенты: Gmail, Яндекс.Почта, Mail.ru (доступ через браузер)

• десктопные приложения: Microsoft Outlook, Mozilla Thunderbird, Apple Mail

• мобильные приложения: email‑приложения для iOS и Android (Mail, Gmail, Яндекс и тому подобное).

b) Серверы пересылки (MTA — Mail Transfer Agent) — получают письмо от клиента и пересылают его серверу получателя по протоколу SMTP. Примеры: Postfix, Exim.

c) Серверы получения/хранения (MDA — Mail Delivery Agent) — принимают письма от MTA и хранят в почтовом ящике пользователя. Примеры: Dovecot, Procmail.

d) Серверы DNS (Domain Name System) — необходимы чтобы найти сервер получателя. MX‑запись (Mail Exchange) в DNS указывает на почтовый сервер(ы) домена

В общем виде, не вдаваясь в подробности передачи электронных сообщений между серверами, процесс функционирования сервиса приведен на рисунке (для упрощения восприятия MTA и MDA объединены в понятие «почтовый сервер». Различные клиенты общаются с сервером, серверы между собой и клиентами. Пользователь взаимодействует с сервисом электронной почты посредством клиентов.

Самый простой формат взаимодействия клиента с сервером через веб‑приложение, представляющее собой браузер. Обмен происходит по протоколу https. Пользователь управляет своим почтовым ящиком на сервере. На клиентской стороне никаких сообщений не содержится.

Во взаимодействии десктопного клиента (здесь и далее в качестве десктопного клиента понимается MS Outlook) с сервером есть вариации:

1. Обмен по протоколам POP/SMTP. Отправленные письма не сохраняются на сервере, а перемещаются на клиентское устройство. Сохранение входящих сообщений на сервере при получении их клиентом регулируется настройкой на клиенте.

2. Обмен по протоколам IMAP/SMTP. IMAP осуществляет двустороннюю синхронизацию сервера и клиента, то есть изменения сделанные на клиенте применяются на сервере и наоборот. Отправленные письма сохраняются на сервере. Это делает возможным работу с почтовым ящиком с нескольких устройств (клиентов).

При отправке письма клиент выполняет два независимых процесса:

• отправка через SMTP: передает письмо на сервер для доставки адресату;

• сохранение копии в папку Отправленные: сохраняет локальную копию письма в своей базе данных.

Затем, в рамках синхронизации по IMAP, клиент загружает эту локальную копию на сервер в папку Отправленные.

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

Следует отметить, что никакой email‑сервис не может гарантировать доставку письма до адресата. На пути письма есть много этапов и факторов, которые сервис не контролирует, например:

• перегрузка почтового сервера получателя;

• ошибки (временные) в DNS или сетевых маршрутах;

• срабатывание антиспам‑фильтра;

• если у получателя настроены DKIM/SPF/DMARC — письмо без корректной подписи может быть отклонено;

• возможна блокировка вложений (например,.exe);

• почтовый ящик адресата переполнен.

В зависимости от настроек задействованных серверов, отправителю может быть направлена отбивка о том, что письмо не доставлено.

Виды фальсификаций и объекты исследования

Эксперты компьютерно‑технического направления нередко сталкиваются с подделкой цифровых доказательств. Для электронной почты можно выделить четыре типа подделок: 

1. Фальсификация отправки. Письмо физически никогда не уходило адресату, но его копия искусственно помещена в папку «Отправленные». Цель — создать видимость добросовестного исполнения обязательств (направил договор, претензию и тому подобное).

2. Сокрытие получения. Письмо было доставлено, но затем намеренно удалено, либо перемещено в спам с последующей автоматической очисткой. Цель — создать видимость того, что письмо никогда не попадало в ящик.

3. Отказ от отправки (ренегатство). Письмо реально отправлено, но отправитель утверждает, что не отправлял, и предоставляет «чистую» папку «Исходящие». Цель — создать видимость отсутствия действий по отправке письма.

4. Фальсификация получения (подмена отправителя). Отправка письма как бы от имени аккаунта с помощью специального сервиса. В настоящее время использование SPF/DKIM устраняют возможность подобной фальсификации с чужим доменом. Однако в корпоративных почтовых системах данный вариант возможен.

При использовании публичного почтового сервиса (mail.ru, yandex.ru) сомнения в достоверности данных отсутствуют. Оптимальный вариант — запросить у оператора сервиса данные по аккаунту, которые хранятся в соответствии с «пакетом Яровой». Это надежно, но на практике операторы не всегда отвечают на запросы судов (ссылаются на политику конфиденциальности или законодательство о персональных данных).

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

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

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

Криминалистически значимым объектом исследования электронных писем являются служебные заголовки. Это «метаданные email», которые помогают маршрутизировать и идентифицировать сообщения, форматировать содержимое, проверять безопасность. Также по заголовкам можно сделать выводы о подлинности письма. Заголовки описаны в RFC5322 “Internet Message Format”.

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

Криминалистически наиболее важны следующие заголовки:

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

Реальный кейс из экспертной практики

Фабула дела

Стороны А и Б в договоре юридически значимой переписку по емайл. В 2025 году Сторона_А подала иск к Стороне_Б по факту неисполнения договора, направленного Стороне_Б по емайл в 2022 году.

Сторона_Б утверждала, что никакого письма не получала и подтверждала свою позицию отсутствием письма в своем почтовом ящике. Поскольку в журнале ящика присутствовали удаления входящих писем позже спорной даты получения, никакого уменьшения неопределенности осмотр ящика не дал.

Сторона_А подтверждала факт отправки письма нотариальным осмотром почтового ящика (через веб‑интерфейс почтового сервера), где письмо присутствовало.

Определением суда была назначена компьютерно‑техническая экспертиза с вопросом: имеет ли место факт отправки емайл такого‑то содержания (далее — Спорное письмо) с электронного адреса А на электронный адрес Б?

«Изюминкой» данного дела было то, что у Стороны_А был доступ к электронной почте только через десктопный почтовый клиент. Сторона поясняла, что после нотариального осмотра доступ к веб‑версии почтового ящика на mail.ru был утерян.

Получение доступа к серверу отправителя

В процессе удаленного осмотра почтового клиента MS Outlook 2010 (тип связи с сервером IMAP/SMTP) Стороны_А Экспертом было обнаружено Спорное письмо в папке Отправленные с датой отправки 01.01.2023.

Понимая, что ответ на вопрос суда в категорической форме невозможен без доступа к письму на сервере, Эксперт попробовал восстановить пароль для связи MS Outlook 2010 с почтовым аккаунтом mail.ru (пароль для внешних приложений) Стороны_А. С помощью специального ПО, запущенного на компьютере Стороны_А пароль был восстановлен.

Это позволило осуществить подключение к почтовому аккаунту Стороны_А через почтовый клиент Эксперта и сделало доступным исследование служебных заголовков не локальных сообщений в клиенте Стороны_А, а сообщений, полученных с сервера.

Анализ писем, полученных с сервера

Сведения заголовка Received указывали на то, что письмо попало на сервер через IMAP c IP‑адреса принадлежащего провайдеру Стороны_А в 2024 году.

Казалось бы, фальсификация подтверждена, однако Эксперт проверил и такую версию: использование Стороной_А в 2022 году режима клиента POP/SMTP. В этом случае письмо было отправлено клиентом и сохранено только в виде локальной копии без появления на сервере. Впоследствии, когда клиент был настроен на режим IMAP/SMTP — письмо появилось на сервере в результате клиент‑серверной синхронизации.

Для проверки данной версии были исследованы иные исходящие письма. В опровержение изложенной версии было обнаружено письмо за 2023 год, то есть между датой Спорного письма по данным клиента и сервера. Данный факт интерпретирован следующим образом: успешная синхронизация с сервером по IMAP осуществлена в 2023 году, таким образом, даже в случае отсутствия синхронизации в 2022 году, Спорное письмо должно было попасть на сервер в 2023, а не в 2024 году.

Косвенные признаки и эксперимент

Следует отметить, что имелись и иные особенности, косвенно свидетельствующие о фальсификации, а именно:

• нотариальный осмотр не содержал заголовков письма и был осуществлен по прямой ссылке, а не поиском письма в интерфейсе почтового ящика;

• экспорт писем в почтовом клиенте Стороны_А осуществлялся в EML, а не в MSG (формат по умолчанию);

• метаданные pdf‑вложений в Спорное письмо содержали даты позднее даты отправки Спорного письма по версии Стороны_А.

В подтверждение вывода проведен экспертный эксперимент c файлом Спорного письма в формате EML, экспортированного из MS Outlook 2010 Стороны_А, воспроизводящий возможный механизм фальсификации:

• в текстовом редакторе изменен адрес получателя и дата,

• измененный EML импортирован в папку Отправленные,

• запущена синхронизация с сервером.

В результате получен емайл по виду и с заголовками, аналогичными Спорному письму, как на клиенте, так и на сервере.

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

Выводы и рекомендации по противодействию фальсификациям

Проведённое исследование позволяет сформулировать ряд практических советов как для участников судебных споров, так и для ИТ‑специалистов.

Для пользователей

• Ставьте в копию нейтральный адрес. Если у вас есть спор с контрагентом, дублируйте значимые письма на свой корпоративный ящик или ящик независимого юриста. Это создаст «распределённую копию».

• Не удаляйте письма без необходимости. Даже если письмо нежелательное, переместите его в отдельную папку. Удаление уничтожает доказательство вашей добросовестности.

• Используйте электронную подпись (DKIM). Для корпоративных доменов настройка SPF/DKIM значительно усложняет подделку — письма без корректной подписи будут отклоняться или маркироваться как спам.

Для владельцев корпоративных почтовых серверов

• Делайте бэкапы на независимые ресурсы. Сохраняйте копии почтовых баз на внешнее хранилище.

• Не пренебрегайте журналированием процессов приема/передачи электронных писем. Храните логи также на независимом ресурсе. Это позволит восстановить картину даже после намеренной чистки.

Для суда

В случае невозможности предоставить эксперту доступ к объектам исследования запрашивайте операторов почтовых сервисов. При отказе — штрафуйте в соответствии со ст.332, 119 АПК РФ! Это должно привить операторам уважение к суду и вернуть их в правовое поле РФ, так как «уплата судебного штрафа не освобождает от обязанности исполнить судебный акт».

Нотариальный осмотр или заключение специалиста по исследованию содержимого почтового ящика должны содержать серверные служебные заголовки. Исследование только клиентской составляющей инфраструктуры емайл не позволяет считать факт отправки/получения письма установленным. Выстраивание доказывания исключительно на факте наличия письма в папке «Отправленные» у одной из сторон является порочной практикой. Такой подход игнорирует техническую природу email.

Заключение

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