IMAP INTERNALDATE: miks kuupäevad katki lähevad

Kolm kuupäeva igas e-kirjas

Iga IMAP-serverisse salvestatud e-kiri kannab endas vähemalt kolme erinevat kuupäevaväärtust. Arusaamine, kuidas need kuupäevad toimivad ja kuidas meilikliendid otsustavad, millist kuvada, on võti mõistmaks, miks migratsioon kuupäevi rikub. See artikkel on põhjalik tehniline analüüs IMAP kuupäevasüsteemist, mõeldud IT-administraatoritele ja kõigile, kes soovivad mõista migratsioonijärgsete kuupäevaprobleemide algpõhjust.

1. RFC 2822 "Date" päis

"Date" päis on defineeritud RFC 2822-s (Interneti sõnumite formaat). Selle seab saatja meiliklient hetkel, mil sõnum koostatakse ja saadetakse. See päis on osa sõnumi kehast endast, see liigub sõnumiga kaasa ja meiliserverid ei muuda seda kohaletoimetamise teel. Tüüpiline Date päis näeb välja nii:

Date: Mon, 15 Jan 2024 09:32:17 +0100

Date päis esindab sõnumi saatmiskuupäeva. See on kõige usaldusväärsem kuupäev, sest see seatakse üks kord ja seda ei muudeta kunagi. Siiski peegeldab see saatja kella, mis võib olla valesti häälestatud. Harvadel juhtudel võib Date päis täielikult puududa, eriti automatiseeritud süsteemiteadetes või vigastes sõnumites.

2. IMAP INTERNALDATE

INTERNALDATE on defineeritud RFC 3501-s (IMAP4rev1 protokoll). See on serveripoolne metaandmete väärtus, mis näitab kuupäeva ja kellaaega, mil sõnum serverisse toimetati. Erinevalt Date päisest ei ole INTERNALDATE osa e-kirjast endast, IMAP-server salvestab seda eraldi metaandmena.

Tavapärase kohaletoimetamise puhul (kui e-kirja ei migreerita) seab IMAP-server INTERNALDATE-i kohaletoimetamise hetke kellaajale. See väärtus vastab tihedalt Date päisele, tavaliselt mõne sekundi või minuti erinevusega. Meilikliendid kasutavad INTERNALDATE-i sageli "vastuvõtmise kuupäevana", sest see peegeldab hetke, mil server sõnumi tegelikult vastu võttis.

Siin läheb asi huvitavaks. Kui sõnum sisestatakse IMAP APPEND käsu kaudu (mida migratsioonitööriistad kasutavad), lubab APPEND käsk kliendil INTERNALDATE-i eksplitsiitselt määrata. Hästi kavandatud migratsioonitööriistad kasutavad seda funktsiooni algse INTERNALDATE väärtuse säilitamiseks lähteserverist. Kuid isegi kui INTERNALDATE on korrektselt seatud, võib allpool kirjeldatud "Received" päise probleem ikkagi kuvatava kuupäeva paljudes klientides üle kirjutada.

3. "Received" päiste ahel

Iga kord, kui e-kiri läbib meiliserverit, lisab see server sõnumi algusesse "Received" päise. Nii tekib Received päiste ahel, mis registreerib e-kirja teekonna saatjast saajani. Kõige uuem (ülemine) Received päis näitab viimast serverit, mis sõnumit töödles, ja kõige vanem (alumine) näitab esimest.

Tavalisel e-kirjal võib olla 3-6 Received päist, mis dokumenteerivad teekonda saatja väljuvast serverist läbi releede saaja sissetuleva serverini. Iga Received päis sisaldab ajatemplit. Siin on lihtsustatud näide:

Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100

Kuidas meilikliendid otsustavad, millist kuupäeva kuvada

Outlook (Desktop, Web, Mobile)

Microsoft Outlook kasutab postkastis kuvatava "Vastuvõtmise" kuupäeva määramiseks INTERNALDATE-i ja kõige värskema "Received" päise kombinatsiooni. Praktikas kaldub Outlook eelistama kõige värskema Received päise ajatemplit veerus "Vastuvõetud". Veerg "Saadetud" kasutab Date päist. Kuna Outlook sorteerib vaikimisi veeru "Vastuvõetud" järgi, on kasutajatele esmalt näha just Received päise ajatempel.

Apple Mail

Apple Mail macOS-is ja iOS-is kasutab kuupäeva kuvamiseks peamiselt IMAP INTERNALDATE-i. Kui INTERNALDATE säilitati migratsiooni käigus korrektselt, võib Apple Mail näidata õiget kuupäeva, kuid ainult juhul, kui INTERNALDATE seati APPEND toimingu käigus eksplitsiitselt. Kui migratsioonitööriist INTERNALDATE-i ei seadnud, kasutab server vaikimisi sisestusaega (migratsiooni kuupäeva). Selle mõju kohta Apple Maili kasutajatele vaadake Apple Mail: vale kuupäev pärast migratsiooni.

Thunderbird

Mozilla Thunderbird pakub kõige rohkem paindlikkust. See saab kuvada nii "Date" (Date päisest) kui "Received" (Received päistest) väärtust. Vaikimisi kuvab Thunderbird Date päise väärtust, mis tähendab, et kuupäevad võivad Thunderbirdis olla korrektsed isegi siis, kui need on Outlookis valed. Veerg "Received" Thunderbirdis näitab siiski migratsiooni kuupäeva. Lisateabe jaoks vaadake Thunderbird: vale kuupäev pärast migratsiooni.

