Veeam/Datto: e-pastu datumi pēc atjaunošanas

Nākamajā rītā pēc atjaunošanas ienāk pirmie ziņojumi

Jūs tikko pabeidzāt pastkastes atjaunošanu ar Veeam Backup for Microsoft 365. Darbība noritēja gludi, dati ir klāt, mapes ir neskartas. Un tad, pirmdienas rītā, lietotājs raksta: "Visiem maniem e-pastiem ir šodienas datums. Es neko nevaru atrast."

Problēma nav tā, ka e-pasti ir pazuduši. Tie ir tur. Taču to rādītais datums atbilst precīzam atjaunošanas brīdim, nevis datumam, kad tie tika nosūtīti vai saņemti. E-pasts no 2021. gada janvāra parādās kā saņemts vakardienas vakarā pulksten 23:47. Sarakstes pavediens ir sabojāts. Hronoloģija ir nelasāma.

Šī uzvedība skar Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 un AvePoint Cloud Backup, cita starpā. Katrs to dara savā veidā, bet rezultāts ir identisks.

Kas notiek tehniski

Lai saprastu, no kurienes rodas nepareizais datums, jāskatās, kā šie rīki injicē e-pastus atpakaļ Exchange Online vai Google Workspace pastkastē.

Kad rezerves kopijas rīks atjauno ziņojumu, tas nevar vienkārši "ielikt atpakaļ" e-pastu, kā pārvieto failu lokālajā diskā. Tas ieraksta jaunu ziņojuma kopiju pastkastē, izmantojot IMAP protokolu vai pakalpojuma sniedzēja API (EWS vai Microsoft Graph Microsoft pusē, Gmail API Google pusē). Un līdz ar šo kopiju tam jānorāda pastkastei, kādu datumu ziņojums nes.

Un tieši tur problēma sākas. (Starp citu, ja kādreiz esat lasījis atjaunota e-pasta neapstrādātās galvenes, visticamāk redzējāt divdesmit Received: rindiņas, pirms atradāt noderīgo saturu.)

IMAP APPEND un Received: galvene

IMAP protokolam ir komanda ar nosaukumu APPEND. Tā kalpo ziņojuma ievietošanai pastkastē. Tieši to izmanto atjaunošanas rīks: tas paņem saglabāto ziņojumu un injicē to mērķa pastkastē, izmantojot IMAP APPEND.

Šī komanda ļauj rīkam nodot datumu kopā ar ziņojumu. Ja rīks nodod ziņojuma sākotnējo datumu, pastkaste to saglabā: tā rīkojas Microsoft 365, Outlook.com un Gmail. Ja tas nenodod nekādu datumu vai nodod atjaunošanas datumu, pastkaste ziņojumu ierindo atjaunošanas dienā. Un daži veidi, kā ziņojums tiek ierakstīts atpakaļ, augšpusē pievieno vēl vienu rindu: Received: galveni, kas datēta ar kopēšanas dienu. Tieši to dara Gmail pašas importēšanas API.

Šī papildu rinda izskatās aptuveni šādi:

Received: by gmailapi.google.com
  with HTTPREST; Mon, 14 Apr 2025 23:47:12 +0000

Rezultāts: sākotnējais e-pasts ir neskarts iekšpusē, ar savu sākotnējo Date: galveni (piemēram, "3 Jan 2021 09:15:00"). Taču augšpusē ir uzlīmēta jauna Received: galvene, datēta ar atjaunošanas brīdi.

Kā Outlook un Gmail lasa datumu

E-pasta klienti, piemēram, Outlook vai Gmail tīmekļa saskarne, ne vienmēr lasa Date: galveni, lai izlemtu, kuru datumu rādīt ziņojumu sarakstā. Daudzi izmanto IMAP protokola INTERNALDATE, tas ir, datumu, kad ziņojums tika pievienots pastkastei, vai visjaunāko Received: galveni.

Outlook for Windows, jo īpaši kopš tā 2023. gada beigās veiktā atjauninājuma, ir īpaši jutīgs pret to. Kad tas redz nesenu Received: galveni ķēdes augšā, to izmanto kā attēlojuma datumu. Sākotnējā Date: galvene tiek atstumta uz ziņojuma detaļām, redzama tikai tad, ja atver e-pasta rekvizītus.

Gala lietotājs tādējādi redz ziņojumu sarakstu, kurā visi datēti ar atjaunošanas nakti. Viņam šķiet, ka trīs gadu vēsture ir sapludināta vienā naktī.

Šī problēma atšķiras no migrācijas

