Λάθος ημερομηνίες email μετά μεταφορά σε Exchange Online

Το κλασικό σενάριο της Δευτέρας το πρωί

Μόλις ολοκληρώσατε τη μεταφορά IMAP στο Exchange Online. Το batch τελείωσε χωρίς σφάλμα στο κέντρο διαχείρισης Exchange, τα γραμματοκιβώτια συγχρονίστηκαν, οι χρήστες μπορούν να συνδεθούν. Κλείνετε τον υπολογιστή σας Παρασκευή βράδυ με την αίσθηση ότι η δουλειά έγινε.

Δευτέρα πρωί, αρχίζουν τα tickets. "Όλα μου τα email έχουν ημερομηνία Παρασκευή." "Το ιστορικό των εισερχομένων μου είναι άχρηστο." "Λείπουν παλιά email." Δεν λείπει τίποτα στην πραγματικότητα: τα email είναι εκεί, αλλά το Outlook τα εμφανίζει όλα με την ημερομηνία μεταφοράς αντί για την πραγματική ημερομηνία αποστολής. Ένα email του 2019 εμφανίζεται με ημερομηνία την περασμένη Παρασκευή. Αποτέλεσμα: το γραμματοκιβώτιο φαίνεται να περιέχει μόνο πρόσφατα μηνύματα.

Αυτό είναι ένα από τα πιο απογοητευτικά προβλήματα στις μεταφορές IMAP προς Exchange Online, και η Microsoft το τεκμηριώνει ελάχιστα.

Γιατί η μεταφορά μέσω EAC καταστρέφει τις ημερομηνίες

Όταν χρησιμοποιείτε το κέντρο διαχείρισης Exchange (EAC) για να ρυθμίσετε μια μεταφορά IMAP από έναν τοπικό διακομιστή (Dovecot, Courier, Cyrus, UW-IMAP, οτιδήποτε), το Exchange Online συνδέεται στον διακομιστή πηγής μέσω IMAP, ανακτά τα μηνύματα και τα εισάγει στα γραμματοκιβώτια προορισμού μέσω της εσωτερικής διαδρομής μεταφοράς.

Εκεί ακριβώς δημιουργείται το πρόβλημα.

Κάθε email που περνά από τη διαδρομή μεταφοράς του Exchange λαμβάνει αυτόματα έναν τύπου Received: header με χρονική σήμανση. Είναι τυπική συμπεριφορά των διακομιστών SMTP και IMAP εδώ και δεκαετίες: κάθε διακομιστής που αγγίζει ένα μήνυμα αποτυπώνει τη χρονική του υπογραφή. Το πρόβλημα είναι ότι το Outlook (και ειδικά το Outlook για Windows σε πρόσφατες εκδόσεις) χρησιμοποιεί τον πιο πρόσφατο Received: header ως αναφορά εμφάνισης όταν άλλα μεταδεδομένα είναι ασαφή.

Ο αρχικός Date: header (αυτός που δείχνει πότε στάλθηκε πραγματικά το email, σύμφωνα με το RFC 2822) βρίσκεται ακόμα στο μήνυμα. Δεν διαγράφηκε. Αλλά «σκιάζεται» από τον νέο Received: header που πρόσθεσε το Exchange κατά την εισαγωγή.

Παράλληλα, το INTERNALDATE του IMAP (το μεταδεδομένο που χρησιμοποιούν οι διακομιστές IMAP για να χρονολογούν εσωτερικά τα μηνύματα και που ελέγχει την ταξινόμηση στους περισσότερους clients) ορίζεται στην ημερομηνία εισαγωγής, όχι στην αρχική ημερομηνία του email. Το Exchange Online δεν έχει κανένα εγγενή τρόπο να διατηρεί το INTERNALDATE του διακομιστή πηγής κατά τη διάρκεια μιας batch μεταφοράς μέσω EAC.

