我试图在 SO 和网络上搜索类似的问题,但没有成功。
tl;dr:当引用和回复标头都不可用(缺失/空)时,线程逻辑会发生什么?电子邮件服务提供商是否有可能将这些标头添加到选择性邮件中,而不是全部?
背景:
我知道引用标头包含消息 ID 的面包屑路径,而回复标头指向链接列表/线程中的直接节点。
但是,当引用和回复标头都不可用(缺失/空)时,线程逻辑会发生什么?就我而言,我看到不相关的消息最终出现在同一个线程中。例如,
Message 1
in-reply-to: <350576222@ip-xxx-xx-x-72.eu-west-1.compute.internal>
references: <350576222@ip-xxx-xx-x-72.eu-west-1.compute.internal>
message-id: <trinity-d2cd4e72-@app-gmx-bap21>
Message 2 - no in-reply-to, and references headers
message-id: <2E0FA10B@icloud.com>
至少从标题中没有相关性,但这两个最终在同一个线程中。唯一的共同元素是主题行,并且在两者中都与根消息保持不变。具有相同主题行并包含引用和回复标头的所有其他消息都有自己的单独线程。
环境:
我正在使用一个共享收件箱工具 (FrontApp),它带有一个基于同步的 GMail,而不是我自己的代码。该工具有自己的“重复数据删除”逻辑,但我不知道它是否修改/删除了标题。根消息始终从我们的系统发送 - Java Mail 通过 GMail SMTP,并包含用于内部审计的 BCC 字段。
另外,如果有帮助,我发现这主要发生在消息 1 来自 GMail/Yahoo 帐户,而消息 2 来自 web.de 或 gmx.de 帐户的情况下。
来自 gmx 和 web de 的所有电子邮件是否都缺少这些标头/为空?不,我有一些包含这些标题的 gmx 和 web de 电子邮件的证据,它们完美地存在于各自的线程中,没有冲突问题。
另一个关键是,GMail 本身不存在这个问题,当我登录帐户并查看这些消息时,它们位于各自的线程中(每个都有自己的 google thread_id)。