以下电子邮件被标记为8月15日发送，但是在9月6日收到。
除了第一个电子邮件的所有date戳都是在9月6日（有些是第7次，但这是因为接收服务器是PDT而不是GMT）。
发件人声称，这封电子邮件是在8月15日，几乎是三周前从他们的电脑发送的。 这有可能是真的吗？ 有没有什么办法可以让它们离开机器，然后在6号之前卡住？
第一封电子邮件：所有时间戳都是在“发送”date后的三个星期
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中被捕获，两个这样的电子邮件变得不太可能。
同一公司另一个人发送的同时发送的第二封电子邮件（2周后）
在此期间，公司没有要求或抱怨任何互联网中断。 请注意，第二封电子邮件的第一跳是前一封电子邮件的第一跳前7秒，而“发送date”显然是两周后：
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给出相当于这个的传出邮件标记，但我想知道是否有任何合法的原因。
不，这是不可能的。 至less不是真的。
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
这表明邮件是在八月写的。 可能是伪造的，但可能的，让我们假设这是真的写在八月。 但收到的第一行显示了第一个真正的邮件服务器。 这是在九月。 这条线也可能是伪造的，但是谁应该伪造它呢？
那么会发生什么？
无论如何（可能是我没有想到的情况），邮件在九月份到达了第一台服务器（或者服务器认为是九月份）。 但问题出在客户端（用户，软件，networking等）。
编辑
或者当你发现有一个最后的情况：第一台服务器closures，根本无法接收邮件。 客户端尝试并尝试，但直到9月份pipe理员重新启动服务器才成功。 或者是“破坏”第一台服务器接受邮件的东西。
是的，如果它在发送方的内部队列中被保留，那么是可能的。 从whois来说，发送IP似乎在xDSL块中，内部邮件软件很可能无法上线并排队。 如果这是一套完整的头文件，那么没有内部邮件服务器将其排队（通常会在“无法传递”5-7天后导致反弹）。
排队在邮件客户端，放弃之前没有明确的“最佳实践”持续多久，但我希望多个邮件的时间戳（大致）是相同的，如果他们“已经在客户端排队了。
只要注意：
在写电子邮件（假定date标题是正确的）和路由中的第一个MTA时间之间是相同的源主机（84.252.254.11）和相同的（相当大的）延迟。
X-MS-Has-Attach: yes X-MS-TNEF-Correlator X-MimeOLE
告诉我，这是一些Exchange，它收集从客户端的Outlook发送的邮件（没有SMTP，因此我们看不到真正的端点），宣称成功接收到用户，但 – 没有发送到networking，也没有为用户长时间生成NDR -长时间