imapsync datum javitas

A --syncinternaldates ígérete (és ahol megáll)

Lefuttatta az imapsync parancsot. Beillesztette a --syncinternaldates kapcsolót, mert elolvasta a dokumentációt, és ilyen alapos ember. A migráció befejeződik, a napló szerint minden átkerült, nulla hiba. Aztán megnyitja a postafiókot az Outlookban, és minden e-mail a tegnapi dátumot mutatja.

Ez az imapsync egyik leggyakoribb bosszúsága, és legalább 2017 óta zavarba hozza a rendszergazdákat. A --syncinternaldates kapcsoló célja az IMAP INTERNALDATE megőrzése a migráció során. És meg is teszi: minden másolatnak azt a belső dátumot adja, amelyet a forrásszerver tárol. Pontosan itt van a csapda.

Az imapsync egy Gilles Lamiral által írt nyílt forráskódú Perl eszköz, és valóban jól csinálja, amit csinál. Az IMAP-IMAP postafiók-átvitelt olyan megbízhatósággal kezeli, amelyet sok kereskedelmi eszköz megkívánna. De az imapsync csak azokat a dátumokat tudja átvinni, amelyeket talál, és itt bonyolodnak a dolgok.

Hogyan működnek valójában az IMAP-dátumok

Minden e-mailben három különböző "dátum" létezik, és a legtöbb ember (néhány informatikai rendszergazdát is beleértve) összekeveri őket:

A Date: fejléc (RFC 2822) - az a dátum, amelyet a küldő e-mail kliense a levél megírásakor helyezett el az üzenetben. Ez az üzenet törzsében él, és a levelezőszerverek soha nem módosítják.
Received: fejlécek - minden levelezőszerver, amely kezeli az üzenetet, hozzáad egyet a saját időbélyegével. Ezek láncot alkotnak a küldőtől a fogadóig. A legfelső (legfrissebb) Received fejlécet néhány e-mail kliens a megjelenítéshez használja.
INTERNALDATE - az IMAP szerver oldali időbélyege, amely meghatározza, hogyan rendeződnek az üzenetek a postafiókban. Ezt akkor állítják be, amikor az üzenetet először tárolják IMAP APPEND művelettel.

Amikor az imapsync migrál egy üzenetet, beolvassa azt a forrásszerverről (az INTERNALDATE-jével együtt), és IMAP APPEND segítségével írja a célszerverre. A --syncinternaldates kapcsoló arra utasítja az imapsync-et, hogy az APPEND során adja át a forrás INTERNALDATE-jét a célszervernek.

A jó hír: a Microsoft 365, az Outlook.com és a Gmail megtartja azt a dátumot, amelyet megkap. Ha a dátumok mégis hibásak, a probléma máshol van.

Miért lehet a dátum mégis hibás

Az IMAP specifikáció (RFC 3501) szerint, ha az APPEND parancshoz dátum-időt adnak meg, a szervernek HASZNÁLNIA KELLENE (SHOULD) azt. A "SHOULD" az RFC nyelvezetében azt jelenti: "tedd meg, hacsak nincs rá jó okod, hogy ne". A Microsoft 365, az Outlook.com és a Gmail meg is teszi: egy másolat, amely magával viszi az eredeti dátumát, megtartja azt.

Az imapsync azonban azt a dátumot adja át, amelyet a FORRÁSSZERVER tárol az egyes üzenetekhez, nem azt, amikor az e-mailt elküldték. Egy egészséges postafiókban a kettő megegyezik. Egy olyan postafiókban, amelyet már egyszer migráltak vagy biztonsági mentésből állítottak vissza, a forrás tarthatja azt a korábbi művelet dátumát, és az imapsync ezt viszi át változatlanul.

A Gmail csak akkor különleges eset, ha a másolás a Gmail saját importálási API-ján keresztül történik, nem IMAP-on: ez az API hozzáad egy Received: sort, amely a másolás napjára van dátumozva, és az Outlook megjelenítheti ezt a dátumot. Az imapsync IMAP-ot használ, tehát ez nem érinti.

A Dovecot és a Cyrus, a két legelterjedtebb nyílt forráskódú IMAP-szerver, ugyanígy megtartja az APPEND-ből érkező dátumot. Így bármi is a célrendszer, a kérdés ugyanaz: milyen dátumot tárolt a forrás?

Gyakori imapsync parancssori hibák, amelyek elrontják a dátumokat

A forrásdátumokon túl a rendszergazdák gyakran belebotlanak az imapsync parancssori kapcsolóiba, vagy rossz dolgot hibáztatnak. Ezek a leggyakrabban látott hibák:

