Veeam/Datto: e-mails gedateerd op herstelmoment, niet op verzending

De dag na het herstel beginnen de tickets

U hebt zojuist een mailboxherstel afgerond via Veeam Backup for Microsoft 365. De operatie is goed verlopen, de gegevens zijn aanwezig, de mappen zijn intact. En dan, maandagochtend, schrijft een gebruiker: "Al mijn e-mails hebben de datum van vandaag. Ik vind niets meer terug."

Het probleem is niet dat de e-mails verdwenen zijn. Ze zijn er gewoon. Maar hun weergegeven datum komt overeen met het exacte tijdstip van de hersteloperatie, niet met de datum waarop ze werden verzonden of ontvangen. Een e-mail uit januari 2021 verschijnt als gisterenavond om 23:47 ontvangen. De gespreksthread is kapot. De chronologie is onleesbaar.

Dit gedrag treft Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365, en AvePoint Cloud Backup, onder andere. Elk op zijn eigen manier, maar het resultaat is identiek.

Wat er technisch gebeurt

Om te begrijpen waar de verkeerde datum vandaan komt, moet u kijken naar hoe deze tools e-mails terugplaatsen in een Exchange Online- of Google Workspace-mailbox.

Wanneer een backuptool een bericht herstelt, kan het de e-mail niet simpelweg "terugzetten" zoals u een bestand op een lokale schijf zou verplaatsen. Het schrijft een nieuwe kopie van het bericht naar de mailbox, via IMAP of via de API van de provider (EWS of Microsoft Graph bij Microsoft, de Gmail API bij Google). En bij die kopie moet het aangeven welke datum het bericht draagt.

En daar begint het probleem. (Als u trouwens al eens de ruwe headers van een hersteld e-mailbericht hebt bekeken, hebt u waarschijnlijk een twintigtal Received:-regels zien voorbijscrollen voordat u de eigenlijke inhoud vond.)

IMAP APPEND en de Received:-header

Het IMAP-protocol beschikt over een commando genaamd APPEND. Het dient om een bericht in een mailbox in te voegen. Dit is precies wat een hersteltool gebruikt: het neemt het opgeslagen bericht en injecteert dit in de doelmailbox via IMAP APPEND.

Met dit commando kan het gereedschap een datum meegeven aan het bericht. Geeft het gereedschap de oorspronkelijke datum van het bericht mee, dan behoudt de mailbox die datum: dat geldt voor Microsoft 365, Outlook.com en Gmail. Geeft het gereedschap geen datum mee, of de datum van het herstel, dan plaatst de mailbox de e-mail onder de dag van het herstel. Sommige manieren om een bericht terug te schrijven voegen bovendien een extra regel toe boven het bericht: een Received:-header met de datum van de kopie. De eigen import-API van Gmail doet precies dat.

Deze extra regel ziet er ongeveer zo uit:

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

Resultaat: de originele e-mail is intact van binnen, met zijn oorspronkelijke Date:-header (zeg "3 Jan 2021 09:15:00"). Maar een nieuwe Received:-header is er bovenop geplakt, gedateerd op het moment van het herstel.

Hoe Outlook en Gmail de datum lezen

E-mailclients zoals Outlook of de webinterface van Gmail lezen niet altijd de Date:-header om te bepalen welke datum in de berichtenlijst wordt weergegeven. Veel clients gebruiken de INTERNALDATE van het IMAP-protocol, dat wil zeggen de datum waarop het bericht aan de mailbox werd toegevoegd, of de meest recente Received:-header.

Outlook voor Windows, met name sinds de update van eind 2023, is hier bijzonder gevoelig voor. Wanneer het een recente Received:-header bovenaan de keten ziet, gebruikt het die als weergavedatum. De originele Date: wordt teruggedrongen naar de berichtdetails, alleen zichtbaar als u de e-maileigenschappen opent.

De eindgebruiker ziet dus een lijst met berichten die allemaal zijn gedateerd op de nacht van het herstel. Voor hem is zijn driejarige geschiedenis samengevallen tot één enkele nacht.

Dit probleem verschilt van een migratie

