Labojiet imapsync e-pasta datumus

Solījums --syncinternaldates (un kur tas apstājas)

Jūs palaidāt imapsync komandu. Iekļāvāt --syncinternaldates, jo izlasījāt dokumentāciju un esat tik rūpīgs. Migrācija beidzas, žurnāls saka, ka viss pārsūtīts, nulle kļūdu. Tad atverat pastkasti programmā Outlook, un katrs e-pasts rāda vakardienas datumu.

Šī ir viena no biežākajām neveiksmēm ar imapsync, un tā mulsina sistēmu administratorus vismaz kopš 2017. gada. Karodziņam --syncinternaldates ir jāsaglabā IMAP INTERNALDATE migrācijas laikā. Un tā tas notiek: tas dod katrai kopijai to iekšējo datumu, kādu tur avota serveris. Tieši tur ir slazds.

imapsync ir atvērtā koda Perl rīks, ko rakstījis Gilles Lamiral, un tas patiešām ir labs tajā, ko tas dara. Tas apstrādā IMAP-uz-IMAP pastkastu pārsūtīšanu ar uzticamības līmeni, ko lielākā daļa komerciālo rīku apskauž. Bet imapsync var nokopēt tikai tos datumus, ko tas atrod, un tieši tur lietas sarežģījas.

Kā IMAP datumi patiesībā darbojas

Katrā e-pastā ir iesaistīti trīs dažādi "datumi", un vairums cilvēku (ieskaitot dažus IT administratorus) tos sajauc:

Date: galvene (RFC 2822) - datums, ko sūtītāja e-pasta klients uzlika ziņojumam, kad tas tika sarakstīts. Tas atrodas ziņojuma pamattekstā, un pasta serveri to nekad nemaina.
Received: galvenes - katrs pasta serveris, kas apstrādā ziņojumu, pievieno vienu ar savu laika zīmogu. Tās veido ķēdi no sūtītāja līdz saņēmējam. Augšējā (jaunākā) Received galvene ir tā, ko daži e-pasta klienti izmanto attēlošanai.
INTERNALDATE - IMAP servera puses laika zīmogs, kas nosaka, kā ziņojumi tiek kārtoti pastkastē. Tas tiek iestatīts, kad ziņojums pirmo reizi tiek saglabāts, izmantojot IMAP APPEND.

Kad imapsync migrē ziņojumu, tas to nolasa no avota servera (ieskaitot tā INTERNALDATE) un ieraksta to galamērķa serverī, izmantojot IMAP APPEND. Karodziņš --syncinternaldates liek imapsync APPEND laikā nodot avota INTERNALDATE galamērķa serverim.

Labā ziņa ir šāda: Microsoft 365, Outlook.com un Gmail saglabā to datumu, kas tiem tiek dots. Tāpēc, kad datumi izrādās nepareizi, problēma ir citur.

Kāpēc datumi var joprojām būt nepareizi

IMAP specifikācija (RFC 3501) nosaka, ka, ja ar APPEND komandu ir norādīts datums un laiks, serverim VAJADZĒTU to izmantot. "VAJADZĒTU" RFC valodā nozīmē "dariet to, ja vien jums nav laba iemesla nedarīt". Microsoft 365, Outlook.com un Gmail to dara: kopija, kas nes savu sākotnējo datumu, to patur.

Tomēr tas, ko imapsync nodod, ir datums, kādu AVOTA serveris tur katram ziņojumam, nevis datums, kad e-pasts tika nosūtīts. Veselā pastkastē šie divi sakrīt. Pastkastē, kas jau reiz tika migrēta vai atjaunota no dublējuma, avots var turēt tās iepriekšējās darbības datumu, un imapsync to nokopē tāpat, kā ir.

Gmail ir īpašs gadījums tikai tad, ja kopēšana notiek caur Gmail paša importēšanas API, nevis IMAP: šī API pievieno Received: rindu, kas datēta ar kopēšanas dienu, un Outlook var rādīt šo datumu. imapsync runā IMAP valodā, tāpēc tas netiek ietekmēts.

Dovecot un Cyrus, divi visbiežāk sastopamie atvērtā koda IMAP serveri, arī saglabā datumu no APPEND. Tātad, lai kāds būtu galamērķis, jautājums ir tas pats: kādu datumu turēja avots?

Biežas imapsync komandrindas kļūdas, kas sabojā datumus

Papildus avota datumiem administratori bieži saduras ar imapsync komandrindas parametriem vai vaino nepareizos no tiem. Šīs ir kļūdas, ko es visbiežāk redzu:

