POP към IMAP: старите имейли показват днешна дата

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

Току-що сте преминали имейл акаунта си от POP3 към IMAP. Конфигурацията беше лесна, хостингът ви помогна, всичко мина гладко. Докато не отворихте пощенската си кутия отново. Имейлите ви от 2019, 2021, архивите от миналата година... всички показват същата дата: днес. Понякога дори едно и също време, с разлика от секунди.

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

POP3 срещу IMAP: фундаментална разлика в съхранението

За да разберем защо проблемът се появява, трябва първо да разберем как работи POP3 и защо е коренно различен от IMAP.

При POP3 сървърът служи само като временна пощенска кутия. Вашият клиент (Outlook, Thunderbird, Apple Mail) се свързва, изтегля съобщенията и ги изтрива от сървъра (или ги оставя, в зависимост от настройките ви). Имейлите след това живеят изключително локално: в .pst файл за Outlook, в локалния профил на Thunderbird, в база данни на твърдия ви диск.

При IMAP е обратното: имейлите живеят на сървъра. Клиентът ви само показва онова, което е съхранено отдалечено. Оттам идва и прозрачната синхронизация между всичките ви устройства.

Проблемът възниква при прехода между двете, когато качвате старите си локални POP имейли на IMAP сървъра.

IMAP APPEND: командата, която променя всичко

Когато имейл клиентът ви качва локално съобщение към IMAP сървър, той използва командата IMAP APPEND. Тя казва на сървъра: „съхрани това съобщение в еди-коя си папка".

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

С други думи: без значение дали съобщението съдържа в хедърите си дата от 2018 г., ако никой не каже на сървъра „този имейл е от 2018 г.", сървърът приема, че е депозиран сега, и му присвоява днешната INTERNALDATE.

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

Защо е различно от IMAP-към-IMAP миграция

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

Във вашия случай тръгвате от изцяло локални данни. Няма INTERNALDATE на източника, която да се копира. .pst файлът или профилът на Thunderbird съхраняват съобщенията в собствен формат с вътрешни метаданни. Когато имейл клиентът прочете тези съобщения, за да ги качи на IMAP сървъра, той изгражда командата APPEND от съдържанието на съобщението. И в повечето случаи не предава изрична дата.

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

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

Кой клиент показва какво и защо

Не всички имейл клиенти реагират по един и същ начин. Това е нещо, което много IT администратори открият след като е станало.

Outlook (в последните версии, особено след актуализациите от 2023-2024) използва INTERNALDATE на сървъра за колоната „Получено". Показва датата на качване, а не оригиналната дата на изпращане. За повече информация относно поведението на Outlook вижте статията Outlook: дата на миграция IMAP срещу дата на изпращане.

Gmail / Google Workspace и Thunderbird имат малко по-нюансирано поведение. Gmail например понякога може да използва полето Date: от хедъра на съобщението за показване, което създава впечатление, че всичко е наред... докато не опитате да сортирате по дата и не видите, че редът е напълно произволен.

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

Добрата новина: оригиналната дата е непокътната

Хедърът Date: на всеки имейл, този, който съдържа истинската дата на изпращане (или получаване), не е бил докоснат. Той е там, в тялото на съобщението. Именно него виждате, когато отворите имейл и погледнете детайлите.

Това, което IMAP сървърът е „счупил", е само INTERNALDATE, тази метаданна, която е외на съобщението. Самото съобщение е непокътнато.

Именно това прави корекцията възможна. И именно затова проблемът може да остане незабелязан известно време: имейлите изглеждат правилни, когато ги отваряте един по един. Едва когато погледнете списъка в пощенската кутия, сортиран по дата, проблемът става видим. Имейли от 2019 г. се появяват най-отгоре, сякаш са току-що пристигнали. Всички с еднаква дата.

Проблемът с мащаба: 3000 имейла не са 3

Може би си мислите: „Просто ще изтрия и ще импортирам отново, но tym правилно." При 5 или 10 тестови имейла, да, това работи. При пощенска кутия с 8000 съобщения, вложени папки, обемисти прикачени файлове, S/MIME подписани имейли и нишки разговори от 2015 г... това е съвсем различна история.

Скрипт, направен у дома, който работи на тест от 50 имейла, може да произведе дубликати, да изгуби прикачени файлове или да счупи нишки разговори в производствена кутия. Управлението на API квоти, мрежови таймаути, съобщения с нетипична MIME структура... всичко това са гранични случаи, с които неспециализиран инструмент не се справя.

А ако нещо се обърка по средата? Без механизъм за архивиране и отказване, губите данни без възможност за възстановяване.

Проблемът е добре познат на администраторите, управляващи обемни миграции. Да разберете защо датите са счупени е едно нещо. Да коригирате правилно 15000 имейла, запазвайки структурата на всяко съобщение, е съвсем друго. За повече подробности по тази тема, статията Могат ли датите на имейлите да се коригират след миграция? разглежда различните подходи и техните ограничения.

Как Redate.io се справя с този конкретен случай

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

Многостепенният pipeline за анализ инспектира верига от хедъри на всяко съобщение, валидира съответствие с RFC и реконструира метаданните за датата, без да променя съдържанието на съобщението: нито текста, нито прикачените файлове, нито MIME структурата, нито евентуалните цифрови подписи. Всеки коригиран имейл се проверява индивидуално преди финализиране.

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

Първоначалното сканиране е безплатно: Redate анализира кутията ви, идентифицира засегнатите имейли и ви показва точния брой, преди да вземете каквото и да е решение. Без ангажимент на тъмно.

Redate.io се свързва директно с пощенските кутии чрез Google Workspace (делегиране на домейн), Microsoft 365 (Azure AD) или директен IMAP. Никаква локална инсталация. Никакви .pst файлове за ръчна обработка.

За администратори, управляващи множество пощенски кутии, статията MSP: коригиране на имейл датите на клиентите е полезно допълнително четиво. А за спецификата на корекцията в Thunderbird, който има собствено поведение при преминаване POP/IMAP, вижте Thunderbird: грешна дата след миграция.

Ако предстои да го правите: предотвратете проблема

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

• Проверете дали имейл клиентът ви поддържа изрично предаване на датата в командата APPEND. Thunderbird например е имал различно поведение в различните версии по този въпрос.
• Направете тест с валидационен акаунт с 50-100 представителни съобщения: стари имейли, с прикачени файлове, подписани имейли. Проверете показваните дати в различни клиенти.
• Планирайте корекцията преди крайните потребители да започнат работа в мигрираната кутия. Коригирането на дати в активна кутия е по-сложно, отколкото в нова след миграция.
• Документирайте броя на имейлите преди и след миграцията. Това е единственият начин да засечете скрити загуби.

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

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