Возможно, на первый взгляд вы подумаете: «Что это за вопрос? Что такое электронная почта, совершенно ясно!». То, что с типичной точки зрения пользователя изначально кажется простым, правильным и понятным для ответа, с более технической (и также с точки зрения соответствия требованиям) стороны может стать сложным вопросом. Особенно когда речь идет об архивировании электронных писем и вопросе об оригинале электронного письма. Финансовое управление проверяет архивирование почты налогоплательщика, в частности, на основе критериев надлежащего порядка GoBD, согласно которым восстановление оригинала любого архивированного электронного письма должно быть возможным.

Разумеется, Benno MailArchiv с самого начала имеет возможность отображать каждое архивированное письмо в оригинале. При этом хранящаяся в нативном формате RFC 822 архивированная электронная почта извлекается из архива, распаковывается и представляется в виде «исходного кода». Ни то, ни другое не является чем-то особенным, и это не объясняет наш вопрос, поставленный в начале. В конце концов, архивируется то, что приходит с почтового сервера или из почтового ящика пользователя и подлежит архивированию.

Оригиналы и экземпляры почты

Но что происходит, когда вместо одного единственного релевантного оригинала электронного письма имеется два, три или даже больше экземпляров? Мы, однако, говорим явно не о простых дубликатах, то есть, например, неоднократно полученных электронных письмах из почтового ящика или подобном. Распознавание дубликатов электронных писем (или двойников) является одной из наиболее элементарных задач решения для архивирования электронной почты. Benno MailArchiv владеет этим так же долго, как и отображением электронных писем в оригинале.

«Несколько релевантных оригиналов одного и того же электронного письма? Невозможно!» скажете вы? Не в сложных средах, как они встречаются у крупных хостинговых компаний и поставщиков облачных услуг (CSP) на практике. Здесь электронные письма попадают через инфраструктурные обстоятельства частично несколько раз в «воронку обработки» Benno MailArchiv.

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

Мы приглашаем вас обсудить с нами, что такое электронная почта (или, возможно, не является ею). Возможно, ваше представление о таком простом «деле», как электронная почта, изменится после прочтения этой статьи. Напишите нам электронное письмо или воспользуйтесь функцией комментариев в конце этой статьи, чтобы поделиться своим мнением.

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

Архивирование почты на месте или в собственном доме

Eine im on premise Betrieb eingerichtete Mailarchivierung ist dabei häufig dadurch gekennzeichnet, dass alle zu archivierenden E-Mails immer und ausnahmslos über den gleichen Weg bzw. den gleichen gewählten Mechanismus archiviert werden. Mag die E-Mail-Zuführung zum Archiv je nach Kunde und dessen IT-Umgebung individuell sein, so ist festzustellen, dass der Weg aller E-Mails bei on premise Installationen (ist er erst einmal festgelegt und eingerichtet) de facto immer der gleiche ist. Hat man also die Anbindung an das Mailarchiv einmal fertiggestellt, läuft alles weitere quasi wie von selbst. Alle zu archivierenden E-Mails nehmen immer den gleichen Weg. One size fits all.

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

Архивация почты в облаке

Совершенно иная картина часто наблюдается в крупных и сложных средах. Например, в инфраструктурах крупных хостинговых и облачных провайдеров. Из-за множества возможных обстоятельств (различные пути передачи почты, разные почтовые транспортные серверы (MTA) и разные стратегии подачи в архив (активно через SMTP или пассивно через IMAP или POP3 и т. д.)) здесь часто происходит так, что одно и то же электронное письмо передается в архив разными путями и, таким образом, ставится в очередь для многократного архивирования.

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

Давайте рассмотрим это более подробно на примере:

В сложной инфраструктуре конкретное электронное письмо «M» передается в Benno MailArchiv для архивирования тремя разными путями. При транспортировке каждого из трех экземпляров этого электронного письма (M1, M2, M3) по разным путям в каждый экземпляр письма добавляются разные заголовки. Экземпляры письма идентичны по содержанию, то есть с точки зрения пользователя, рассматривающего сообщение или текст. Тем не менее, они формально и технически различаются разными заголовками.

