Αλλαγή ημερομηνίας email: τεχνικά όρια

Κάθε email έχει τρεις "ημερομηνίες". Όχι μία.

Όταν μιλάμε για "αλλαγή της ημερομηνίας λήψης ενός email", οι περισσότεροι φαντάζονται ότι τροποποιούν ένα πεδίο κάπου, όπως θα άλλαζαν την ημερομηνία δημιουργίας ενός αρχείου στα Windows. Η πραγματικότητα είναι λίγο πιο σύνθετη. Κάθε email μεταφέρει στην πραγματικότητα τρία ξεχωριστά επίπεδα χρονολόγησης, το καθένα με τους δικούς του κανόνες, τους δικούς του «φύλακες», και τις δικές του συνέπειες αν κάποιος παρέμβει σε αυτό.

Κατανοώντας αυτά τα τρία επίπεδα, καταλαβαίνει κανείς γιατί ορισμένες διορθώσεις είναι τεχνικά σωστές, ενώ άλλες είναι είτε αδύνατες είτε άμεσα ανιχνεύσιμες ως παραποιήσεις.

Επίπεδο 1: το INTERNALDATE του IMAP

Το INTERNALDATE είναι ένα μεταδεδομένο που αποθηκεύεται στην πλευρά του διακομιστή, εκτός του ίδιου του μηνύματος. Δεν αποτελεί μέρος του περιεχομένου του email. Ο διακομιστής IMAP το ορίζει, και αυτό χρησιμοποιεί η πλειονότητα των προγραμμάτων-πελατών αλληλογραφίας για να ταξινομεί τα μηνύματα στη λίστα.

Το Outlook, για παράδειγμα, εμφανίζει από προεπιλογή τα μηνύματα ταξινομημένα κατά INTERNALDATE. Το ίδιο κάνει και το Gmail σε ορισμένα πλαίσια. Έτσι, αν το INTERNALDATE είναι λανθασμένο, όλα τα email σας φαίνεται να έχουν την ίδια ημερομηνία στη διεπαφή, ανεξάρτητα από ό,τι αναγράφουν οι εσωτερικές κεφαλίδες του μηνύματος.

Το INTERNALDATE ορίζεται τη στιγμή που το μήνυμα κατατίθεται στον διακομιστή. Μέσω του πρωτοκόλλου IMAP, ο μόνος τρόπος «τροποποίησής» του είναι έμμεσος: χρειάζεται η εντολή APPEND για να κατατεθεί ένα νέο αντίγραφο του μηνύματος με την επιθυμητή ημερομηνία. Δεν υπάρχει εντολή IMAP SETINTERNALDATE. Αυτή η λεπτομέρεια θα αποδειχθεί σημαντική παρακάτω.

Επίπεδο 2: η κεφαλίδα Date: (RFC 2822)

Πρόκειται για το πεδίο Date: στις ακατέργαστες κεφαλίδες του μηνύματος. Ορίζεται από το πρόγραμμα-πελάτη αλληλογραφίας κατά την αποστολή και ταξιδεύει με το μήνυμα από διακομιστή σε διακομιστή. Είναι η ημερομηνία αποστολής που δηλώνει ο αποστολέας.

(Παρεμπιπτόντως, αν δεν έχετε δει ποτέ τις ακατέργαστες κεφαλίδες ενός email, είναι μια αρκετά περίεργη ανάγνωση. Κάθε μήνυμα σέρνει περίπου είκοσι τεχνικές γραμμές που το 99% των ανθρώπων δεν έχουν δει ποτέ.)

Τεχνικά, τίποτα δεν εμποδίζει την αποστολή ενός email με πεδίο Date: αντιχρονολογημένο ή μεταχρονολογημένο. Οι διακομιστές SMTP δεν επαληθεύουν αυτό το πεδίο. Όμως οι διακομιστές-παραλήπτες καταγράφουν την πραγματική ώρα άφιξης στις κεφαλίδες Received:, γεγονός που δημιουργεί αμέσως μια αναντιστοιχία ορατή από οποιοδήποτε πρόγραμμα αλληλογραφίας ή εργαλείο ανάλυσης.

Επίπεδο 3: οι κεφαλίδες Received: σε στοίβα

