Αλλαγή ημερομηνίας email: αλήθεια ή ψέμα;

Η ερώτηση που κάνουν όλοι (και γιατί κρύβει δύο πολύ διαφορετικές καταστάσεις)

Αναζητήστε "αλλαγή ημερομηνίας email" στο Google. Θα βρείτε δεκάδες νήματα σε φόρουμ Microsoft Q&A, threads στο Reddit, ερωτήσεις στο Quora. Το αίτημα είναι ξεκάθαρο, αλλά οι λόγοι πίσω από αυτό διαφέρουν ριζικά ανάλογα με τον ερωτώντα.

Υπάρχουν αυτοί που θέλουν να παραποιήσουν μια ημερομηνία αναδρομικά, για λόγους που προτιμάμε να μην φανταστούμε. Και υπάρχουν διαχειριστές IT που, μετά από μια μετεγκατάσταση IMAP, βλέπουν όλα τα email τους να εμφανίζουν την ίδια μέρα (αυτή της μετεγκατάστασης), και θέλουν απλώς να ανακτήσουν τις πραγματικές ημερομηνίες. Αυτές οι δύο καταστάσεις δεν έχουν καμία σχέση μεταξύ τους, αλλά μοιράζονται την ίδια αναζήτηση.

Αυτό το άρθρο απαντά και στις δύο. Spoiler: στην πρώτη περίπτωση, η τροποποίηση δεν είναι δυνατή με τρόπο που να μην ανιχνευθεί. Στη δεύτερη, είναι απολύτως νόμιμη και αυτό ακριβώς κάνει το Redate.io.

Πρώτα απ' όλα: τι είναι η "ημερομηνία" ενός email;

Ένα email δεν περιέχει μία μόνο ημερομηνία. Περιέχει αρκετές, αποθηκευμένες σε διαφορετικά σημεία, που ελέγχονται από διαφορετικές οντότητες.

Η κεφαλίδα Date: (RFC 2822)

Είναι η ημερομηνία που ο client του αποστολέα εγγράφει στο μήνυμα κατά την αποστολή. Εμφανίζεται στις ακατέργαστες κεφαλίδες με τη μορφή:

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

Αυτή η κεφαλίδα αποτελεί μέρος του σώματος του μηνύματος. Τεχνικά μπορεί να τροποποιηθεί αν έχετε πρόσβαση στο ακατέργαστο αρχείο. Αλλά το "τεχνικά" είναι η λέξη-κλειδί εδώ.

Οι κεφαλίδες Received:

Κάθε διακομιστής αλληλογραφίας από τον οποίο διέρχεται ένα email προσθέτει τη δική του κεφαλίδα Received: με timestamp. Αυτές οι κεφαλίδες σχηματίζουν μια χρονολογική αλυσίδα, από τον διακομιστή του αποστολέα μέχρι το γραμματοκιβώτιό σας. (Αν έχετε δοκιμάσει ποτέ να διαβάσετε ακατέργαστες κεφαλίδες email, ξέρετε ότι δεν είναι ακριβώς ανάγνωση για χαλάρωση. Δεκάδες γραμμές τεχνικών μεταδεδομένων, με σειρά από το πιο πρόσφατο στο πιο παλιό.)

Το INTERNALDATE του IMAP

Είναι το πιο σημαντικό μεταδεδομένο για να κατανοήσουμε γιατί ορισμένες τροποποιήσεις δεν έχουν καμία ορατή επίδραση. Το INTERNALDATE είναι ένα χαρακτηριστικό αποθηκευμένο στον διακομιστή IMAP, ανεξάρτητα από το περιεχόμενο του μηνύματος. Αυτό χρησιμοποιούν οι περισσότεροι email clients για να ταξινομήσουν τα email στους φακέλους. Το Outlook το χρησιμοποιεί. Το Gmail επίσης. Και το Apple Mail, στις περισσότερες περιπτώσεις, ομοίως.

Το INTERNALDATE δεν βρίσκεται μέσα στο μήνυμα. Βρίσκεται στη βάση δεδομένων του διακομιστή. Δεν μπορείτε να το τροποποιήσετε επεξεργαζόμενοι ένα αρχείο .eml στο δίσκο σας.

Τι συμβαίνει πραγματικά όταν κάνετε τοπικές τροποποιήσεις

Επεξεργασία αρχείου .eml

Τεχνικά, ένα αρχείο .eml είναι αρχείο κειμένου. Μπορείτε να το ανοίξετε σε ένα editor, να αλλάξετε τη γραμμή Date:, να το αποθηκεύσετε. Αν επαναφέρετε αυτό το αρχείο σε έναν τοπικό email client, η εμφανιζόμενη ημερομηνία μπορεί να αλλάξει, ανάλογα με τον client.

Αλλά να τι δεν αλλάζει:

• Το INTERNALDATE στον διακομιστή IMAP (παραμένει ανέπαφο)
• Οι κεφαλίδες Received: που έχουν προστεθεί από τους ενδιάμεσους διακομιστές
• Τα logs παράδοσης στη Google, τη Microsoft, ή τον πάροχό σας
• Η υπογραφή DKIM, εφόσον το μήνυμα είχε μία

