以下电子邮件标记为于 8 月 15 日发送，但于 9 月 6 日收到。
电子邮件上除第一个之外的所有日期戳都是 9 月 6 日的（有些是 7 日，但这是因为接收服务器是 PDT 而不是 GMT）。
发件人声称这封电子邮件是在 8 月 15 日从他们的机器发出的，差不多是三周前。这可能是真的吗？有没有可能它离开他们的机器然后被卡在某个地方直到 6 日？
第一封电子邮件：所有时间戳均在“发送”日期之后三周
Delivered-To: xxxxxxxx
Received: by 10.231.4.202 with SMTP id 10cs144069ibs;
Tue, 6 Sep 2011 20:25:32 -0700 (PDT)
Received: by 10.227.152.129 with SMTP id g1mr5802672wbw.56.1315365931065;
Tue, 06 Sep 2011 20:25:31 -0700 (PDT)
Return-Path: <xxxxxxxx>
Received: from coumta04.netbenefit.co.uk (coumta04.netbenefit.co.uk [95.130.76.115])
by mx.google.com with ESMTP id 21si9249722wbw.107.2011.09.06.20.25.29;
Tue, 06 Sep 2011 20:25:30 -0700 (PDT)
Received-SPF: neutral (google.com: 95.130.76.115 is neither permitted nor denied by best guess record for domain of xxxxxxxx) client-ip=95.130.76.115;
Authentication-Results: mx.google.com; spf=neutral (google.com: 95.130.76.115 is neither permitted nor denied by best guess record for domain of xxxxxxxx) smtp.mail=xxxxxxxx
Received: from [84.252.254.11] (port=1257 helo=xxxxxxxx)
by coumta04.netbenefit.co.uk with esmtp (NBT 4.72 2)
id 1R18lR-0001SR-DZ
for xxxxxxxx; Wed, 07 Sep 2011 04:25:29 +0100
Return-Receipt-To: "xxxxxxxx" <xxxxxxxx>
Subject: xxxxxxxx
Date: Mon, 15 Aug 2011 15:51:10 +0100
Message-ID: <xxxxxxxx>
X-MS-Has-Attach: yes
MIME-Version: 1.0
Content-Type: multipart/related;
type="multipart/alternative";
boundary="----_=_NextPart_001_01CC5B5A.C52AC300"
X-MS-TNEF-Correlator:
Thread-Topic: xxxxxxxx
Thread-Index: xxxxxxxx
Disposition-Notification-To: xxxxxxxx
Content-class: urn:content-classes:message
From: xxxxxxxx
X-MimeOLE: Produced By Microsoft Exchange V6.5
To: xxxxxxxx
X-NB-Virus-Scan: virus-free
X-Originally-To: xxxxxxxx
This is a multi-part message in MIME format.
------_=_NextPart_001_01CC5B5A.C52AC300
Content-Type: multipart/alternative;
boundary="----_=_NextPart_002_01CC5B5A.C52AC300"
------_=_NextPart_002_01CC5B5A.C52AC300
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
xxxxxxxx
------_=_NextPart_002_01CC5B5A.C52AC300
xxxxxxxx
------_=_NextPart_002_01CC5B5A.C52AC300--
------_=_NextPart_001_01CC5B5A.C52AC300
Content-Type: image/jpeg;
name="xxxxxxxx"
Content-Transfer-Encoding: base64
Content-Description: xxxxxxxx
Content-Location: xxxxxxxx
xxxxxxxx
------_=_NextPart_001_01CC5B5A.C52AC300--
编辑
有第二封电子邮件与第一封电子邮件同时到达。两封电子邮件都来自同一家公司，但它们来自不同的个人，并且可能来自该公司的不同计算机。虽然可能的答案是该个人忘记按“发送和接收”按钮长达三周，或者电子邮件被 Outlook 捕获，但两封这样的电子邮件的可能性就小得多。
同一家公司的另一个人同时发送的第二封电子邮件（两周后）
该公司没有声称或抱怨在此期间出现任何互联网中断。请注意，第二封电子邮件的第一次跳转比上一封电子邮件的第一次跳转早 7 秒，而“发送日期”显然晚了两周：
Delivered-To: xxxxxxxx
Received: by 10.231.4.202 with SMTP id 10cs144068ibs;
Tue, 6 Sep 2011 20:25:26 -0700 (PDT)
Received: by 10.216.229.88 with SMTP id g66mr2963523weq.9.1315365924837;
Tue, 06 Sep 2011 20:25:24 -0700 (PDT)
Return-Path: <xxxxxxxx>
Received: from coumta04.netbenefit.co.uk (coumta04.netbenefit.co.uk [95.130.76.115])
by mx.google.com with ESMTP id u35si8835621weq.122.2011.09.06.20.25.23;
Tue, 06 Sep 2011 20:25:23 -0700 (PDT)
Received-SPF: neutral (google.com: 95.130.76.115 is neither permitted nor denied by best guess record for domain of xxxxxxxx) client-ip=95.130.76.115;
Authentication-Results: mx.google.com; spf=neutral (google.com: 95.130.76.115 is neither permitted nor denied by best guess record for domain of xxxxxxxx) smtp.mail=xxxxxxxx
Received: from [84.252.254.11] (port=1257 helo=xxxxxxxx)
by coumta04.netbenefit.co.uk with esmtp (NBT 4.72 2)
id 1R18lO-0001SR-G0
for xxxxxxxx; Wed, 07 Sep 2011 04:25:23 +0100
Subject: xxxxxxxx
Date: Tue, 30 Aug 2011 10:49:00 +0100
Message-ID: <xxxxxxxx>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
MIME-Version: 1.0
Content-Type: multipart/related;
type="multipart/alternative";
boundary="----_=_NextPart_001_01CC66FA.0B9BFD72"
Thread-Topic: xxxxxxxx
Thread-Index: Acxm+gtdtV3BSonSR826xyTFQoiE9w==
From: "xxxxxxxx" <xxxxxxxx>
Content-class: urn:content-classes:message
To: <xxxxxxxx>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Cc: "xxxxxxxx" <xxxxxxxx>
X-NB-Virus-Scan: virus-free
X-Originally-To: xxxxxxxx
This is a multi-part message in MIME format.
------_=_NextPart_001_01CC66FA.0B9BFD72
Content-Type: multipart/alternative;
boundary="----_=_NextPart_002_01CC66FA.0B9BFD72"
------_=_NextPart_002_01CC66FA.0B9BFD72
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
xxxxxxxx
------_=_NextPart_002_01CC66FA.0B9BFD72
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
xxxxxxxx
------_=_NextPart_002_01CC66FA.0B9BFD72--
xxxxxxxx
------_=_NextPart_001_01CC66FA.0B9BFD72
Content-Type: image/jpeg;
name="xxxxxxxx"
Content-Transfer-Encoding: base64
Content-Description: xxxxxxxx
Content-Location: xxxxxxxx
xxxxxxxx
------_=_NextPart_001_01CC66FA.0B9BFD72--
我知道更改计算机时钟将导致 Outlook 给出与此等效的外发邮件戳，但我想知道这样做是否有任何正当理由。
答案1
不，这是不可能的。至少实际上不可能。
Received: from [84.252.254.11] (port=1257 helo=xxxxxxxx)
by coumta04.netbenefit.co.uk with esmtp (NBT 4.72 2)
id 1R18lR-0001SR-DZ
for xxxxxxxx; Wed, 07 Sep 2011 04:25:29 +0100
Date: Mon, 15 Aug 2011 15:51:10 +0100
这表明该邮件是在 8 月份写的。可能是伪造的，但有可能，我们假设这确实是在 8 月份写的。但收到的第一行表示收到邮件的第一个真实邮件服务器。这是在 9 月份。这条线也可能是伪造的，但谁能伪造它来对付他呢？
那么会发生什么呢？
- 用户将时钟调回 8 月来欺骗你，但由于他无法控制（第一个）服务器，因此这个服务器揭露了他的谎言。
- 用户在 8 月份写了一封邮件，并将邮件放在客户端（Outlook）的“发件箱”中。直到他按下“发送和接收”按钮，邮件才被发送出去。
- 用户在 8 月份撰写了邮件，并将其放在“草稿”文件夹中。然后他在 9 月份发现了错误并点击了“发送”按钮。
无论事实如何（可能是我没想到的情况），邮件在 9 月到达了第一台服务器（或者服务器认为是 9 月）。但问题出在客户端（用户、软件、网络等）。
编辑
或者，正如您所发现的，还有最后一种情况：第一台服务器宕机了，根本无法接受邮件。客户端尝试了一次又一次，但直到 9 月份管理员重新启动服务器后才成功。或者其他原因导致第一台服务器无法接受邮件。
答案2
是的，如果邮件被保存在发送方的内部队列中，那么这是有可能的。根据 whois，发送 IP 似乎在 xDSL 块中，很可能是内部邮件软件无法上线并将其排队。如果这是一组完整的标头，则没有内部邮件服务器将其排队（这通常会导致在 5-7 天后“无法投递”后被退回）。
在邮件客户端中排队，没有明确定义的“最佳实践”来确定在放弃之前要保留电子邮件多长时间，但我希望如果它们已经在客户端中排队，那么来自多封邮件的时间戳（大致）相同。
答案3
请注意：
它是相同的源主机（84.252.254.11），并且在编写电子邮件（假设日期标头正确）和路由中第一个 MTA 时间之间的延迟相同（相当大的）。
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator
X-MimeOLE
告诉我，这是一些 Exchange，它收集了从客户端 Outlook 发送的邮件（没有 SMTP，因此我们看不到真实的端点），声称已成功发送给用户，但很长时间没有发送到网络，也没有为用户生成 NDR