Заголовки делают разницу

С точки зрения обнаружения дубликатов Benno MailArchiv эти три экземпляра электронной почты M1, M2 и M3, безусловно, являются разными электронными письмами. При архивации для каждой переданной электронной почты генерируется контрольная сумма SHA256. Из-за различных заголовков (в остальном идентичных экземпляров электронной почты) неизбежно получаются три разные контрольные суммы «C1», «C2» и «C3» для различных экземпляров. Таким образом, с точки зрения Benno MailArchiv три экземпляра одного и того же электронного письма являются разными электронными письмами. Они также будут архивированы индивидуально как таковые. Это, в свою очередь, будет означать, что с точки зрения пользователя (т. е. в отношении чисто информационного содержания электронного письма) кажется, что в архиве содержатся три одинаковых электронных письма. При поиске по содержанию сообщения будут найдены и отображены все три экземпляра электронного письма.

В такой среде традиционное обнаружение дубликатов не имеет смысла. Кто хочет найти несколько одинаковых писем (по содержанию) при поиске? И как можно добиться того, чтобы было сохранено только одно из трёх экземпляров письма?

Сложность требует простых решений

Известно, что сложность лучше всего компенсируется внутренней простотой и простыми решениями, а не сложными конструкциями решений.

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

  • Envelope-From – X-REAL-MAILFROM
  • Envelope-To – X-REAL-RCPTTO
  • Return-Path
  • Тема
  • Message-Id
  • Дата
  • От
  • Кому
  • Копия
  • Тело

Конечно, в частности, при передаче по SMTP появляются дополнительные специфические заголовки (так называемые Received-Header) в электронном письме. Содержимое этих Received-Header зависит от фактического пути передачи соответствующего электронного письма. Это означает, что если два электронных письма M1 и M2 идентичны в отношении вышеупомянутых (не связанных с передачей) заголовков, то это определенно одно и то же электронное письмо — независимо от того, какие и сколько зависящих от передачи заголовков еще содержатся в электронном письме.

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

Кроме того, не только полученные заголовки, но и подписи DKIM (и другие элементы) не связаны напрямую с содержимым электронного письма. Эти заголовки можно отнести к оболочке электронного письма.

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

Практика versus формальные критерии и соблюдение нормативных требований

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

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

Вернемся к нашему примеру: если теперь несколько текстовых или содержательно одинаковых электронных писем M1, M2 и M3 (в вышеупомянутом смысле разных экземпляров одного и того же электронного письма) передаются в архив, возникает вопрос, как следует обращаться с разными экземплярами электронных писем с разными заголовками.

Взгляд на правовые аспекты этой ситуации

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

Чтобы исключить возможную (правовую) дилемму, поэтому целесообразно (практически говоря) архивировать все экземпляры соответствующего электронного письма (в нашем примере M1, M2, M3).

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

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

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

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

Решение о виде используемого обнаружения дубликатов и связанная с этим ответственность перед финансовым управлением лежит исключительно на операторе.

Что такое электронная почта?

Является ли электронное письмо каждым экземпляром, даже если два экземпляра различаются только одним транспортным заголовком, который в свою очередь не способствует увеличению информационного значения сообщения? Следует ли классифицировать электронную почту исключительно по формальным критериям? Или электронная почта - это сообщение между двумя или более пользователями, существенной (и также релевантной для соответствующего GoBD архивирования) частью которого является само сообщение? Имеют ли (обычно остающиеся скрытыми для пользователя) почтовые заголовки значение для GoBD (даже если они архивируются как часть исходного письма)?

Что именно представляет собой электронная почта, остается в этом смысле открытым вопросом еще некоторое время.

Теперь у вас, дорогой читатель, есть слово! Напишите нам письмо или комментарий о вашем понимании вида и объема электронной почты.

Правовое уведомление / Отказ от ответственности / Дисклеймер

Эта статья не является юридической консультацией. Она служит только для общей информации. Мы не несём ответственности за точность или полноту предоставленной информации. Любая ответственность исключена.