Corectare date imapsync

Promisiunea --syncinternaldates (și unde se oprește)

Ați rulat comanda imapsync. Ați inclus --syncinternaldates pentru că ați citit documentația și sunteți atent la asemenea lucruri. Migrarea se termină, logul spune că totul a fost transferat, zero erori. Apoi deschideți cutia poștală în Outlook și fiecare e-mail arată data de ieri.

Aceasta este una dintre cele mai frecvente frustrări legate de imapsync și încurcă administratorii de sistem cel puțin din 2017. Flag-ul --syncinternaldates ar trebui să păstreze INTERNALDATE IMAP în timpul migrării. Și o face: dă fiecărei copii data internă pe care o are serverul sursă. Exact acolo se află capcana.

imapsync este un instrument open-source în Perl, scris de Gilles Lamiral, și este într-adevăr bun la ceea ce face. Gestionează transferurile de cutii poștale IMAP-la-IMAP cu un nivel de fiabilitate pe care majoritatea instrumentelor comerciale îl invidiază. Dar imapsync poate copia doar datele pe care le găsește, și aici lucrurile se complică.

Cum funcționează de fapt datele IMAP

Există trei "date" diferite implicate în fiecare e-mail, și majoritatea oamenilor (inclusiv unii administratori IT) le confundă:

Headerul Date: (RFC 2822) - data pe care clientul de e-mail al expeditorului a aplicat-o mesajului la compunere. Aceasta se află în corpul mesajului și nu este niciodată modificată de serverele de e-mail.
Headerele Received: - fiecare server de e-mail care procesează mesajul adaugă unul cu propria marcă temporală. Acestea formează un lanț de la expeditor la destinatar. Headerul Received cel mai de sus (cel mai recent) este cel pe care unii clienți de e-mail îl folosesc pentru afișare.
INTERNALDATE - o marcă temporală pe partea serverului IMAP care controlează modul în care mesajele sunt sortate în cutia poștală. Aceasta este setată când mesajul este stocat pentru prima dată prin IMAP APPEND.

Când imapsync migrează un mesaj, îl citește de pe serverul sursă (inclusiv INTERNALDATE) și îl scrie pe serverul destinație folosind IMAP APPEND. Flag-ul --syncinternaldates îi spune lui imapsync să transmită INTERNALDATE sursă serverului destinație în timpul APPEND.

Vestea bună: Microsoft 365, Outlook.com și Gmail păstrează data care le este dată. Așa că atunci când datele apar greșite, problema se află în altă parte.

De ce datele pot fi totuși greșite

Specificația IMAP (RFC 3501) spune că, dacă o dată-oră este furnizată cu comanda APPEND, serverul AR TREBUI să o folosească. "SHOULD" în limbajul RFC înseamnă "faceți asta, cu excepția cazului în care aveți un motiv bun să nu o faceți". Microsoft 365, Outlook.com și Gmail o fac: o copie care poartă data ei originală o păstrează.

Ceea ce transmite imapsync, totuși, este data pe care o deține serverul SURSĂ pentru fiecare mesaj, nu data la care e-mailul a fost trimis. Pe o cutie poștală sănătoasă, cele două coincid. Pe o cutie poștală care a fost deja migrată o dată sau restaurată dintr-un backup, sursa poate deține data acelei operațiuni anterioare, iar imapsync o copiază așa cum este.

Gmail este un caz aparte doar când copia trece prin API-ul propriu de import al Gmail în locul IMAP: acel API adaugă o linie Received datată cu ziua copiei, și Outlook poate afișa acea dată. imapsync vorbește IMAP, așa că nu este afectat.

Dovecot și Cyrus, cele două servere IMAP open-source cele mai comune, păstrează de asemenea data din APPEND. Așa că, indiferent de destinație, întrebarea este aceeași: ce dată deținea sursa?

Greșeli frecvente la linia de comandă imapsync care strică datele