Kopēšana no avota, kura datumi jau bija nepareizi

--syncinternaldates pēc noklusējuma ir ieslēgts: imapsync dod katrai kopijai to iekšējo datumu, kādu tur avota serveris (tā dokumentācija: "Sets the internal dates on host2 as the same as host1"). Ja avota pastkaste pati ir iepriekšējas migrācijas vai atjaunošanas rezultāts, tās iekšējie datumi var jau būt tās darbības datumi, un imapsync uzticami nokopē nepareizo datumu. Šis ir biežākais iemesls un vienlaikus visvieglāk palaist garām, jo žurnālā redzami divi identiski datumi.

--syncinternaldates lietošana kopā ar --addheader

Dažas pamācības iesaka izmantot --addheader, lai migrācijas laikā ievietotu pielāgotu galveni. Galvenes pievienošana modificē ziņojumu (viena papildu rinda augšpusē), bet ne datumu, ko nodod imapsync, tāpēc tas nepaskaidros nepareizus datumus. Kopija vienkārši vairs nav identiska oriģinālam, kas ir svarīgi, ja jūs salīdzināt abus.

--minage un --maxage sajaukšana ar datumu saglabāšanu

Karodziņi --minage un --maxage filtrē, kuri ziņojumi tiek migrēti, pamatojoties uz to vecumu. Tie neietekmē to, kā datumi tiek apstrādāti galamērķī. Esmu redzējis administratorus stundām ilgi pielāgot šos karodziņus, domājot, ka tie novērsīs datumu problēmu. Tie to nedarīs.

TLS vainošana par nobīdītiem datumiem

Izmantojot TLS (--ssl1, --ssl2), savienojumu izveide pievieno latentumu, un lielā migrācijā (50 000+ ziņojumu) tas var uzkrāties līdz vairākām stundām. Tas neietekmē datumus: katra kopija nes datumu, ko nodod imapsync, lai kad tā faktiski nonāktu galamērķī.

imapsync žurnālu lasīšana: ko izvade patiesībā stāsta

imapsync veido detalizētus žurnālus, kas ir lieliski. Bet žurnāla izvade var būt maldinoša, kad runa ir par datumiem.

Tipiska veiksmīgas pārsūtīšanas rinda izskatās šādi:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

Abi datumi sakrīt. Tas nozīmē, ka imapsync nosūtīja pareizo INTERNALDATE uz galamērķi. Un Microsoft 365, Outlook.com un Gmail visi saglabā to datumu, kas tiem tiek dots. Bet divi identiski datumi pierāda tikai to, ka kopija ir uzticama AVOTAM: ja avota datums jau bija nepareizs, abas kolonnas rāda to pašu nepareizo datumu.

Vēlaties pārbaudīt, kas patiesībā notika? Pēc migrācijas pieslēdzieties galamērķim ar IMAP klientu un pārbaudiet INTERNALDATE tieši:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Ja atgrieztais datums nav tas datums, kad e-pasts tika nosūtīts, apskatiet to pašu ziņojumu avotā: tur atradīsiet to pašu nepareizo datumu. Žurnāls nemelo, tas nokopēja to, kas tam tika dots.

Šis ir viens no visvairāk frustrējošiem aspektiem, atkļūdojot datumu problēmas: tīrs žurnāla fails, divi identiski datumi, un tomēr Outlook rāda nepareizu datumu, jo kļūda bija tur jau pirms imapsync darbības.

Liela mēroga imapsync migrācijas: kur datumu problēmas vairojas

Vienas pastkastes migrācija ar imapsync ir kaitinoša, kad datumi sabojājas. Bet MSP un IT nodaļas, kas palaiž imapsync simtiem pastkastu, saskaras ar pavisam citu problēmas mērogu.

Iedomājieties tipisku uzņēmuma migrācijas scenāriju. Jūs pārceļat 200 pastkastes no Zimbra servera uz Microsoft 365. Rakstāt aptinuma skriptu, kas cikliski iet cauri lietotāju CSV failam, izsaucot imapsync katram no tiem. Migrācija notiek nedēļas nogalē. Pirmdienas rītā jums ir 200 pastkastes ar nepareiziem datumiem, un apmēram 1,2 miljoni e-pastu kopā rāda migrācijas laika zīmogu.

Vai varat vēlreiz palaist imapsync, lai to novērstu? Tehniski jā, bet imapsync izlaidīs ziņojumus, kas galamērķī jau eksistē (tas ir izstrādāts tā, lai būtu idempotents). Jums būtu nepieciešams --delete2, lai izdzēstu galamērķa ziņojumus un pārsūtītu tos no jauna, kas ir riskanti aktīvai pastkastei. Un, ja avota datumi bija problēma, otrā palaišana nokopē tos pašus nepareizos datumus vēlreiz.