Er moet een onderscheid worden gemaakt met het klassieke probleem van verkeerde datums na een IMAP-migratie. Bij een migratie verplaatst het gereedschap e-mails van server A naar server B, en of elke e-mail zijn datum behoudt, hangt af van wat het gereedschap aan server B doorgeeft bij het schrijven. Het is hetzelfde mechanisme, maar de context is anders.

Hier gaat het om een herstel vanuit een back-up. De e-mails hebben de organisatie nooit verlaten, ze zijn gewoon ergens veilig bewaard (Azure Blob Storage, AWS S3, Datto-appliance...) en daarna opnieuw ingevoegd. De gebruiker verwacht dit des te minder: voor hem komen "zijn" e-mails terug, geen geïmporteerde berichten.

Maar technisch gezien is het mechanisme identiek. Een herinjectie die de oorspronkelijke datum niet meegeeft, produceert dezelfde artefacten. En de correctie volgt ook dezelfde logica.

Hoe elk gereedschap omgaat (of niet omgaat) met INTERNALDATE

Niet alle tools gedragen zich precies hetzelfde, en dat is waar het interessant wordt.

Veeam Backup for Microsoft 365

Veeam gebruikt de EWS-API (Exchange Web Services) om naar Exchange Online te herstellen. EWS maakt het mogelijk om de berichtdatum op te geven via het veld DateTimeReceived, maar deze waarde wordt niet altijd doorgevoerd naar de INTERNALDATE op IMAP-niveau. Resultaat: de sorteerdatum in Outlook kan afwijken van de originele datum, met name als het herstel naar een andere mailbox gaat dan de originele (granulaire herstel naar een alternatieve mailbox, bijvoorbeeld).

Datto SaaS Protection

Datto herstelt via Microsoft Graph API of IMAP, afhankelijk van de configuratie. In beide gevallen hangt de datum die de mailbox toont af van de vraag of het herstel de oorspronkelijke datum van elk bericht meegeeft. MSPs die Datto gebruiken voor hun klanten komen dit probleem vrij regelmatig tegen, met name na ransomware-incidenten waarbij in allerijl meerdere honderden mailboxen tegelijk worden hersteld. Dan is het niet het moment om te ontdekken dat alle datums verkeerd zijn.

AvePoint en Synology Active Backup

AvePoint Cloud Backup en Synology Active Backup for Microsoft 365 volgen vergelijkbare mechanismen. AvePoint heeft dit gedrag gedocumenteerd in zijn kennisbank (het bericht wordt hersteld met de hersteldatum als zichtbare ontvangstdatum), zonder daarbij een native oplossing aan te bieden. Synology Active Backup vertoont hetzelfde probleem, versterkt door het feit dat de herstelinterface geen duidelijk onderscheid maakt tussen "berichtdatum" en "hersteldatum".

Goed nieuws: de originele datum is er nog steeds

Wat de situatie herstelbaar maakt, is dat de originele Date:-header van het bericht niet is gewijzigd. Hij is nog steeds aanwezig, intact, in elke herstelde e-mail. Het herstel heeft de datum die de mailbox registreerde veranderd, en soms een Received:-regel bovenop geplakt, maar heeft de inhoud van het bericht zelf niet aangeraakt.

Dit is een eigenschap van het MIME-formaat (RFC 2822): een bericht is onveranderlijk in zijn interne structuur. De Received:-headers stapelen zich bovenaan op als lagen, maar de originele informatie blijft eronder bewaard.

U hebt de informatie dus niet verloren. Ze is gewoon verborgen achter een herinjectie-artefact.

Waarom het herstel opnieuw uitvoeren geen oplossing is

Het eerste idee dat opkomt: de herstelde e-mails verwijderen en het herstel opnieuw uitvoeren in de hoop dat de datums nu wel kloppen. Dat is een slecht idee, om meerdere redenen.

Allereerst zullen de hersteltools zich bij een tweede poging niet anders gedragen. Hetzelfde gereedschap, dezelfde instellingen: de e-mails worden op dezelfde manier teruggeschreven, zonder hun oorspronkelijke datum.

