Oprava dat ručního kopírování IMAP v Gmailu

Ruční kopírování IMAP do Gmailu zní dost jednoduše: přidejte zdrojový účet i Gmail do e-mailového klienta jako Outlook, Thunderbird nebo Apple Mail a pak zprávy přetáhněte. Co vám nikdo neřekne, je to, že každý e-mailový klient zahodí původní datová metadata během této operace. Klient nahraje zprávy do Gmailu bez specifikace původního INTERNALDATE, takže Gmail místo toho zaznamená časové razítko nahrání. Tisíce e-mailů, jedno datum.

Gmail přidává k problému vlastní komplikaci. Když obdrží nahranou zprávu, IMAP brána Gmailu přidá novou hlavičku Received orazítkovanou aktuálním datem a časem. Tato hlavička se umístí na vrchol řetězce hlaviček. Webové rozhraní Gmailu je dost chytré na to, aby pro zobrazení použilo hlavičku Date z těla e-mailu, takže data mohou v prohlížeči vypadat správně. Jenže každý IMAP klient, který se poté připojí, čte poškozené INTERNALDATE ze serverů Google.

Kdo vlastně provádí ruční kopírování přes IMAP? Více lidí, než byste čekali. Malé firmy konsolidující z Yahoo Mail nebo levného hostingu do Gmailu. Freelanceři slučující tři účty do jednoho. IT konzultanti migrující schránku klienta od poskytovatele, který nemá žádný oficiální migrační nástroj. Přístup přetáhni-a-pusť působí intuitivně a bezpečně. Jenže na úrovni protokolu IMAP jsou datová metadata tiše zničena během přenosu - a než si toho kdokoli všimne, zdrojový účet už může být zrušený.

Dopad se dělí do dvou světů. Ve webovém rozhraní Gmailu mohou data vypadat správně, protože Gmail čte hlavičku Date z těla e-mailu. V jakémkoli IMAP klientu - Outlook, Apple Mail, Thunderbird, aplikace Gmail na Androidu - se místo toho zobrazuje datum kopírování. To vytváří matoucí situaci, kdy tentýž e-mail zobrazuje různá data v závislosti na způsobu přístupu.

Ale škody jdou hlouběji než jen nesrovnalosti v zobrazení. Zkoušeli jste někdy provést audit shody na schránce, kde má 30 000 e-mailů stejné INTERNALDATE? Vyhledávání Google Vault podle data vrací zavádějící výsledky. Zálohovací nástroje jako MailStore, Veeam nebo vlastní archivační skripty připojené přes IMAP trvale zaznamenají špatná data. Exporty Google Takeout mohou odkazovat na INTERNALDATE pro pojmenování souborů, čímž vytvářejí archivní složky, kde e-maily z roku 2017 sedí vedle e-mailů z roku 2023 pod jedním datem. Například pro někoho, kdo konsolidoval roky e-mailů od více poskytovatelů do Gmailu, to může znamenat, že celá historie e-mailů má na serverech Google nesprávná datová metadata.

Redate.io tento problém řeší prostřednictvím proprietárního korekčního enginu, který používá porovnávání vzorů napříč signaturami migračních nástrojů k identifikaci postižených zpráv. Proces provádí cílenou korekci metadat na úrovni serveru - zachovává obsah zprávy, štítky, stav přečtení a přílohy, zatímco obnovuje přesné datové informace. Každá zpráva obdrží individuální ověření před i po opravě.