Промяна на дата на имейл

Въпросът, който всеки задава (и защо зад него се крият две много различни ситуации)

Потърсете "промяна на дата на получен имейл" в Google. Ще намерите десетки теми във форумите на Microsoft Q&A, нишки в Reddit, въпроси в Quora. Заявката е ясна, но причините зад нея са коренно различни в зависимост от това кой задава въпроса.

Има такива, които искат да фалшифицират дата ретроспективно, по причини, за които предпочитаме да не си мислим. И има IT администратори, които след IMAP миграция виждат всичките си имейли с една и съща дата (деня на миграцията) и просто искат да върнат истинските дати. Тези две ситуации нямат нищо общо помежду си, но споделят една и съща формулировка при търсенето.

Тази статия отговаря и на двете. Спойлер: в първия случай промяната не е наистина възможна по неоткриваем начин. Във втория тя е напълно легитимна и точно това прави Redate.io.

Първо: какво всъщност е "датата" на имейл?

Един имейл не съдържа само една дата. Съдържа няколко, съхранени на различни места, контролирани от различни субекти.

Заглавието Date: (RFC 2822)

Това е датата, която клиентът на подателя записва в съобщението в момента на изпращане. Тя се вижда в суровите заглавия под формата:

Date: Mon, 14 Oct 2024 09:32:11 +0200

Това заглавие е част от тялото на съобщението. Технически може да се промени, ако имате достъп до суровия файл. Но "технически" е важната дума тук.

Заглавията Received:

Всеки пощенски сървър, през който минава един имейл, добавя свое заглавие Received: с времево клеймо. Тези заглавия образуват хронологична верига от сървъра на подателя до вашата пощенска кутия. (Между другото, ако някога сте се опитвали да четете суровите заглавия на имейл, знаете, че не е точно леко четиво. Десетки редове технически метаданни, в ред от най-новото към най-старото.)

IMAP INTERNALDATE

Това е най-важният метаданен елемент за разбирането защо някои промени нямат видим ефект. INTERNALDATE е атрибут, съхраняван от страна на IMAP сървъра, независимо от съдържанието на съобщението. Именно него повечето имейл клиенти използват за сортиране на имейлите в папките. Outlook го използва. Gmail също. Apple Mail в повечето случаи - също.

INTERNALDATE не е в съобщението. Той е в базата данни на сървъра. Не можете да го промените, като редактирате .eml файл на диска си.

Какво наистина се случва при локално редактиране

Редактиране на .eml файл

Технически, .eml файлът е текстов файл. Можете да го отворите в редактор, да промените реда Date:, да запишете. Ако след това го импортирате в локален имейл клиент, показваната дата може да се промени, в зависимост от клиента.

Но ето какво не се променя:

INTERNALDATE на IMAP сървъра (остава непроменен)
Заглавията Received:, добавени от междинните сървъри
Логовете за доставка при Google, Microsoft или вашия доставчик
DKIM подписът, ако съобщението е имало такъв

Резултат: на локалната машина може да виждате различна дата. От Outlook, свързан към Exchange Online, или от Gmail в браузър, нищо не се е променило.

Промяна на системния часовник

Някои форуми препоръчват промяна на часовника на работната станция, за да "излъжете" имейл клиента. Това не работи. Outlook и Gmail не четат системния час, за да показват датите на получени имейли. Те четат INTERNALDATE от сървъра или заглавията на съобщението. Локалният часовник не участва никъде в този процес.

Манипулация чрез Thunderbird

Thunderbird предлага повече гъвкавост от повечето клиенти. С разширения или чрез директна манипулация на профила (mbox файлове, .msf файлове), някои се опитват да променят показването на датите. Може да работи в самия Thunderbird, за имейли, съхранени локално в POP3 режим. Но щом Thunderbird е свързан по IMAP, той се ресинхронизира със сървъра. "Поправката" изчезва при следващото синхронизиране.

DKIM: невидимата бариера, за която никой не споменава

Повечето имейли, изпратени след 2018 г., са подписани с DKIM (DomainKeys Identified Mail). DKIM подписът изглежда така в заглавията:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

Полето h= изброява заглавията, обхванати от подписа. В горния пример Date е подписано. Ако промените заглавието Date: на съобщението, DKIM проверката се проваля. Всеки пощенски сървър и всеки инструмент за форензичен анализ може да открие промяната, като изчисли отново подписа.

Това не е перфектна защита (злонамерен подател контролира собствения си DKIM ключ и може да подпише каквото пожелае в момента на изпращане). Но за вече получен и подписан имейл, промяната на заглавието Date: оставя откриваема следа.

