Διόρθωση Ημερομηνιών imapsync

Η Υπόσχεση του --syncinternaldates (και Πού Σταματά)

Εκτελέσατε την εντολή imapsync. Συμπεριλάβατε το --syncinternaldates επειδή διαβάσατε την τεκμηρίωση και είστε προσεκτικοί με αυτά. Η μεταφορά ολοκληρώνεται, το log λέει ότι όλα μεταφέρθηκαν, μηδέν σφάλματα. Μετά ανοίγετε το γραμματοκιβώτιο στο Outlook και κάθε email δείχνει τη χθεσινή ημερομηνία.

Αυτή είναι μία από τις πιο συχνές απογοητεύσεις με το imapsync, και μπερδεύει τους διαχειριστές IT τουλάχιστον από το 2017. Η σημαία --syncinternaldates υποτίθεται ότι διατηρεί το IMAP INTERNALDATE κατά τη μεταφορά. Και όντως το κάνει: δίνει σε κάθε αντίγραφο την εσωτερική ημερομηνία που κρατά ο server προέλευσης. Εκεί ακριβώς βρίσκεται η παγίδα.

Το imapsync είναι ένα open source εργαλείο σε Perl, γραμμένο από τον Gilles Lamiral, και είναι πραγματικά καλό σε αυτό που κάνει. Διαχειρίζεται μεταφορές γραμματοκιβωτίων IMAP προς IMAP με ένα επίπεδο αξιοπιστίας που ζηλεύουν τα περισσότερα εμπορικά εργαλεία. Όμως το imapsync μπορεί να αντιγράψει μόνο τις ημερομηνίες που βρίσκει, και εκεί τα πράγματα περιπλέκονται.

Πώς Λειτουργούν Πραγματικά οι Ημερομηνίες IMAP

Υπάρχουν τρεις διαφορετικές "ημερομηνίες" σε κάθε email, και οι περισσότεροι (συμπεριλαμβανομένων ορισμένων διαχειριστών IT) τις συγχέουν:

Το header Date: (RFC 2822) - η ημερομηνία που ο email client του αποστολέα σφράγισε στο μήνυμα κατά τη σύνθεσή του. Βρίσκεται μέσα στο σώμα του μηνύματος και δεν τροποποιείται ποτέ από τους mail servers.
Τα headers Received: - κάθε mail server που χειρίζεται το μήνυμα προσθέτει ένα με τη δική του χρονοσφραγίδα. Σχηματίζουν μια αλυσίδα από τον αποστολέα προς τον παραλήπτη. Το ανώτερο (πιο πρόσφατο) header Received είναι αυτό που ορισμένοι email clients χρησιμοποιούν για την εμφάνιση.
INTERNALDATE - μια χρονοσφραγίδα από την πλευρά του IMAP server, που ελέγχει πώς ταξινομούνται τα μηνύματα στο γραμματοκιβώτιο. Ορίζεται όταν το μήνυμα αποθηκεύεται για πρώτη φορά μέσω IMAP APPEND.

Όταν το imapsync μεταφέρει ένα μήνυμα, το διαβάζει από τον server προέλευσης (μαζί με το INTERNALDATE του) και το γράφει στον server προορισμού χρησιμοποιώντας IMAP APPEND. Η σημαία --syncinternaldates λέει στο imapsync να περάσει το INTERNALDATE της προέλευσης στον server προορισμού κατά το APPEND.

Τα καλά νέα είναι τα εξής: το Microsoft 365, το Outlook.com και το Gmail κρατούν την ημερομηνία που τους δίνεται. Άρα όταν οι ημερομηνίες βγαίνουν λάθος, το πρόβλημα βρίσκεται αλλού.

Γιατί οι Ημερομηνίες Μπορεί Ακόμα να Είναι Λάθος