Κάθε φορά που ένας διακομιστής SMTP αναμεταδίδει ένα μήνυμα, προσθέτει μια κεφαλίδα Received: στην κορυφή της στοίβας, με χρονική σήμανση. Ένα email που πέρασε από τρεις διακομιστές θα έχει τρεις κεφαλίδες Received:. Διαβάζονται από κάτω προς τα πάνω: η παλαιότερη είναι κάτω, η πιο πρόσφατη πάνω.

Εδώ ακριβώς τα εργαλεία μετεγκατάστασης δημιουργούν το πρόβλημα. Όταν το BitTitan MigrationWiz, το CloudM, το imapsync ή το GSMMO μεταφέρουν ένα email, το επανεισάγουν στον νέο διακομιστή μέσω IMAP. Αυτή η κατάθεση δημιουργεί μια νέα καταχώρηση Received: χρονοσημασμένη κατά τη στιγμή της μετεγκατάστασης. Αποτέλεσμα: το παλαιότερο μήνυμα στο γραμματοκιβώτιό σας, ένα email του 2019, καταλήγει με ένα Received: που δείχνει Νοέμβριος 2024. Και επειδή ορισμένα προγράμματα-πελάτες αλληλογραφίας (το Outlook πρωτίστως) χρησιμοποιούν το πιο πρόσφατο Received: ως ημερομηνία εμφάνισης...

Νά το πρόβλημα. 15.000 email εμφανίζουν όλα την ίδια ημερομηνία μετεγκατάστασης.

Μπορεί κανείς πραγματικά να «τροποποιήσει» αυτές τις ημερομηνίες;

Τεχνικά, ναι για το INTERNALDATE (με περιορισμούς). Τεχνικά εφικτό αλλά άχρηστο για το Date:. Και για τις κεφαλίδες Received:, αξίζει να σταθούμε λίγο παραπάνω.

Η επανεγγραφή μιας κεφαλίδας Received: είναι τετριμμένη. Και άμεσα ανιχνεύσιμη.

Μια κεφαλίδα Received: δεν είναι παρά μια γραμμή κειμένου μέσα στο μήνυμα. Μπορεί να επεξεργαστεί όπως οποιοδήποτε αρχείο κειμένου. Τόσο απλό είναι.

Αλλά νά τι συμβαίνει στη συνέχεια.

Πρώτο πρόβλημα: DKIM. Η υπογραφή DKIM (DomainKeys Identified Mail) υπολογίζεται επί ενός συνόλου κεφαλίδων του μηνύματος, συμπεριλαμβανομένων μερικές φορές των Received:. Η τροποποίηση μιας υπογεγραμμένης κεφαλίδας ακυρώνει την υπογραφή. Οποιοσδήποτε διακομιστής-παραλήπτης που επαληθεύει DKIM θα δει αμέσως ότι το μήνυμα έχει παραποιηθεί. Δεν είναι λεπτή παραχάραξη, είναι ηχηρό συναγερμός.

Δεύτερο πρόβλημα: οι εσωτερικοί αναγνωριστικοί κωδικοί. Οι σύγχρονοι διακομιστές αλληλογραφίας (Google Workspace, Microsoft 365) εκχωρούν σε κάθε μήνυμα έναν αυξητικό και μοναδικό εσωτερικό αναγνωριστικό κωδικό. Αυτοί οι κωδικοί συνδέονται με το INTERNALDATE και τη σειρά λήψης. Η τροποποίηση ενός Received: χωρίς συνοχή με αυτούς τους κωδικούς δημιουργεί αναντιστοιχίες που τα εργαλεία ελέγχου εντοπίζουν χωρίς καμία δυσκολία.

Τρίτο πρόβλημα, πιο πρακτικό: ακόμα και αν τροποποιήσετε το Received: στο περιεχόμενο του μηνύματος, δεν έχετε αγγίξει το INTERNALDATE, που παραμένει αυτό της κατάθεσης IMAP. Το πρόγραμμα-πελάτης αλληλογραφίας συνεχίζει να εμφανίζει τη λανθασμένη ημερομηνία για την ταξινόμηση. Τροποποιήσατε το μήνυμα χωρίς κανένα αποτέλεσμα.

Συνοπτικά: η επανεγγραφή των Received: για παραποίηση ημερομηνίας email με κακόβουλο σκοπό είναι τεχνικά τετριμμένη, αλλά ανιχνεύσιμη σε λίγα δευτερόλεπτα από έναν ειδικό. Δεν είναι σοβαρή προσέγγιση.

