Антидатиране на имейл: възможно и разкриваемо

Антидатиране на имейл: за какво точно говорим?

Въпросът се появява редовно в администраторски форуми и Slack групи на MSP специалисти: може ли датата на имейл да се промени след изпращане? Краткият отговор е да, технически. Но пълният отговор е много по-малко обнадеждаващ за тези, които биха го направили с неблаговидни цели.

Имейлът не е монолитен файл. Той е колекция от текстови заглавия, следвани от тяло на съобщението. Сред тези заглавия няколко носят информация за дата. И някои се променят по-лесно от други.

В всеки имейл съществуват три пласта на датиране:

• Заглавието Date: (RFC 2822), написано от имейл клиента в момента на изпращане
• Заглавията Received:, добавяни от всеки сървър, който препраща съобщението
• IMAP INTERNALDATE, метаданни съхранявани на сървъра, независими от съдържанието на съобщението

Всеки от тези пластове може да се промени. Нито един не може да се промени без да остави следи.

Промяна на заглавието Date:: най-очевидната манипулация

Заглавието Date: е обикновен текст в .eml файла. Технически всеки шестнадесетичен редактор или Python скрипт може да го пренапише за секунди. Ако сте отваряли оригиналните заглавия на имейл в Gmail (малкото меню "Покажи оригинала"), знаете, че е четимо от всеки.

Проблемът? От 2004 г. насам огромното мнозинство от пощенски сървъри подписват изходящите имейли с DKIM (DomainKeys Identified Mail). Тази криптографска подпис изрично обхваща няколко заглавия, включително Date:, From:, Subject:, и тялото на съобщението. Подписът се съхранява в заглавието DKIM-Signature:.

Промяната на Date: след подписване механично анулира DKIM проверката. Всеки сървър получател може да провери подписа, като извлече публичния ключ от DNS на изпращащия домейн. Ако подписът вече не съответства, съобщението се маркира като променено. Gmail, Outlook.com и всички големи доставчици правят тази проверка автоматично.

(Между другото, ако искате да видите конкретно как изглежда DKIM подпис, отворете оригиналните заглавия на имейл, получен от Gmail или Office 365: ще намерите ред DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=..., който изглежда като шум, но всъщност е криптографски хеш на цялото съобщение.)

Резултатът: промяната на Date: в имейл, подписан с DKIM, означава счупване на печата. Промяната е видима за всеки администратор, който знае къде да търси.

Пренаписване на заглавията Received:: верига, трудна за фалшифициране

Заглавията Received: проследяват пътя на имейла между изпращача и получателя. Всеки SMTP сървър, минал покрай съобщението, добавя свое заглавие, с името си, IP адреса си и времеви печат. Имейл, преминал през два или три релейни сървъра, съдържа два или три наредени заглавия Received:.

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

Съгласуваността на веригата е проверима. Ако времевите печати на последователните Received: са несъгласувани (например релеен сървър е получил съобщението преди изпращачът да го е изпратил), това е незабавно подозрително. Инструменти за форензичен анализ на имейли като MXToolbox или вътрешните инструменти на екипите по сигурността проверяват точно това.

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

IMAP INTERNALDATE: най-техническият случай

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

IMAP командата APPEND позволява качването на съобщение на сървър с изрично посочена INTERNALDATE. Това е легитимна функция на протокола, документирана в RFC 3501. Инструментите за миграция я използват постоянно: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... всички качват имейли на целевия сървър с посочена INTERNALDATE.

Теоретично, някой с IMAP достъп до собствената си пощенска кутия може да качи имейл с произволна INTERNALDATE. Но тази манипулация не променя заглавията на съобщението. Оригиналното Date: остава непокътнато, заглавията Received: остават непокътнати, DKIM подписът остава непокътнат. Само сървърната метаданна за сортиране се променя.

За експерт, разглеждащ оригиналното съобщение, несъответствието между INTERNALDATE и Date: е незабавно видимо. А ако съобщението е подписано с DKIM, оригиналната дата е криптографски удостоверена.

Message-ID: отпечатък, трудно за фалшифициране

Всеки имейл генерира уникален идентификатор, заглавието Message-ID:. Този идентификатор се изгражда от изпращащия SMTP сървър в момента на изпращане, обикновено комбинирайки времеви печат, случаен идентификатор и доменното име на сървъра.

Типичен Message-ID изглежда така: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Времевият печат често е кодиран директно в идентификатора. Промяната на датата на съобщението при запазване на Message-ID с несъвместим времеви печат създава несъответствие, което е незабавно забележимо.