Dincolo de datele sursă, administratorii se poticnesc des în opțiunile de linie de comandă ale imapsync, sau dau vina pe cele greșite. Acestea sunt greșelile pe care le văd cel mai des:

Copierea dintr-o sursă ale cărei date erau deja greșite

--syncinternaldates este activat implicit: imapsync dă fiecărei copii data internă pe care o deține serverul sursă (documentația sa: "Sets the internal dates on host2 as the same as host1"). Dacă cutia poștală sursă este ea însăși rezultatul unei migrări anterioare sau al unei restaurări, datele ei interne pot fi deja cele ale acelei operațiuni, și imapsync copiază fidel data greșită. Aceasta este cauza cea mai frecventă, și cea mai ușor de ratat, pentru că logul arată două date identice.

Folosirea --syncinternaldates cu --addheader

Unele ghiduri recomandă folosirea --addheader pentru a injecta un header personalizat în timpul migrării. Adăugarea unui header modifică mesajul (o linie în plus la început) dar nu data pe care o transmite imapsync, așa că nu explică datele greșite. Copia pur și simplu nu mai este identică cu originalul, ceea ce contează dacă le comparați pe cele două.

Confundarea --minage și --maxage cu păstrarea datelor

Flag-urile --minage și --maxage filtrează mesajele de migrat în funcție de vechimea lor. Nu afectează modul în care sunt gestionate datele la destinație. Am văzut administratori care petrec ore ajustând aceste flag-uri crezând că vor repara problema datelor. Nu o vor face.

Vina pusă pe TLS pentru datele deplasate

Prin TLS (--ssl1, --ssl2), stabilirea conexiunilor adaugă latență, și la o migrare mare (peste 50.000 de mesaje) se adună la ore. Nu afectează datele: fiecare copie poartă data pe care o transmite imapsync, indiferent de momentul în care ajunge efectiv.

Citirea logurilor imapsync: ce vă spune de fapt rezultatul

imapsync produce loguri detaliate, ceea ce este excelent. Dar rezultatul din log poate fi înșelător când vine vorba de date.

O linie tipică de transfer reușit arată așa:

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

Ambele date se potrivesc. Aceasta înseamnă că imapsync a trimis INTERNALDATE corect către destinație. Și Microsoft 365, Outlook.com și Gmail păstrează toate data care le este dată. Dar două date identice dovedesc doar că copia este fidelă față de SURSĂ: dacă data sursei era deja greșită, ambele coloane arată aceeași dată greșită.

Vreți să verificați ce s-a întâmplat de fapt? După migrare, conectați-vă la destinație cu un client IMAP și verificați direct INTERNALDATE:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Dacă data returnată nu este data la care a fost trimis e-mailul, priviți același mesaj pe sursă: veți găsi aceeași dată greșită acolo. Logul nu a mințit, a copiat ceea ce i s-a dat.

Acesta este unul dintre cele mai frustrante aspecte ale depanării problemelor de date: un fișier de log curat, două date identice, și totuși data greșită în Outlook, pentru că eroarea era deja acolo înainte ca imapsync să ruleze.

Migrări imapsync la scară mare: unde se multiplică problemele de date

O migrare a unei singure cutii poștale cu imapsync este enervantă atunci când datele se strică. Dar MSP-urile și departamentele IT care rulează imapsync pe sute de cutii poștale se confruntă cu o problemă de o cu totul altă amploare.

Luați în considerare un scenariu tipic de migrare la nivel de întreprindere. Mutați 200 de cutii poștale de pe un server Zimbra pe Microsoft 365. Scrieți un script wrapper care parcurge un CSV de utilizatori, apelând imapsync pentru fiecare. Migrarea rulează peste un weekend. Luni dimineață, aveți 200 de cutii poștale cu date greșite, și în jur de 1,2 milioane de e-mailuri în total care arată marca temporală a migrării.