Másolás olyan forrásból, amelynek dátumai már eleve rosszak voltak

--syncinternaldates alapesetben bekapcsolt: az imapsync minden másolatnak azt a belső dátumot adja, amelyet a forrásszerver tárol (a dokumentáció szerint: "Sets the internal dates on host2 as the same as host1"). Ha a forrás postafiók maga is egy korábbi migráció vagy visszaállítás eredménye, a belső dátumai már azt a műveletet tükrözhetik, és az imapsync hűen átviszi a rossz dátumot. Ez a leggyakoribb ok, és a legnehezebben észrevehető, mert a napló két azonos dátumot mutat.

A --syncinternaldates használata --addheader-rel együtt

Néhány útmutató azt javasolja, hogy a --addheader kapcsolóval egyéni fejlécet illesszenek be a migráció során. A fejléc hozzáadása módosítja az üzenetet (egy sorral több a tetején), de nem az imapsync által átadott dátumot, így ez nem lehet a hibás dátumok magyarázata. A másolat egyszerűen már nem lesz azonos az eredetivel, ami akkor számít, ha a kettőt összehasonlítja.

A --minage és --maxage összekeverése a dátummegőrzéssel

A --minage és --maxage kapcsolók az üzenetek korát figyelembe véve szűrik, mely leveleket kell migrálni. Nincs hatásuk arra, hogyan kezeli a célrendszer a dátumokat. Láttam rendszergazdákat, akik órákat töltöttek ezeknek a kapcsolóknak a finomhangolásával, azt hitték, ez megoldja a dátumproblémát. Nem fogja.

A TLS hibáztatása az eltolódott dátumokért

TLS-en keresztül (--ssl1, --ssl2) a kapcsolatok felépítése késleltetést ad, és egy nagy migráció esetén (50 000+ üzenet) ez akár órákra is nőhet. A dátumokat ez nem érinti: minden másolat azt a dátumot viseli, amelyet az imapsync átad, függetlenül attól, hogy valójában mikor érkezik meg.

Az imapsync naplók olvasása: mit mond valójában a kimenet

Az imapsync részletes naplókat készít, ami nagyszerű. De a napló kimenete félrevezető lehet, ha a dátumokról van szó.

Egy tipikus, sikeres átvitel sora így néz ki:

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

Mindkét dátum egyezik. Ez azt jelenti, hogy az imapsync a helyes INTERNALDATE-et küldte el a célnak. És a Microsoft 365, az Outlook.com és a Gmail is megtartja a megadott dátumot. De két azonos dátum csak azt bizonyítja, hogy a másolat hűen követi a FORRÁST: ha a forrás dátuma már eleve rossz volt, mindkét oszlop ugyanazt a rossz dátumot mutatja.

Szeretné ellenőrizni, mi történt valójában? A migráció után csatlakozzon a célhoz egy IMAP klienssel, és nézze meg közvetlenül az INTERNALDATE-et:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Ha a visszaadott dátum nem azonos azzal az időponttal, amikor az e-mailt elküldték, nézze meg ugyanazt az üzenetet a forráson: ugyanazt a rossz dátumot fogja találni ott is. A napló nem hazudott, csak azt másolta, amit megkapott.

Ez a dátumproblémák hibakeresésének egyik legbosszantóbb oldala: tiszta naplófájl, két azonos dátum, és mégis rossz dátum jelenik meg az Outlookban, mert a hiba már azelőtt megvolt, hogy az imapsync elindult.

Nagy léptékű imapsync migrációk: ahol a dátumproblémák megsokszorozódnak

Egyetlen postafiókot érintő imapsync migráció bosszantó, ha a dátumok elromlanak. De a több száz postafiókon imapsync-et futtató MSP-k és informatikai osztályok egészen más nagyságrendű problémával néznek szembe.

Vegyünk egy tipikus vállalati migrációs helyzetet. 200 postafiókot mozgat egy Zimbra szerverről Microsoft 365-be. Ír egy wrapper szkriptet, amely egy felhasználói CSV-n megy végig, minden felhasználóra meghívva az imapsync-et. A migráció egy hétvégén fut. Hétfő reggelre 200 postafiók áll rossz dátumokkal, és összesen körülbelül 1,2 millió e-mail mutatja a migráció időpontját.

