什么是电子邮件？- Benno邮件存档

也许您乍一看会想到“这到底是什么问题？电子邮件到底是什么，显而易见！”。从典型用户的角度来看，最初似乎确实简单、正确且易于理解，但从更技术（以及合规）层面来看，却可能成为一个棘手的问题。尤其是涉及电子邮件的归档以及电子邮件原件的问题时。税务部门会根据GoBD的合规性标准，对纳税人的邮件归档进行检查，其中要求必须能够恢复每封归档电子邮件的原件。.

当然，Benno MailArchiv 自第一时刻起就具备显示每封原始归档邮件的功能。此时会从归档中取出以原生 RFC 822 格式归档的电子邮件，解压后以“源代码”形式呈现。这既不是特别之处，也不能解释我们最初提出的问题。归档的最终是来自邮件服务器或用户邮箱的邮件，并且需要归档的内容。.

原件和邮件示例

但是如果一个电子邮件的唯一相关原件可能有两个、三个甚至更多的副本会怎样？我们在这里却明确不不是指简单的重复，例如多次检索的邮箱中的电子邮件或类似的情况。识别电子邮件重复（或双重）是邮件归档解决方案最基本的任务之一。Benno MailArchiv 同样能够在显示原始电子邮件时处理此类情况。

“多个相同邮件的相关原件？不可能！” 您这么说？在大型托管公司和云服务提供商（CSP）实际中经常出现的复杂环境中并非如此。由于基础设施因素，电子邮件有时会多次进入Benno MailArchiv的“处理漏斗”。.

以下所述的情况从技术角度来看相对容易理解。但符合法规的邮件归档远远更多超过技术上对（GoBD和合规）要求的映射或实现。这是一种在用户需求、法律要求以及可能的通用合规要求之间的平衡的IT-Lösung。

我们特此邀请您与我们讨论电子邮件是什么（或者也许根本不是）。当您阅读了本文后，您对如此琐碎的“东西”（如电子邮件）的看法可能会改变。请给我们发送电子邮件或使用本文末尾的评论功能，向我们阐述您的看法。.

归档电子邮件从技术角度来说是一项相对简单的任务。（大致来说）它涉及用户邮箱、邮件服务器和传输路径。整个系统配备了相应的接口。根据不同的本地环境，通常有多种方法以（适当的方式）归档电子邮件。.

本地邮件存档或内部邮件存档

本地部署的邮件归档系统通常具有这样的特点，即所有需要归档的电子邮件始终且毫无例外地通过相同的路径或所选机制进行归档。虽然根据客户及其IT环境的不同，邮件导入归档系统的方式可能各不相同，但可以确定的是，在本地部署安装中，一旦确定并设置了邮件路径，所有邮件实际上都将遵循相同的路径。因此，一旦完成了与邮件归档系统的连接，后续的一切都将自动运行。所有需要归档的电子邮件都将始终遵循相同的路径。一套方案适用于所有情况。.

这种情况下的优势是统一性。邮件被按照一个固定的模式归档。这种情况下通常没有例外。因此，电子邮件重复件基本上被排除在外。其余的，即对实际重复件进行分类，由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的角度来看，这三封相同的邮件是不同的电子邮件。它们也会被分别存档。这样一来，从用户的角度（即仅就电子邮件的内容而言）看来，存档中似乎包含了三封相同的电子邮件。在搜索邮件内容时，会找到并显示所有三个邮件示例。.

在这样的环境中，传统的重复检测并不合理。谁会在搜索时找到多封（按消息内容）相同的邮件？如何才能实现只存档三份邮件中的一份？

复杂性需要简单的解决方案

众所周知，复杂性最容易通过内部简单性和简单的解决方案来弥补，而不是通过复杂的解决方案结构.

让我们进一步研究这个问题，我们发现一封电子邮件已经可以通过以下头信息以及其消息文本明确标识：

发件人 – X-REAL-MAILFROM
收件人 – X-REAL-RCPTTO
返回路径
主题
消息ID
日期
发件人
收件人
抄送
正文

当然，在通过SMTP传输时，电子邮件中会出现额外的特定头部（所谓的Received-Header）。这些Received-Header的内容取决于每封电子邮件的实际传输路径。这意味着，如果两封电子邮件M1和M2在上述（非传输特定的）头部方面是相同的，那么它们肯定是同一封电子邮件–无论其中包含哪些和多少传输相关的头部。.

结论：传输路径可能会导致额外的头部。因此，一封电子邮件变成了多封不完全相同的电子邮件。传输相关的头部对于电子邮件的消息或内容唯一性并不重要（它们的存在仅记录了经过的传输路径）。.

此外，不仅接收头（Received-Header），还有DKIM签名（以及其他元素）与电子邮件的内容没有直接关系。可以将这些头信息归为电子邮件的信封（Envelope）。.

因此，对于技术上不同但内容相同的多个邮件实例的情况，解决方案是显而易见的：虽然出于合规性考虑，对整个电子邮件的校验和（Checksum）是强制性的，但基于上述电子邮件组成部分的第二校验和同样简单有效地解决了这一难题。.

实践与形式标准和合规性

许多问题可以通过技术手段优雅地解决。然而，有些实际解决方案在日常应用中却因形式方面的考虑而失败。因此，这里需要更仔细地观察，因为合规性在邮件归档方面优先于实用性。

符合GoBD的邮件归档需要能够将每封电子邮件在原始状态下从归档中恢复。每封电子邮件必须包括所有标题、附件等，也即在 “消息源文本” 中显示。此外，每封电子邮件必须能够检查是否存在任何篡改。具体而言，可以通过上述提到的校验和对整封电子邮件以及整个归档内容的一致性或完整性进行检查。.

现在回到我们的例子：如果现在将多个文本或内容相同的电子邮件M1、M2和M3（在上述意义上不同的相同电子邮件的副本）提交给存档，就会产生一个问题，即如何处理具有不同标头的电子邮件副本。.

对这种情况的法律方面的看法

我们认为，从纯法律角度来看，没有强制要求必须归档多个版本的电子邮件，特别是当它们仅在所包含的邮件头方面存在差异时。然而，不能排除不同的人对法律有不同的理解，因此我们的假设可能不会得到一致同意，或者从法律角度来看是错误的。.

为了避免可能的（法律）困境，因此（从实际角度考虑）应该将相关电子邮件的所有副本（在我们的示例中为M1、M2、M3）进行归档。.

如果从形式上看待情况，我们的例子中的多个邮件样本是不同的电子邮件。即使它们之间的差异是技术性的，并且在日常生活中它们之间的差异的实际实用价值不存在或几乎不存在，从形式上讲，它们是不同的电子邮件。这可以立即通过不同的校验和来验证。.

另一方面，可以简单地排除任何法律不确定性，只要所有邮件样本都被存档。即使根据上述具有每个电子邮件两个不同校验和的过程，技术上很容易实现，例如，只存档一系列邮件样本中的第一个样本。

为了实现对运营商具有法律约束力的解决方案，我们建议在实施之前与选定的法律顾问讨论这一事项。只有在就重复识别的具体实施形式进行讨论和决定之后，才应相应地实施该解决方案。.

在此期间，我们假设在法律上已经足够可能，以使用简化的重复邮件或副本检测，只归档多个到达的电子邮件实例中的一个。基于GoBD的要求，编制程序文件的创建是毫无疑问的，并且是强制性的。我们在此背景下假设，对事实的说明或记录，即仅归档一个邮件实例，在程序文件中已经足够应该，以实现合法合规的归档。

关于所采用的重复检测方式的决定以及随之而来的对财政部门的责任归属于 唯一且仅 运营商。