EAC έναντι εργαλείων τρίτων: μια σημαντική διαφορά

Πρέπει να διακρίνουμε δύο διαφορετικές καταστάσεις. Με εργαλεία όπως το BitTitan MigrationWiz ή το CloudM Migrate, το πρόβλημα υπάρχει επίσης, αλλά αυτά τα εργαλεία έχουν μερικές φορές επιλογές ρύθμισης (μερικώς τεκμηριωμένες, συχνά κρυμμένες στις προχωρημένες ρυθμίσεις) που προσπαθούν να διατηρήσουν κάποια μεταδεδομένα ημερομηνίας.

Η εγγενής μεταφορά μέσω EAC δεν προσφέρει τίποτα τέτοιο. Η Microsoft δεν εκθέτει κανένα παράμετρο για τον έλεγχο της διατήρησης INTERNALDATE στη διαδρομή batch migration. Είναι ένα μαύρο κουτί: ρυθμίζετε το batch, το ξεκινάτε, και το Exchange κάνει ό,τι θέλει εσωτερικά. Και αυτό που κάνει, συστηματικά, είναι να χρονολογεί τα μηνύματα στην ημερομηνία εισαγωγής τους.

(Αν έχετε ποτέ προσπαθήσει να διαβάσετε τα ακατέργαστα headers ενός email που μεταφέρθηκε μέσω EAC, ξέρετε ότι ο Received: header που προσθέτει το Exchange είναι αναγνωρίσιμος αμέσως: περιέχει αναφορές σε εσωτερικούς διακομιστές Microsoft όπως *.protection.outlook.com ή *.prod.exchangelabs.com, με χρονική σήμανση που αντιστοιχεί ακριβώς στο παράθυρο μεταφοράς.)

Γιατί η επανεκκίνηση του batch δεν λύνει τίποτα

Η αυθόρμητη αντίδραση πολλών διαχειριστών IT απέναντι σε αυτό το πρόβλημα είναι: «Αν διαγράψω τα μεταφερθέντα γραμματοκιβώτια και ξεκινήσω το batch από την αρχή, ίσως αυτή τη φορά οι ημερομηνίες να είναι σωστές.»

Είναι κατανοητό. Αλλά δεν λειτουργεί.

Το πρόβλημα δεν βρίσκεται στη ρύθμιση του batch. Δεν βρίσκεται σε κάποια επιλογή που ξεχάσατε να επιλέξετε. Βρίσκεται στην ίδια την αρχιτεκτονική της διαδρομής μεταφοράς Exchange, η οποία είναι ίδια σε κάθε μεταφορά. Η επανεκκίνηση του batch θα παράγει ακριβώς το ίδιο αποτέλεσμα: τους ίδιους Received: headers με τη νέα ημερομηνία μεταφοράς, και τα ίδια λανθασμένα INTERNALDATE. Θα χάσετε χρόνο και οι χρήστες θα ενοχληθούν δεύτερη φορά για τίποτα.

Κάποιοι διαχειριστές προσπαθούν επίσης να αλλάξουν τις ρυθμίσεις ταξινόμησης στο Outlook («ταξινόμηση κατά ημερομηνία αποστολής» αντί για «ημερομηνία λήψης»). Η ταξινόμηση κατά ημερομηνία αποστολής δεν αποτελεί λύση. Είναι επίδεσμος. Ο Date: header και το INTERNALDATE παραμένουν λανθασμένα για τους clients που δεν επιτρέπουν αυτή τη ρύθμιση, για το OWA, για το Outlook Mobile και για κάθε εφαρμογή τρίτου μέρους που προσπελαύνει το γραμματοκιβώτιο μέσω IMAP ή EWS.

Τι συμβαίνει στ' αλήθεια στα headers

Ορίστε ένα απλοποιημένο παράδειγμα αυτού που περιέχει ένα email μετά τη μεταφορά μέσω EAC. Το αρχικό header:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@palaiodominio.gr
Subject: Αναφορά Q1 2019