Η κεφαλίδα Date:: αλλαγή του παρελθόντος στα χαρτιά

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

Για να είμαστε ακριβείς, αυτό δεν εμποδίζει ορισμένα προγράμματα-πελάτες αλληλογραφίας να εμφανίζουν το τροποποιημένο Date: αν τους παρουσιαστεί απευθείας το αρχείο .eml. Όμως στο πλαίσιο ενός ενεργού διακομιστή αλληλογραφίας, με πιστοποίηση και καταγραφές, η τροποποίηση είναι διαφανής.

Η μετεγκατάσταση IMAP: το μόνο πλαίσιο όπου η διόρθωση ημερομηνιών είναι σωστή

Υπάρχει μία, και μόνο μία, περίπτωση όπου η τροποποίηση της ημερομηνίας λήψης ενός email είναι όχι μόνο δυνατή αλλά και τεχνικά δικαιολογημένη: η διόρθωση των ζημιών που προκλήθηκαν από μια κακώς διαχειριζόμενη μετεγκατάσταση IMAP.

Να η συγκεκριμένη κατάσταση. Μόλις μεταφέρατε 80 γραμματοκιβώτια Exchange στο Microsoft 365. Η μετεγκατάσταση ολοκληρώθηκε ένα Παρασκευή βράδυ. Δευτέρα πρωί, τα πρώτα αιτήματα υποστήριξης αρχίζουν να φτάνουν: «Όλα τα email μου έχουν την ίδια ημερομηνία», «Δεν μπορώ να βρω ένα email από πέρυσι», «Το ιστορικό επικοινωνίας με αυτόν τον πελάτη είναι εντελώς χαλασμένο». Έχετε 80 χρήστες μπλοκαρισμένους και τον προϊστάμενό σας να περιμένει απάντηση.

Σε αυτό το πλαίσιο, το πρόβλημα είναι τεκμηριωμένο, αναγνωρίσιμο, και η αιτία του είναι σαφής: το εργαλείο μετεγκατάστασης πρόσθεσε ένα Received: με ημερομηνία την ημέρα της μετεγκατάστασης, και ορισμένα προγράμματα-πελάτες αλληλογραφίας χρησιμοποιούν αυτή την νέα κεφαλίδα ως ημερομηνία εμφάνισης. Η αρχική κεφαλίδα Date:, από την άλλη, είναι άθικτη σε κάθε μήνυμα. Δεν τροποποιήθηκε ποτέ. Περιέχει ακόμα την αρχική, σωστή ημερομηνία αποστολής.

Η διόρθωση δεν είναι λοιπόν παραποίηση: είναι αποκατάσταση. Ξεκινάμε από αληθινά δεδομένα (το αρχικό Date:) για να ανακατασκευάσουμε συνεκτικά μεταδεδομένα. Αυτό είναι θεμελιωδώς διαφορετικό από το να προσπαθεί κανείς να κάνει ένα email του 2024 να περνά για email του 2019.

Για περισσότερες λεπτομέρειες σχετικά με τους μηχανισμούς που αφορούν κάθε εργαλείο, αυτοί οι οδηγοί αναλύουν τις συγκεκριμένες περιπτώσεις: διόρθωση ημερομηνιών BitTitan στο Microsoft 365, διόρθωση ημερομηνιών CloudM στο Outlook, ή διόρθωση ημερομηνιών imapsync στο Google Workspace.

Γιατί δεν πρέπει να γράψετε script μόνοι σας

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

Το πρόβλημα είναι η απόσταση μεταξύ ενός script που δουλεύει σε 50 email δοκιμής και ενός script που τρέχει σε 40.000 μηνύματα σε παραγωγή χωρίς να χάσει ούτε ένα email, χωρίς να καταστρέψει ούτε ένα συνημμένο, και χωρίς να σπάσει ούτε ένα νήμα συνομιλίας.

Μερικές συγκεκριμένες περιπτώσεις που τα script σπιτικής κατασκευής συνήθως δεν χειρίζονται:

