Spremeniti datum e-pošte: tehnične omejitve

E-mail ima tri "datume". Ne enega.

Ko govorimo o "spremembi datuma prejetega e-pošte", si večina ljudi predstavlja, da gre za urejanje nekega polja, podobno kot bi spremenili datum ustvarjanja datoteke v Windowsih. Resničnost je nekoliko bolj zapletena. Vsak e-mail v resnici prenaša tri ločene plasti datumov, vsaka s svojimi pravili, svojimi "varuhi" in svojimi posledicami, če se jih dotaknemo.

Razumeti te tri plasti pomeni razumeti, zakaj so nekatere popravke tehnično utemeljene, druge pa so bodisi nemogoče bodisi takoj prepoznavne kot ponarejanje.

Plast 1: IMAP INTERNALDATE

INTERNALDATE je metapodatek, shranjen na strežniku, zunaj samega sporočila. Ni del vsebine e-pošte. Določi ga IMAP strežnik, in prav ta vrednost je tista, ki jo večina poštnih odjemalcev uporablja za razvrščanje sporočil v seznamu.

Outlook na primer privzeto prikazuje sporočila, razvrščena po INTERNALDATE. V določenih kontekstih enako velja za Gmail. Če je torej vaš INTERNALDATE napačen, se v vmesniku zdi, da imajo vsa vaša e-poštna sporočila enak datum, ne glede na to, kaj pravijo notranji glavi sporočila.

INTERNALDATE se nastavi v trenutku, ko je sporočilo dostavljeno na strežnik. Po protokolu IMAP ga je mogoče "spremeniti" le posredno: uporabiti je treba ukaz APPEND, ki na strežnik odloži novo kopijo sporočila z želenim datumom. Ukaz IMAP SETINTERNALDATE preprosto ne obstaja. Ta podrobnost bo čez hip dobila pomen.

Plast 2: glava Date: (RFC 2822)

To je polje Date: v surovih glavah sporočila. Poštni odjemalec ga nastavi ob pošiljanju, nato pa potuje s sporočilom od strežnika do strežnika. Gre za datum pošiljanja, ki ga je deklariral pošiljatelj.

(Mimogrede, če še niste nikoli pogledali surovih glav e-pošte, je to precej nenavadno branje. Vsako sporočilo vleče za sabo kakih dvajset tehničnih vrstic, ki jih 99 % ljudi ni nikoli videlo.)

Tehnično nič ne preprečuje, da bi poslali e-mail s poljem Date:, nastavljenim v preteklost ali prihodnost. SMTP strežniki tega polja ne preverjajo. Toda prejemni strežniki si zabeležijo dejansko uro prihoda v glave Received:, kar takoj ustvari neskladnost, ki jo zazna vsak poštni odjemalec ali orodje za analizo.

Plast 3: zložene glave Received:

Vsakič, ko SMTP strežnik posreduje sporočilo, doda glavo Received: na vrh sklada, skupaj s časovnim žigom. E-mail, ki je šel skozi tri strežnike, bo imel tri glave Received:. Berejo se od spodaj navzgor: najstarejša je spodaj, najnovejša je zgoraj.

Prav tu migracijska orodja povzročijo težavo. Ko BitTitan MigrationWiz, CloudM, imapsync ali GSMMO migrirajo e-mail, ga znova vstavijo na novi strežnik prek IMAP. Ta dostava ustvari nov vnos Received: s časovnim žigom, nastavljenim na trenutek migracije. Rezultat: najstarejše sporočilo v vašem nabiralniku, e-mail iz leta 2019, ima naenkrat Received: z datumom november 2024. In ker nekateri poštni odjemalci (Outlook na prvem mestu) za prikaz datuma uporabljajo najnovejši Received:...

Zdaj je problem jasen. 15.000 e-poštnih sporočil prikazuje enak datum migracije.

Ali je te datume mogoče resnično "spremeniti"?

