Λάθος ημερομηνίες email μετά μεταφορά Zoho σε Microsoft 365

Τι συνέβη στο γραμματοκιβώτιό σας

Μόλις ολοκληρώσατε τη μεταφορά του domain σας από το Zoho Mail στο Microsoft 365. Η υποδομή Exchange Online είναι έτοιμη, τα γραμματοκιβώτια έχουν ενεργοποιηθεί, τα MX records έχουν ενημερωθεί. Και μετά, Δευτέρα πρωί, ένας χρήστης ανοίγει το Outlook και βλέπει ότι όλα τα e-mail του από το 2021 εμφανίζουν τη σημερινή ημερομηνία. Ένας άλλος παρατηρεί ότι τα μηνύματα του προηγούμενου χρόνου είναι ταξινομημένα στην κορυφή των Εισερχομένων, σαν να έφτασαν μόλις τώρα. Τα tickets αρχίζουν να συσσωρεύονται.

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

Η τεχνική αιτία: INTERNALDATE και Received headers

Ένα e-mail που είναι αποθηκευμένο σε έναν IMAP server αποτελείται από δύο διαφορετικά πράγματα: το ακατέργαστο περιεχόμενο του μηνύματος (τα headers RFC 2822, το σώμα, τα συνημμένα) και τα μεταδεδομένα αποθήκευσης που διαχειρίζεται ο IMAP server, μεταξύ των οποίων το INTERNALDATE. Αυτό το μεταδεδομένο χρησιμοποιούν τα προγράμματα e-mail για να εμφανίζουν και να ταξινομούν τα μηνύματα.

Το header Date: που ορίζεται στο ακατέργαστο μήνυμα (RFC 2822) αντιπροσωπεύει την ημερομηνία κατά την οποία το μήνυμα συντάχθηκε ή εστάλη από τον αποστολέα. Το INTERNALDATE, από την άλλη, είναι η ημερομηνία κατά την οποία ο IMAP server παρέλαβε ή αποθήκευσε το μήνυμα. Κανονικά, σε έναν server που λειτουργεί σωστά, οι δύο αυτές τιμές είναι κοντά. Μετά από μια μεταφορά, η ιστορία αλλάζει τελείως.

Πώς η μεταφορά IMAP καταστρέφει τις ημερομηνίες

Όταν ένα εργαλείο μεταφοράς (το Zoho Migration Wizard, το imapsync, το BitTitan ή οποιοδήποτε άλλο) μεταφέρει ένα μήνυμα από το Zoho Mail στο Exchange Online, το κάνει μέσω του πρωτοκόλλου IMAP. Το εργαλείο συνδέεται στο Zoho, ανακτά το μήνυμα και στη συνέχεια το εισάγει στο Exchange Online μέσω μιας εντολής IMAP APPEND. Και εκεί είναι που τα πράγματα πάνε στραβά.

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

Αποτέλεσμα: είτε πρόκειται για e-mail που στάλθηκε το 2019 είτε το 2022, το INTERNALDATE του δείχνει πλέον στην εβδομάδα της μεταφοράς. Το Outlook διαβάζει αυτή την τιμή κατά προτεραιότητα. Η ταξινόμηση καταρρέει.

Η συγκεκριμένη συμπεριφορά του Zoho Migration Wizard

Το Zoho προσφέρει το δικό του εργαλείο μεταφοράς για να φύγετε από την πλατφόρμα του: το Zoho Migration Wizard. Το εργαλείο αυτό είναι βολικό για απλές μεταφορές, αλλά έχει μια τεκμηριωμένη συμπεριφορά στα φόρουμ διαχειριστών: δεν μεταδίδει πάντα σωστά το αρχικό INTERNALDATE κατά την εισαγωγή στον server προορισμού.

Για να είμαστε ακριβείς, το πρόβλημα αφορά κυρίως τις μεταφορές προς servers που προσθέτουν συστηματικά ένα header Received: σε κάθε εισερχόμενο μήνυμα, κάτι που είναι ακριβώς η συμπεριφορά του Exchange Online. Ακόμα και αν το Zoho Migration Wizard περάσει την αρχική ημερομηνία μέσω της παραμέτρου APPEND, το header Received: που δημιουργεί το Exchange Online καταλήγει στην πρώτη θέση της αλυσίδας των headers, και το Outlook το χρησιμοποιεί αυτό για να καθορίσει "πότε έφτασε το e-mail".

