E-mail entregue exatamente um mês depois

Question

O que poderia explicar esse comportamento estranho de entrega de e-mail?

Alguém me enviou uma mensagem de e-mail em 16 de fevereiro. Eu não a recebi nem imediatamente nem nos próximos dias.

Então, do nada, EXATAMENTE 1 MÊS DEPOIS (em 16 de março), recebo a mensagem que ele me disse que enviou em 16 de fevereiro.

Eu recebi e-mails devolvidos, vi e-mails perdidos, mas nunca vi e-mails sendo entregues exatamente um mês depois.

Assumindo que aquele cara realmente clicou no botão 'Enviar' em 16 de fevereiro, o que poderia explicar a entrega em 16 de março?

Para ajudar a resolver esse mistério, estou citando o cabeçalho abaixo (os detalhes de identificação foram alterados para proteger a privacidade):

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

    

Answer 1

Veja os cabeçalhos Received: , começando no último e trabalhando. O último é:

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 é um cliente da Comcast:

$ 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.

Como esse é o primeiro Received: header, ele nos diz que a mensagem não foi entregue a um servidor até 16 de março. Observe também que o Date: header é 16 de março.

Assim, a única conclusão que posso apresentar é a mensagem que fica na caixa de saída do remetente por um mês devido a alguma configuração incorreta ou problema no cliente final. Talvez a configuração do servidor de saída estivesse errada? Então, o que estava errado, foi corrigido em 16 de março e o cliente de e-mail conseguiu enviar o e-mail com sucesso.

    

Answer 2

Minha primeira suspeita seria uma configuração de data incorreta em um dos sistemas envolvidos. A data de envio é definida pelo sistema que cria o email, por isso, se tiver a hora errada, será enviada na hora errada.

Se ele realmente pressionasse o envio naquela data, ele poderia ter ficado preso na fila de email de saída de seu cliente de email e, por acaso, entregue um mês depois, quando ele reiniciou o cliente de email ou algo semelhante. / p>

É improvável que ele tenha ficado preso em um servidor de e-mail, já que a maioria dos servidores de e-mail descartará mensagens que não podem entregar dentro de um determinado período de tempo (geralmente quatro dias)