Tehnično da, kar zadeva INTERNALDATE (z določenimi omejitvami). Tehnično izvedljivo, a brez pravega učinka za Date:. In pri Received: se je vredno zaustaviti.

Prepisati glavo Received: je preprosto. In takoj zaznavno.

Glava Received: je le ena vrstica besedila v sporočilu. Uredite jo lahko kot katerokoli besedilno datoteko. Točno tako preprosto, kot se zdi.

A potem se zgodi naslednje.

Prva težava: DKIM. Podpis DKIM (DomainKeys Identified Mail) se izračuna na podlagi nabora glav sporočila, med katerimi so včasih tudi Received:. Sprememba podpisane glave razveljavi podpis. Vsak prejemni strežnik, ki preverja DKIM, bo takoj videl, da je bilo sporočilo spremenjeno. To ni subtilno ponarejanje, to je alarm.

Druga težava: interni identifikatorji. Sodobni poštni strežniki (Google Workspace, Microsoft 365) vsakemu sporočilu dodelijo naraščajoč in edinstven interni identifikator. Ti identifikatorji so vezani na INTERNALDATE in vrstni red sprejema. Sprememba Received: brez usklajenosti s temi identifikatorji ustvari neskladnosti, ki jih revizijska orodja zaznajo brez težav.

Tretja težava, bolj praktična: tudi če spremenite Received: v vsebini sporočila, se INTERNALDATE ni spremenil. Ostane tak, kakršen je bil ob dostavi prek IMAP. Poštni odjemalec bo za razvrščanje še vedno prikazoval napačen datum. Spremenili ste sporočilo zastonj.

Skratka. Prepisati Received: z namenom ponarejanja datuma e-pošte v zlonamerne namene: tehnično trivialično, zaznavno v nekaj sekundah s strani strokovnjaka. To ni resna pot.

Glava Date:: spremeniti preteklost na papirju

Enako velja za Date:. Spremenite jo lahko v telesu sporočila. Toda glave Received:, ki so jih overili vmesni strežniki, ostanejo nedotaknjene in pripovedujejo drugačno zgodbo. Časovna veriga je neskladna. Vsak analitik ali sodišče, ki bi primerjalo ta polja, bi to takoj opazilo.

Da bom natančen: to ne prepreči, da bi nekateri poštni odjemalci prikazali spremenjen Date:, če jim datoteko .eml podamo neposredno. Toda v kontekstu živega poštnega strežnika z avtentikacijo in dnevniki je sprememba popolnoma transparentna.

IMAP migracija: edini kontekst, kjer je popravek datumov upravičen

Obstaja en in samo en primer, ko je sprememba datuma prejetega e-pošte ne le mogoča, ampak tudi tehnično utemeljena: popravek škode, ki jo povzroči slabo upravljana IMAP migracija.

Konkretna situacija. Pravkar ste preselili 80 poštnih nabiralnikov Exchange v Microsoft 365. Migracija se je zaključila v petek zvečer. V ponedeljek zjutraj prihajajo prve zahteve za pomoč: "Vsi moji e-maili imajo enak datum", "Sporočila iz lanskega leta ne morem najti", "Moja korespondenca s to stranko je popolnoma pokvarjena". Imate 80 blokiranih uporabnikov in nadrejenega, ki čaka odgovor.

V tem kontekstu je problem dokumentiran, prepoznaven in vzrok jasen: orodje za migracijo je dodalo Received: z datumom dneva migracije, nekateri poštni odjemalci pa ta novi glavo uporabljajo kot datum prikaza. Izvirna glava Date: je v vsakem sporočilu nedotaknjena. Nikoli ni bila spremenjena. Vsebuje prvotni datum pošiljanja, pravilnega.

Popravek torej ni ponarejanje: to je obnovitev. Izhajamo iz resničnih podatkov (izvirni Date:), da bi rekonstruirali usklajena metapodatka. To se bistveno razlikuje od poskusa, da bi e-mail iz leta 2024 prikazali kot sporočilo iz leta 2019.