Οι διαχειριστές που χρησιμοποιούν γενικά εργαλεία IMAP όπως το imapsync για να αποχωρήσουν από το Zoho αντιμετωπίζουν ακριβώς το ίδιο πρόβλημα, μερικές φορές χειρότερα, επειδή η προεπιλεγμένη διαμόρφωση του imapsync δεν είναι βελτιστοποιημένη για Exchange Online. (Κι αν έχετε ποτέ διαβάσει ένα log του imapsync γραμμή προς γραμμή ψάχνοντας ένα σφάλμα συγχρονισμού στις 2 τα ξημερώματα, ξέρετε ότι είναι ένα ισχυρό εργαλείο, αλλά όχι ιδιαίτερα συγχωρητικό για οριακές περιπτώσεις.)

Γιατί το Outlook εμφανίζει λάθος ημερομηνία

Το Outlook δεν χρησιμοποιεί αποκλειστικά το header Date: για να εμφανίσει την ημερομηνία ενός e-mail. Στην πλειονότητα των προβολών, χρησιμοποιεί το INTERNALDATE που παρέχει ο server IMAP/Exchange, ιδίως για την ταξινόμηση των Εισερχομένων. Το αρχικό header Date: είναι παρόν στο μήνυμα, ανέπαφο, αλλά αγνοείται υπέρ του INTERNALDATE.

Γι' αυτό η επιλογή "Ταξινόμηση κατά ημερομηνία αποστολής" στο Outlook δεν λύνει πραγματικά το πρόβλημα. Εμφανίζει μια διαφορετική ημερομηνία, ναι, αλλά η συμπεριφορά ταξινόμησης παραμένει ασταθής ανάλογα με την έκδοση του Outlook και τις ρυθμίσεις προβολής (ομαδοποιημένες συνομιλίες ή όχι). Η ταξινόμηση κατά ημερομηνία αποστολής δεν είναι λύση. Είναι ένα επίθεμα που πέφτει με την πρώτη ενημέρωση του client.

Η πραγματική έκταση του προβλήματος

Σε μια μεταφορά μεσαίου μεγέθους από Zoho σε Microsoft 365, μιλάμε εύκολα για 50.000 έως 500.000 μηνύματα που έχουν επηρεαστεί, ανάλογα με την ηλικία των γραμματοκιβωτίων και το μέγεθος του οργανισμού. Κάθε e-mail που μεταφέρθηκε κατά τη διάρκεια της μεταφοράς φέρει την ίδια αλλοιωμένη ημερομηνία, γεγονός που καθιστά το πρόβλημα άμεσα ορατό στους χρήστες από την πρώτη κιόλας φορά που ανοίγουν το Outlook.

Οι φάκελοι Απεσταλμένων είναι συχνά οι πιο προβληματικοί. Ένας πωλητής που ψάχνει μια προσφορά που έστειλε τον Μάρτιο του 2022 βρίσκεται να ψάχνει μέσα σε εκατοντάδες e-mail που εμφανίζουν όλα την ημερομηνία της μεταφοράς. Ο επιχειρησιακός αντίκτυπος είναι πραγματικός, όχι απλώς αισθητικός.

Και σε αντίθεση με ό,τι θα μπορούσε κανείς να πιστεύει, το πρόβλημα δεν εξαφανίζεται με τον χρόνο. Το INTERNALDATE ορίζεται τη στιγμή της εισαγωγής. Δεν διορθώνεται μόνο του. Χωρίς ενεργή παρέμβαση, τα e-mail θα διατηρήσουν την αλλοιωμένη ημερομηνία τους επ' αόριστον.

Γιατί η αυτόνομη διόρθωση είναι πιο επικίνδυνη απ' ό,τι φαίνεται

Ο πειρασμός είναι κατανοητός: αφού το αρχικό header Date: βρίσκεται πάντα στο μήνυμα, αρκεί να... διορθωθούν τα μεταδεδομένα. Στη θεωρία, έχει λογική. Στην πράξη, σε ένα γραμματοκιβώτιο παραγωγής με 80.000 e-mail, είναι μια επέμβαση που μπορεί να πάει καταστροφικά στραβά.

Ορισμένες οριακές περιπτώσεις που ένα script χαμηλού επιπέδου πιθανώς δεν θα χειριστεί σωστά:

• E-mail υπογεγραμμένα με S/MIME, όπου η υπογραφή καλύπτει το σύνολο των headers. Οποιαδήποτε αλλαγή στη δομή του μηνύματος ακυρώνει την κρυπτογραφική υπογραφή.
• Μηνύματα κρυπτογραφημένα με PGP, όπου το περιεχόμενο είναι αδιαφανές και κάθε χειρισμός των MIME envelopes μπορεί να καταστρέψει το μήνυμα.
• Non-ASCII headers κωδικοποιημένα κατά RFC 2047 (ονόματα αποστολέων με ειδικούς χαρακτήρες), που σπάνε αν το script δεν χειρίζεται σωστά την κωδικοποίηση.
• Συνημμένα κωδικοποιημένα σε base64 με μη κανονικά τερματισμένες γραμμές, μη τυπικά MIME boundaries, ή εμφωλευμένες multipart δομές.
• E-mail χωρίς έγκυρο header Date: (υπάρχουν, ιδίως σε παλαιά exports του Zoho), όπου το script πρέπει να αποφασίσει τι να κάνει.