Puteți rula din nou imapsync pentru a repara asta? Tehnic, da, dar imapsync va omite mesajele care există deja la destinație (este conceput să fie idempotent). Ați avea nevoie de --delete2 pentru a elimina mesajele de la destinație și a le retransfera, ceea ce este riscant pe o cutie poștală de producție. Și dacă datele sursă erau problema, o a doua rulare copiază din nou aceleași date greșite.

Unii administratori încearcă o abordare hibridă: rulează imapsync cu --dry mai întâi pentru a testa, apoi migrarea reală. Dar --dry doar simulează transferul: arată datele pe care imapsync le-ar transmite, nu dacă acestea sunt datele la care au fost trimise e-mailurile. Nimic nu vă avertizează că datele sursă sunt deja greșite.

Reparații DIY și limitele lor

Dacă căutați pe forumuri și liste de discuții (lista imapsync-devel de pe SourceForge este încă activă la începutul lui 2026), veți găsi sugestii care variază de la creative la periculoase.

Unii recomandă folosirea unui one-liner Perl pentru a modifica direct INTERNALDATE pe serverul destinație. Alții recomandă exportarea tuturor mesajelor în format mbox, manipularea datelor, și reimportarea. Câțiva au scris scripturi Python care folosesc imaplib pentru a extrage, modifica și reintroduce mesajele.

Toate aceste abordări au aceleași probleme fundamentale. Cum gestionați mesajele semnate S/MIME fără a rupe semnătura? Ce se întâmplă cu structurile MIME multipart cu limite imbricate? Headerele non-ASCII codificate cu RFC 2047? Mesajele criptate PGP la care nici nu puteți inspecta conținutul? Un script care gestionează 50 de mesaje de test într-un mediu de dezvoltare va da rateuri la cazurile limită dintr-o cutie poștală de producție cu 30.000 de mesaje.

Și cea mai mare întrebare pe care nimeni nu o pune până nu este prea târziu: cum verificați că fiecare mesaj modificat este încă intact? Că atașamentele nu s-au corupt, că firul conversației funcționează încă, că foaia de calcul de 85 MB pe care cineva a trimis-o prin e-mail în 2020 a supraviețuit manipulării?

(Dacă ați încercat vreodată să analizați headere brute de e-mail în Perl, știți că nu este exact o activitate relaxantă de după-amiază.)

Cum corectează Redate.io problemele de date după imapsync

Headerul original Date: este întotdeauna intact după o migrare imapsync. imapsync transferă mesajul brut cu fidelitate; data greșită se află în metadatele pe care le-a primit copia, nu în mesaj. Acel header original este cel care face posibilă corectarea.

Redate.io se conectează direct la cutia poștală (Google Workspace, Microsoft 365 sau orice server IMAP), scanează e-mailurile cu anomalii de dată și aplică o corectare țintită a metadatelor printr-un pipeline proprietar de analiză a lanțului de headere și reconstrucție a datei. Nu are nevoie să știe care instrument a făcut migrarea: găsește e-mailurile a căror dată afișată nu corespunde datei lor originale.

Fiecare e-mail corectat este verificat individual: integritatea mesajului, păstrarea atașamentelor, plasarea în folder, firul conversației, etichetele. Originalele sunt păstrate într-un folder vizibil de backup Redate.io - Originals, și rămân acolo până când le ștergeți dumneavoastră. Dacă ceva pare greșit, revenirea la starea inițială este la un clic distanță.

Scanarea gratuită se conectează la cutia poștală, identifică fiecare e-mail cu o anomalie de dată, și raportează numărul exact și costul. Fără card de credit necesar, fără software de instalat. Pentru specificul platformei dumneavoastră:

Redate.io funcționează și pe migrări care au avut loc acum luni sau ani. Headerul Date: nu expiră, și nici capacitatea de a corecta ce a fost greșit.

Ați migrat cu imapsync și ați rămas cu date greșite? Rulați o scanare gratuită pentru a vedea exact câte e-mailuri sunt afectate.

imapsync: datele nu s-au păstrat? Cum le corectați