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

Всеки имейл има три "дати". Не една.

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

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

Слой 1: INTERNALDATE в IMAP

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

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

INTERNALDATE се задава в момента, в който съобщението се депозира на сървъра. Чрез IMAP протокола единственият начин да я "промените" е косвен: трябва да се използва командата APPEND, за да се депозира ново копие на съобщението с желаната дата. Не съществува IMAP команда SETINTERNALDATE. Този детайл ще стане важен след малко.

Слой 2: заглавието Date: (RFC 2822)

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

(Между другото, ако никога не сте гледали необработените заглавия на имейл, четенето им е доста обезпокоително изживяване. Всяко съобщение носи около двадесет технически реда, които 99% от хората никога не са виждали.)

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

Слой 3: наслоените заглавия Received:

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

Именно тук инструментите за миграция създават проблема. Когато BitTitan MigrationWiz, CloudM, imapsync или GSMMO мигрират имейл, те го реинжектират на новия сървър чрез IMAP. Това депозиране генерира ново заглавие Received:, подпечатано с датата на миграцията. Резултатът: най-старото съобщение в пощенската ви кутия, имейл от 2019 година, се оказва с Received: датиран от ноември 2024. И тъй като някои имейл клиенти (Outlook на първо място) използват най-новото Received: като дата за показване...

Ето и проблемът. 15000 имейла показват всички една и съща дата на миграция.

Може ли наистина да се "промени" тази дата?

Технически да за INTERNALDATE (с ограничения). Технически възможно, но безполезно за Date:. А за Received: заслужава да се спрем по-подробно.

Пренаписването на Received: е тривиално. И незабавно разпознаваемо.

Заглавието Received: не е нищо повече от ред текст в съобщението. Може да се редактира като всеки текстов файл. Точно толкова просто е, колкото изглежда.

Но ето какво се случва след това.

Първи проблем: DKIM. Подписът DKIM (DomainKeys Identified Mail) се изчислява върху набор заглавия на съобщението, включително понякога Received: заглавията. Промяната на подписано заглавие обезсилва подписа. Всеки сървър получател, който проверява DKIM, ще види незабавно, че съобщението е изменено. Не е фина фалшификация, а направо алармена система.

Втори проблем: вътрешните идентификатори. Съвременните пощенски сървъри (Google Workspace, Microsoft 365) присвояват на всяко съобщение нарастващ уникален вътрешен идентификатор. Тези идентификатори са свързани с INTERNALDATE и реда на получаване. Промяната на Received: без съответствие с тези идентификатори създава несъответствия, които инструментите за одит разпознават без затруднение.

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

Накратко. Пренаписване на Received: с цел злонамерено фалшифициране на дата: тривиално технически, разпознаваемо за секунди от експерт. Не е сериозен вариант.

Заглавието Date:: промяна на миналото само на хартия

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

За да сме точни, това не пречи на някои имейл клиенти да показват промененото Date:, ако им се предостави директно .eml файлът. Но в контекста на работещ пощенски сървър с удостоверяване и журнали, промяната е прозрачна.

IMAP миграцията: единственият контекст, в който корекцията е издържана

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

Ето конкретната ситуация. Току-що сте мигрирали 80 пощенски кутии от Exchange към Microsoft 365. Миграцията приключи в петък вечерта. В понеделник сутринта пристигат първите тикети: "Всичките ми имейли имат еднаква дата", "Не мога да намеря имейл от миналата година", "Цялата ми история с този клиент е напълно разбита". Имате 80 блокирани потребители и ръководителя, чакащ отговор.

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

Корекцията следователно не е фалшификация: тя е възстановяване. Тръгваме от верни данни (оригиналното Date:), за да пресъздадем съгласувани метаданни. Това е фундаментално различно от опита да се представи имейл от 2024 година като имейл от 2019.

За по-подробна информация относно механизмите при конкретни инструменти, тези ръководства разглеждат конкретните случаи: коригиране на дати от BitTitan в Microsoft 365, коригиране на дати от CloudM в Outlook, или коригиране на дати от imapsync в Google Workspace.

Защо да не пишете скрипт сами

Основната логика е достъпна. Всеки IT администратор, прекарал известно време в IMAP форуми, може да реконструира общия подход. Не това е проблемът.

Проблемът е разликата между скрипт, работещ върху 50 тестови имейла, и скрипт, обработващ 40000 съобщения в производствена среда без да загуби нито един имейл, без да повреди нито едно приложение и без да счупи нито една нишка на разговор.

Няколко конкретни случая, с които домашните скриптове обикновено не се справят:

• S/MIME подписани имейли: подписът покрива съдържанието и заглавията. Всяка промяна в структурата на съобщението обезсилва подписа. Неловко коригиран подписан имейл пристига при получателите с "невалиден подпис".
• PGP криптирани съобщения: същото семейство проблеми, с потенциално по-лоши последствия в зависимост от имплементацията.
• Не-ASCII кодировки в заглавия: RFC 2047 описва кодирането на специални символи в заглавията. Скрипт, манипулиращ заглавия без обработка на тези случаи, ще повреди безшумно теми на имейли с акценти, японски символи или арабски имена.
• API ограничения на честотата: Google Workspace и Microsoft 365 прилагат агресивно ограничаване. В 3 часа сутринта партида от 10000 имейла, натъкнала се на грешка 429 Too Many Requests без обработка на експоненциален backoff, оставя половината пощенски кутии наполовина коригирани.
• Повредени MIME граници: многочастни съобщения с приложения имат точни MIME граници. Неправилното им регенериране прави приложенията нечетими.

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

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

Какво прави Redate.io в този контекст

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

Услугата се свързва директно с засегнатите пощенски кутии (Google Workspace чрез делегиране на домейн, Microsoft 365 чрез Azure AD или директен IMAP), сканира безплатно съобщенията с неправилни дати, след което прилага собствен многоетапен pipeline за корекция, обработващ описаните по-горе гранични случаи. Всеки имейл се проверява индивидуално след корекция. Оригиналите остават в видима резервна папка в продължение на 30 дни.

Разпознаването на шаблони покрива стотици сигнатури на известни инструменти за миграция: BitTitan MigrationWiz, CloudM, imapsync, GSMMO и техните варианти. Засичането е прецизно: Redate.io не докосва имейли с вярна дата.

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

Ако управлявате пощенски кутии, засегнати от този проблем, тази статия за грешни дати в Outlook след миграция разглежда подробно най-честите симптоми и как да ги разграничите от други причини.

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