E-pasta datuma maiņa: tehniskie ierobežojumi

E-pastam ir trīs "datumi". Ne viens.

Runājot par e-pasta saņemšanas datuma maiņu, lielākā daļa cilvēku iedomājas, ka jāmaina kāds lauks, tāpat kā mainot faila izveides datumu Windows vidē. Patiesībā tas ir sarežģītāk. Katrs e-pasts glabā trīs atsevišķus datuma slāņus, katram ar saviem noteikumiem, saviem "sargiem" un savām sekām, ja tajā iejaucas.

Izprast šos trīs slāņus nozīmē saprast, kāpēc dažas korekcijas ir tehniski pamatotas, bet citas ir vai nu neiespējamas, vai uzreiz atpazīstamas kā viltojums.

1. slānis: IMAP INTERNALDATE

INTERNALDATE ir metadati, kas glabājas servera pusē, ārpus paša ziņojuma satura. Tā nav e-pasta daļa. To nosaka IMAP serveris, un tieši to lielākā daļa e-pasta klientu izmanto, lai kārtotu ziņojumu sarakstu.

Outlook, piemēram, pēc noklusējuma rāda ziņojumus, kārtotus pēc INTERNALDATE. Gmail arī dažos gadījumos. Tādēļ, ja INTERNALDATE ir nepareizs, visi e-pasti saskarnē izskatās ar vienādu datumu, neatkarīgi no tā, ko saka iekšējās ziņojuma galvenes.

INTERNALDATE tiek noteikts brīdī, kad ziņojums nonāk serverī. Izmantojot IMAP protokolu, vienīgais veids, kā to "mainīt", ir netiešs: jāizmanto komanda APPEND, lai ievietotu jaunu ziņojuma kopiju ar vēlamo datumu. Komanda SETINTERNALDATE IMAP protokolā vienkārši nepastāv. Šī nianse būs svarīga nedaudz vēlāk.

2. slānis: galvene Date: (RFC 2822)

Tas ir lauks Date: ziņojuma neapstrādātajās galvenēs. To nosaka e-pasta klients nosūtīšanas brīdī, un tas ceļo kopā ar ziņojumu no servera uz serveri. Tas ir nosūtītāja deklarētais nosūtīšanas datums.

(Starp citu, ja jūs nekad neesat skatījies e-pasta neapstrādātās galvenes, tas ir diezgan pārsteidzošs lasījums. Katrs ziņojums satur apmēram divdesmit tehniskas rindiņas, kuras 99 % cilvēku nekad nav redzējuši.)

Tehniski nekas neliedz nosūtīt e-pastu ar antidatētu vai postdatētu lauku Date:. SMTP serveri šo lauku nepārbauda. Taču saņēmēja serveri reģistrē faktisko ierašanās laiku galvenēs Received:, kas uzreiz rada neatbilstību, ko var pamanīt jebkurš e-pasta klients vai analīzes rīks.

3. slānis: uzkrātās galvenes Received:

Katru reizi, kad SMTP serveris pārsūta ziņojumu, tas augšā pievieno jaunu galveni Received: ar laikspiedolu. E-pasts, kas izgājis caur trim serveriem, iegūst trīs Received: galvenes. Tās lasa no apakšas uz augšu: vecākā ir apakšā, jaunākā augšā.

Tieši tur migrācijas rīki rada problēmu. Kad BitTitan MigrationWiz, CloudM, imapsync vai GSMMO migrē e-pastu, tie to atkārtoti ievieto jaunajā serverī caur IMAP. Šī ievietošana rada jaunu Received: ierakstu ar migrācijas dienas laikspiedolu. Rezultāts: jūsu pastkastes vecākais e-pasts, teiksim, no 2019. gada, iegūst Received: ar novembra 2024. gada datumu. Un tā kā daži e-pasta klienti (Outlook pirmkārt) izmanto jaunāko Received: kā parādāmo datumu...

Lūk, problēma. 15 000 e-pasti visi rāda vienu un to pašu migrācijas datumu.

Vai šos datumus var tiešām "mainīt"?

Tehniski jā INTERNALDATE gadījumā (ar ierobežojumiem). Tehniski iespējams, bet bezjēdzīgi Date: gadījumā. Un attiecībā uz Received: galvenēm, tas ir vērts apskatīt tuvāk.