Η προδιαγραφή IMAP (RFC 3501) λέει ότι αν παρέχεται μια ημερομηνία-ώρα με την εντολή APPEND, ο server θα έπρεπε να τη χρησιμοποιήσει. Το "SHOULD" στη γλώσσα των RFC σημαίνει "κάντε το εκτός αν έχετε καλό λόγο να μην το κάνετε". Το Microsoft 365, το Outlook.com και το Gmail το κάνουν: ένα αντίγραφο που φέρει την αρχική του ημερομηνία τη διατηρεί.

Αυτό που περνάει το imapsync, όμως, είναι η ημερομηνία που κρατά ο server ΠΡΟΕΛΕΥΣΗΣ για κάθε μήνυμα, όχι η ημερομηνία αποστολής του email. Σε ένα υγιές γραμματοκιβώτιο οι δύο ταιριάζουν. Σε ένα γραμματοκιβώτιο που έχει ήδη μεταφερθεί μία φορά ή έχει επαναφερθεί από αντίγραφο ασφαλείας, η προέλευση μπορεί να κρατά την ημερομηνία αυτής της προηγούμενης λειτουργίας, και το imapsync την αντιγράφει ως έχει.

Το Gmail αποτελεί ξεχωριστή περίπτωση μόνο όταν το αντίγραφο περνάει μέσω του API εισαγωγής του Gmail αντί για IMAP: αυτό το API προσθέτει μια γραμμή Received: με ημερομηνία την ημέρα του αντιγράφου, και το Outlook μπορεί να δείξει αυτή την ημερομηνία. Το imapsync μιλά IMAP, άρα δεν επηρεάζεται.

Οι Dovecot και Cyrus, οι δύο πιο συνηθισμένοι open source IMAP servers, κρατούν επίσης την ημερομηνία από το APPEND. Άρα όποιος και να είναι ο προορισμός, το ερώτημα είναι το ίδιο: ποια ημερομηνία κρατούσε η προέλευση;

Συνηθισμένα Λάθη στη Γραμμή Εντολών imapsync που Χαλάνε τις Ημερομηνίες

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

Αντιγραφή από προέλευση όπου οι ημερομηνίες ήταν ήδη λάθος

Το --syncinternaldates είναι ενεργό εξ ορισμού: το imapsync δίνει σε κάθε αντίγραφο την εσωτερική ημερομηνία που κρατά ο server προέλευσης (η τεκμηρίωσή του: "Sets the internal dates on host2 as the same as host1"). Αν το γραμματοκιβώτιο προέλευσης είναι το ίδιο αποτέλεσμα μιας προηγούμενης μεταφοράς ή επαναφοράς, οι εσωτερικές του ημερομηνίες μπορεί ήδη να είναι αυτές εκείνης της λειτουργίας, και το imapsync αντιγράφει πιστά τη λάθος ημερομηνία. Αυτή είναι η πιο συχνή αιτία, και η ευκολότερη να μη γίνει αντιληπτή, γιατί το log δείχνει δύο πανομοιότυπες ημερομηνίες.

Χρήση του --syncinternaldates με το --addheader

Μερικοί οδηγοί συνιστούν τη χρήση του --addheader για την εισαγωγή ενός προσαρμοσμένου header κατά τη μεταφορά. Η προσθήκη ενός header τροποποιεί το μήνυμα (μία ακόμα γραμμή στην κορυφή) αλλά όχι την ημερομηνία που περνάει το imapsync, άρα δεν εξηγεί λάθος ημερομηνίες. Το αντίγραφο απλά δεν είναι πλέον ίδιο με το πρωτότυπο, κάτι που έχει σημασία αν συγκρίνετε τα δύο.

Σύγχυση των --minage και --maxage με τη διατήρηση ημερομηνιών

Οι σημαίες --minage και --maxage φιλτράρουν ποια μηνύματα θα μεταφερθούν με βάση την ηλικία τους. Δεν επηρεάζουν τον τρόπο με τον οποίο αντιμετωπίζονται οι ημερομηνίες στον προορισμό. Έχω δει διαχειριστές να ξοδεύουν ώρες ρυθμίζοντας αυτές τις σημαίες, πιστεύοντας ότι θα διορθώσουν το πρόβλημα των ημερομηνιών. Δεν θα το κάνουν.