Bovendien kost het opnieuw uitvoeren van een herstel op productie-mailboxen tijd, bandbreedte en risico's. Op 50 mailboxen met elk 20.000 berichten gaat het om een operatie van meerdere uren die de API's bezet houdt en rate limits kan triggeren bij Microsoft of Google (het beruchte 429 Too Many Requests om 2 uur 's nachts tijdens een batchverwerking).

Kortom. Het herstel heeft gewerkt. De gegevens zijn er. Wat gecorrigeerd moet worden, is het datumartefact, niet het herstel zelf.

Zelf corrigeren: de concrete risico's

Het probleem begrijpen is één ding. Het corrigeren op 80.000 e-mails zonder er één te verliezen, is een andere zaak.

Een Python-script dat IMAP-berichten doorloopt en datums corrigeert kan haalbaar lijken. Op 50 teste-mails werkt het prima. In productie is dat anders. De randgevallen stapelen zich op: S/MIME-ondertekende e-mails (de header aanpassen maakt de cryptografische handtekening ongeldig), PGP-versleutelde berichten, multipart-structuren met niet-standaard MIME-grenzen, in RFC 2047 gecodeerde headers (niet-ASCII), bijlagen van 40 MB die het geheugen van het script opblazen. En e-mails met meerdere toegevoegde Received:-headers (als het herstel gedeeltelijk opnieuw werd uitgevoerd, wat voorkomt), die fijnere detectielogica vereisen.

Het echte risico is trouwens niet het script dat crasht: het is het script dat foutloos lijkt te draaien maar beschadigde berichten produceert. Gebroken gespreksthreads. Duplicaten. Losgeraakte bijlagen. Die u misschien pas weken later ontdekt, wanneer een gebruiker een belangrijk e-mailbericht probeert terug te vinden.

En hoe controleert u of elke gecorrigeerde e-mail na de wijziging echt intact is? Een zelfgeschreven script doet dat doorgaans niet.

Wat Redate.io anders doet

Redate.io analyseert de headerketen van elke e-mail om herinjectie-artefacten te identificeren, of ze nu afkomstig zijn van een Veeam-herstel, een BitTitan-migratie, of een handmatige import. De propriëtaire correctie-engine hoeft niet te weten welk gereedschap de schade heeft aangericht: hij zoekt e-mails waarvan de weergegeven datum niet overeenkomt met de oorspronkelijke datum, zodat ook een onbekend gereedschap wordt opgemerkt.

Voordat er iets wordt gecorrigeerd, scant Redate.io de volledige mailbox en toont een rapport: hoeveel e-mails zijn getroffen, wat is de incorrecte datum, welke originele datum werd gedetecteerd. Deze scan is gratis. U ziet de omvang van het probleem voordat u besluit actie te ondernemen.

Elke e-mail wordt na correctie individueel geverifieerd. De originelen blijven bewaard in een zichtbare back-upmap in uw eigen mailbox, tot u ze zelf verwijdert.

Elke gebruiker meldt zich aan met zijn eigen Microsoft- of Google-account, en Redate.io opent alleen die mailbox met de toegang die deze aanmelding geeft, zonder dat e-mails via tussenliggende servers worden geleid. De correctie vindt ter plaatse plaats, in de mailbox zelf, zonder export of reimport.

Voor MSPs die meerdere getroffen klanten tegelijk beheren: zie de pagina voor MSPs. Redate.io maakt het mogelijk meerdere mailboxen parallel te verwerken vanuit één interface.

Andere scenario's die hetzelfde artefact produceren

Herstel vanuit een backuptool is niet het enige geval. Hetzelfde datumartefact verschijnt in andere situaties:

• IMAP-import vanuit Exchange (gearchiveerde mailboxen die opnieuw in Exchange Online worden ingevoegd)
• Migratie naar Exchange Online met tools die IMAP aan de ontvangstzijde gebruiken
• Granulaire herstel vanuit een geëxporteerde en vervolgens geïmporteerde PST (zie het artikel over PST-import)
• Gedeelde mailboxen die na een incident zijn hersteld (zie de correctie van gedeelde mailboxen)

In al deze gevallen is het onderliggende mechanisme identiek: een herinjectie die de oorspronkelijke datum niet meegeeft (soms met een nieuwe Received:-header erbovenop), en een e-mailclient die deze nieuwe datum als referentie toont.

De e-mails zijn er, de originele datum is in elk bericht bewaard. Start een gratis scan op Redate.io om precies te zien hoeveel e-mails in uw mailbox zijn getroffen, en beslis daarna of u de correctie wilt uitvoeren.