Trīs datumi katra e-pasta iekšienē
Katrs e-pasts, kas glabāts IMAP serverī, satur vismaz trīs atšķirīgas datuma vērtības. Izpratne par to, kā šie datumi darbojas un kā e-pasta klienti izvēlas, kuru no tiem attēlot, ir atslēga, lai saprastu, kāpēc migrācija sabojā datumus. Šis raksts ir padziļināta IMAP datumu sistēmas tehniskā analīze, kas paredzēta IT administratoriem un ikvienam, kas vēlas izprast pēcmigrācijas datumu problēmu pamatcēloni.
1. RFC 2822 "Date" galvene
"Date" galvene ir definēta RFC 2822 (interneta ziņojumu formāts). To iestata sūtītāja e-pasta klients brīdī, kad ziņojums tiek sarakstīts un nosūtīts. Šī galvene ir daļa no paša ziņojuma korpusa - tā ceļo kopā ar ziņojumu un to nekad nemaina e-pasta serveri piegādes ceļā. Tipiska Date galvene izskatās šādi:
Date: Mon, 15 Jan 2024 09:32:17 +0100
Date galvene apzīmē ziņojuma "nosūtīšanas datumu". Tas ir visuzticamākais datums, jo tas tiek iestatīts vienreiz un nekad netiek mainīts. Tomēr tas atspoguļo sūtītāja pulksteni, kas var būt nepareizi konfigurēts. Retos gadījumos Date galvene var pilnībā trūkt (jo īpaši automatizētos sistēmas paziņojumos vai nepareizi formētos ziņojumos).
2. IMAP INTERNALDATE
INTERNALDATE ir definēts RFC 3501 (IMAP4rev1 protokols). Tā ir servera puses metadatu vērtība, kas apzīmē datumu un laiku, kad ziņojums tika piegādāts serverim. Atšķirībā no Date galvenes, INTERNALDATE nav daļa no paša e-pasta ziņojuma. To atsevišķi glabā IMAP serveris kā metadatus.
Kad e-pasts tiek piegādāts normāli (nav migrēts), IMAP serveris iestata INTERNALDATE uz pašreizējo laiku piegādes brīdī. Šī vērtība cieši atbilst Date galvenei, parasti dažu sekunžu vai minūšu robežās. E-pasta klienti bieži izmanto INTERNALDATE kā "saņemšanas datumu", jo tas atspoguļo brīdi, kad serveris faktiski saņēma ziņojumu.
Un šeit sākas interesantā daļa. Kad ziņojums tiek ievietots caur IMAP APPEND komandu (ko izmanto migrācijas rīki), APPEND komanda ļauj klientam skaidri norādīt INTERNALDATE. Labi izstrādāti migrācijas rīki izmanto šo funkciju, lai saglabātu avota servera oriģinālo INTERNALDATE. Taču pat tad, kad INTERNALDATE ir pareizi iestatīts, "Received" galvenes problēma (aprakstīta zemāk) tik un tā var pārrakstīt attēloto datumu daudzos klientos.
3. "Received" galveņu ķēde
Katru reizi, kad e-pasts iziet caur e-pasta serveri, šis serveris pievieno "Received" galveni ziņojuma sākumā. Tas izveido Received galveņu ķēdi, kas reģistrē e-pasta ceļu no sūtītāja pie adresāta. Jaunākā (augšā) rāda pēdējo serveri, kas apstrādāja ziņojumu, un vecākā (apakšā) rāda pirmo.
Normālam e-pastam var būt 3 līdz 6 Received galvenes, kas dokumentē ceļu no sūtītāja izejošā servera caur starpniekiem līdz adresāta ienākošajam serverim. Katra Received galvene ietver laikspiedolu. Šeit ir vienkāršots piemērs:
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
Kā e-pasta klienti izvēlas, kuru datumu attēlot
Outlook (darbvirsma, tīmeklis, mobilā versija)
Microsoft Outlook izmanto INTERNALDATE un jaunākās "Received" galvenes kombināciju, lai noteiktu ienākošajā pastā attēloto "Saņemts" datumu. Praksē Outlook mēdz piešķirt prioritāti jaunākās Received galvenes laikspiedolam kolonnai "Saņemts". Kolonna "Nosūtīts" izmanto Date galveni. Tā kā Outlook pēc noklusējuma kārto pēc "Saņemts" kolonnas, lietotāji vispirms redz tieši Received galvenes laikspiedolu.
Apple Mail
Apple Mail uz macOS un iOS galvenokārt izmanto IMAP INTERNALDATE datuma attēlošanai. Ja INTERNALDATE tika pareizi saglabāts migrācijas laikā, Apple Mail var rādīt pareizo datumu, bet tikai tad, ja INTERNALDATE tika skaidri iestatīts APPEND operācijas laikā. Ja migrācijas rīks neiestatīja INTERNALDATE, serveris noklusējumā izmanto ievietošanas laiku (migrācijas datumu). Detaļām par ietekmi uz Apple Mail lietotājiem skatiet Apple Mail: nepareizs datums pēc migrācijas.
Thunderbird
Mozilla Thunderbird piedāvā visvairāk elastības. Tas var attēlot gan "Datums" (no Date galvenes), gan "Saņemts" (no Received galvenēm). Pēc noklusējuma Thunderbird rāda Date galvenes vērtību, kas nozīmē, ka datumi var izskatīties pareizi Thunderbird pat tad, kad tie ir nepareizi Outlook. Kolonna "Saņemts" Thunderbird vienmēr rāda migrācijas datumu. Skatiet Thunderbird: nepareizs datums pēc migrācijas sīkākai informācijai.
Gmail tīmekļa saskarne
Gmail tīmekļa klients izmanto Date galveni savam galvenajam datuma attēlojumam. Tas nozīmē, ka Gmail tīmeklis bieži rāda pareizos datumus pat pēc migrācijas. Taču IMAP INTERNALDATE Gmail serverī tik un tā ir nepareizs, kas ietekmē katru IMAP klientu, kas pieslēdzas šim Gmail kontam. Atšķirība starp Gmail tīmekli un Outlook vai Apple Mail ir bieža neskaidrības avots, un tāds, kas patērē daudz administratoru laika atkļūdošanā.
Kāpēc IMAP APPEND sabojā datumus
Kas notiek migrācijas laikā
Kad migrācijas rīks pārvieto e-pastu no Servera A uz Serveri B, rīks pieslēdzas Serverim A caur IMAP un lejupielādē neapstrādāto ziņojumu, pēc tam pieslēdzas Serverim B un izmanto APPEND komandu tā ievietošanai. Šīs ievietošanas laikā Serveris B apstrādā ienākošo ziņojumu un pievieno jaunu Received galveni ar pašreizējo laikspiedolu: migrācijas datumu. Tā ir standarta IMAP uzvedība, kas definēta protokolā. Serveris apstrādā katru APPEND kā jaunu ziņojuma piegādi.
Rezultāts: kontaminēta galveņu ķēde
Pēc migrācijas e-pasta Received galvenes izskatās šādi:
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
Migrācijas rīka Received galvene tagad ir augstākais ieraksts. Jebkurš e-pasta klients, kas izmanto jaunāko Received galveni attēlojamā datuma noteikšanai (Outlook, jo īpaši) rādīs "2025. gada 11. aprīlis", nevis "2024. gada 15. janvāris". Oriģinālā Date galvene un oriģinālās Received galvenes joprojām ir neskartas zem tās, bet tās vairs nav pozīcijā, kurai e-pasta klienti piešķir prioritāti.
Pat laba INTERNALDATE apstrāde to neaizkavē
Daži migrācijas rīki pareizi iestata INTERNALDATE APPEND laikā. Piemēram, imapsync skaidri saglabā avota servera INTERNALDATE. Taču Received galveni pievieno galamērķa serveris, nevis migrācijas rīks. Migrācijas rīkam nav kontroles pār šo uzvedību. Pat ar perfektu INTERNALDATE saglabāšanu augstākā Received galvene joprojām satur migrācijas datumu, un klienti, piemēram, Outlook, tik un tā rāda nepareizo datumu.
Tad ko konkrēti var darīt?
Kuri migrācijas rīki pievieno Received galvenes
Visi IMAP migrācijas rīki izraisa šo problēmu, jo Received galveni pievieno galamērķa serveris, nevis pats rīks. Pievienotās galvenes saturs atšķiras atkarībā no rīka un servera.
BitTitan MigrationWiz pievieno Received galveni, kas satur "mx.migrationwiz.com". CloudM Migrate pievieno galvenes, kas atsaucas uz "cloudm.io". imapsync aktivizē vispārīgu galamērķa servera Received galveni. GSMMO pievieno galvenes ar "gmailapi.google.com" atsaucēm.
Labojums: pareizo datumu atjaunošana
Labā ziņa ir tāda, ka pareizā datuma informācija joprojām pastāv katrā e-pastā. Oriģinālā Date galvene ir neskarta. Oriģinālās Received galvenes ir neskartas. Problēma ir tāda, ka kontaminējoša galvene atrodas virs tām.
Redate.io patentētais labošanas dzinējs analizē katra skartā e-pasta pilnu galveņu ķēdi, piemērojot parakstu salīdzināšanu simtiem zināmu migrācijas rīku parakstu, lai precīzi identificētu, kurām galvenēm nepieciešama korekcija. Daudzpakāpju analīzes cauruļvads apstrādā robežgadījumus, kas liek vienkāršākām pieejām ciest neveiksmi: S/MIME parakstītus ziņojumus, PGP šifrētu saturu, multipart/alternative struktūras, Content-Transfer-Encoding problēmas, galvenes ar simboliem ārpus ASCII (RFC 2047), pārmērīga izmēra pielikumus un sabojātas MIME robežas.
Pēc labošanas katrs e-pasts iziet integritātes verifikācijas procesu, lai apstiprinātu, ka ziņojuma struktūra, saturs un pielikumi ir saglabāti identiski. Oriģināli tiek saglabāti redzamā dublējumkopiju mapē 30 dienas.
Vai varētu uzrakstīt skriptu, lai mēģinātu šo labojumu pašam? Tehniski, jā. Taču atšķirība starp "darbojas ar 95 % e-pastu" un "darbojas ar 100 % e-pastu, nesabojājot nevienu" nozīmē mēnešus izstrādes. Un kad runa ir par kāda pilnu pastkasti, 5 % neveiksmes līmenis nozīmē simtiem klusējot sabojātu ziņojumu bez iespējas verificēt, kas ir nogājis greizi.
Vai vēlaties uzzināt, cik e-pastiem jūsu pastkastē ir nepareizi datumi? Palaidiet bezmaksas analīzi ar Redate.io, lai iegūtu tūlītēju skartu e-pastu skaitījumu bez maksājuma.