Received: galvenes pārrakstīšana ir vienkārša. Un uzreiz atklājama.

Galvene Received: ir tikai teksta rindiņa ziņojumā. To var rediģēt kā jebkuru teksta failu. Tas ir tieši tik vienkārši, cik šķiet.

Bet lūk, kas notiek tālāk.

Pirmā problēma: DKIM. DKIM paraksts (DomainKeys Identified Mail) tiek aprēķināts uz ziņojuma galvenu kopas, dažreiz ieskaitot Received: galvenes. Parakstītas galvenes modificēšana padara parakstu par nederīgu. Jebkurš saņēmēja serveris, kas pārbauda DKIM, uzreiz redzēs, ka ziņojums ir mainīts. Tas nav smalkls viltojums, tas ir trauksmes signāls.

Otrā problēma: iekšējie identifikatori. Mūsdienu e-pasta serveri (Google Workspace, Microsoft 365) katram ziņojumam piešķir unikālu, augošu iekšējo identifikatoru. Šie identifikatori ir saistīti ar INTERNALDATE un saņemšanas secību. Received: galvenes mainīšana bez saskaņotības ar šiem identifikatoriem rada neatbilstības, kuras audita rīki konstatē bez grūtībām.

Trešā problēma, vairāk praktiska: pat ja jūs maināt Received: ziņojuma saturā, INTERNALDATE paliek nemainīts, jo tas tika iestatīts IMAP ievietošanas brīdī. E-pasta klients turpina rādīt nepareizo datumu kārtošanai. Ziņojumu mainījāt velti.

Citiem vārdiem: Received: galvenu pārrakstīšana, lai ļaunprātīgos nolūkos viltotu e-pasta datumu, ir tehniski vienkārša un eksperta acīs atklājama dažu sekunžu laikā. Tā nav nopietna pieeja.

Galvene Date:: mainīt pagātni uz papīra

Tāds pats spriedums attiecas uz Date:. To var mainīt ziņojuma saturā. Taču Received: galvenes, ko autentificēja starpposma serveri, paliek neskartas un stāsta citu stāstu. Laika ķēde ir nekonsekventa. Jebkurš analītiķis vai tiesa, kas salīdzina šos laukus, to uzreiz pamanīs.

Precīzāk sakot, tas netraucē dažiem e-pasta klientiem rādīt mainīto Date:, ja tiem tieši uzrāda .eml failu. Taču aktīva e-pasta servera kontekstā, ar autentifikāciju un žurnāliem, izmaiņa ir caurspīdīga.

IMAP migrācija: vienīgais konteksts, kur datumu labošana ir pamatota

Ir viens, un tikai viens gadījums, kad e-pasta saņemšanas datuma maiņa nav tikai iespējama, bet tehniski pamatota: nepareizi pārvaldītas IMAP migrācijas radīto bojājumu labošana.

Lūk konkrēta situācija. Jūs tikko migrējāt 80 Exchange pastkastes uz Microsoft 365. Migrācija beidzās piektdienas vakarā. Pirmdienas rītā sāk ienākt pirmie pieteikumi: "Visiem maniem e-pastiem ir viens un tas pats datums", "Nevaru atrast pagājušā gada e-pastu", "Mana saziņas vēsture ar šo klientu ir pilnīgi sabojāta". Jums ir 80 nobloķēti lietotāji un priekšnieks, kas gaida atbildi.

Šajā kontekstā problēma ir dokumentēta, identificējama un tās cēlonis ir skaidrs: migrācijas rīks pievienoja Received: galveni ar migrācijas dienas datumu, un daži e-pasta klienti izmanto šo jauno galveni kā parādāmo datumu. Oriģinālā Date: galvene, savukārt, katrā ziņojumā ir neskarata. Tā nekad netika mainīta. Tajā joprojām ir pareizais, oriģinālais nosūtīšanas datums.

Tādēļ labošana nav viltošana: tā ir atjaunošana. Tiek izmantoti patiesie dati (oriģinālais Date:), lai atjaunotu saskaņotus metadatus. Tas ir būtiski atšķirīgs no mēģinājuma padarīt 2024. gada e-pastu par 2019. gada e-pastu.

Lai uzzinātu vairāk par konkrētiem rīku mehānismiem, šie ceļveži apraksta konkrētus gadījumus: BitTitan datumu labošana Microsoft 365, CloudM datumu labošana Outlook vai imapsync datumu labošana Google Workspace.