Za podrobnosti o mehanizmih posameznih orodij ti vodiči obravnavajo konkretne primere: popravek datumov BitTitan v Microsoft 365, popravek datumov CloudM v Outlooku, ali popravek datumov imapsync v Google Workspace.

Zakaj pisati lastni skript ni dobra ideja

Osnovna logika je dostopna. Vsak skrbnik IT, ki je preživel nekaj časa na forumih o IMAP, si zna sestaviti splošen pristop. To ni problem.

Problem je razlika med skriptom, ki deluje na 50 testnih sporočilih, in skriptom, ki obdela 40.000 sporočil v produkciji brez izgube enega samega e-maila, brez poškodbe ene same priponke in brez zlomitve ene same konverzacije.

Nekateri konkretni primeri, ki jih domači skripti navadno ne obvladajo:

• S/MIME podpisani e-maili: podpis pokriva vsebino in glave. Vsaka sprememba strukture sporočila razveljavi podpis. E-mail, ki je bil nerodno popravljen, prispe k prejemnikom z opozorilom "neveljaven podpis".
• PGP šifrirana sporočila: ista vrsta težav, s potencialno hujšimi posledicami, odvisno od implementacije.
• Ne-ASCII kodiranje v glavah: RFC 2047 opisuje kodiranje posebnih znakov v glavah. Skript, ki manipulira glave brez upoštevanja teh primerov, bo tiho pokvaril zadeve e-mailov z akcenti, japonskimi znaki ali arabskimi imeni.
• API omejitve hitrosti: Google Workspace in Microsoft 365 uveljavljata agresivno omejevanje zahtev. Ob 3. uri zjutraj paket 10.000 e-mailov, ki naleti na napako 429 Too Many Requests brez upravljanja eksponencialnega odloga, pusti pol nabiralnikov le delno popravljenih.
• Pokvarjene MIME meje: večdelna sporočila s priponkami imajo natančne MIME meje. Njihova nepravilna regeneracija naredi priponke neberljive.

In vprašanje, ki ga noben domači skript ne reši: kako preveriti, da je vsak popravljeni e-mail nedotaknjen? Skript, ki spremeni 40.000 sporočil brez posamičnega preverjanja, je stava. Stava na podatke, ki jih vaši uporabniki pogosto štejejo za nenadomestljive.

Članek o možnostih za popravek datumov po selitvi obravnava različne pristope, vključno z njihovimi omejitvami.

Kaj počne Redate.io v tem kontekstu

Redate.io je zasnovan natančno za ta primer: popravek datumov, pokvarjenih z IMAP migracijo, v velikem obsegu, brez tveganja za celovitost sporočil.

Storitev se neposredno poveže z zadevnimi nabiralniki (Google Workspace prek delegacije domene, Microsoft 365 prek Azure AD ali neposrednega IMAP), brezplačno pregleda sporočila z napačnimi datumi, nato pa s pomočjo lastnega mehanizma za popravke obdela dokumentirane robne primere iz tega članka. Vsak e-mail se po popravku posamično preveri. Izvirniki ostanejo v vidni varnostni mapi 30 dni.

Prepoznavanje vzorcev pokriva stotine podpisov znanih migracijskih orodij: BitTitan MigrationWiz, CloudM, imapsync, GSMMO in njihove različice. Zaznava je natančna: Redate.io se ne dotakne sporočil, katerih datum je pravilen.

Cenovni model je preprost: enkratno plačilo na poštni nabiralnik, brez naročnine. Diagnostično skeniranje je brezplačno, kar vam omogoča, da ocenite obseg škode, preden se odločite za karkoli.

Če upravljate nablirnike, prizadete s to težavo, ta članek o napačnih datumih v Outlooku po selitvi podrobno opisuje najpogostejše simptome in kako jih ločiti od drugih vzrokov.

Pripravljeni oceniti obseg težave na svojih nabiralnikih? Zaženite brezplačno skeniranje na Redate.io in preverite točno, koliko e-mailov je prizadetih, preden karkoli popravite.