Трите дати вътре във всеки имейл
Всеки имейл, съхранен на IMAP сървър, носи поне три различни стойности за дата. Разбирането как тези дати работят и как пощенските клиенти избират коя да покажат е ключът за разбиране защо миграцията разваля датите. Тази статия е задълбочен технически анализ на системата за дати в IMAP, предназначен за IT администратори и всеки, който иска да разбере основната причина за проблемите с дати след миграция.
1. RFC 2822 "Date" хедър
"Date" хедърът е дефиниран в RFC 2822 (формат на интернет съобщения). Задава се от пощенския клиент на подателя в момента на съставяне и изпращане на съобщението. Този хедър е част от тялото на самото съобщение - пътува със съобщението и никога не се модифицира от пощенските сървъри по пътя на доставка. Типичен Date хедър изглежда така:
Date: Mon, 15 Jan 2024 09:32:17 +0100
Date хедърът представлява "датата на изпращане" на съобщението. Това е най-надеждната дата, тъй като се задава веднъж и никога не се променя. Въпреки това, тя отразява часовника на подателя, който може да е неправилно конфигуриран. В редки случаи Date хедърът може изобщо да липсва (особено при автоматизирани системни известия или неправилно форматирани съобщения).
2. IMAP INTERNALDATE
INTERNALDATE е дефинирана в RFC 3501 (IMAP4rev1 протокол). Това е стойност на метаданни от страна на сървъра, представляваща датата и часа, когато съобщението е доставено на сървъра. За разлика от Date хедъра, INTERNALDATE не е част от самото имейл съобщение. Съхранява се отделно от IMAP сървъра като метаданна.
Когато имейл е доставен нормално (не мигриран), IMAP сървърът задава INTERNALDATE на текущия час в момента на доставката. Тази стойност кореспондира плътно с Date хедъра, обикновено с разлика от няколко секунди или минути. Пощенските клиенти често използват INTERNALDATE като "дата на получаване", тъй като тя отразява момента, в който сървърът реално е получил съобщението.
И тук нещата стават интересни. Когато съобщение се вмъква чрез IMAP APPEND командата (което инструментите за миграция използват), APPEND командата позволява на клиента да зададе INTERNALDATE изрично. Добре проектираните инструменти за миграция използват тази функция за запазване на оригиналната INTERNALDATE от изходния сървър. Но дори когато INTERNALDATE е правилно зададена, проблемът с "Received" хедъра (описан по-долу) може все пак да замени показваната дата в много клиенти.
3. Веригата "Received" хедъри
Всеки път когато имейл преминава през пощенски сървър, този сървър добавя "Received" хедър в началото на съобщението. Това създава верига от Received хедъри, записваща пътя на имейла от подателя до получателя. Най-скорошният (отгоре) показва последния сървър, обработил съобщението, а най-старият (отдолу) показва първия.
Нормален имейл може да има 3 до 6 Received хедъра, документиращи пътуването от изходящия сървър на подателя през релетата до входящия сървър на получателя. Всеки Received хедър включва времеви печат. Ето опростен пример:
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Как пощенските клиенти избират коя дата да покажат
Outlook (Desktop, Web, Mobile)
Microsoft Outlook използва комбинация от INTERNALDATE и най-скорошния "Received" хедър за определяне на показваната дата на "Получаване" във входящата поща. На практика Outlook дава приоритет на времевия печат от най-скорошния Received хедър за колоната "Получено". Колоната "Изпратено" използва Date хедъра. Тъй като Outlook сортира по подразбиране по колоната "Получено", именно времевият печат от Received хедъра е това, което потребителите виждат първо.
Apple Mail
Apple Mail на macOS и iOS използва основно IMAP INTERNALDATE за показване на датата. Ако INTERNALDATE е правилно запазена по време на миграцията, Apple Mail може да покаже правилната дата, но само ако INTERNALDATE е изрично зададена при APPEND операцията. Ако инструментът за миграция не е задал INTERNALDATE, сървърът използва по подразбиране времето на вмъкване (датата на миграцията). За подробности относно въздействието за потребителите на Apple Mail вижте Apple Mail: грешна дата след миграция.
Thunderbird
Mozilla Thunderbird предлага най-голяма гъвкавост. Може да покаже и "Дата" (от Date хедъра), и "Получено" (от Received хедърите). По подразбиране Thunderbird показва стойността от Date хедъра, което означава, че датите могат да изглеждат правилни в Thunderbird, дори когато са грешни в Outlook. Колоната "Получено" в Thunderbird все пак показва датата на миграцията. Вижте Thunderbird: грешна дата след миграция за повече подробности.
Уеб интерфейс на Gmail
Уеб клиентът на Gmail използва Date хедъра за основното си показване на дата. Това означава, че Gmail уеб често показва правилни дати дори след миграция. Но IMAP INTERNALDATE на Gmail сървъра все пак е неправилна, което засяга всеки IMAP клиент, свързан към този Gmail акаунт. Разликата между Gmail уеб и Outlook или Apple Mail е чест източник на объркване и такъв, който губи много време за отстраняване на неизправности от администраторите.
Защо IMAP APPEND разваля датите
Какво се случва по време на миграция
Когато инструмент за миграция премества имейл от Сървър А към Сървър Б, инструментът се свързва с Сървър А чрез IMAP и изтегля суровото съобщение, после се свързва с Сървър Б и използва APPEND командата, за да го вмъкне. По време на това вмъкване Сървър Б обработва входящото съобщение и добавя нов Received хедър с текущия времеви печат: датата на миграцията. Това е стандартно IMAP поведение, дефинирано в протокола. Сървърът третира всеки APPEND като нова доставка на съобщение.
Резултатът: замърсена верига хедъри
След миграция Received хедърите на имейла изглеждат така:
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Received хедърът от инструмента за миграция е вече най-горният запис. Всеки пощенски клиент, който използва най-скорошния Received хедър за определяне на показваната дата (Outlook, в частност), ще покаже "11 април 2025" вместо "15 януари 2024". Оригиналният Date хедър и оригиналните Received хедъри все още са непокътнати отдолу, но те вече не са в позицията, която пощенските клиенти предпочитат.
Дори добрата обработка на INTERNALDATE не предотвратява това
Някои инструменти за миграция задават правилно INTERNALDATE по време на APPEND. Например imapsync изрично запазва INTERNALDATE от изходния сървър. Но Received хедърът се добавя от целевия сървър, а не от инструмента за миграция. Инструментът за миграция няма контрол над това поведение. Дори с перфектно запазване на INTERNALDATE, най-горният Received хедър все пак съдържа датата на миграцията и клиенти като Outlook все пак показват грешната дата.
На практика, какво конкретно може да се направи по въпроса?
Кои инструменти за миграция добавят Received хедъри
Всички IMAP инструменти за миграция причиняват този проблем, тъй като Received хедърът се добавя от целевия сървър, а не от самия инструмент. Съдържанието на добавения хедър варира в зависимост от инструмента и сървъра.
BitTitan MigrationWiz добавя Received хедър, съдържащ "mx.migrationwiz.com". CloudM Migrate добавя хедъри, рефериращи "cloudm.io". imapsync предизвиква генеричен Received хедър от целевия сървър. GSMMO добавя хедъри с препратки към "gmailapi.google.com".
Корекцията: възстановяване на правилните дати
Добрата новина е, че правилната информация за дата все още съществува във всеки имейл. Оригиналният Date хедър е непокътнат. Оригиналните Received хедъри са непокътнати. Проблемът е, че замърсяващ хедър стои над тях.
Собственият коригиращ двигател на Redate.io анализира пълната верига хедъри на всеки засегнат имейл, прилагайки съпоставяне на сигнатури срещу стотици сигнатури на известни инструменти за миграция, за да идентифицира точно кои хедъри се нуждаят от корекция. Многоетапният процес на анализ обработва специалните случаи, които провалят по-простите подходи: S/MIME подписани съобщения, PGP криптирано съдържание, multipart/alternative структури, проблеми с Content-Transfer-Encoding, не-ASCII хедъри (RFC 2047), свръхголеми прикачени файлове и повредени MIME граници.
След корекция всеки имейл преминава през процес на проверка на целостта, за да потвърди, че структурата, съдържанието и прикачените файлове на съобщението са запазени идентично. Оригиналите се съхраняват във видима резервна папка за 30 дни.
Може ли да се напише скрипт за опит за тази корекция? Технически, да. Но разликата между "работи на 95% от имейлите" и "работи на 100% от имейлите без да повреди нито един" представлява месеци разработка. А когато става дума за пълната пощенска кутия на някого, 5% процент на провал означава стотици безшумно повредени съобщения без начин да проверите какво е тръгнало наопаки.
Искате да разберете колко имейла в кутията ви имат грешни дати? Стартирайте безплатен анализ с Redate.io за мигновен подсчет на засегнатите имейли, без необходимо плащане.