Kāpēc rakstīt skriptu pašam ir riskanti

Pamata loģika ir pieejama. Jebkurš IT administrators, kurš pavadījis laiku IMAP forumos, var rekonstruēt vispārīgo pieeju. Tas nav problēma.

Problēma ir plaisa starp skriptu, kas darbojas uz 50 testa e-pastiem, un skriptu, kas apstrādā 40 000 ziņojumu ražošanas vidē bez neviena zaudēta e-pasta, bez neviena bojāta pielikuma un bez neviena salauztā sarakstes pavediena.

Daži konkrēti gadījumi, ar kuriem mājas skripsmi parasti netiek galā:

• S/MIME parakstīti e-pasti: paraksts aptver saturu un galvenes. Jebkura ziņojuma struktūras izmaiņa padara parakstu par nederīgu. Neveikli labots parakstīts e-pasts saņēmējiem nonāk kā "nederīgs paraksts".
• PGP šifrēti ziņojumi: līdzīga problēmu klase, ar potenciāli sliktākām sekām atkarībā no ieviešanas.
• Ne-ASCII kodējumi galvenēs: RFC 2047 apraksta speciālo rakstzīmju kodēšanu galvenēs. Skripts, kas manipulē galvenes bez šo gadījumu apstrādes, klusi sabojās e-pastu tēmas ar akcentiem, japāņu rakstzīmēm vai arābu vārdiem.
• API pieprasījumu ātruma ierobežojumi: Google Workspace un Microsoft 365 izmanto agresīvu throttling. Pulksten 3 naktī 10 000 e-pastu partija, kas uzdustas pret kļūdu 429 Too Many Requests bez eksponenciālas atkāpšanās apstrādes, atstāj pusi pastkastju pusēm labotu.
• Bojātas MIME robežas: multipart ziņojumiem ar pielikumiem ir precīzas MIME robežas. To nepareiza atkārtota ģenerēšana padara pielikumus nelasāmus.

Un jautājums, ko neviens mājas skripts neatrisina: kā pārbaudīt, ka katrs labotais e-pasts ir neskarats? Skripts, kas maina 40 000 ziņojumus bez individuālas pārbaudes, ir azartspēle. Azartspēle ar datiem, kurus jūsu lietotāji bieži uzskata par neaizstājamiem.

Raksts par e-pastu datumu labošanas iespējām pēc migrācijas apskata dažādas pieejas, ieskaitot to attiecīgos ierobežojumus.

Ko Redate.io dara šajā kontekstā

Redate.io ir izstrādāts tieši šim gadījumam: labot IMAP migrācijas sabojātos datumus lielā apjomā, neapdraudot ziņojumu integritāti.

Pakalpojums tieši savienojas ar attiecīgajām pastkastēm (Google Workspace caur domēna delegāciju, Microsoft 365 caur Azure AD vai tieši caur IMAP), bez maksas skenē ziņojumus ar nepareiziem datumiem, pēc tam piemēro patentētu labošanas konveijeru, kas apstrādā iepriekš aprakstītos robežgadījumus. Katrs e-pasts tiek individuāli pārbaudīts pēc labošanas. Oriģināļi paliek redzamā dublēšanas mapē 30 dienas.

Modeļu saskaņošana aptver simtiem zināmo migrācijas rīku parakstus: BitTitan MigrationWiz, CloudM, imapsync, GSMMO un to variantus. Noteikšana ir precīza: Redate.io nepieskaras e-pastiem ar pareiziem datumiem.

Cenu modelis ir vienkāršs: vienreizējs maksājums par katru pastkasti, bez abonēšanas. Diagnostikas skenēšana ir bezmaksas, kas ļauj novērtēt bojājuma apjomu pirms jebkāda lēmuma pieņemšanas.

Ja jūs pārvaldāt pastkastes, kuras skar šī problēma, šis raksts par nepareiziem datumiem Outlook pēc migrācijas detalizēti apraksta biežākos simptomus un to atšķiršanu no citiem cēloņiem.

Gatavs novērtēt problēmas apjomu savās pastkastēs? Palaidiet bezmaksas skenēšanu Redate.io un redziet precīzi, cik daudz e-pastu ir ietekmēti pirms jebkādas labošanas.