Shared hosting σε M365: το κρυφό πρόβλημα ημερομηνιών

Το πρόβλημα που κανείς δεν σας ανέφερε

Μόλις ολοκληρώσατε τη μετεγκατάσταση της αλληλογραφίας σας από OVH, Infomaniak, Ionos ή o2switch στο Microsoft 365. Ο οδηγός μετεγκατάστασης του EAC (Exchange Admin Center) έτρεξε όλη νύχτα, όλα είναι πράσινα, τα γραμματοκιβώτια είναι γεμάτα. Δευτέρα πρωί, πρώτο ticket: "Όλα τα παλιά μου email έχουν τη σημερινή ημερομηνία." Μετά ένα δεύτερο. Μετά δέκα.

Δεν είναι bug του Microsoft 365. Δεν είναι τυχαίο. Είναι το μηχανικό αποτέλεσμα μιας migration IMAP, και στην περίπτωση shared hosting, το πρόβλημα είναι συχνά δύο φορές πιο σοβαρό από μια κλασική μετεγκατάσταση. Να γιατί.

Πώς το IMAP διαχειρίζεται τις ημερομηνίες (και πού πάει στραβά)

Κάθε email αποθηκευμένο σε έναν διακομιστή IMAP έχει δύο διαφορετικούς τύπους χρονολόγησης. Από τη μία πλευρά, η κεφαλίδα Date: (ορισμένη από το RFC 2822), που βρίσκεται μέσα στο σώμα του μηνύματος και δείχνει πότε το μήνυμα στάλθηκε ή παραλήφθηκε. Από την άλλη, το INTERNALDATE, ένα μεταδεδομένο σε επίπεδο διακομιστή που υποδεικνύει πότε το μήνυμα τοποθετήθηκε στο γραμματοκιβώτιο. Αυτή η τιμή χρησιμοποιείται από τα προγράμματα email όπως το Outlook ως προεπιλογή για την ταξινόμηση και την εμφάνιση των email.

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

Όταν ένα εργαλείο migration IMAP μεταφέρει ένα μήνυμα από ένα γραμματοκιβώτιο σε άλλο, πρέπει να αναδημιουργήσει αυτό το INTERNALDATE στον προορισμό. Μερικά εργαλεία το κάνουν σωστά. Πολλά δεν το κάνουν, ή το κάνουν με περιορισμούς. Ο διακομιστής υποδοχής, από την πλευρά του, κρατάει ό,τι του δίνεται: όταν ένα αντίγραφο φέρει την αρχική ημερομηνία του, το Exchange Online τη διατηρεί. Έτσι, όταν οι ημερομηνίες εμφανίζονται λάθος, το εργαλείο είναι αυτό που πρέπει να εξεταστεί, όχι το Microsoft 365.

Αποτέλεσμα: κάθε email που μεταφέρθηκε φαίνεται να έχει "ληφθεί" την ημέρα της migration. Ανεξάρτητα αν χρονολογείται από το 2019.

Το σενάριο δύο σταδίων: γιατί το shared hosting τα κάνει χειρότερα

Εδώ η κατάσταση γίνεται πραγματικά προβληματική για τις μετεγκαταστάσεις από shared hosting όπως OVH, Infomaniak, Gandi, Ionos ή o2switch.

Αυτά τα hosting χρησιμοποιούν γενικά διακομιστές Postfix, Dovecot ή cPanel με τυπικές ρυθμίσεις IMAP. Πολλές μικρές και μεσαίες επιχειρήσεις έχουν συσσωρεύσει χρόνια email εκεί, μερικές φορές από το 2010 ή το 2012. Όταν αποφασίζουν να μεταβούν στο Microsoft 365, η μετεγκατάσταση γίνεται συχνά σε δύο φάσεις.

Φάση 1: η πρώτη καταστροφή (πριν καν το Microsoft 365)

Σε πολλές περιπτώσεις, τα email έχουν ήδη υποστεί μια πρώτη μετεγκατάσταση. Η εταιρεία άλλαξε hosting μία ή δύο φορές τα τελευταία χρόνια: από Gandi σε OVH το 2018, μετά από OVH σε Infomaniak το 2022, για παράδειγμα. Κάθε μεταφορά IMAP μπορεί να έχει επαναφέρει το αρχικό INTERNALDATE στην ημερομηνία της μεταφοράς (όποτε το εργαλείο δεν μετέφερε την αρχική ημερομηνία), και ορισμένα εργαλεία αφήνουν επίσης δικές τους κεφαλίδες migration, με ημερομηνία εκείνη την ημέρα.

Όταν τα email φτάνουν στο Microsoft 365, φέρουν ήδη σημάδια. Η αρχική κεφαλίδα Date: είναι άθικτη (αποτελεί μέρος του σώματος του μηνύματος, κανείς δεν την αγγίζει), αλλά τα μεταδεδομένα ημερομηνίας έχουν ήδη διαταραχθεί μια φορά.