Μετά τη μεταφορά, το μήνυμα λαμβάνει στην αρχή της αλυσίδας κάτι τέτοιο:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Το Outlook βλέπει αυτόν τον Received: header πρώτο (προστίθεται στην κορυφή του μπλοκ headers), τον ερμηνεύει ως την πιο πρόσφατη ημερομηνία επεξεργασίας του μηνύματος και τον εμφανίζει ως ημερομηνία λήψης. Ο αρχικός Date: header του 2019 είναι ακόμα εκεί, άθικτος, λίγες γραμμές παρακάτω. Αλλά το Outlook δεν τον χρησιμοποιεί για την εμφάνιση στη λίστα μηνυμάτων.

Για να είμαστε ακριβείς: η συμπεριφορά διαφέρει ελαφρώς ανάλογα με την έκδοση του Outlook. Οι εκδόσεις μετά το 2021 (και ειδικά το νέο Outlook για Windows που αναπτύχθηκε από τα τέλη του 2023) είναι ιδιαίτερα ευαίσθητες σε αυτό το πρόβλημα, επειδή βασίζονται περισσότερο στα μεταδεδομένα Exchange Graph παρά στον ακατέργαστο Date: header. Αυτό σημαίνει ότι μεταφορές που δεν προκαλούσαν ορατό πρόβλημα με το Outlook 2016 μπορεί τώρα να δημιουργούν πρόβλημα με το νέο Outlook.

Ποιος επηρεάζεται πραγματικά

Οι πιο συνηθισμένοι διακομιστές IMAP πηγής σε αυτόν τον τύπο μεταφοράς είναι ο Dovecot (πολύ διαδεδομένος σε περιβάλλον Linux/cPanel) και ο Courier. Και οι δύο εκθέτουν INTERNALDATE μέσω IMAP που το EAC δεν διατηρεί. Αν μεταφέρετε από έναν Exchange on-premises διακομιστή στο Exchange Online (hybrid ή cutover migration), η συμπεριφορά είναι διαφορετική, επειδή η Microsoft χρησιμοποιεί εσωτερικό πρωτόκολλο μεταφοράς (MAPI/EWS) που διατηρεί καλύτερα τα μεταδεδομένα. Το πρόβλημα αφορά τη γενική IMAP μεταφορά μέσω EAC.

Οι χρήστες που επηρεάζονται περισσότερο είναι αυτοί που έχουν γραμματοκιβώτια με μακρύ ιστορικό (5 χρόνια και πάνω) και μεγάλο όγκο μηνυμάτων. Ένας χρήστης με 300 email θα ανακάμψει γρήγορα. Ένας εμπορικός διευθυντής με 12.000 email ταξινομημένα κατά ημερομηνία, στα οποία βασίζεται καθημερινά για να βρει ανταλλαγές με πελάτες, είναι παραλυμένος.

Γιατί ένα script της ανάγκης είναι κακή ιδέα εδώ

Κάποιοι διαχειριστές IT που κατανοούν το τεχνικό πρόβλημα μπαίνουν στον πειρασμό να γράψουν ένα script PowerShell ή Python για να διορθώσουν τα headers χειροκίνητα. Η βασική ιδέα μπορεί να φαίνεται απλή αφού έχετε εντοπίσει τον μηχανισμό. Αλλά η πραγματικότητα μιας διόρθωσης σε παραγωγικό περιβάλλον είναι εντελώς διαφορετική υπόθεση.

