Outlook: ημερομηνία IMAP παραλαβής vs αποστολής

Το σύμπτωμα που όλοι γνωρίζουν

Μόλις ολοκληρώσατε μια μετεγκατάσταση IMAP σε Microsoft 365 ή Google Workspace. Δευτέρα πρωί, αρχίζουν τα tickets: "Όλα μου τα e-mail έχουν την ίδια ημερομηνία", "Το ιστορικό μου χάθηκε", "Δεν βρίσκω τίποτα στο γραμματοκιβώτιό μου". Ανοίγετε το Outlook και, ναι, χιλιάδες e-mail εμφανίζουν την ημερομηνία του προηγούμενου Σαββατοκύριακου. Όχι την ημερομηνία που στάλθηκαν. Την ημερομηνία που έγινε η μετεγκατάσταση.

Δεν είναι bug του Outlook. Είναι άμεση συνέπεια του τρόπου λειτουργίας του πρωτοκόλλου IMAP και των εργαλείων μετεγκατάστασης. Για να καταλάβουμε όμως γιατί συμβαίνει, πρέπει να ανοίξουμε το καπό.

Τρεις ημερομηνίες σε ένα μόνο e-mail

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

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

Αυτή είναι η ημερομηνία που έβαλε ο αποστολέας στο μήνυμά του τη στιγμή της αποστολής. Ορίζεται από το RFC 2822 και μοιάζει με αυτό:

Date: Tue, 14 Mar 2023 09:42:17 +0100

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

Η κεφαλίδα Received: (προστίθεται σε κάθε δρομολογητή δικτύου)

Κάθε διακομιστής που χειρίζεται ένα e-mail κατά τη διαμετακόμισή του προσθέτει μια κεφαλίδα Received: στην αρχή του μηνύματος, με τη δική του ημερομηνία. Ένα e-mail που περνά από τρεις διακομιστές συγκεντρώνει τρεις κεφαλίδες Received:. Η πιο πρόσφατη είναι πάντα πρώτη. Το αποτέλεσμα μοιάζει κάπως έτσι:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Αποτέλεσμα: όταν ένα εργαλείο μετεγκατάστασης όπως το BitTitan MigrationWiz, το CloudM, το imapsync ή το GSMMO μεταφέρει ένα e-mail από έναν πηγαίο διακομιστή σε έναν διακομιστή προορισμού, συμπεριφέρεται κι αυτό σαν "δρομολογητής δικτύου". Εισάγει μια νέα κεφαλίδα Received: στην κορυφή της στοίβας, με την ημερομηνία και ώρα της μετεγκατάστασης.

Το INTERNALDATE του IMAP

Αυτή είναι η τρίτη ημερομηνία, και είναι αυτή που δημιουργεί το πρόβλημα. Το INTERNALDATE είναι ένα μεταδεδομένο αποθηκευμένο από την πλευρά του διακομιστή IMAP, ανεξάρτητο από το περιεχόμενο του μηνύματος. Αντιπροσωπεύει την ημερομηνία κατά την οποία το e-mail παραδόθηκε (ή εισήχθη) στο γραμματοκιβώτιο. Όταν ένα εργαλείο μετεγκατάστασης εισάγει ένα e-mail μέσω της εντολής IMAP APPEND, αυτό είναι που επιλέγει τι τιμή θα δώσει στο INTERNALDATE. Και σε πολλές περιπτώσεις, τα εργαλεία χρησιμοποιούν την ημερομηνία της μετεγκατάστασης. Όχι την αρχική ημερομηνία.

Εκεί είναι που αρχίζουν τα προβλήματα.

Γιατί το Outlook εμφανίζει την ημερομηνία μετεγκατάστασης

Το Outlook χρησιμοποιεί το INTERNALDATE για να εμφανίσει τη στήλη "Παρελήφθη". Αυτή είναι η προεπιλεγμένη συμπεριφορά του, και είναι συνεπής με την προδιαγραφή IMAP: το INTERNALDATE υποτίθεται ότι αντιπροσωπεύει την ημερομηνία παραλαβής στο γραμματοκιβώτιο. Σε μια κανονική ροή (ένα πραγματικό e-mail που φτάνει), το INTERNALDATE είναι κοντά στην ημερομηνία της κεφαλίδας Date:. Τα δύο είναι συνεπή.

Μετά από μια αποτυχημένη μετεγκατάσταση, το INTERNALDATE όλων των εισαχθέντων e-mail δείχνει στη νύχτα της 14ης προς 15η Ιουνίου 2024 (ή οποιαδήποτε άλλη ημερομηνία έγινε η μετεγκατάσταση). Το Outlook διαβάζει αυτή την τιμή, την εμφανίζει στη στήλη "Παρελήφθη", και το αποτέλεσμα είναι καταστροφικό: 45.000 e-mail φαίνεται να έχουν ληφθεί την ίδια βραδιά.