Φάση 2: η δεύτερη καταστροφή κατά τη μεταφορά στο Exchange Online

Το εργαλείο migration IMAP του EAC, ή ένα τρίτο εργαλείο όπως το BitTitan MigrationWiz σε λειτουργία IMAP, επεξεργάζεται τότε αυτά τα ήδη κατεστραμμένα email. Αν αυτό το εργαλείο δεν μεταφέρει ούτε την αρχική ημερομηνία κάθε email, το Exchange Online καταχωρίζει το email με την ημερομηνία της μεταφοράς, και αυτή είναι η "ημερομηνία λήψης" που καταλήγει να δείχνει το Outlook.

Ένα email που στάλθηκε τον Μάρτιο 2017 μπορεί να φέρει δύο επίπεδα λανθασμένων ημερομηνιών: κεφαλίδες migration από τη μετακίνηση του 2022, και μια ημερομηνία λήψης από τη μεταφορά στο Microsoft 365 το 2024. Το Outlook δείχνει 2024. Ο χρήστης βλέπει 2024. Είναι λάθος σε δύο επίπεδα.

Για να είμαστε απόλυτα ακριβείς, δεν είναι πάντα η πιο πρόσφατη κεφαλίδα Received: που χρησιμοποιείται. Το Outlook καθορίζει την εμφανιζόμενη ημερομηνία βάσει συνδυασμού του INTERNALDATE του γραμματοκιβωτίου Exchange Online και των κεφαλίδων που υπάρχουν. Αλλά όποτε το εργαλείο μεταφοράς δεν μεταφέρει τις αρχικές ημερομηνίες, η μεταφορά στο Exchange Online προσθέτει ένα νέο επίπεδο λαθών πάνω από το παλιό.

Εργαλεία migration και hosting: οι επικίνδυνοι συνδυασμοί

Μερικοί συνδυασμοί εμφανίζονται πολύ συχνά σε μετεγκαταστάσεις από shared hosting:

• OVH / Infomaniak / Ionos + εργαλείο IMAP του EAC: το native εργαλείο της Microsoft είναι βολικό αλλά γνωστό για το ότι δεν διατηρεί σωστά τις ημερομηνίες σε μαζικές IMAP migrations.
• cPanel (o2switch, LWS, κ.λπ.) + BitTitan MigrationWiz σε λειτουργία IMAP: το MigrationWiz σε λειτουργία IMAP προσθέτει τις δικές του κεφαλίδες migration. Το αποτέλεσμα τεκμηριώνεται, μεταξύ άλλων, στη σελίδα μας διόρθωση ημερομηνιών BitTitan στο Microsoft 365.
• Gandi / Mailcow + imapsync: το imapsync είναι ένα ισχυρό εργαλείο αλλά η διαχείριση του INTERNALDATE εξαρτάται από τη ρύθμιση. Χωρίς την κατάλληλη επιλογή, οι ημερομηνίες δεν διατηρούνται. Δείτε επίσης imapsync: ημερομηνίες δεν διατηρήθηκαν.
• Κάθε χειροκίνητη migration με drag-and-drop στο Outlook: αν κάποιος αντέγραψε ολόκληρους φακέλους σέρνοντας και αποθέτοντας μεταξύ δύο λογαριασμών στο Outlook, το INTERNALDATE κάθε email ξαναγράφεται στην ημερομηνία της αντιγραφής. Χωρίς εξαίρεση.

Ο κοινός παρονομαστής: όλες αυτές οι μέθοδοι καταλήγουν στο Exchange Online με email των οποίων η εμφανιζόμενη ημερομηνία στο Outlook δεν αντιστοιχεί πλέον σε τίποτα πραγματικό.

Γιατί το "να το διορθώσετε μόνοι σας" είναι κακή ιδέα σε μεγάλη κλίμακα

Να καταλάβετε το πρόβλημα είναι ένα πράγμα. Να διορθώσετε 8.000 email κατανεμημένα σε 40 γραμματοκιβώτια Exchange Online, σε λογαριασμούς με σύνθετες δομές φακέλων, email υπογεγραμμένα με S/MIME, μεγάλα συνημμένα και ένθετα νήματα συνομιλιών, είναι εντελώς διαφορετικό.

Ένα script PowerShell που φαίνεται να λειτουργεί σε δέκα δοκιμαστικά email μπορεί να αποτύχει αθόρυβα στο μήνυμα αριθμός 4.237 λόγω κατεστραμμένου ορίου MIME ή κεφαλίδας κωδικοποιημένης σε RFC 2047 (αυτή η μορφή =?UTF-8?B?...?= για μη-ASCII χαρακτήρες σε ονόματα αποστολέων). Χωρίς μηχανισμό ατομικής επαλήθευσης, δεν θα το μάθετε. Απλά θα έχετε ένα χαμένο email.

