É possível que este email tenha sido enviado quando o remetente afirma?

Question

O seguinte e-mail foi marcado como tendo sido enviado em 15 de agosto, mas foi recebido em 6 de setembro.

Todos os registros de data no email, exceto o primeiro, são para o dia 6 de setembro (alguns são o 7º, mas isso ocorre porque o servidor de recebimento era PDT em vez de GMT).

O remetente afirma que este e-mail foi enviado de sua máquina no dia 15 de agosto, quase três semanas antes. É possível que isso seja verdade? Existe alguma maneira que poderia ter deixado sua máquina e depois ficou preso em algum lugar até o dia 6?

Primeiro e-mail: todos os registros de data e hora são datados três semanas após a data de envio

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

EDITAR

Houve um segundo email que chegou simultaneamente ao primeiro. Ambos os e-mails vieram da mesma empresa, no entanto, eram de pessoas diferentes e presumivelmente de computadores daquela empresa. Embora uma possível resposta seja que o indivíduo tenha esquecido de pressionar "enviar e receber" por três semanas ou que o e-mail tenha sido pego no Outlook, isso se torna muito menos provável com dois desses e-mails.

Segundo e-mail simultâneo enviado por uma pessoa diferente na mesma empresa (2 semanas depois)

A empresa não reivindicou nem se queixou de qualquer interrupção na Internet durante este período. Observe que o primeiro salto do segundo e-mail é de 7 segundos antes do primeiro salto do e-mail anterior, enquanto a "data de envio" é aparentemente duas semanas depois:

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

Sei que alterar o relógio do computador fará com que o Outlook forneça uma mensagem de correio de saída equivalente a esta, no entanto, gostaria de saber se existe algum motivo legítimo para isso.

    

Answer 1

Não, isso não é possível. Pelo menos não de verdade.

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

Isso indica que o email foi escrito em agosto. Pode ser forjado, mas possível e vamos supor que isso foi realmente escrito em agosto. Mas a primeira linha recebida indica o primeiro servidor de e-mail real que recebeu o e-mail. E isso foi em setembro. Esta linha poderia ter sido forjada também, mas quem deveria falsificá-la contra ele?

Então o que poderia ter acontecido?

• O usuário ajustou o relógio de volta para agosto para mentir para você, mas como ele não tem controle sobre o (primeiro) servidor, este revelou a mentira.
• O usuário escreveu o e-mail em agosto e colocou o e-mail na "Caixa de saída" em seu cliente (Outlook). De onde nunca foi enviado até que ele pressionou o botão "Enviar e receber".
• O usuário escreveu o e-mail em agosto e colocou o e-mail na pasta "Rascunho". Então ele notou o erro em setembro e apertou o botão "Enviar".

Para o que quer que seja verdade (pode ser um cenário em que não pensei), o e-mail chegou ao primeiro servidor em setembro (ou o que o servidor achou que era setembro). Mas o problema está no lado do cliente (usuário, software, rede ou afins).

Editar

Ou, como você descobriu, há um último cenário: o primeiro servidor estava inativo e não podia aceitar o e-mail. O cliente tentou e tentou, mas não teve sucesso até que o administrador reiniciou o servidor em setembro. Ou algo mais que "quebrou" o primeiro servidor a aceitar o (s) email (s).

    

Answer 2

Sim, é possível, se foi mantido em uma fila interna no lado de envio. De whois, o IP de envio parece estar em um bloco xDSL, é bem possível que o software de e-mail interno não tenha conseguido ficar on-line e colocado na fila. Se esse é um conjunto completo de cabeçalhos, não havia nenhum servidor de correio interno na fila (isso normalmente resulta em uma rejeição após 5 a 7 dias de "impossível entregar").

Enfileirado no cliente de e-mail, não há "melhores práticas" bem definidas por quanto tempo manter o e-mail antes de desistir, mas eu esperaria que os timestamps de vários e-mails fossem (aproximadamente) os mesmos, se eles foram enfileirados no cliente.

    

Answer 3

Apenas para anotar:

É o mesmo host de origem (84.252.254.11) e o mesmo atraso (bastante grande) entre a gravação de e-mail (suponha que o cabeçalho de Data esteja correto) e o primeiro tempo de MTA na rota.

X-MS-Has-Attach: yes
X-MS-TNEF-Correlator
X-MimeOLE

Diz-me, que é algum Exchange, que coletou e-mails enviados do Outlook do cliente (sem SMTP, portanto não podemos ver endpoints reais ), reivindicados como recebidos com êxito para o usuário, mas - não enviados para Net nem gerar NDR para usuários por um longo tempo