Migration iCloud σε Office 365: λάθος ημερομηνίες email

Ένα σενάριο μεταφοράς που χαλάει συστηματικά τις ημερομηνίες

Μόλις ολοκληρώσατε τη μεταφορά της αλληλογραφίας σας από το iCloud στο Office 365. Τα email είναι εκεί, οι φάκελοι είναι στη θέση τους, όλα φαίνονται τέλεια. Δευτέρα πρωί, φτάνει το πρώτο παράπονο: "Όλα τα παλιά μου email εμφανίζουν τη σημερινή ημερομηνία." Μετά ένα δεύτερο. Μετά δέκα.

Δεν πρόκειται για μεμονωμένο σφάλμα. Η μεταφορά από το iCloud Mail στο Office 365 είναι ένα από τα πιο τεκμηριωμένα σενάρια καταστροφής ημερομηνιών email, για πολύ συγκεκριμένους τεχνικούς λόγους που σχετίζονται τόσο με τη συμπεριφορά του Apple Mail, όσο και με το πρωτόκολλο IMAP, και με τον τρόπο που το Microsoft 365 επεξεργάζεται τα εισερχόμενα μηνύματα.

Γιατί το iCloud προς Office 365 χαλάει τις ημερομηνίες

Για να καταλάβουμε το πρόβλημα, πρέπει να ξεχωρίσουμε τρία πράγματα που πολλοί μπερδεύουν (ακόμα και έμπειροι διαχειριστές IT): την κεφαλίδα Date:, το INTERNALDATE του IMAP και την ημερομηνία δημιουργίας αρχείου.

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

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

Το INTERNALDATE του IMAP

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

Το πρόβλημα; Όταν ένα εργαλείο μεταφοράς αντιγράφει ένα email από έναν IMAP διακομιστή σε έναν άλλον, ιδανικά θα έπρεπε να διατηρεί το INTERNALDATE. Στην πράξη, δεν γίνεται πάντα έτσι.

Η ιδιαίτερη συμπεριφορά του Apple Mail

Το Apple Mail, όταν συγχρονίζει μηνύματα από το iCloud, χρησιμοποιεί μερικές φορές την ημερομηνία δημιουργίας αρχείου στην πλευρά του διακομιστή ως αναφορά για το INTERNALDATE. Δεν είναι σφάλμα με την αυστηρή έννοια, είναι μια ερμηνεία της προδιαγραφής IMAP που αποκλίνει από αυτό που κάνουν άλλοι clients. (Αν έχετε δοκιμάσει ποτέ να εντοπίσετε σφάλμα INTERNALDATE διαβάζοντας ακατέργαστα RFC IMAP, ξέρετε ότι η προδιαγραφή αφήνει αρκετά μεγάλο περιθώριο ερμηνείας σε αυτό το σημείο.)

Αποτέλεσμα: όταν εξάγετε ή μεταφέρετε από το iCloud μέσω Apple Mail, τα INTERNALDATE των μηνυμάτων μπορεί να είναι ήδη λανθασμένα πριν καν φτάσουν στο Office 365.

Οι τρεις μέθοδοι μεταφοράς iCloud και οι παγίδες τους

Άμεση μεταφορά IMAP

Η πιο συνηθισμένη μέθοδος είναι να ρυθμίσετε το iCloud ως πηγή IMAP και το Office 365 ως προορισμό, και στη συνέχεια να χρησιμοποιήσετε ένα εργαλείο μεταφοράς (imapsync, MigrationWiz ή κάποιο άλλο). Το εργαλείο συνδέεται και στους δύο διακομιστές και αντιγράφει τα μηνύματα.

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

Ορισμένα εργαλεία το κάνουν σωστά. Άλλα, όχι πάντα. Και σε ένα γραμματοκιβώτιο 40.000 μηνυμάτων, ακόμα και ένα ποσοστό σφάλματος 2% αντιστοιχεί σε 800 email με λάθος ημερομηνία.

Για μεταφορές μέσω imapsync, δείτε επίσης: διόρθωση ημερομηνιών imapsync στο Microsoft 365.

Εξαγωγή .mbox ή .eml και εισαγωγή

Μερικοί χρήστες εξάγουν τα email τους από το iCloud μέσω Apple Mail σε μορφή .mbox, και μετά προσπαθούν να τα εισαγάγουν στο Outlook. Είναι μια χειροποίητη μέθοδος που παράγει αποτελέσματα με μεγάλη διακύμανση.

Η μορφή .mbox κωδικοποιεί τα email ως ακολουθία μηνυμάτων κειμένου. Οι ημερομηνίες υπάρχουν στις μεμονωμένες κεφαλίδες Date:, αλλά η γραμμή διαχωρισμού μεταξύ μηνυμάτων ("From ") περιέχει μια ημερομηνία που μπορεί να ερμηνευθεί ως ημερομηνία δημιουργίας από ορισμένα εργαλεία εισαγωγής. Το Outlook, όταν εισάγει ένα .mbox μετατραπέν σε .pst, χρησιμοποιεί μερικές φορές αυτή τη γραμμή διαχωρισμού αντί της κεφαλίδας Date: του ίδιου του μηνύματος.

Drag-and-drop μέσω Outlook

Αυτή είναι η μέθοδος που προκαλεί τις μεγαλύτερες ζημιές. Ένας χρήστης ρυθμίζει και τους δύο λογαριασμούς στο Outlook (iCloud και Office 365), και μετά κάνει drag-and-drop τα μηνύματά του από έναν φάκελο στον άλλον. Φαίνεται απλό. Είναι καταστροφή για τις ημερομηνίες.