Daži administratori izmēģina hibrīdu pieeju: pirms tam palaižot imapsync ar --dry, lai testētu, tad reālo migrāciju. Bet --dry vienkārši simulē pārsūtīšanu: tas parāda datumus, kurus imapsync nodotu, ne to, vai tie ir datumi, kad e-pasti tika nosūtīti. Nekas jūs nebrīdina, ka avota datumi jau ir nepareizi.

Paštaisīti risinājumi un to robežas

Ja meklējat forumos un pasta sarakstos (imapsync-devel saraksts pakalpojumā SourceForge joprojām ir aktīvs 2026. gada sākumā), atradīsiet ierosinājumus no radošiem līdz bīstamiem.

Daži iesaka izmantot Perl vienrindiņu, lai tieši modificētu INTERNALDATE galamērķa serverī. Citi iesaka eksportēt visus ziņojumus mbox formātā, manipulēt ar datumiem un importēt tos atpakaļ. Daži ir uzrakstījuši Python skriptus, kas izmanto imaplib, lai izgūtu, modificētu un no jauna ievietotu ziņojumus.

Visām šīm pieejām ir vienas un tās pašas pamatproblēmas. Kā jūs apstrādājat S/MIME parakstītus ziņojumus, nesabojājot parakstu? Kā ar daudzdaļu MIME struktūrām ar ligzdotām robežām? Ne-ASCII galvenēm, kas kodētas ar RFC 2047? PGP šifrētiem ziņojumiem, kuru saturu jūs pat nevarat apskatīt? Skripts, kas apstrādā 50 testa ziņojumus izstrādes vidē, aizrīsies uz robežgadījumiem 30 000 ziņojumu lielā produkcijas pastkastē.

Un lielākais jautājums, ko neviens neuzdod, kamēr nav par vēlu: kā jūs pārbaudāt, ka katrs modificētais ziņojums joprojām ir neskarts? Ka pielikumi netika bojāti, ka pavedieni joprojām darbojas, ka 85 MB izklājlapa, kuru kāds nosūtīja 2020. gadā, izturēja manipulāciju?

(Ja jūs jebkad esat mēģinājis parsēt neapstrādātas e-pasta galvenes valodā Perl, jūs zināt, ka tas nemaz nav tik relaksējoša pēcpusdienas nodarbe.)

Kā Redate.io labo imapsync datumu problēmas

Sākotnējā Date: galvene pēc imapsync migrācijas vienmēr ir neskarta. imapsync uzticami pārsūta neapstrādātu ziņojumu; nepareizais datums atrodas metadatos, ko kopija saņēma, nevis ziņojumā. Šī sākotnējā galvene ir tas, kas padara korekciju iespējamu.

Redate.io tieši pieslēdzas pastkastei (Google Workspace, Microsoft 365 vai jebkuram IMAP serverim), skenē e-pastus ar datumu anomālijām un piemēro mērķtiecīgu metadatu korekciju, izmantojot savu izstrādāto galveņu ķēdes analīzes un datumu rekonstrukcijas cauruļvadu. Tam nav jāzina, kurš rīks veica migrāciju: tas atrod e-pastus, kuru redzamais datums neatbilst to sākotnējam datumam.

Katrs labotais e-pasts tiek pārbaudīts individuāli: ziņojuma integritāte, pielikumu saglabāšana, mapes izvietojums, pavedieni, etiķetes. Oriģināli tiek glabāti redzamā Redate.io - Originals dublējuma mapē un paliek tur, līdz jūs paši tos izdzēšat. Ja kaut kas izskatās nepareizi, atgriezties ir viena klikšķa attālumā.

Bezmaksas skenēšana pieslēdzas pastkastei, identificē katru e-pastu ar datuma anomāliju un uzrāda precīzu skaitu un izmaksas. Nav nepieciešama kredītkarte, nav nekādas programmatūras, ko instalēt. Jūsu platformas specifikai:

Redate.io darbojas arī ar migrācijām, kas notikušas mēnešiem vai gadiem atpakaļ. Date: galvene nenoveco, un tāpat nenoveco spēja labot to, kas nogāja greizi.

Migrējāt ar imapsync un paliekat ar nepareiziem datumiem? Palaidiet bezmaksas skenēšanu, lai redzētu tieši, cik e-pastu ir ietekmēti.

imapsync nesaglabāja datumus? Kā tos labot