Újra lefuttatható az imapsync a hiba javítására? Technikailag igen, de az imapsync kihagyja azokat az üzeneteket, amelyek már léteznek a célon (idempotensre lett tervezve). A --delete2 kapcsolóra van szükség a cél üzeneteinek eltávolításához és újbóli átviteléhez, ami kockázatos egy éles postafiókon. És ha a forrás dátumai voltak a probléma, egy második futás ugyanazokat a rossz dátumokat viszi át újra.

Néhány rendszergazda hibrid megközelítést próbál: először --dry kapcsolóval futtatja az imapsync-et teszteléshez, majd a valós migrációt. De a --dry csak szimulálja az átvitelt: azt mutatja meg, milyen dátumokat adna át az imapsync, nem azt, hogy ezek a dátumok valóban azok-e, amikor az e-maileket elküldték. Semmi nem figyelmezteti arra, hogy a forrás dátumai már eleve rosszak.

Házi megoldások és korlátaik

Ha fórumokat és levelezőlistákat keres (az imapsync-devel lista a SourceForge-on 2026 elején is aktív), a kreatívtól a veszélyesig terjedő javaslatokat talál.

Néhányan egy Perl egysorost javasolnak, amely közvetlenül a célszerveren módosítja az INTERNALDATE-et. Mások azt ajánlják, hogy exportálja az összes üzenetet mbox formátumba, módosítsa a dátumokat, majd importálja vissza. Néhányan Python szkripteket írtak, amelyek az imaplib segítségével lekérik, módosítják és visszaillesztik az üzeneteket.

Ezek a megközelítések mind ugyanazokkal az alapvető problémákkal küzdenek. Hogyan kezeli az S/MIME aláírt üzeneteket úgy, hogy az aláírás ne törjön? Mi van a beágyazott határvonalakkal rendelkező többrészes MIME struktúrákkal? Az RFC 2047 szerint kódolt, nem ASCII fejlécekkel? A PGP-vel titkosított üzenetekkel, amelyeknek a tartalmát még ellenőrizni sem lehet? Egy szkript, amely 50 tesztüzeneten fejlesztői környezetben működik, egy 30 000 üzenetes éles postafiók szélsőséges eseteinél elakad.

És a legnagyobb kérdés, amelyet senki nem kérdez meg, amíg nem túl késő: hogyan ellenőrzi, hogy minden egyes módosított üzenet valóban sértetlen maradt? Hogy a mellékletek nem sérültek meg, hogy a szálazás továbbra is működik, hogy az a 85 MB-os táblázat, amelyet valaki 2020-ban küldött, túlélte a beavatkozást?

(Ha már próbált nyers e-mail fejléceket elemezni Perlben, tudja, hogy ez nem éppen egy nyugodt délutáni elfoglaltság.)

Hogyan javítja a Redate.io az imapsync dátumproblémáit

Az eredeti Date: fejléc egy imapsync migráció után mindig sértetlen marad. Az imapsync hűen viszi át a nyers üzenetet; a rossz dátum a másolat metaadataiban ül, nem az üzenetben. Ez az eredeti fejléc teszi lehetővé a javítást.

A Redate.io közvetlenül csatlakozik a postafiókhoz (Google Workspace, Microsoft 365 vagy bármely IMAP-szerver), átvizsgálja a dátumanomáliát mutató e-maileket, és célzott metaadat-javítást alkalmaz egy sajátfejlesztésű fejléclánc-elemzési és dátum-helyreállítási folyamattal. Nem kell tudnia, melyik eszköz végezte a migrációt: azokat az e-maileket találja meg, amelyeknek a megjelenített dátuma nem egyezik az eredeti dátumukkal.

Minden javított e-mailt egyedileg ellenőriznek: az üzenet sértetlenségét, a mellékletek megőrzését, a mappaelhelyezést, a szálazást, a címkéket. Az eredetiket egy jól látható Redate.io - Originals biztonsági másolat mappában tartják, és addig maradnak ott, amíg maga nem törli őket. Ha valami nem stimmel, a visszaállítás egy kattintásnyira van.

Az ingyenes átvizsgálás csatlakozik a postafiókhoz, azonosítja minden dátumanomáliát mutató e-mailt, és megadja a pontos darabszámot és a költséget. Nincs szükség bankkártyára, nincs telepítendő szoftver. Az adott platformra vonatkozó részletekért:

A Redate.io olyan migrációkon is működik, amelyek hónapokkal vagy évekkel korábban történtek. A Date: fejléc nem évül el, és a hiba kijavításának lehetősége sem.

Imapsync-kel migrált, és hibás dátumokkal maradt? Indítson ingyenes átvizsgálást, hogy pontosan lássa, hány e-mailt érint a probléma.

imapsync: nem maradtak meg a datumok? Javitas