Ένα script που λειτουργεί σε 50 e-mail δοκιμής δεν θα λειτουργήσει σε ένα γραμματοκιβώτιο παραγωγής Zoho που εξήχθη με χρόνια ιστορικό. Και πώς να επαληθευτεί, μήνυμα προς μήνυμα, ότι κάθε διόρθωση είναι άθικτη και ότι τα συνημμένα δεν έχουν κοπεί; Η επαλήθευση είναι τουλάχιστον εξίσου πολύπλοκη με την ίδια τη διόρθωση.

Υπάρχει επίσης το ζήτημα των quotas. Το API του Exchange Online μέσω του Microsoft Graph επιβάλλει αυστηρά rate limits (τα γνωστά σφάλματα 429 Too Many Requests). Ένα batch χωρίς throttling σε 100.000 μηνύματα μπορεί να προκαλέσει προσωρινές αποκλείσεις ή αθόρυβα σφάλματα δύσκολα να διαγνωστούν εκ των υστέρων. Χωρίς μηχανισμό επανεκκίνησης σε περίπτωση σφάλματος, ξεκινάτε από την αρχή.

Πώς το Redate.io διορθώνει τις ημερομηνίες μετά τη μεταφορά από Zoho

Το Redate.io συνδέεται στο tenant Microsoft 365 σας μέσω τυπικών δικαιωμάτων Azure AD, χωρίς global admin πρόσβαση. Η αρχική σάρωση είναι δωρεάν: το Redate.io εντοπίζει τα επηρεασμένα γραμματοκιβώτια και εκτιμά τον αριθμό των e-mail με λανθασμένες ημερομηνίες, συγκρίνοντας το INTERNALDATE με τις τιμές που φέρει η αλυσίδα headers του μηνύματος.

Η διόρθωση χρησιμοποιεί έναν ιδιόκτητο κινητήρα που αναλύει την πλήρη αλυσίδα headers κάθε μηνύματος, εντοπίζει τις ειδικές υπογραφές των εργαλείων μεταφοράς Zoho (είτε πρόκειται για το Zoho Migration Wizard είτε για το imapsync διαμορφωμένο για αποχώρηση από Zoho), και ανακατασκευάζει τα μεταδεδομένα ημερομηνίας μέσω ενός pipeline επικύρωσης πολλαπλών σταδίων. Κάθε διορθωμένο e-mail επαληθεύεται μεμονωμένα: ακεραιότητα περιεχομένου, διατήρηση συνημμένων, συμμόρφωση με RFC. Τα αρχικά μηνύματα διατηρούνται σε φάκελο backup προσβάσιμο για 30 ημέρες.

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

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

Παρεμφερή σενάρια που αξίζει να γνωρίζετε

Αν διαχειρίζεστε πολλαπλές μεταφορές παράλληλα, ή αν είστε MSP και διαχειρίζεστε πελάτες που αποχωρούν από το Zoho, αξίζει να σημειωθεί ότι το ίδιο πρόβλημα εμφανίζεται κατά τις μεταφορές από άλλες πλατφόρμες προς Exchange Online. Ο μηχανισμός είναι πανομοιότυπος: το header Received: που δημιουργεί το Exchange αντικαθιστά το INTERNALDATE ανεξάρτητα από την πηγή.

Για μεταφορές από Google Workspace, από Exchange on-premises, ή μέσω εργαλείων όπως το BitTitan MigrationWiz ή το CloudM, τα αντίστοιχα άρθρα στο blog του Redate.io αναλύουν τις συμπεριφορές που είναι ειδικές για κάθε εργαλείο. Το άρθρο Λάθος ημερομηνίες email μετά μεταφορά σε Exchange Online δίνει μια συνολική εικόνα όλων των σεναρίων που καταλήγουν σε αυτό το tenant.

Αν η μεταφορά σας περιλαμβάνει κοινόχρηστα γραμματοκιβώτια ή Exchange resources (αίθουσες, εξοπλισμό), το πρόβλημα είναι το ίδιο, και τα ίδια εργαλεία διόρθωσης εφαρμόζονται. Οι οδηγοί διόρθωσης IMAP προς Exchange στο site του Redate.io αναλύουν τα βήματα σύνδεσης στο tenant σας.

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

Οι ημερομηνίες από τη μεταφορά Zoho εξακολουθούν να εμφανίζονται λάθος στο Outlook; Σαρώστε τα γραμματοκιβώτιά σας δωρεάν στο Redate.io για να μετρήσετε την ακριβή έκταση του προβλήματος πριν αποφασίσετε πώς να δράσετε.