Για να είμαστε ακριβείς, η πρώτη κεφαλίδα Received: (η πιο πρόσφατη στη στοίβα) επηρεάζει επίσης την εμφάνιση σε ορισμένες διαμορφώσεις. Αλλά το INTERNALDATE παραμένει ο κύριος καθοριστικός παράγοντας για τη στήλη "Παρελήφθη" του Outlook σε λειτουργία συγχρονισμένου IMAP.

Η παράκαμψη "Προσθήκη στήλης Αποστολής" στο Outlook

Το πρώτο πράγμα που κάνουν οι περισσότεροι διαχειριστές IT όταν ανακαλύπτουν το πρόβλημα είναι να αναζητήσουν μια παράκαμψη από την πλευρά του client. Και υπάρχει μία, όντως.

Στο Outlook, μπορείτε να τροποποιήσετε την εμφάνιση στηλών ενός φακέλου για να αντικαταστήσετε (ή να συμπληρώσετε) τη στήλη "Παρελήφθη" με τη στήλη "Ημερομηνία" ή "Αποστολή". Η στήλη "Ημερομηνία" διαβάζει απευθείας την κεφαλίδα Date: του μηνύματος, όχι το INTERNALDATE. Επειδή η κεφαλίδα Date: δεν επηρεάστηκε από τη μετεγκατάσταση, εμφανίζονται πάλι οι αρχικές ημερομηνίες.

Για να το κάνετε στο Outlook (desktop, έκδοση Microsoft 365): δεξί κλικ στην κεφαλίδα στήλης στη λίστα μηνυμάτων, "Ρυθμίσεις προβολής", και μετά τροποποιήστε τις στήλες για να αφαιρέσετε το "Παρελήφθη" και να προσθέσετε "Ημερομηνία". Μπορεί να γίνει μέσω GPO για μαζική ανάπτυξη.

Εντάξει. Στη θεωρία, αυτό λύνει το οπτικό πρόβλημα. Στην πράξη, είναι ένα επίθεμα πάνω σε αρτηρία.

Τα συγκεκριμένα όρια αυτής της παράκαμψης

Οι mobile και web clients

Το Outlook σε iOS, Android και στο Outlook Web App (OWA) δεν έχουν τις ίδιες επιλογές προσαρμογής. Η τροποποίηση προβολής που αναπτύξατε στους υπολογιστές Windows δεν μεταφέρεται εκεί. Οι χρήστες που ελέγχουν τα e-mail τους στο τηλέφωνο συνεχίζουν να βλέπουν την ημερομηνία μετεγκατάστασης. Και σε μια μεσαία επιχείρηση, αυτό είναι πιθανώς ο μισός αριθμός χρηστών.

Η αναζήτηση

Η αναζήτηση του Outlook χρησιμοποιεί το Windows Search index (ή τον δείκτη Exchange/Microsoft 365 από πλευράς διακομιστή). Αυτός ο δείκτης κατασκευάζεται βάσει του INTERNALDATE, όχι της κεφαλίδας Date:. Αν ένας χρήστης αναζητήσει "e-mail από τον Ιανουάριο 2022", η αναζήτηση επιστρέφει τα e-mail των οποίων το INTERNALDATE είναι τον Ιανουάριο 2022. Όχι εκείνα των οποίων η κεφαλίδα Date: είναι τον Ιανουάριο 2022. Αποτέλεσμα: τα παλαιότερα e-mail δεν εμφανίζονται πλέον στα φίλτρα ημερομηνίας. Η αλλαγή στήλης εμφάνισης δεν αλλάζει τίποτα σε αυτό.

Οι κανόνες αλληλογραφίας

Οι κανόνες Outlook ("αν το e-mail παρελήφθη πριν από...", "αν το e-mail παρελήφθη μετά από...") χρησιμοποιούν επίσης το INTERNALDATE. Ένας κανόνας ταξινόμησης ή αρχειοθέτησης βασισμένος σε χρονικές περιόδους δεν θα λειτουργεί σωστά μετά τη μετεγκατάσταση αν το INTERNALDATE δεν έχει διορθωθεί.

Συμμόρφωση και eDiscovery

Αυτό είναι ίσως το πιο σοβαρό σημείο. Τα εργαλεία συμμόρφωσης, νομικής αρχειοθέτησης και eDiscovery (όπως το Microsoft Purview) χρησιμοποιούν το INTERNALDATE ως ημερολογιακή αναφορά για νομικά ερωτήματα. Αν η επιχείρησή σας υπόκειται σε υποχρεώσεις διατήρησης δεδομένων (π.χ. βάσει του ΓΚΠΔ ή τοπικών φορολογικών απαιτήσεων) ή πρέπει να ανταποκριθεί σε αιτήματα discovery, τα κατεστραμμένα INTERNALDATE μπορούν να δημιουργήσουν πραγματικά νομικά προβλήματα. Ένας έλεγχος που ζητά "όλα τα e-mail μεταξύ τάδε και τάδε ημερομηνίας" δεν θα επιστρέψει τα σωστά αποτελέσματα.

