Vai var mainīt saņemtā e-pasta datumu?

Jautājums, ko uzdod visi (un kāpēc aiz tā slēpjas divas pilnīgi atšķirīgas situācijas)

Ierakstiet "mainīt saņemtā e-pasta datumu" meklētājā. Uzreiz parādās desmitiem Microsoft Q&A forumu pavedienu, Reddit diskusiju, Quora jautājumu. Pieprasījums ir skaidrs, taču iemesli aiz tā ir kardināli atšķirīgi atkarībā no tā, kurš jautā.

Ir tādi, kuri vēlas viltot datumu, retrospektīvi, ar nolūkiem, par kuriem labāk nedomāt. Un ir IT administratori, kuri pēc IMAP migrācijas redz, ka visi e-pasti rāda vienu un to pašu dienu (migrācijas dienu), un viņi vienkārši grib atgūt īstos datumus. Šīm divām situācijām nav nekā kopīga, taču tām ir viens un tas pats meklēšanas formulējums.

Šis raksts atbild uz abiem jautājumiem. Sabojātā ziņa: pirmajā gadījumā nemanāma modificēšana nav īsti iespējama. Otrajā tā ir pilnīgi leģitīma, un tieši to dara Redate.io.

Vispirms: kas ir e-pasta "datums"?

E-pastā nav tikai viens datums. Tajā ir vairāki, glabāti dažādās vietās, ko kontrolē dažādas puses.

Galvene Date: (RFC 2822)

Šis ir datums, ko sūtītāja e-pasta klients ieraksta ziņojumā sūtīšanas brīdī. Neapstrādātajās galvenēs tas ir redzams šādā formā:

Date: Mon, 14 Oct 2024 09:32:11 +0200

Šī galvene ir ziņojuma daļa. To var tehniski mainīt, ja piekļūstat neapstrādātajai datnei. Bet "tehniski" šeit ir atslēgvārds.

Galvenes Received:

Katrs pasta serveris, caur kuru iziet e-pasts, pievieno savu Received: galveni ar laika zīmogu. Šīs galvenes veido hronoloģisku ķēdi no sūtītāja servera līdz jūsu pastkastei. (Starp citu, ja esat kādreiz mēģinājuši lasīt e-pasta neapstrādātās galvenes, zināt, ka tas nav tieši pludmales lasāmviela. Vairāki desmiti rindu tehnisku metadatu, secībā no jaunākā uz vecāko.)

IMAP INTERNALDATE

Tas ir svarīgākais metadatu elements, lai saprastu, kāpēc dažas izmaiņas neatstāj nekādu redzamu ietekmi. INTERNALDATE ir atribūts, kas glabājas IMAP servera pusē, neatkarīgi no ziņojuma satura. Tieši to lielākā daļa e-pasta klientu izmanto, lai kārtotu e-pastus mapēs. Outlook to izmanto. Gmail arī. Apple Mail lielākajā daļā gadījumu - tikpat.

INTERNALDATE nav ziņojumā. Tas atrodas servera datu bāzē. To nevar mainīt, rediģējot .eml datni savā diskā.

Kas patiesībā notiek, kad veicat lokālas izmaiņas

Rediģēt .eml datni

Tehniski .eml datne ir teksta fails. Varat to atvērt redaktorā, mainīt rindu Date:, saglabāt. Ja šo datni atkārtoti importējat lokālajā e-pasta klientā, rādītais datums var mainīties, atkarībā no klienta.

Bet lūk, kas nemainās:

• INTERNALDATE uz IMAP servera (vienmēr neskartas)
• Starpserveru pievienotās Received: galvenes
• Piegādes žurnāli pie Google, Microsoft vai jūsu pakalpojumu sniedzēja
• DKIM paraksts, ja ziņojumam tāds bija

Rezultāts: jūsu lokālajā datorā iespējams redzat citu datumu. Bet Outlook, kas savienots ar Exchange Online, vai Gmail pārlūkā, nekas nav mainījies.

Mainīt sistēmas pulksteni

Daži forumi iesaka mainīt darbstacijas pulksteni, lai "apmānītu" e-pasta klientu. Tas nedarbojas. Outlook un Gmail nelasa sistēmas laiku, lai attēlotu saņemto e-pastu datumus. Tie lasa INTERNALDATE no servera vai ziņojuma galvenes. Lokālais pulkstenis šajā procesā neiesaistās nekur.

Thunderbird manipulācija

Thunderbird piedāvā lielāku elastību nekā vairums klientu. Ar paplašinājumiem vai tieši manipulējot ar profilu (mbox datnes, .msf datnes), daži mēģina mainīt datumu attēlošanu. Tas var darboties pašā Thunderbird, lokāli glabātiem e-pastiem POP3 režīmā. Bet tiklīdz Thunderbird ir savienots ar IMAP, tas resinhronizējas ar serveri. "Labojums" pazūd nākamās sinhronizācijas laikā.

DKIM: neredzamais šķērslis, ko neviens nepiemin

Lielākā daļa e-pastu, kas nosūtīti kopš 2018. gada, ir parakstīti ar DKIM (DomainKeys Identified Mail). DKIM paraksts galvenēs izskatās šādi:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

Lauks h= uzskaita parakstā iekļautās galvenes. Iepriekš minētajā piemērā Date ir parakstīts. Ja mainīsiet ziņojuma Date: galveni, DKIM pārbaude neizdosies. Jebkurš pasta serveris, jebkurš kriminālistikas analīzes rīks, var noteikt izmaiņas, pārrēķinot parakstu.

