eM Client: nepareizi datumi pēc PST vai Thunderbird importa

Simptoms: visi e-pasti rāda vienu un to pašu datumu

Jūs tikko pabeidzāt PST importu eM Client, vai arī migrējāt no Thunderbird uz jauno pastkasti. Imports noritēja bez redzamām kļūdām. Taču, atverot iesūtni, kaut kas ir greizi: simtiem, dažreiz tūkstošiem e-pastu rāda vienu un to pašu datumu, konkrēti importa dienu. E-pasts no 2019. gada izskatās, it kā tas būtu saņemts vakar. Pirms trim gadiem parakstīts līgums parādās kā tikko ienācis.

Pirmā dabiskā reakcija ir vainot eM Client. Nepareizs iestatījums, nepareizā kārtošanas kolonna, attēlošanas kļūda... Meklē preferenčās. Pārslēdzas starp "Saņemšanas datumu" un "Nosūtīšanas datumu". Nekas nemainās. Vai drīzāk, kaut kas mainās, bet tas neatrisina galveno problēmu.

Tāpēc, ka problēma nav eM Client. Tā ir servera metadatos.

Patiesais cēlonis: IMAP INTERNALDATE pārrakstīts importa laikā

Lai saprastu, kas notiek, jāpaskatās dziļāk un jāsaprot, kā IMAP protokols glabā e-pastus.

Katram ziņojumam IMAP serverī ir divi atšķirīgi datumu veidi:

• Galvene Date: (definēta RFC 2822): tas ir datums, ko sūtītājs ierakstīja ziņojumā nosūtīšanas brīdī. Tas ir iekapsulēts ziņojuma pamattekstā un teorētiski nav maināms.
• INTERNALDATE: servera metadati, ārpus ziņojuma, kas apzīmē datumu, kad ziņojums tika nogādāts pastkastē. Tieši šo vērtību e-pasta klienti primāri izmanto e-pastu kārtošanai un attēlošanai.

PST importa vai migrācijas no Thunderbird laikā importa rīks (vai tas ir eM Client iebūvētais modulis, trešās puses rīks, vai manuāla IMAP kopēšana) nogādā ziņojumus uz galamērķa IMAP serveri. Un šajā brīdī, ja rīks nepārglabā oriģinālo INTERNALDATE nogādāšanas brīdī, serveris automātiski piešķir pašreizējo INTERNALDATE, tas ir, importa datumu un laiku.

Rezultāts: 8000 arhivēti e-pasti kopš 2017. gada, visi apzīmogoti kā "saņemti" jūsu migrācijas brīdī.

(Starp citu, ja esat mēģinājuši lasīt e-pasta neapstrādātās galvenes, izmantojot Rādīt avotu eM Client, varējāt pamanīt, ka oriģinālā galvene Date: joprojām tur ir, neskarta. Tas ir zīme, ka problēma nāk no servera INTERNALDATE, nevis no paša ziņojuma.)

Kāpēc kārtošanas kolonnas maiņa nepalīdz

Sajukums rodas no atšķirības, ko maz cilvēku pazīst. eM Client, tāpat kā Outlook vai Thunderbird, parasti ir divas datumu kolonnas:

• "Saņemšanas datums" (vai "Ierašanās datums"): balstīts uz servera INTERNALDATE.
• "Datums" vai "Nosūtīšanas datums": balstīts uz ziņojuma galveni Date:.

Daudzi administratori to atklāj un domā, ka ir atraduši risinājumu: pārslēgties uz "Nosūtīšanas datumu", un problēma vizuāli pazūd eM Client. Bet tas nav gluži pareizi.

Precizējums: pat kārtojot pēc nosūtīšanas datuma eM Client, problēma saglabājas visiem pārējiem klientiem un visām pārējām saskarnēm, kas piekļūst tai pašai pastkastei. Ja lietotāji skatās savus e-pastus no OWA, no Outlook birojā, no Gmail lietotnes mobilajā tālrunī, vai no jebkura cita IMAP konfigurēta klienta, viņi redzēs importa datumus. eM Client kārtošanas iestatījums attiecas tikai uz eM Client, un tas neietekmē servera pusē glabātos metadatus.

