Возможно, вы на первый взгляд подумаете “В чём же смысл этого вопроса? Что такое электронная почта, ведь это же очевидно!”. То, что с точки зрения типичного пользователя сначала, безусловно, просто, правильно и понятно ответить, может под более техническими (и также Compliance-) аспектами стать сложным вопросом. Особенно когда речь идёт об архивировании электронных писем и вопросе оригинала письма. Налоговые органы проверяют архивирование почты налогоплательщика, в частности, на основе критериев надлежащего ведения записей GoBD, согласно которым восстановление оригинала каждой заархивированной электронной почты должно быть возможным.

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

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

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

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

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

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

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

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

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 (даже если они архивируются как часть исходного письма)?

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

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

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

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