Gmaili veebiliides

Gmaili veebiklient kasutab kuupäeva peamiseks kuvamiseks Date päist. See tähendab, et Gmaili veeb näitab sageli õigeid kuupäevi isegi pärast migratsiooni. Kuid Gmaili serveril olev IMAP INTERNALDATE jääb valeks, mis mõjutab iga IMAP-klienti, mis selle Gmaili kontoga ühendub. Erinevus Gmaili veebi ja Outlooki või Apple Maili vahel on tavaline segaduse allikas, mis kulutab palju administraatori aega.

Miks IMAP APPEND rikub kuupäevi

Mis juhtub migratsiooni käigus

Kui migratsioonitööriist liigutab e-kirja serverist A serverisse B, ühendub tööriist serveriga A IMAP kaudu ja laadib alla algupärase sõnumi, siis ühendub serveriga B ja kasutab selle sisestamiseks APPEND käsku. Sisestamise ajal töötleb server B sisenevat sõnumit ja lisab uue Received päise praeguse ajatempliga, migratsiooni kuupäevaga. See on tavapärane IMAP-i käitumine. Server käsitleb iga APPEND-i uue sõnumi kohaletoimetamisena.

Tulemus: saastunud päiste ahel

Pärast migratsiooni näeb e-kirja Received päiste ahel välja nii:

Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100

Migratsioonitööriista Received päis on nüüd ülemine kirje. Iga meiliklient, mis kasutab kuvatava kuupäeva määramiseks ülemist Received päist (eriti Outlook), näitab "11. aprill 2025" selle asemel, et näidata "15. jaanuar 2024". Algne Date päis ja algsed Received päised on endiselt allpool säilinud, kuid nad ei asu enam positsioonis, mida meilikliendid eelistavad.

Isegi korrektne INTERNALDATE käsitlus ei hoia seda ära

Mõned migratsioonitööriistad seavad APPEND käigus INTERNALDATE-i korrektselt. Näiteks imapsync säilitab eksplitsiitselt lähteserveri INTERNALDATE väärtuse. Kuid Received päise lisab sihtserver, mitte migratsioonitööriist. Migratsioonitööriistal ei ole selle käitumise üle kontrolli. Isegi täieliku INTERNALDATE säilitamise korral sisaldab ülemine Received päis siiski migratsiooni kuupäeva ja kliendid, nagu Outlook, näitavad ikkagi vale kuupäeva.

Mida saab selle kohta tegelikult ette võtta?

Millised migratsioonitööriistad lisavad Received päiseid

Iga IMAP migratsioonitööriist tekitab selle probleemi, sest Received päise lisab sihtserver, mitte migratsioonitööriist. Lisatud päise sisu varieerub tööriista ja serveri lõikes.

BitTitan MigrationWiz lisab Received päise, mis sisaldab "mx.migrationwiz.com". CloudM Migrate lisab päised, mis viitavad "cloudm.io". imapsync käivitab sihtserveri üldise Received päise. GSMMO lisab päised viitega "gmailapi.google.com".

Lahendus: õigete kuupäevade taastamine

Hea uudis on, et õige kuupäevainfo eksisteerib endiselt igas e-kirjas. Algne Date päis on säilinud. Algsed Received päised on säilinud. Probleem on selles, et nende peale on asetunud saastav päis.

Redate.io eraomandiline parandusmootor analüüsib igas mõjutatud e-kirjas kuupäevaanomaaliaid kogu päiste ahelas, et tuvastada täpselt, millised päised vajavad korrigeerimist. Meetod tuvastab probleemi kuupäevade lahknevuse põhjal, sõltumata sellest, mis migratsioonitööriistaga e-kirjad üle kanti. Mitmeetapiline analüüsiprotsess käsitleb erijuhtusid, mis lihtsamate lähenemiste puhul tekitavad probleeme: S/MIME allkirjastatud sõnumid, PGP-krüpteeritud sisu, multipart/alternative struktuurid, Content-Transfer-Encoding probleemid, mitte-ASCII päised (RFC 2047), suuremahulised manused ja kahjustatud MIME piirid.

Pärast korrigeerimist läbib iga e-kiri terviklikkuse kontrolli, mis tagab, et sõnumi struktuur, sisu ja manused jäävad täpselt samaks. Algsed sõnumid liigutatakse nähtavasse varukausta postkastis ja need jäävad seal alles, kuni klient need eemaldab.

Kas te saaksite selle jaoks skripti kirjutada? Tehniliselt küll. Kuid erinevus lause "toimib 95% e-kirjadel" ja "toimib 100% e-kirjadel, kahjustamata ühtki neist" vahel on koht, kuhu kulub kuid arendustööd. Ja kui jutt käib kellegi täielikust postkastist, tähendab 5% ebaõnnestumise määr sadu vaikselt kahjustatud sõnumeid, mille viga on võimatu tuvastada.

Soovite näha, mitmel e-kirjal teie postkastis on katkised kuupäevad? Käivitage tasuta skann Redate.io-ga ja saate koheselt mõjutatud e-kirjade arvu, ilma et see nõuaks makset.