Αποτέλεσμα: στο τοπικό σας μηχάνημα, βλέπετε ίσως μια διαφορετική ημερομηνία. Από το Outlook συνδεδεμένο στο Exchange Online, ή το Gmail σε πρόγραμμα περιήγησης, τίποτα δεν έχει αλλάξει.

Αλλαγή ώρας συστήματος

Κάποια φόρουμ προτείνουν να αλλάξετε την ώρα του υπολογιστή για να "εξαπατήσετε" τον email client. Δεν λειτουργεί. Το Outlook και το Gmail δεν διαβάζουν την ώρα συστήματος για να εμφανίσουν τις ημερομηνίες των εισερχόμενων email. Διαβάζουν το INTERNALDATE από τον διακομιστή, ή τις κεφαλίδες του μηνύματος. Η τοπική ώρα δεν παρεμβαίνει πουθενά σε αυτή τη διαδικασία.

Η παρέμβαση μέσω Thunderbird

Το Thunderbird προσφέρει μεγαλύτερη ευελιξία από τους περισσότερους clients. Με extensions ή χειριστικές παρεμβάσεις απευθείας στο προφίλ (αρχεία mbox, αρχεία .msf), κάποιοι επιχειρούν να τροποποιήσουν την εμφάνιση των ημερομηνιών. Αυτό μπορεί να λειτουργήσει στο ίδιο το Thunderbird, για email αποθηκευμένα τοπικά σε λειτουργία POP3. Μόλις όμως το Thunderbird συνδεθεί μέσω IMAP, επανασυγχρονίζεται με τον διακομιστή. Η "διόρθωση" εξαφανίζεται στην επόμενη συγχρονισμό.

DKIM: το αόρατο εμπόδιο που κανείς δεν αναφέρει

Τα περισσότερα email που αποστέλλονται από το 2018 φέρουν υπογραφή DKIM (DomainKeys Identified Mail). Μια υπογραφή DKIM εμφανίζεται ως εξής στις κεφαλίδες:

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...

Το πεδίο h= απαριθμεί τις κεφαλίδες που καλύπτονται από την υπογραφή. Στο παραπάνω παράδειγμα, η Date υπογράφεται. Αν τροποποιήσετε την κεφαλίδα Date: του μηνύματος, η επαλήθευση DKIM αποτυγχάνει. Οποιοσδήποτε διακομιστής αλληλογραφίας, οποιοδήποτε εργαλείο forensic ανάλυσης, μπορεί να ανιχνεύσει την τροποποίηση επαναϋπολογίζοντας την υπογραφή.

Δεν είναι τέλεια προστασία (ένας κακόβουλος αποστολέας ελέγχει το δικό του κλειδί DKIM και μπορεί να υπογράψει ό,τι θέλει κατά την αποστολή). Αλλά για ένα email που έχει ήδη παραληφθεί και υπογραφεί, η τροποποίηση της κεφαλίδας Date: αφήνει ανιχνεύσιμο ίχνος.

Τα logs διακομιστή: η πραγματική πηγή αλήθειας

Ακόμα και αν καταφέρνατε να τροποποιήσετε όλα τα ορατά μεταδεδομένα ενός email (κεφαλίδες, INTERNALDATE, τα πάντα), οι πάροχοι διατηρούν τα δικά τους logs.

Το Google Workspace καταγράφει κάθε μήνυμα στα logs ελέγχου της Admin Console. Το Microsoft 365 κάνει το ίδιο στο Κέντρο Συμμόρφωσης (Purview). Αυτά τα logs περιλαμβάνουν timestamps παράδοσης, ανεξάρτητα από αυτό που εμφανίζεται στους clients. Ένας δικηγόρος, μια νομική υπηρεσία, ή μια ομάδα ασφαλείας IT μπορεί να ανακτήσει αυτά τα δεδομένα. Η ημερομηνία που εμφανίζεται στο Outlook δεν αποτελεί αποδεικτικό στοιχείο σε δικαστήριο ή σε έλεγχο ασφαλείας.

Για να είμαστε ακριβείς: ακόμα και ένας διαχειριστής που έχει πρόσβαση στο γραμματοκιβώτιο μέσω domain delegation δεν μπορεί να ξαναγράψει αναδρομικά αυτά τα logs. Είναι εκτός εμβέλειας ακόμα και για προνομιούχους χρήστες.

Η νόμιμη περίπτωση: η διόρθωση μετά τη μετεγκατάσταση

Μόλις ολοκληρώσατε τη μετεγκατάσταση 150 γραμματοκιβωτίων από Exchange on-premise στο Microsoft 365. Τη Δευτέρα, αρχίζουν να έρχονται τα αιτήματα υποστήριξης: "όλα τα παλιά μου email έχουν ημερομηνία την Παρασκευή". Την ημερομηνία της μετεγκατάστασης.