Οι συγκεκριμένοι κίνδυνοι του DIY σε αυτού του τύπου migration:

• Διπλά μηνύματα αν η λογική εισαγωγής αποτύχει στη μέση
• Ελλείποντα συνημμένα αν η δομή multipart ανακατασκευαστεί λανθασμένα
• Σπασμένα νήματα συνομιλιών στο Outlook (οι συνομιλίες βασίζονται σε κεφαλίδες References: και In-Reply-To: που μπορεί να έχουν αλλοιωθεί)
• Σφάλματα 429 (Too Many Requests) από το Microsoft Graph API στις 3 τα ξημερώματα, που διακόπτουν την επεξεργασία χωρίς rollback
• Κανένας απλός τρόπος να επαληθεύσετε ότι και οι 8.000 διορθώσεις εφαρμόστηκαν σωστά

Και στη συγκεκριμένη περίπτωση των migrations από shared hosting, υπάρχει μια επιπλέον δυσκολία: τα email φέρουν πολλαπλά επίπεδα παρασιτικών κεφαλίδων Received:, όχι μόνο μία. Ένα απλό script που αφαιρεί "την τελευταία Received:" δεν αρκεί. Χρειάζεται να αναλύσετε ολόκληρη την αλυσίδα για να εντοπίσετε ποια κεφαλίδα αντιστοιχεί σε ποια migration, και ποια αντιπροσωπεύει πραγματικά την αρχική ημερομηνία λήψης.

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

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

Η διόρθωση βασίζεται σε ένα ιδιόκτητο μηχανισμό που αναλύει την πλήρη αλυσίδα κεφαλίδων κάθε μηνύματος, όποιο εργαλείο migration και να χρησιμοποιήθηκε, και ανακατασκευάζει σωστά τα μεταδεδομένα ημερομηνίας, ακόμα και όταν υπάρχουν πολλαπλά επίπεδα καταστροφής. Κάθε email που διορθώνεται επαληθεύεται ατομικά. Το Redate.io δεν διαγράφει ποτέ τα πρωτότυπα. Παραμένουν σε έναν ορατό φάκελο του γραμματοκιβωτίου σας μέχρι να τα διαγράψετε εσείς οι ίδιοι.

Για τις migrations από shared hosting, το pipeline πολυεπίπεδης ανάλυσης του Redate.io διαχειρίζεται ρητά τα σενάρια διπλής καταστροφής: δεν κοιτάει απλώς την τελευταία κεφαλίδα Received:, αναδρομεί στο πλήρες ιστορικό για να βρει την πραγματική ημερομηνία λήψης. Δείτε επίσης πώς να διορθώσετε τις ημερομηνίες μετά από migration στο Microsoft 365 γενικά, και τον ειδικό οδηγό για κατεστραμμένα INTERNALDATE σε IMAP για να κατανοήσετε την υποκείμενη μηχανική.

Πριν ή μετά τη migration: δύο στιγμές για να δράσετε

Δύο καταστάσεις, δύο προσεγγίσεις.

Δεν έχετε κάνει ακόμα migration. Τα καλά νέα: μπορείτε να περιορίσετε τις ζημιές. Ορισμένα εργαλεία migration (MigrationWiz σε λειτουργία Exchange, CloudM με τις σωστές επιλογές) διατηρούν καλύτερα τις ημερομηνίες από άλλα. Αλλά ακόμα και στην καλύτερη περίπτωση, μια migration από shared hosting χωρίς καθαρό ιστορικό πιθανώς θα αφήσει ίχνη. Προγραμματίστε ένα πέρασμα από το Redate.io μετά τη migration, πριν παραδώσετε τα γραμματοκιβώτια στους χρήστες.

Έχετε ήδη κάνει migration και τα tickets μπαίνουν. Το Redate.io διορθώνει τα υπάρχοντα γραμματοκιβώτια στο Microsoft 365, ανεξάρτητα από την ηλικία της migration. Η σάρωση σάς δίνει μια ακριβή εικόνα της πραγματικής κατάστασης κάθε γραμματοκιβωτίου πριν από οποιαδήποτε επέμβαση. Δείτε επίσης το checklist μετεγκατάστασης email για να αποφύγετε τα ίδια προβλήματα στο μέλλον.

Κάνατε migration από OVH, Infomaniak, Ionos ή o2switch στο Microsoft 365 και οι ημερομηνίες είναι λανθασμένες; Δημιουργήστε λογαριασμό στο Redate.io για να σαρώσετε δωρεάν τα γραμματοκιβώτιά σας και να δείτε ακριβώς την έκταση της ζημιάς πριν αποφασίσετε οτιδήποτε.