Όταν το Outlook μεταφέρει ένα μήνυμα με drag-and-drop μεταξύ δύο IMAP λογαριασμών, στην πραγματικότητα δημιουργεί ένα νέο αρχείο .EML, το εισάγει στον λογαριασμό προορισμού και διαγράφει το πρωτότυπο. Αυτό το νέο αρχείο κληρονομεί την ημερομηνία δημιουργίας αρχείου των Windows, δηλαδή τη στιγμή ακριβώς του drag-and-drop. Η αρχική κεφαλίδα Date: υπάρχει ακόμα στο σώμα του μηνύματος, αλλά το INTERNALDATE που καταγράφεται στον διακομιστή Exchange Online αντιστοιχεί στην ημερομηνία της ενέργειας. Το Outlook εμφανίζει στη συνέχεια αυτή την ημερομηνία μεταφοράς για όλα τα μηνύματα που μεταφέρθηκαν.

Για να είμαστε ακριβείς, αυτή η συμπεριφορά διαφέρει ανάλογα με την έκδοση του Outlook. Από την ενημέρωση του Outlook το φθινόπωρο του 2023, η συμπεριφορά βελτιώθηκε ελαφρώς για ορισμένα σενάρια, αλλά το drag-and-drop μεταξύ λογαριασμών παραμένει τεκμηριωμένη πηγή καταστροφής ημερομηνιών.

Τι εμφανίζουν τελικά το Office 365 και το Outlook

Το Exchange Online αποθηκεύει τα email με το INTERNALDATE τους. Το Outlook Desktop διαβάζει αυτό το INTERNALDATE για να εμφανίσει την ημερομηνία στη στήλη "Ελήφθη" και για να ταξινομήσει τα εισερχόμενα. Αν το INTERNALDATE έχει αντικατασταθεί κατά τη μεταφορά, το Outlook εμφανίζει την ημερομηνία μεταφοράς, τελεία και παύλα.

Το Outlook Web App (OWA) κάνει το ίδιο. Δεν υπάρχει «εναλλακτική προβολή» που θα έδειχνε την αρχική ημερομηνία της κεφαλίδας Date:. Αυτό που βλέπετε στη στήλη ημερομηνίας είναι το INTERNALDATE.

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

Τι δεν λύνει η υποστήριξη της Microsoft

Αν ανοίξετε ένα ticket στο Microsoft Support για αυτό το πρόβλημα, πιθανότατα θα λάβετε: επιβεβαίωση ότι οι ημερομηνίες που εμφανίζονται αντιστοιχούν στα αποθηκευμένα INTERNALDATE, πρόταση να ελέγξετε τις ρυθμίσεις ταξινόμησης στο Outlook, και ενδεχομένως παραπομπή στο εργαλείο μεταφοράς που χρησιμοποιήσατε.

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

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

Το πρόβλημα κλίμακας

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

Μερικοί διαχειριστές IT επιχειρούν να γράψουν script για τη διόρθωση. Η βασική ιδέα δεν είναι δύσκολη να συλληφθεί εννοιολογικά, αλλά η εκτέλεση σε πραγματικούς όγκους δημιουργεί προβλήματα που τα σπιτικά scripts δεν διαχειρίζονται καλά:

• Τα email υπογεγραμμένα με S/MIME ή κρυπτογραφημένα με PGP δεν μπορούν να τροποποιηθούν χωρίς να ακυρωθεί η κρυπτογραφική υπογραφή
• Τα μηνύματα με σύνθετες δομές multipart/alternative (HTML + απλό κείμενο + ένθετα συνημμένα) είναι εύθραυστα στη χειρισμό
• Οι κεφαλίδες κωδικοποιημένες σε non-ASCII (RFC 2047, ιδίως για ιαπωνικούς, αραβικούς ή κυριλλικούς χαρακτήρες) μπορούν να καταστραφούν από εργαλεία που δεν διαχειρίζονται σωστά αυτές τις κωδικοποιήσεις
• Τα όρια API του Microsoft Graph και τα όρια ρυθμού του Exchange Online (σφάλμα 429 Too Many Requests) σταματούν scripts που δεν έχουν σχεδιαστεί για διαχείριση εκθετικής καθυστέρησης
• Ένα script που τρέχει σωστά σε 500 email δοκιμής σταματάει στις 3 το πρωί στο 8.000ό μήνυμα ενός πραγματικού γραμματοκιβωτίου, χωρίς μηχανισμό επανεκκίνησης

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

Πώς το Redate.io διαχειρίζεται τις μεταφορές iCloud προς Office 365

Το Redate.io συνδέεται απευθείας στο Office 365 μέσω αδειών Microsoft 365 (Azure AD), χωρίς να χρειάζεται πρόσβαση στους διακομιστές του iCloud. Τα email βρίσκονται ήδη στο Exchange Online τη στιγμή που το Redate παρεμβαίνει.

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

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

Το Redate υποστηρίζει επίσης μεταφορές από Google Workspace προς Office 365 και διορθώσεις μετά από μεταφορά cPanel. Δείτε για παράδειγμα: διόρθωση ημερομηνιών email μετά από μεταφορά σε Microsoft 365 ή λάθος ημερομηνίες μετά από μεταφορά σε Exchange Online.

Πρώτα σάρωση, μετά διόρθωση

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

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

Αν οι ημερομηνίες των email σας είναι λανθασμένες μετά από μεταφορά από το iCloud, ξεκινήστε με τη δωρεάν σάρωση στο Redate.io για να μετρήσετε την έκταση του προβλήματος στα γραμματοκιβώτια Office 365 σας.