Κατηγορώντας το TLS για μετατοπισμένες ημερομηνίες

Μέσω TLS (--ssl1, --ssl2), η εγκατάσταση συνδέσεων προσθέτει καθυστέρηση, και σε μια μεγάλη μεταφορά (50.000+ μηνύματα) αυτή συσσωρεύεται σε ώρες. Δεν επηρεάζει τις ημερομηνίες: κάθε αντίγραφο φέρει την ημερομηνία που περνάει το imapsync, ανεξάρτητα από την ώρα που πραγματικά καταλήγει.

Ανάγνωση των Logs του imapsync: Τι Λέει Πραγματικά η Έξοδος

Το imapsync παράγει λεπτομερή logs, κάτι πολύ καλό. Όμως η έξοδος του log μπορεί να είναι παραπλανητική όσον αφορά τις ημερομηνίες.

Μια τυπική γραμμή επιτυχημένης μεταφοράς μοιάζει έτσι:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

Οι δύο ημερομηνίες ταιριάζουν. Αυτό σημαίνει ότι το imapsync έστειλε το σωστό INTERNALDATE στον προορισμό. Και το Microsoft 365, το Outlook.com και το Gmail κρατούν όλα την ημερομηνία που τους δίνεται. Όμως δύο πανομοιότυπες ημερομηνίες αποδεικνύουν μόνο ότι το αντίγραφο είναι πιστό στην ΠΡΟΕΛΕΥΣΗ: αν η ημερομηνία προέλευσης ήταν ήδη λάθος, και οι δύο στήλες δείχνουν την ίδια λάθος ημερομηνία.

Θέλετε να επαληθεύσετε τι συνέβη στην πραγματικότητα; Μετά τη μεταφορά, συνδεθείτε στον προορισμό με έναν IMAP client και ελέγξτε απευθείας το INTERNALDATE:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Αν η ημερομηνία που επιστρέφεται δεν είναι η ημερομηνία αποστολής του email, δείτε το ίδιο μήνυμα στην προέλευση: θα βρείτε εκεί την ίδια λάθος ημερομηνία. Το log δεν είπε ψέματα, αντέγραψε αυτό που του δόθηκε.

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

Μεταφορές imapsync Μεγάλης Κλίμακας: Όπου τα Προβλήματα Ημερομηνιών Πολλαπλασιάζονται

Η μεταφορά ενός μεμονωμένου γραμματοκιβωτίου με το imapsync είναι ενοχλητική όταν χαλάνε οι ημερομηνίες. Όμως οι MSP και τα τμήματα IT που τρέχουν το imapsync σε εκατοντάδες γραμματοκιβώτια αντιμετωπίζουν ένα εντελώς διαφορετικό μέγεθος προβλήματος.

Σκεφτείτε ένα τυπικό σενάριο εταιρικής μεταφοράς. Μεταφέρετε 200 γραμματοκιβώτια από έναν server Zimbra στο Microsoft 365. Γράφετε ένα wrapper script που διατρέχει ένα CSV χρηστών, καλώντας το imapsync για τον καθένα. Η μεταφορά τρέχει όλο το Σαββατοκύριακο. Τη Δευτέρα το πρωί, έχετε 200 γραμματοκιβώτια με λάθος ημερομηνίες, και περίπου 1,2 εκατομμύρια email συνολικά που δείχνουν τη χρονοσφραγίδα της μεταφοράς.

Μπορείτε να ξανατρέξετε το imapsync για να το διορθώσετε; Τεχνικά ναι, αλλά το imapsync θα παραλείψει μηνύματα που υπάρχουν ήδη στον προορισμό (είναι σχεδιασμένο να είναι idempotent). Θα χρειαζόσασταν το --delete2 για να αφαιρέσετε τα μηνύματα του προορισμού και να τα ξαναμεταφέρετε, κάτι ριψοκίνδυνο σε ένα γραμματοκιβώτιο παραγωγής. Και αν το πρόβλημα ήταν οι ημερομηνίες προέλευσης, μια δεύτερη εκτέλεση αντιγράφει ξανά τις ίδιες λάθος ημερομηνίες.