• Email με υπογραφή S/MIME: η υπογραφή καλύπτει το περιεχόμενο και τις κεφαλίδες. Οποιαδήποτε τροποποίηση στη δομή του μηνύματος ακυρώνει την υπογραφή. Ένα υπογεγραμμένο email που διορθώθηκε αδέξια φτάνει ως «μη έγκυρη υπογραφή» στους παραλήπτες.
• Μηνύματα κρυπτογραφημένα με PGP: ίδια οικογένεια προβλημάτων, με δυνητικά χειρότερες συνέπειες ανάλογα με την υλοποίηση.
• Κωδικοποιήσεις non-ASCII στις κεφαλίδες: το RFC 2047 περιγράφει την κωδικοποίηση ειδικών χαρακτήρων στις κεφαλίδες. Ένα script που χειρίζεται κεφαλίδες χωρίς να διαχειρίζεται αυτές τις περιπτώσεις θα καταστρέψει αθόρυβα θέματα email που περιέχουν τόνους, ιαπωνικούς χαρακτήρες ή αραβικά ονόματα.
• Όρια ρυθμού API: το Google Workspace και το Microsoft 365 εφαρμόζουν επιθετικό throttling. Στις 3 τα ξημερώματα, ένα batch 10.000 email που συναντά σφάλμα 429 Too Many Requests χωρίς διαχείριση εκθετικής αναμονής αφήνει τα μισά γραμματοκιβώτια διορθωμένα à medias.
• Κατεστραμμένα όρια MIME: τα μηνύματα multipart με συνημμένα έχουν ακριβή όρια MIME. Η εσφαλμένη αναγέννησή τους καθιστά τα συνημμένα μη αναγνώσιμα.

Και η ερώτηση που κανένα script σπιτικής κατασκευής δεν απαντά: πώς επαληθεύετε ότι κάθε διορθωμένο email είναι άθικτο; Ένα script που τροποποιεί 40.000 μηνύματα χωρίς μεμονωμένη επαλήθευση είναι ένα στοίχημα. Ένα στοίχημα με δεδομένα που οι χρήστες σας θεωρούν συχνά αναντικατάστατα.

Ένα άρθρο σχετικά με τις διαθέσιμες επιλογές για τη διόρθωση ημερομηνιών μετά τη μετεγκατάσταση εξετάζει τις διάφορες προσεγγίσεις, συμπεριλαμβανομένων των αντίστοιχων περιορισμών τους.

Τι κάνει το Redate.io σε αυτό το πλαίσιο

Το Redate.io έχει σχεδιαστεί ειδικά για αυτή την περίπτωση: τη διόρθωση ημερομηνιών που καταστράφηκαν από μετεγκατάσταση IMAP, σε μεγάλη κλίμακα, χωρίς κίνδυνο για την ακεραιότητα των μηνυμάτων.

Η υπηρεσία συνδέεται απευθείας στα επηρεαζόμενα γραμματοκιβώτια (Google Workspace μέσω domain delegation, Microsoft 365 μέσω Azure AD, ή απευθείας IMAP), σαρώνει δωρεάν τα μηνύματα με λανθασμένες ημερομηνίες, και στη συνέχεια εφαρμόζει ένα ιδιόκτητο pipeline διόρθωσης που χειρίζεται τις οριακές περιπτώσεις που τεκμηριώθηκαν παραπάνω. Κάθε email επαληθεύεται μεμονωμένα μετά τη διόρθωση. Τα πρωτότυπα παραμένουν σε έναν ορατό φάκελο αντιγράφων ασφαλείας για 30 ημέρες.

Η αντιστοίχιση προτύπων καλύπτει εκατοντάδες υπογραφές γνωστών εργαλείων μετεγκατάστασης: BitTitan MigrationWiz, CloudM, imapsync, GSMMO, και τις παραλλαγές τους. Η ανίχνευση είναι ακριβής: το Redate.io δεν αγγίζει τα email των οποίων η ημερομηνία είναι σωστή.

Το μοντέλο τιμολόγησης είναι απλό: εφάπαξ πληρωμή ανά γραμματοκιβώτιο, χωρίς συνδρομή. Η διαγνωστική σάρωση είναι δωρεάν, πράγμα που επιτρέπει να μετρήσετε την έκταση της ζημιάς πριν αποφασίσετε οτιδήποτε.

Αν διαχειρίζεστε γραμματοκιβώτια που επηρεάζονται από αυτό το πρόβλημα, αυτό το άρθρο για τις λανθασμένες ημερομηνίες στο Outlook μετά τη μετεγκατάσταση αναλύει τα πιο συνηθισμένα συμπτώματα και πώς να τα διακρίν