Возможно ли, что это письмо было отправлено, когда отправитель утверждает?

Следующее электронное письмо было помечено как отправленное 15 августа, но было получено 6 сентября.

Все отметки даты в электронном письме, за исключением первой, относятся к 6 сентября (некоторые - к 7-му, но это потому, что принимающим сервером было PDT, а не GMT).

Отправитель утверждает, что это письмо было отправлено с его машины 15 августа, почти за три недели до этого. Возможно ли, что это правда? Есть ли способ, чтобы он оставил машину и застрял где-нибудь до 6-го числа?

Первое электронное письмо: все временные метки датированы тремя неделями позже даты отправки.

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;
Return-Receipt-To: "xxxxxxxx" <xxxxxxxx>
Subject: xxxxxxxx
Date: Mon, 15 Aug 2011 15:51:10 +0100
Message-ID: <xxxxxxxx>
MIME-Version: 1.0
Content-Type: multipart/related;
    type="multipart/alternative";
    boundary="----_=_NextPart_001_01CC5B5A.C52AC300"
Thread-Topic: xxxxxxxx
Thread-Index: xxxxxxxx
Disposition-Notification-To: xxxxxxxx
Content-class: urn:content-classes:message
From: xxxxxxxx
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 предоставит исходящую почтовую метку, эквивалентную этой, однако я хотел бы знать, есть ли для этого какая-либо законная причина.

email smtp

Нет, это невозможно. По крайней мере, не совсем.

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

Это указывает на то, что письмо было написано в августе. Может быть подделано, но возможно, и давайте предположим, что это действительно было написано в августе. Но первая полученная строка указывает на первый реальный почтовый сервер, получивший почту. И это было в сентябре. Эту линию тоже можно было подделать, но кто должен подделывать ее против него?

Так что же могло случиться?

Пользователь установил часы на август, чтобы солгать вам, но, поскольку он не контролирует (первый) сервер, этот раскрыл ложь.
Пользователь написал письмо в августе и положил его в «Исходящие» на своем клиенте (Outlook). Откуда он никогда не отправлялся, пока он не нажал кнопку «Отправить и получить».
Пользователь написал письмо в августе и положил его в папку «Черновик». Затем в сентябре он заметил ошибку и нажал кнопку «Отправить».

Независимо от того, что верно (это может быть сценарий, о котором я не думал), почта достигла первого сервера в сентябре (или то, что сервер считал сентябрем). Но проблема на стороне клиента (пользователя, программного обеспечения, сети и т.п.).

редактировать

Или, как вы выяснили, есть последний сценарий: первый сервер не работал и вообще не мог принимать почту. Клиент пытался и пытался, но безуспешно, пока администратор не перезапустил сервер в сентябре. Или что-то еще, что "сломало" первый сервер, принимавший почту (и).

Да, возможно, если он находился во внутренней очереди на стороне отправителя. Судя по whois, отправляющий IP-адрес находится в блоке xDSL, вполне возможно, что внутреннее почтовое программное обеспечение не смогло подключиться к сети и поставило его в очередь. Если это полный набор заголовков, значит, внутренний почтовый сервер не ставил его в очередь (обычно это приводит к отказу после 5-7 дней «невозможности доставки»).

В очереди в почтовом клиенте нет четко определенных "лучших практик" относительно того, как долго хранить электронное письмо, прежде чем отказаться, но я ожидаю, что временные метки для нескольких писем будут (примерно) одинаковыми, если они ' были поставлены в очередь клиента.

Просто обратите внимание:

Это тот же хост-источник (84.252.254.11) и такая же (довольно большая) задержка между записью электронного письма (предположим, что заголовок даты правильный) и первым временем MTA в маршруте.

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

Сообщает мне, что это некий Exchange, который собирал почту, отправленную из Outlook клиента (без SMTP, поэтому мы не можем видеть настоящий конечные точки), утверждают, что они успешно получены пользователем, но не отправляются в сеть и не генерируют отчет о недоставке для пользователей в течение долгого времени