Tā nav ideāla aizsardzība (ļaunprātīgs sūtītājs kontrolē savu DKIM atslēgu un var parakstīt ko vēlas sūtīšanas brīdī). Bet jau saņemtam un parakstītam e-pastam, mainoties Date: galvenei, paliek atklājamas pēdas.

Serveru žurnāli: patiesais patiesuma avots

Pat ja izdotos mainīt visus redzamos e-pasta metadatus (galvenes, INTERNALDATE, visu), pakalpojumu sniedzēji glabā savus žurnālus.

Google Workspace reģistrē katru ziņojumu Admin Console audita žurnālos. Microsoft 365 dara to pašu atbilstības centrā (Purview). Šajos žurnālos ir iekļauti piegādes laika zīmogi, neatkarīgi no tā, kas tiek attēlots klientos. Jurists, juridiskā nodaļa vai IT drošības komanda var izgūt šos datus. Datums, kas redzams Outlook, nav pierādījums tiesā vai drošības audita laikā.

Precizitātes labad: pat administrators ar piekļuvi pastkastei, izmantojot domēna delegēšanu, nevar retrospektīvi pārrakstīt šos žurnālus. Tie ir ārpus jebkura lietotāja sasniedzamības, pat priviliģētu.

Leģitīmais gadījums: labošana pēc migrācijas

Tikko esat pabeidzis 150 pastkastes migrāciju no lokālā Exchange uz Microsoft 365. Nākamajā pirmdienā sāk nākt pieteikumi: "visi mani vecie e-pasti datēti ar pagājušo piektdienu". Migrācijas dienu.

Tā ir labi dokumentēta problēma, kas pilnīgi atšķiras no tikko aprakstītā. Šeit neviens negrib neko viltot. Īstie oriģinālie datumi joprojām pastāv, neskarti, katra ziņojuma Date: galvenē. Problēma ir citur: migrācijas rīks (BitTitan MigrationWiz, CloudM, imapsync vai cits) ir ievietojis Received: galveni ar migrācijas datumu ķēdes sākumā. Outlook, kas noteiktos kontekstos paļaujas uz jaunākajām Received: galvenēm, nevis INTERNALDATE, attēlo šo datumu tā vietā.

Šajā gadījumā "labošana" nozīmē konsekvences atjaunošanu starp to, ko ziņojums saka (oriģinālā Date: galvene, joprojām klāt), un to, ko serveris uzskata (INTERNALDATE, kas fiksēts migrācijas brīdī). Tas nav viltošana. Tas ir atjaunošana.

Tieši šādu problēmu rada nepareizi konfigurēta migrācija tūkstošiem pastkasču. Un tieši to Redate.io atrisina.

Kāpēc "dari pats" metode izgāžas liela mēroga gadījumos

Saprast problēmu ir viena lieta. Izlabot 40 000 e-pastus 150 pastkastēs, nezaudējot nevienu, ir pavisam cita.

GitHub vai Stack Overflow atrastie skripti darbojas uz 20 testa e-pastiem. Ražošanas vidē tie saskaras ar problēmām, ko skripta autors nebija paredzējis:

• S/MIME parakstīti vai PGP šifrēti e-pasti ir ar struktūrām, ko nevar manipulēt kā parastus ziņojumus
• Multipart ziņojumi ar nestandarta MIME robežām izraisa parsēšanas kļūdas
• RFC 2047 kodētas galvenes (ne-ASCII rakstzīmes From: vai Subject: laukos) sabojā vienkāršus parsētājus
• Google un Microsoft API uzliek pieprasījumu limitus: pulksten 3 naktī, apstrādājot 30 000 e-pastu paketi, kļūda 429 Too Many Requests netiek apstrādāta, skripts apstājas, un neviens nezina, kur tas apstājās
• Nav atcelšanas mehānisma: ja ziņojums tiek bojāts apstrādes laikā, nav iespējas atgriezties atpakaļ

Redate.io saglabā katra oriģinālā e-pasta kopiju redzamā rezerves kopiju mapē 30 dienas. Katrs labojums tiek pārbaudīts atsevišķi. Analīzes cauruļvads apstrādā simtiem zināmo migrācijas rīku parakstu, kā arī visus robežgadījumus, ko mājas skripts nespētu apstrādāt.

Lai uzzinātu vairāk par konkrētiem rīkiem: BitTitan MigrationWiz un e-pastu datumi, vai CloudM Migrate: nepareizu datumu labošana.

Kas mainās, kas nekad nemainās

Atšķirība ir skaidra. Pirmās trīs tabulas rindas apraksta virspusējas vai atklājamas izmaiņas. Pēdējā apraksta leģitīmu metadatu labošanu, kas saskanēta ar ziņojuma oriģinālo saturu, pēc migrācijas, kas ieviesa nekonsekvenci.

Ja atrodaties situācijā, kas aprakstīta tabulas apakšā, pēc migrācijas ar imapsync, BitTitan, CloudM vai citu rīku, Redate.io ir paredzēts tieši tam.

Jūsu e-pasti rāda migrācijas datumu īsto datumu vietā? Bezmaksas skenējiet savas pastkastes ar Redate.io un uzziniet precīzi, cik e-pastu ir skarts, pirms pieņemat lēmumu.