![电子邮件恰好在一个月后送达](https://linux22.com/image/543613/%E7%94%B5%E5%AD%90%E9%82%AE%E4%BB%B6%E6%81%B0%E5%A5%BD%E5%9C%A8%E4%B8%80%E4%B8%AA%E6%9C%88%E5%90%8E%E9%80%81%E8%BE%BE.png)
什么可以解释这种奇怪的电子邮件传递行为?
2 月 16 日有人给我发了一封电子邮件。我没有立即收到,也没有在接下来的几天里收到。
然后,出乎意料的是,整整一个月后(3 月 16 日),我收到了他告诉我他在 2 月 16 日发送的消息。
我见过被退回的电子邮件,也见过丢失的电子邮件,但我从未见过一个月后才送达的电子邮件。
假设那个人确实在 2 月 16 日点击了“发送”按钮,那么如何解释他在 3 月 16 日发送邮件呢?
为了帮助解决这个谜团,我引用了下面的标题(为保护隐私而更改了识别细节):
From - Wed Mar 16 14:55:21 2011
X-Account-Key: account3
X-UIDL: UID1720-1259701283
X-Mozilla-Status: 0003
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-path: <[email protected]>
Envelope-to: [email protected]
Delivery-date: Wed, 16 Mar 2011 13:18:14 -0500
Received: from smtpauth23.prod.mesa1.secureserver.net ([64.202.165.47]:52866)
by server521.webhost.com with smtp (Exim 4.69)
(envelope-from <[email protected]>)
id 1Q0H08-0004ke-5M
for [email protected]; Wed, 16 Mar 2011 13:18:14 -0500
Received: (qmail 9698 invoked from network); 16 Mar 2011 17:28:43 -0000
Received: from unknown (76.24.218.3)
by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 16 Mar 2011 17:28:42 -0000
From: "Alan Doe" <[email protected]>
To: "My Co" <[email protected]>
Subject: Confidentiality Agreement
Date: Wed, 16 Mar 2011 13:18:10 -0400
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0001_01CBE4A7.3BCF3DE0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AbvPQ9BP9rTIPgVpRWqahWXuOLXz9g==
Content-Language: en-us
X-Spam-Status: No, score=0.3
X-Spam-Score: 3
X-Spam-Bar: /
X-Spam-Flag: NO
This is a multipart message in MIME format.
------=_NextPart_000_0001_01CBE4A7.3BCF3DE0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
答案1
查看Received:
标题,从最后一个开始向上。最后一个是:
Received: from unknown (76.24.218.3)
by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 16 Mar 2011 17:28:42 -0000
76.24.218.3 是康卡斯特客户:
$ nslookup 76.24.218.3
Non-authoritative answer:
3.218.24.76.in-addr.arpa name = c-76-24-218-3.hsd1.ct.comcast.net.
因为这是第一个Received:
标题,它告诉我们该消息直到 3 月 16 日才交给服务器。另请注意,Date:
标题是 3 月 16 日。
因此,我能得出的唯一结论是,由于客户端的一些配置错误或问题,该邮件在发件人的发件箱中停留了一个月。也许他的发件服务器配置有误?不管出了什么问题,都在 3 月 16 日得到修复,邮件客户端能够成功发送邮件。
答案2
我首先怀疑是某个系统日期设置不正确。发送日期由创建电子邮件的系统设置,因此如果时间错误,则会在错误的时间发送。
如果他确实在那天按下了“发送”键,邮件可能会卡在他的邮件客户端的出站电子邮件队列中,然后在一个月后,当他碰巧重新启动邮件客户端或类似操作时,邮件才会被发送。
它不太可能被困在邮件服务器上,因为大多数邮件服务器都会丢弃在一定时间内(通常是 4 天)无法投递的消息