Turklāt Microsoft 365 un Google Workspace natīvais tīmekļa skats kārto pēc INTERNALDATE. Šo uzvedību no klienta puses mainīt nevar.

Kārtošana pēc nosūtīšanas datuma nav risinājums. Tas ir plāksteris, kas maskē reālu problēmu, to nelabojot.

PST importa īpašais gadījums

PST failu imports ir pelnījis atsevišķu rindkopu. PST fails (Personal Storage Table) ir patentēts Microsoft formāts, kas lokāli glabā e-pastus, kontaktus un kalendārus. Importējot PST eM Client, iespējami divi scenāriji:

• Lokāls imports uz IMAP kontu: eM Client nolasa PST un izvieto ziņojumus galamērķa IMAP serverī. Ja nogādāšanas datums netiek saglabāts, INTERNALDATE tiek pārrakstīts. Šis ir biežākais gadījums, un tieši šeit datumi tiek bojāti.
• Imports lokālā mapē: ziņojumi paliek mašīnā, ārpus servera. Šajā kontekstā INTERNALDATE nepastāv, un eM Client var attēlot ziņojuma galvenes Date: vērtību. Šeit datumu problēmu ir mazāk, taču arī praktiskā noderīgums ir mazāks.

Thunderbird gadījumā situācija ir līdzīga. Ja izmantojat eM Client iebūvēto importa funkciju (kas nolasa Thunderbird profilus), vai arī kopējāt mbox mapes caur IMAP, ziņojumi tiek atkārtoti nogādāti serverī bez garantijas par INTERNALDATE saglabāšanu. Un serveris, kas saņem ziņojumu bez skaidras datuma instrukcijas par INTERNALDATE, sistemātiski uzliek saņemšanas brīža laika zīmogu.

Kuras platformas tas skar?

Problēma ir identiska neatkarīgi no galamērķa platformas, jo tā ir standarta IMAP protokola uzvedība:

• Microsoft 365 / Exchange Online: INTERNALDATE tiek pārrakstīts jebkura importa laikā, kas neizmanto IMAP APPEND komandu ar skaidru datuma parametru. Tas pats attiecas uz migrāciju no Exchange on-premise.
• Google Workspace: tāda pati uzvedība. E-pasti, importēti caur eM Client vai trešās puses rīkiem, Gmail un administrācijas saskarnē rāda importa datumu.
• Klasiskie IMAP hosti (OVH, Infomaniak, Ionos, u.c.): nav speciālas datuma apstrādes, saņemot ziņojumu APPEND. INTERNALDATE būs nogādāšanas datums.

Kāds klients sazinājās ar mums pēc tam, kad bija migrējis aptuveni simtu pastkastes no Exchange 2013 uz Microsoft 365, izmantojot eM Client kā pārejas rīku dažiem VIP kontiem. Rezultāts: pastkastes, kas tika migrētas pareizi caur MigrationWiz, bija kārtībā, bet pastkastes, kas gāja caur eM Client, visas bija ar importa datumiem. Lieki teikt, ka attiecīgie lietotāji nebija apmierināti.

Kāpēc pašrocīgs skripts to viegli neatrisinās

Tehniski kāds, kas izprot IMAP protokolu, varētu domāt par skripta rakstīšanu INTERNALDATE labošanai. Oriģinālā galvene Date: tur ir, neskarta katrā ziņojumā. Pietiktu to nolasīt un atbilstoši atjaunot servera metadatus, vai ne?

Teorētiski, jā. Praksē tas ir mīnu lauks.

Pirmkārt, malas gadījumi ražošanas pastkastē strauji uzkrājas. Digitāli parakstīti S/MIME ziņojumi ir īpaši jutīgi pret jebkādu struktūras manipulāciju. Arī PGP šifrēti ziņojumi. E-pasti ar apjomīgiem pielikumiem, nestandarta MIME robežām, vai neparastiem Content-Transfer-Encoding kodējumiem var tikt klusi bojāti, ja apstrāde nav pietiekami rūpīga. Skripts, kas darbojas uz 50 testa e-pastiem, nestrādās uzticami uz 20 000 ziņojumu pastkasti ar 6 gadu vēsturi.