Освен това Message-ID-тата се индексират от големите пощенски системи. Google, Microsoft и други поддържат логове, позволяващи проследяване на кога едно съобщение реално е преминало през техните инфраструктури. В правен или форензичен контекст тези логове са достъпни чрез съдебни процедури.

На практика: кой може да открие опит за манипулация?

Да поставим въпроса конкретно. Получавате имейл, чиято дата подозирате, че е променена. Какво може да направи ИТ администратор или адвокат с минимална техническа подготовка?

• DKIM проверка: в Gmail менюто "Покажи оригинала" показва директно резултата от DKIM проверката в горната част на страницата. "PASS" потвърждава целостта на съобщението от изпращането. "FAIL" или "SOFTFAIL" сигнализира за промяна.
• Анализ на заглавията: инструменти като MXToolbox Header Analyzer или Google Admin Toolbox автоматично анализират веригата Received: и сигнализират временни несъответствия.
• Съгласуваност на Message-ID / Date: анализатор може да сравни времевия печат, кодиран в Message-ID, с декларираната стойност на Date:.
• Сървърни логове: ако имейлът е преминал през сървър, на който сте администратор, SMTP логовете съдържат реалната дата и час на приемане на съобщението, независимо от заглавията.

Накратко, инструментите за откриване са достъпни, безплатни и не изискват напреднала форензична експертиза. Малко любопитен ИТ администратор може да провери целостта на имейл за под две минути.

Единственият легитимен случай на масова промяна на дати: IMAP миграция

Съществува един сценарий, при който стотици хиляди имейли получават неправилни дати без никакво злонамерено намерение: IMAP миграцията.

Току-що завършихте миграция на 150 Exchange пощенски кутии към Google Workspace. В понеделник сутринта започват тикетите. Потребителите съобщават, че всичките им стари имейли се показват с една и съща дата, тази на уикенда на миграцията. Пощенските им кутии са нечетими.

Случилото се е документирано и предвидимо: инструментът за миграция (BitTitan, CloudM, imapsync, без значение кой) е качил имейлите в Google Workspace чрез IMAP APPEND. Задал е INTERNALDATE, съответстваща на датата на миграцията, не на оригиналната дата на имейла. Резултатът: Outlook, който по подразбиране сортира по INTERNALDATE, показва датата на миграцията за всички съобщения. Защо имейлите показват грешна дата след миграция обяснява подробно този механизъм.

Оригиналното заглавие Date: е непокътнато в всяко съобщение. DKIM подписите са непокътнати. Съдържанието не се е местило. Само сървърният INTERNALDATE е неправилен.

Този проблем засяга BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO и всички инструменти, използващи IMAP APPEND без правилно запазване на INTERNALDATE. Статията, посветена на BitTitan MigrationWiz, разглежда особеностите на този инструмент. Чеклистът за имейл миграция изброява точките, които трябва да се проверят преди и след миграция, за да се избегват подобни проблеми.

Разликата между коригиране и фалшифициране

Корекцията, която Redate.io извършва, е точно обратното на опит за фалшифициране. Собственият корекционен механизъм анализира веригата от заглавия на всяко съобщение, идентифицира оригиналната дата, кодирана в заглавието Date: (RFC 2822), която никога не се е местила, и коригира метаданните за дата, за да ги приведе в съответствие с тази автентична информация, вече присъстваща в съобщението.

Заглавието Date: е истинският източник. То е написано от имейл клиента на изпращача в момента на изпращане. Покрито е от DKIM подписа. Не се променя от Redate.io. Това, което се коригира, е несъответствието, въведено от инструмента за миграция, не оригиналната дата.

Коригирането на 47 000 имейла след неуспешна миграция, без да се изгуби нито един, без да се счупят дискусионни нишки, без да се повредят прикачени файлове, без да се задейства грешка 429 в 3 часа сутринта от Google API: това е многоетапен аналитичен конвейер с обработка на гранични случаи (S/MIME, PGP, не-ASCII кодирания по RFC 2047, сложни multipart структури). Python скрипт от пет реда не би издържал при първата производствена пощенска кутия. Могат ли датите на имейлите да се коригират след миграция обяснява подробно защо самостоятелният подход е рисков при реални обеми.

Redate.io сканира пощенските кутии безплатно, идентифицира имейлите с неправилни дати и коригира чрез конвейер за валидация, проверяващ всяко съобщение индивидуално. Оригиналите се съхраняват в видима резервна папка за 30 дни. Ако нещо се обърка, връщането назад е възможно.

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