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

Question

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

Вы могли категоризировать свои данные согласно важности и работать с бизнесом для создания соответствующего SLA. Типичные вещи сфокусироваться на пора восстановить и как устаревший данные добираются. Вес дан между полным и возрастающим, обычно еженедельно и ежедневно соответственно. Если Ваш резервный SLA разрабатывается правильно, технические опции должны быть очевидными.

LTO-4 может сохранить 800 ГБ. В то время как не всегда идеал, много людей использует ленту. Вы собираетесь найти обнаружение с логистическими проблемами независимо. Часто, компромиссы делаются между важностью данных и стоятся. Чем больше данных, тем более стоимость.

Жесткие диски могут быть соответствующими, но из-за них являющийся механическим устройством я не рекомендовал бы использовать их для вращения. Для удаленного устройства хранения данных основной выбор между копированием по сети к физически отдельному местоположению или портативному носителю, это менее подвержено отказу. (Лента)

Править

Мы не должны перемещать удаленную ежедневную газету. У нас есть ежедневные резервные копии на Сервер, у Нас есть проблема, перемещающаяся удаленный.

Так запишите возрастающие резервные копии ежедневно для записи на ленту также. Я действительно не понимаю Вашу проблему в этой точке. Полное резервное копирование с большими наборами данных не будет мгновенным.

2

email smtp

задан Peter Nixey 28 October 2011 в 19:11

Ссылка

3 ответа

Похожие вопросы

score 3 · Answer 1 · 3 December 2019 в 08:43

Yes, it's possible, if it was held in an internal queue on the sending side. From whois, the sending IP seems to be in an xDSL block, it's quite possible that the internal mail software was unable to get on-line and queued it. If that's a complete set of headers, there was no internal mail server queueing it up (that normally results in a bounce after 5-7 days of "unable to deliver").

Queued up in the mail client, there's no well-defined "best practices" for how long to hold on to the email before giving up, but I'd expect the timestamps from multiple mails to be (roughly) the same, if they've been queued in the client.

score 0 · Answer 2 · 3 December 2019 в 08:43

Обратите внимание:

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

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

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

score 7 · Answer 3 · 3 December 2019 в 08:43

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

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). Откуда он никогда не отправлялся, пока он не нажал кнопку «Отправить и получить».
Пользователь написал письмо в августе и поместил его в папку «Черновик». Затем он заметил ошибку в сентябре и нажал кнопку «Отправить».

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

Изменить