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

也许您第一眼就想到了“这个问题有什么意义？什么是电子邮件，这不是很明显吗！”。从典型的用户角度来看，这个问题最初肯定是简单、正确和可以理解的，但是从技术（以及合规性）的角度来看，它可能会成为一个棘手的问题。特别是当涉及到电子邮件存档和原始电子邮件的问题时。税务机关根据GoBD的合规性标准检查纳税人的邮件存档，按照该标准，必须能够恢复每封存档电子邮件的原件。.

当然，Benno MailArchiv 从一开始就具备显示每封存档邮件原件的功能。在此过程中，存档在原生RFC 822格式的电子邮件从存档中取出，解压缩并以“源代码”形式显示。这一切并不特别，也不能解释我们最初提出的问题。最终，邮件服务器或用户邮箱中的内容将被存档并保存。.

原件和邮件示例

但是，如果不是只有一个相关的电子邮件原始邮件，而是可能有两个、三个甚至更多的副本，会发生什么？我们在这里讨论的当然不是明确地 不是简单的重复邮件，例如多次检索的电子邮件或类似内容。识别电子邮件重复邮件（或称为重复邮件）是邮件存档解决方案的最基本任务之一。Benno MailArchiv 能够做到这一点，就像以原始形式显示电子邮件一样。

“同一封电子邮件有多个相关原始邮件？不可能！”您会说？在大型托管公司和云服务提供商（CSP）的实践中，这种情况并不少见。在这里，由于基础架构的原因，电子邮件可能会多次进入 Benno MailArchiv 的“处理渠道”。.

下面描述的事实从技术角度来看相对容易理解。但是，符合法律规定的邮件归档远远超过

我们在此邀请您与我们讨论什么是电子邮件（或者可能不是）。阅读完这篇文章后，您对电子邮件这样一个看似平凡的“东西”的看法可能会有所改变。请给我们发送电子邮件或使用本文末尾的评论功能，向我们讲述您对此的看法。.

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

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

本地部署的邮件归档系统通常具有这样的特点，即所有需要归档的电子邮件始终且毫无例外地通过相同的路径或所选机制进行归档。虽然根据客户及其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的要求，创建程序文档是毫无疑问的，并且是强制性的。在这种情况下，我们假设在程序文档中解释或记录仅存档一个电子邮件示例的事实，应该足以实现法律安全的存档。

有关重复邮件识别方式的决定以及由此带来的对税务部门的责任完全由运营者承担。