Jānodala šī situācija no klasiskās nepareizo datumu problēmas pēc IMAP migrācijas. Migrācijā rīks pārvieto e-pastus no servera A uz serveri B, un tas, vai katrs e-pasts saglabā savu datumu, ir atkarīgs no tā, ko rīks paziņo serverim B, to ierakstot. Mehānisms ir identisks, bet konteksts atšķiras.

Šeit runa ir par atjaunošanu no rezerves kopijas. E-pasti nekad nav atstājuši organizāciju, tie vienkārši tika drošā vietā uzglabāti (Azure Blob Storage, AWS S3, Datto ierīce...) un tad injicēti atpakaļ. Lietotājs to sagaida vēl mazāk: viņam šķiet, ka "viņa" e-pasti atgriežas, nevis ka tiek importēti jauni.

Taču tehniski mehānisms ir vienāds. Reinjekcija, kas nenes sākotnējo datumu, rada tādus pašus artefaktus. Un labojums arī seko tai pašai loģikai.

Kā katrs rīks apstrādā (vai neapstrādā) INTERNALDATE

Visi rīki neuzvedas pilnīgi vienādi, un tieši tur lietas kļūst interesantas.

Veeam Backup for Microsoft 365

Veeam izmanto EWS (Exchange Web Services) API, lai atjaunotu uz Exchange Online. EWS ļauj norādīt ziņojuma datumu, izmantojot lauku DateTimeReceived, taču šī vērtība ne vienmēr tiek atspoguļota INTERNALDATE IMAP līmenī. Rezultāts: kārtošanas datums Outlook var neatbilst sākotnējam datumam, jo īpaši ja atjaunošana notiek uz citu pastkasti nekā sākotnējā (piemēram, granulāra atjaunošana uz alternatīvu pastkasti).

Datto SaaS Protection

Datto atjauno, izmantojot Microsoft Graph API vai IMAP atkarībā no konfigurācijas. Abos gadījumos datums, ko pastkaste rāda, ir atkarīgs no tā, vai atjaunošana nodod katra ziņojuma sākotnējo datumu. MSP, kas izmanto Datto saviem klientiem, saskaras ar šo problēmu diezgan regulāri, jo īpaši pēc ransomware incidentiem, kad steidzami jāatjauno vairāki simti pastkastes vienlaikus. Tieši šajā brīdī nav laika atklāt, ka visi datumi ir nepareizi.

AvePoint un Synology Active Backup

AvePoint Cloud Backup un Synology Active Backup for Microsoft 365 izmanto līdzīgus mehānismus. AvePoint ir dokumentējis šo uzvedību savā zināšanu bāzē (ziņojums tiek atjaunots ar atjaunošanas datumu kā redzamo saņemšanas datumu), neierosinot vietēju labojumu. Synology Active Backup uzrāda to pašu problēmu, ko vēl pastiprina tas, ka atjaunošanas saskarne skaidri neatšķir "ziņojuma datumu" no "atjaunošanas datuma".

Labā ziņa: sākotnējais datums joprojām ir tur

Situāciju atgūstamu padara tas, ka sākotnējā Date: galvene nav mainīta. Tā joprojām ir klāt, neskarta, katrā atjaunotā e-pastā. Atjaunošana ir nomainījusi datumu, ko pastkaste ierakstīja, un dažreiz virsū pievienojusi Received: rindu, taču nav aiztikusi paša ziņojuma saturu.

Tā ir MIME formāta (RFC 2822) īpašība: ziņojums iekšējā struktūrā ir nemainīgs. Received: galvenes uzkrājas augšpusē kā slāņi, taču sākotnējā informācija paliek apakšā.

Tātad nē, informācija nav zudusi. Tā vienkārši ir slēpta injicēšanas artefakta dēļ.

Kāpēc atjaunošanas atkārtošana nav risinājums

Pirmā doma, kas nāk prātā: dzēst atjaunotos e-pastus un atkārtot atjaunošanu, cerot, ka šoreiz datumi būs pareizi. Tā ir sliktā ideja, un lūk, kāpēc.

Pirmkārt, atjaunošanas rīki neuzvedīsies savādāk otrajā reizē. Tas pats rīks, tie paši iestatījumi: e-pasti tiek ierakstīti atpakaļ tāpat, bez sava sākotnējā datuma. Rezultāts būs tieši tāds pats.

Otrkārt, atjaunošanas atkārtošana ražošanas pastkastēs prasa laiku, joslas platumu un rada riskus. Ja ir 50 pastkastes ar 20 000 ziņojumiem katrā, runa ir par vairāku stundu darbību, kas monopolizē API un var izraisīt Microsoft vai Google ātruma ierobežojumus (slavenais 429 Too Many Requests pulksten 2:00 naktī pakešu laikā).