Μερικοί διαχειριστές δοκιμάζουν μια υβριδική προσέγγιση: τρέχουν το imapsync με --dry πρώτα για δοκιμή, και μετά την πραγματική μεταφορά. Όμως το --dry απλά προσομοιώνει τη μεταφορά: δείχνει τις ημερομηνίες που θα περνούσε το imapsync, όχι αν είναι οι ημερομηνίες αποστολής των email. Τίποτα δεν σας προειδοποιεί ότι οι ημερομηνίες προέλευσης είναι ήδη λάθος.

Λύσεις DIY και τα Όριά τους

Αν ψάξετε σε forums και mailing lists (η λίστα imapsync-devel στο SourceForge είναι ακόμα ενεργή στις αρχές του 2026), θα βρείτε προτάσεις που κυμαίνονται από δημιουργικές έως επικίνδυνες.

Μερικοί προτείνουν τη χρήση ενός Perl one-liner για την απευθείας τροποποίηση του INTERNALDATE στον server προορισμού. Άλλοι συνιστούν την εξαγωγή όλων των μηνυμάτων σε μορφή mbox, τον χειρισμό των ημερομηνιών, και την επανεισαγωγή τους. Λίγοι έχουν γράψει scripts σε Python που χρησιμοποιούν το imaplib για να ανακτήσουν, τροποποιήσουν και επανεισάγουν μηνύματα.

Όλες αυτές οι προσεγγίσεις μοιράζονται τα ίδια θεμελιώδη προβλήματα. Πώς χειρίζεστε μηνύματα υπογεγραμμένα με S/MIME χωρίς να σπάσετε την υπογραφή; Τι γίνεται με δομές multipart MIME με ενσωματωμένα boundaries; Με headers non-ASCII κωδικοποιημένα με RFC 2047; Με μηνύματα κρυπτογραφημένα με PGP, όπου δεν μπορείτε ούτε να επιθεωρήσετε το περιεχόμενο; Ένα script που χειρίζεται 50 δοκιμαστικά μηνύματα σε ένα dev περιβάλλον θα κολλήσει στις ακραίες περιπτώσεις ενός γραμματοκιβωτίου παραγωγής με 30.000 μηνύματα.

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

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

Πώς το Redate.io Διορθώνει Προβλήματα Ημερομηνιών του imapsync

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

Το Redate.io συνδέεται απευθείας στο γραμματοκιβώτιο (Google Workspace, Microsoft 365, ή οποιοδήποτε IMAP server), εντοπίζει, μέσω ανάλυσης, email με ανωμαλίες ημερομηνιών, και εφαρμόζει στοχευμένη διόρθωση μεταδεδομένων μέσω ιδιόκτητης ανάλυσης αλυσίδας headers και διαδικασίας ανακατασκευής ημερομηνιών. Δεν χρειάζεται να γνωρίζει ποιο εργαλείο έκανε τη μεταφορά: εντοπίζει τα email των οποίων η εμφανιζόμενη ημερομηνία δεν ταιριάζει με την αρχική τους ημερομηνία.

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

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

Το Redate.io λειτουργεί επίσης σε μεταφορές που έγιναν μήνες ή χρόνια πριν. Το header Date: δεν λήγει, ούτε λήγει η δυνατότητα να διορθωθεί ό,τι πήγε στραβά.

Μεταφέρατε με imapsync και έχετε κολλήσει με λάθος ημερομηνίες; Εκτελέστε δωρεάν ανάλυση για να δείτε ακριβώς πόσα email επηρεάζονται.

imapsync: Ημερομηνίες δεν Διατηρήθηκαν; Διόρθωση