Сървърните логове: истинският източник на истина

Дори да успеете да промените всички видими метаданни на имейл (заглавия, INTERNALDATE, всичко), доставчиците пазят собствени логове.

Google Workspace регистрира всяко съобщение в логовете за одит на Admin Console. Microsoft 365 прави същото в Центъра за съответствие (Purview). Тези логове включват времевите клейма на доставката, независимо от това, което се показва в клиентите. Адвокат, правен отдел или екип по информационна сигурност може да извлече тези данни. Датата, видима в Outlook, не е доказателство пред съд или при одит.

За да сме точни: дори администратор с достъп до пощенска кутия чрез делегация не може ретроспективно да презапише тези логове. Те са извън обхвата на потребителите, дори на привилегированите.

Легитимният случай: корекция след миграция

Току-що завършихте миграция на 150 пощенски кутии от локален Exchange към Microsoft 365. В понеделник сутринта тикетите започват да валят: "всичките ми стари имейли са датирани от миналия петък". Датата на миграцията.

Това е добре документиран проблем и е напълно различен от описаното по-горе. Тук никой не иска да фалшифицира нищо. Истинските оригинални дати съществуват, непокътнати, в заглавието Date: на всяко съобщение. Проблемът е другаде: инструментът за миграция (BitTitan MigrationWiz, CloudM, imapsync или друг) е вмъкнал заглавие Received: с датата на миграцията в началото на веригата. Outlook, който разчита на най-новите заглавия Received:, а не на INTERNALDATE в определени контексти, показва тази дата вместо истинската.

В този случай "корекцията" се състои в възстановяване на съответствието между това, което съобщението казва (оригиналното заглавие Date:, което е там) и това, което сървърът смята (INTERNALDATE, фиксиран в момента на миграцията). Това не е фалшификация. Това е възстановяване.

Точно такъв проблем описваме подробно в защо имейлите показват грешна дата след миграция. И точно това решава Redate.io.

Защо "направи си сам" се проваля в мащаб

Да разберете проблема е едно. Да го коригирате върху 40 000 имейла в 150 пощенски кутии, без да изгубите нито един, е съвсем друго.

Скриптовете, намерени в GitHub или Stack Overflow, работят с 20 тестови имейла. В production среда срещат проблеми, които авторът не е предвидил:

Имейли, подписани с S/MIME или криптирани с PGP, имат структури, които не се манипулират като обикновени съобщения
Multipart съобщения с нестандартни MIME граници предизвикват грешки при парсирането
Заглавия, кодирани по RFC 2047 (не-ASCII символи в полетата From: или Subject:), чупят наивните парсери
Google и Microsoft API-тата налагат ограничения на скоростта (rate limiting): в 3 часа сутринта по време на batch от 30 000 имейла, грешката 429 Too Many Requests не се обработва, скриптът спира и никой не знае точно къде
Няма механизъм за връщане назад: ако съобщение се повреди по време на обработката, няма как да се върне

Redate.io запазва копие на всеки оригинален имейл в видима резервна папка за 30 дни. Всяка корекция се проверява индивидуално. Pipeline-ът за анализ обработва стотици известни сигнатури на инструменти за миграция, заедно с всички гранични случаи, с които домашен скрипт не би се справил.

За повече подробности според използвания инструмент: BitTitan MigrationWiz и датите на имейли или CloudM Migrate: как да поправите датите на имейли.

Какво се променя и какво никога не се променя

Действие	Локален клиент	INTERNALDATE сървър	Логове доставчик	DKIM проверка
Редактиране на .eml файл	Понякога се променя	Непроменен	Непроменени	Невалидна ако Date: е подписан
Промяна на системен часовник	Без ефект	Непроменен	Непроменени	Непроменена
Манипулация чрез Thunderbird (IMAP)	Временно променен	Непроменен	Непроменени	Непроменена
Корекция с Redate.io (след миграция)	Коригиран	Коригиран	Непроменени	Запазена

Разграничението е ясно. Първите три реда описват повърхностни или открити промени. Последният описва легитимна корекция на метаданните, в съответствие с оригиналното съдържание на съобщението, след миграция, която е внесла несъответствие.

Ако се намирате в ситуацията, описана в последния ред на таблицата, след миграция с imapsync, BitTitan, CloudM или друг инструмент, Redate.io е направен точно за това.

Имейлите ви показват датата на миграцията вместо истинските дати? Сканирайте безплатно пощенските си кутии с Redate.io и вижте точно колко имейла са засегнати, преди да вземете решение.

Промяна на дата на получен имейл: вярно или невярно?