Īsāk sakot. Atjaunošana darbojās. Dati ir klāt. Labojams ir datuma artefakts, nevis pati atjaunošana.

Pašrocīga labošana: konkrēti riski

Problēmas izpratne ir viena lieta. Labot to 80 000 e-pastos, nezaudējot nevienu, ir pavisam kas cits.

Python skripts, kas šķērso IMAP ziņojumus un labo datumus, var šķist izpildāms. Uz 50 testa e-pastiem tas strādās lieliski. Ražošanā ir citādi. Robežgadījumi sakrājas: S/MIME parakstīti e-pasti (galvenes modificēšana padara kriptogrāfisko parakstu nederīgu), PGP šifrēti ziņojumi, multipart struktūras ar nestandarta MIME robežām, RFC 2047 kodētas galvenes (ne-ASCII), 40 MB pielikumi, kas pārpludina skripta atmiņu. Un e-pasti ar vairākām pievienotām Received: galvenēm (ja atjaunošana tika daļēji atkārtota, kas gadās), kam nepieciešama smalkāka noteikšanas loģika.

Patiesībā galvenais risks nav skripts, kas avarē: tas ir skripts, kas darbojas bez redzamām kļūdām, bet rada bojātus ziņojumus. Sabojātus sarakstes pavedienus. Dublikātus. Atdalītus pielikumus. Ko, iespējams, atklāsiet tikai vairākas nedēļas vēlāk, kad lietotājs meklēs svarīgu e-pastu.

Un kā jūs pārbaudāt, ka katrs labotais e-pasts pēc modificēšanas tiešām ir neskarts? Mājas gatavots skripts to parasti nedara.

Ko Redate.io dara savādāk

Redate.io analizē katra e-pasta galveņu ķēdi, lai identificētu injicēšanas artefaktus, neatkarīgi no tā, vai tie nāk no Veeam atjaunošanas, BitTitan migrācijas vai manuāla importa. Redate.io izstrādātajam korekcijas dzinējam nav svarīgi, kurš rīks radījis kaitējumu: tas meklē e-pastus, kuru attēlotais datums neatbilst sākotnējam datumam, tāpēc tiek atklāts arī rīks, par kuru nekas nav dzirdēts.

Pirms jebkā labošanas Redate.io skenē visu pastkasti un uzrāda pārskatu: cik e-pastu ir ietekmēti, kāds ir nepareizais datums, kāds ir atklātais sākotnējais datums. Šis skenēšanas ir bezmaksas. Jūs redzat problēmas apmēru, pirms izlemjat rīkoties.

Katrs e-pasts tiek individuāli pārbaudīts pēc korekcijas. Oriģināļi tiek glabāti redzamā rezerves mapē jūsu pastkastē, līdz jūs paši izlemjat tos izdzēst.

Redate.io pieslēdzas ar katra lietotāja pašu Microsoft vai Google kontu, un neviens e-pasts neiziet caur starpserveriem. Korekcija notiek uz vietas, pastkastē, bez eksportēšanas vai atkārtotas importēšanas.

MSP, kas vienlaikus pārvalda vairākus ietekmētus klientus, sk. MSP veltīto lapu: Redate.io ļauj apstrādāt vairākas pastkastes paralēli no vienas saskarnes.

Citi scenāriji, kas rada to pašu artefaktu

Atjaunošana no rezerves kopijas rīka nav vienīgais gadījums. Tāds pats datuma artefakts parādās citās situācijās:

• IMAP imports no Exchange (arhivētas pastkastes, kas injicētas atpakaļ Exchange Online)
• Migrācija uz Exchange Online ar rīkiem, kas izmanto IMAP galamērķa pusē
• Granulāra atjaunošana no eksportēta un atkārtoti importēta PST (sk. rakstu par PST importu)
• Koplietojamas pastkastes, kas atjaunotas pēc incidenta (sk. koplietojamo pastkastes datumu labošanu)

Visos šajos gadījumos pamata mehānisms ir identisks: injicēšana, kas nenes sākotnējo datumu (dažreiz ar jaunu Received: galveni virsū), un e-pasta klients, kas šo jauno datumu rāda kā atsauces datumu.

E-pasti ir klāt, sākotnējais datums ir saglabāts katrā ziņojumā. Palaidiet bezmaksas skenēšanu Redate.io, lai redzētu tieši, cik e-pastu ir ietekmēti jūsu pastkastē, un tad izlemiet, vai vēlaties sākt korekciju.