Αυτό είναι ένα καλά τεκμηριωμένο πρόβλημα, εντελώς διαφορετικό από αυτό που περιγράψαμε. Εδώ, κανείς δεν επιχειρεί να παραποιήσει τίποτα. Οι πραγματικές αρχικές ημερομηνίες υπάρχουν ακόμα, ανέπαφες, στην κεφαλίδα Date: κάθε μηνύματος. Το πρόβλημα έρχεται αλλού: το εργαλείο μετεγκατάστασης (BitTitan MigrationWiz, CloudM, imapsync, ή κάποιο άλλο) έχει εισαγάγει μια κεφαλίδα Received: με την ημερομηνία μετεγκατάστασης στην κορυφή της αλυσίδας. Το Outlook, που στηρίζεται στις πιο πρόσφατες κεφαλίδες Received: αντί για το INTERNALDATE σε ορισμένα πλαίσια, εμφανίζει αυτή την ημερομηνία αντ' άλλης.

Σε αυτή την περίπτωση, η "διόρθωση" συνίσταται στην αποκατάσταση της συνέπειας μεταξύ αυτού που λέει το μήνυμα (η αρχική κεφαλίδα Date:, που είναι πάντα εκεί) και αυτού που νομίζει ο διακομιστής (το INTERNALDATE, που ορίστηκε κατά τη μετεγκατάσταση). Δεν πρόκειται για παραποίηση. Πρόκειται για αποκατάσταση.

Αυτό είναι ακριβώς το πρόβλημα που προκαλεί μια κακώς ρυθμισμένη μετεγκατάσταση σε χιλιάδες γραμματοκιβώτια (δείτε γιατί τα email δείχνουν λάθος ημερομηνία μετά τη μεταφορά). Και αυτό λύνει το Redate.io.

Γιατί το "κάντο μόνος σου" αποτυγχάνει σε κλίμακα

Να κατανοείς το πρόβλημα είναι ένα πράγμα. Να το διορθώνεις σε 40.000 email κατανεμημένα σε 150 γραμματοκιβώτια χωρίς να χάσεις ούτε ένα, είναι εντελώς άλλο.

Τα scripts που βρίσκετε στο GitHub ή το Stack Overflow λειτουργούν σε 20 δοκιμαστικά email. Συναντούν προβλήματα σε παραγωγικό περιβάλλον για λόγους που ο συγγραφέας δεν είχε προβλέψει:

• Τα email υπογεγραμμένα S/MIME ή κρυπτογραφημένα PGP έχουν δομές που δεν χειρίζονται όπως κανονικά μηνύματα
• Τα μηνύματα multipart με μη τυποποιημένα MIME boundaries προκαλούν σφάλματα parsing
• Οι κεφαλίδες κωδικοποιημένες κατά RFC 2047 (μη-ASCII χαρακτήρες στα πεδία From: ή Subject:) σπάνε τους αφελείς parsers
• Τα API της Google και της Microsoft επιβάλλουν rate limiting: στις 3 π.μ. κατά τη διάρκεια ενός batch 30.000 email, το σφάλμα 429 Too Many Requests δεν αντιμετωπίζεται, το script σταματά, και κανείς δεν ξέρει πού σταμάτησε
• Κανένας μηχανισμός rollback: αν ένα μήνυμα καταστραφεί κατά την επεξεργασία, δεν υπάρχει τρόπος επαναφοράς

Το Redate.io διατηρεί αντίγραφο κάθε αρχικού email σε έναν ορατό φάκελο αντιγράφων ασφαλείας για 30 ημέρες. Κάθε διόρθωση επαληθεύεται μεμονωμένα. Το pipeline ανάλυσης διαχειρίζεται εκατοντάδες υπογραφές γνωστών εργαλείων μετεγκατάστασης, καθώς και όλες τις οριακές περιπτώσεις που ένα αυτοσχέδιο script δεν θα αντιμετώπιζε.

Για περισσότερες λεπτομέρειες ανάλογα με το εργαλείο που χρησιμοποιήσατε, δείτε BitTitan MigrationWiz και ημερομηνίες email, ή CloudM Migrate: διόρθωση λάθος ημερομηνιών.

Τι αλλάζει, τι δεν αλλάζει ποτέ

Η διάκριση είναι σαφής. Οι τρεις πρώτες γραμμές του πίνακα περιγράφουν επιφανειακές ή ανιχνεύσιμες τροποποιήσεις. Η τελευταία περιγράφει μια νόμιμη διόρθωση μεταδεδομένων, εναρμονισμένη με το αρχικό περιεχόμενο του μηνύματος, μετά από μια μετεγκατάσταση που εισήγαγε ασυνέπεια.

Αν βρίσκεστε στην κατάσταση που περιγράφει η τελευταία γραμμή, μετά από μετεγκατάσταση με imapsync, BitTitan, CloudM ή άλλο εργαλείο, το Redate.io είναι φτιαγμένο για αυτό.

Τα email σας εμφανίζουν την ημερομηνία μετεγκατάστασης αντί για τις πραγματικές ημερομηνίες; Σαρώστε δωρεάν τα γραμματοκιβώτιά σας με το Redate.io και δείτε ακριβώς πόσα email επηρεάζονται, πριν αποφασίσετε.