Otrkārt, API kvotu pārvaldība. Microsoft 365 likmes ierobežojumi Graph API vai EWS ir jāpārvalda, labojot 8000 ziņojumu partiju pulksten 3 naktī. Taču tie neapstrādājas paši. Neuzraudzīts skripts, kas ziņojuma nr. 3741 uz kļūdu 429 Too Many Requests reaģē nepareizi, jūs, iespējams, nekad nezināsiet, kuri ziņojumi tika apstrādāti.

Un galvenais: kā pārbaudīt, ka katrs labotais e-pasts pēc apstrādes ir neskaits? Pašrocīgam skriptam parasti nav individuālas verifikācijas mehānisma. Redate.io to dara automātiski, katram ziņojumam.

Datumu labošana pašā avotā ar Redate.io

Redate.io risina problēmu tur, kur tā atrodas: servera metadatu līmenī, nevis e-pasta klienta līmenī.

Process sākas ar bezmaksas skenēšanas fāzi. Redate.io pieslēdzas attiecīgajai pastkastei (Microsoft 365 caur Azure AD, Google Workspace caur domēna deleģēšanu, vai IMAP tieši klasiskajiem hostiem) un identificē e-pastus, kuru datumu metadati neatbilst ziņojuma saturam. Jūs redzat rezultātu pirms jebkāda maksājuma.

Labošana izmanto patentētu dzinēju, kas analizē katras galvenes ķēdi katram ziņojumam, veic paraugu atbilstību pret simtiem zināmu importa rīku parakstu (tostarp eM Client, Thunderbird un PST importu specifisko uzvedību), un mērķtiecīgi rekonstruē datumu metadatus, nemainot ziņojuma saturu, pielikumus vai MIME struktūru.

Katrs labotais e-pasts tiek pārbaudīts individuāli. Oriģināli tiek glabāti redzamā dublēšanas mapē 30 dienas, ko pašrocīgs skripts nekad nedarīs pēc noklusējuma.

Cenas ir vienkāršas: vienreizējs maksājums par pastkasti, pamatojoties uz labojamo e-pastu apjomu. Nav abonēšanas, nav atkārtotu maksājumu. Skatiet sākšanas lapu, lai redzētu detaļas.

Nākamās migrācijas priekšā: kas jāpārbauda

Ja plānojat migrāciju un vēlaties izvairīties no šīs problēmas iepriekš, kontrolpunkts ir vienkāršs: vai jūsu izmantotais rīks skaidri saglabā INTERNALDATE, nogādājot ziņojumus galamērķa serverī?

PST importiem uz Microsoft 365 Microsoft sertificēti rīki (piemēram, MigrationWiz savos natīvajos režīmos, vai Exchange Online migrācijas rīks) parasti šo saglabāšanu nodrošina. Manuālajiem importiem caur eM Client vai Thunderbird tas reti ir gadījumā. Pirms importa uzsākšanas ražošanas pastkastēs pārbaudiet sava rīka dokumentāciju.

Laba e-pasta migrācijas kontrolsaraksts vienmēr ietver migrācijas pēc datumu verifikāciju uz izlases pastkastēm. Ja vēlaties uzzināt vairāk, migrācijas kontrolsaraksts šo punktu apskata sīkāk.

Administratoriem, kas regulāri pārvalda migrācijas klientiem, raksts par e-pasta datumu labošanu MSP pusē un raksts par IMAP INTERNALDATE darbību sniedz pilnīgāku problēmas priekšstatu.

Jūsu e-pastu datumi ir bojāti pēc eM Client importa? Palaidiet bezmaksas skenēšanu Redate.io, lai novērtētu problēmas apmēru pirms lēmuma pieņemšanas.