Πρώτα, οι οριακές περιπτώσεις. Τα email υπογεγραμμένα με S/MIME και τα μηνύματα κρυπτογραφημένα με PGP έχουν δομή που δεν επιτρέπει τροποποίηση των headers χωρίς να ακυρωθεί η υπογραφή. Τα μηνύματα multipart/alternative με κακοσχηματισμένα MIME boundaries (συχνά σε παλιούς διακομιστές Courier) μπορεί να καταστραφούν από ένα script που τροποποιεί το μήνυμα χωρίς να ανακατασκευάσει σωστά τη δομή. Τα headers μη-ASCII κωδικοποιημένα σύμφωνα με RFC 2047 (ονόματα αποστολέων με τονούμενους χαρακτήρες ή ιαπωνικά, για παράδειγμα) είναι κλασική πηγή σφαλμάτων.

Έπειτα, ο όγκος. Ένα script που λειτουργεί σε 50 δοκιμαστικά email σε περιβάλλον ανάπτυξης δεν διαχειρίζεται τα rate limits του API Exchange Online σε παραγωγή. Το σφάλμα 429 Too Many Requests στις 2 τα ξημερώματα κατά τη διάρκεια ενός batch 8.000 μηνυμάτων, χωρίς μηχανισμό επανέναρξης, σημαίνει άγρυπνη νύχτα και πιθανώς διπλά ή χαμένα μηνύματα.

Και το πιο σημαντικό: πώς να επαληθεύσετε ότι κάθε διορθωμένο email είναι άθικτο; Ότι καμία συνημμένη δεν έχει κοπεί, κανένα νήμα συνομιλίας δεν έχει σπάσει, ότι οι ετικέτες και οι φάκελοι διατηρούνται; Χωρίς μηχανισμό ατομικής επαλήθευσης, απλώς ελπίζετε ότι όλα πήγαν καλά.

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

Τι κάνει διαφορετικά το Redate.io

Το Redate.io συνδέεται στο Exchange Online μέσω των API Microsoft 365 (Azure Active Directory, δικαιώματα委任 σε επίπεδο tenant) και σαρώνει τα επηρεασμένα γραμματοκιβώτια για να εντοπίσει τα email των οποίων τα μεταδεδομένα ημερομηνίας έχουν καταστραφεί από τη μεταφορά. Αυτό το βήμα σάρωσης είναι δωρεάν και δίνει ακριβή εικόνα της έκτασης του προβλήματος: αριθμός επηρεαζόμενων μηνυμάτων, γραμματοκιβώτια που αφορά, εύρος κατεστραμμένων ημερομηνιών.

Ο ιδιόκτητος μηχανισμός διόρθωσης του Redate.io επεξεργάζεται στη συνέχεια κάθε email ξεχωριστά μέσω ενός pipeline πολλαπλών σταδίων ανάλυσης που περιλαμβάνει αντιστοίχιση προτύπων σε γνωστές υπογραφές εργαλείων μεταφοράς (συμπεριλαμβανομένης της διαδρομής μεταφοράς Exchange Online), επαλήθευση συμμόρφωσης RFC και έλεγχο δομικής ακεραιότητας του μηνύματος πριν και μετά τη διόρθωση. Τα email υπογεγραμμένα με S/MIME, οι σύνθετες δομές MIME, τα μη-τυπικά encodings: όλα αντιμετωπίζονται από ειδικές διαδρομές επεξεργασίας.

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

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

Για μεταφορές Exchange Online ειδικά, το Redate.io υποστηρίζει σύνδεση μέσω δικαιωμάτων εφαρμογής Azure AD (χωρίς να χρειάζεται να δημιουργήσετε ξεχωριστά credentials για κάθε γραμματοκιβώτιο), κάτι που κάνει τη διαχείριση μεγάλου αριθμού γραμματοκιβωτίων πολύ πιο εύκολη για έναν διαχειριστή IT ή MSP.

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

Τα email είναι εκεί, οι αρχικές ημερομηνίες επίσης. Ξεκινήστε μια δωρεάν σάρωση στο Redate.io για να δείτε ακριβώς πόσα μηνύματα επηρεάζονται στα γραμματοκιβώτια Exchange Online σας, πριν αποφασίσετε τι να κάνετε.