Microsoft 365'te imapsync taşıma tarihlerini düzeltme

Microsoft 365'e imapsync ile göç makul görünür. Ücretsizdir, betik desteği vardır ve çoğu senaryoda IMAP-IMAP aktarımlarını iyi yönetir. Ancak Microsoft 365'te, her e-postanın hangi tarihle kalacağına tek bir ayrıntı karar verir.

Exchange Online, kendisine verilen tarihi korur: imapsync bir e-postayı IMAP üzerinden yazdığında, her e-postanın dahili tarihini de birlikte iletir (--syncinternaldates seçeneği varsayılan olarak açıktır) ve kopya bu tarihi korur. Ancak imapsync'in ilettiği tarih, e-postanın gönderildiği tarih değil, KAYNAK sunucunun her mesaj için tuttuğu tarihtir. Sağlıklı bir posta kutusunda bu iki tarih eşleşir. Daha önce bir kez taşınmış veya bir yedekten geri yüklenmiş bir posta kutusunda ise kaynak, o önceki işlemin tarihini tutabilir ve imapsync bunu olduğu gibi kopyalar.

Bu, Microsoft 365'te veya imapsync'te bir hata değildir. Her kopya, kendisine verilen tarihi olduğu gibi taşır. Bu tarih kaynakta zaten yanlışsa, 500 veya 500.000 e-posta taşısanız da, etkilenen her e-posta alındığı tarih yerine o önceki işlemin tarihini gösterir.

BT müdürünüze hafta sonu çalıştırdığınız göçün 6 yıllık e-posta geçmişini tek bir tarihe düzleştirdiğini söylediğinizi hayal edin. Bu, yöneticilerin imapsync'ten Microsoft 365'e göç sonrası karşılaştığı gerçekliktir. Ve Google Workspace'in aksine (Gmail web istemcisinin sorunu gizleyebildiği), Microsoft 365 yanlış tarihi her yerde gösterir - Outlook masaüstü, OWA, Outlook mobil, Microsoft Search. İstemci tarafından bir çıkış yolu yoktur.

Microsoft 365'te hasar tamamen görünürdür. Her istemci - Windows için Outlook, Mac için Outlook, OWA, iOS ve Android'de Outlook mobil - göç zaman damgasını gösterir. Kullanıcılar tarihe göre sıralayamaz, e-postaları kronolojik olarak bulamaz, tarih aralığına göre filtrelenmiş arama sonuçlarına güvenemez. Tümü "12 Kasım 2024" gösteren 80.000 e-postalık bir posta kutusu, günlük iş için işlevsel olarak bozuktur.

Uyumluluk sonuçları daha kötüdür. Exchange Online Protection, Microsoft Purview ve saklama ilkeleri, hepsi bozuk teslimat zaman damgasını dizinler. 7 yıldan eski e-postaları silmek üzere ayarlanmış bir saklama ilkesi yanlış tarihle çalışır - bu, silinmeye yaklaşması gereken 2018'deki e-postaların şimdi 2024'ten gibi görünmesi anlamına gelir. KVKK, HIPAA veya SPK düzenlemelerine tabi kuruluşlar, e-posta saklamalarına güvenilmediğinde gerçek düzenleyici riskle karşı karşıya kalır. Ve "Q3 2023'teki tüm e-postalar" için bir yasal tutma talebi geldiğinde, bozuk tarihler Purview'ın hiçbir şey döndürmemesi anlamına gelir - çünkü üst verilere göre o dönemden e-posta mevcut değildir.

Redate.io, Microsoft 365'e bağlanır ve başlık zinciri analizi ile tarih üst veri yeniden yapılandırma sürecini etkilenen her mesaja uygular. Hangi aracın geçişi yaptığını bilmesi gerekmez: görüntülenen tarihi orijinal tarihiyle uyuşmayan e-postaları bulur. Her mesaj ayrı ayrı düzeltilir ve doğrulanır, orijinal bir yedek klasöründe saklanır. Redate.io, boyutu ne olursa olsun tüm posta kutusunu işler.