Τα εργαλεία τρίτων

CRM, εργαλεία ticketing, αρχειοθέτες... οτιδήποτε συνδέεται στον mail server σας μέσω IMAP ή των API Microsoft 365/Google Workspace διαβάζει το INTERNALDATE. Η αλλαγή προβολής στο Outlook δεν διορθώνει τίποτα για αυτά τα συστήματα.

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

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

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

Στο Google Workspace, το Gmail API εκθέτει μια παράμετρο internalDate που επιτρέπει άμεση παρέμβαση σε αυτό το μεταδεδομένο. Στο Microsoft 365, ο μηχανισμός είναι διαφορετικός αλλά το αναμενόμενο αποτέλεσμα είναι το ίδιο. Σε έναν τυπικό διακομιστή IMAP, το πρότυπο προβλέπει ότι η ημερομηνία μπορεί να καθοριστεί κατά την εισαγωγή ενός μηνύματος.

Στην πράξη, η εκτέλεση αυτής της λειτουργίας σε δεκάδες χιλιάδες e-mail σε παραγωγικό περιβάλλον, χωρίς απώλεια δεδομένων, χωρίς διπλότυπα, χωρίς να σπάσουν τα νήματα συνομιλίας ή τις ετικέτες, διαχειριζόμενοι τις ακραίες περιπτώσεις (μηνύματα υπογεγραμμένα με S/MIME, σύνθετες δομές MIME, κωδικοποιήσεις non-ASCII κατά το RFC 2047, ογκώδη συνημμένα)... αυτό είναι άλλη ιστορία. Ένα script που λειτουργεί σε 50 δοκιμαστικά e-mail δεν θα αντέξει σε ένα γραμματοκιβώτιο με 40.000 μηνύματα. Η διαχείριση σφαλμάτων 429 (υπέρβαση ορίου API), των timeouts δικτύου στις 2 το πρωί, των μηνυμάτων με δομή MIME ήδη μερικώς κατεστραμμένη μετά τη μετεγκατάσταση... όλα αυτά απαιτούν σοβαρή μηχανική.

Αυτό ακριβώς κάνει το Redate.io. Ο ιδιόκτητος κινητήρας διόρθωσης αναλύει την αλυσίδα κεφαλίδων κάθε e-mail, εντοπίζει την αξιόπιστη αρχική ημερομηνία, και εφαρμόζει στοχευμένη διόρθωση μεταδεδομένων χωρίς να αγγίζει το περιεχόμενο του μηνύματος. Κάθε διορθωμένο e-mail επαληθεύεται ξεχωριστά. Τα πρωτότυπα διατηρούνται σε φάκελο backup για 30 ημέρες, κάτι που εξασφαλίζει δυνατότητα rollback ανά πάσα στιγμή. Κάτι που κανένα homemade script δεν προσφέρει ποτέ.

Εντοπισμός του εργαλείου μετεγκατάστασης που ευθύνεται

Το πρόβλημα εκδηλώνεται με τον ίδιο τρόπο ανεξάρτητα από την προέλευση της μετεγκατάστασης, αλλά οι λεπτομέρειες διαφέρουν ανάλογα με το εργαλείο που χρησιμοποιήθηκε. Το BitTitan MigrationWiz, το CloudM, το imapsync και το GSMMO έχουν το καθένα τη δική του υπογραφή στις κεφαλίδες Received: που εισάγουν. Το pipeline ανάλυσης του Redate.io διατηρεί μια βάση αντιστοιχίας για εκατοντάδες υπογραφές γνωστών εργαλείων μετεγκατάστασης, για να διακρίνει την κεφαλίδα μετεγκατάστασης από την υπόλοιπη νόμιμη αλυσίδα διαμετακόμισης.

Αν δεν γνωρίζετε ποιο εργαλείο χρησιμοποιήθηκε για τη μετεγκατάστασή σας (συμβαίνει, ειδικά όταν παραλαμβάνετε ένα περιβάλλον από άλλον MSP), το δωρεάν scan του Redate.io εντοπίζει τα επηρεαζόμενα γραμματοκιβώτια και δίνει εκτίμηση του όγκου προς διόρθωση πριν από οποιαδήποτε δέσμευση.

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

Τι να κάνετε τώρα

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

Μπορείτε επίσης να συμβουλευτείτε το άρθρο IMAP INTERNALDATE: γιατί χαλάνε οι ημερομηνίες για να εμβαθύνετε στη μηχανική του προβλήματος, ή τον πλήρη οδηγό για τις λάθος ημερομηνίες στο Outlook μετά τη μετεγκατάσταση αν θέλετε μια συνολική εικόνα των περιπτώσεων.

Έτοιμοι να διορθώσετε τις ημερομηνίες των γραμματοκιβωτίων σας; Ξεκινήστε ένα δωρεάν scan στο Redate.io για να εντοπίσετε τα επηρεαζόμενα e-mail και να εκτιμήσετε τον όγκο πριν από οποιαδήποτε διόρθωση.