Yeni Outlook: Migrasyondan Sonra Yanlış Tarihler

İki Outlook, aynı e-postalara iki farklı tepki

Kısa süre önce Microsoft 365'e posta kutusu migrasyon yaptıysanız ve bazı kullanıcılar eski e-postalarının tamamının aynı tarihi (migrasyon tarihini) gösterdiğinden yakınıyorsa, ilginç bir şeyin farkına varmış olabilirsiniz: klasik Outlook kullanan kullanıcılar okuma bölmesinde zaman zaman doğru tarihi görürken, yeni Outlook for Windows kullananlar sürekli migrasyon tarihini görüyor. Aynı posta kutusu. Aynı e-postalar. Farklı sonuçlar.

Bu tam anlamıyla bir hata değil. Bir mimari tercihin IMAP migrasyonu sonrasında tarihlerin görüntülenme biçimine doğrudan yansımasıdır. Ne olduğunu anlamak için e-posta başlıklarının ve IMAP protokolünün ayrıntılarına girmek gerekiyor; bu pek de kolay bir okuma değil, ama istemci tarafında yapılan hiçbir müdahalenin sorunu neden çözemeyeceğini açıklıyor.

IMAP INTERNALDATE: asıl suçlu

Bir e-posta IMAP sunucusunda depolandığında, birbiriyle karışmayan iki farklı tarih türü vardır.

Birincisi, RFC 2822 tarafından tanımlanan Date: başlığıdır. Bu, mesajın içine yazılan, gönderenin e-postayı gönderirken eklediği tarihtir. Mesaj gövdesinin bir parçasıdır ve e-posta hangi yolu izlerse izlesin hiçbir zaman değişmez.

İkincisi ise INTERNALDATE'tir; mesajın dışında, IMAP sunucusu tarafından yönetilen bir metaveridir. Sunucunun mesajı kaydettiği tarihi gösterir. Normal bir migrasyonda ciddi araçlar orijinal INTERNALDATE'i korur. Ancak hatalı yapılandırılmış bir migrasyonda ya da bu metaveriyi doğru yönetmeyen araçlarla çalışıldığında, INTERNALDATE migrasyon gününün tarihine sıfırlanır. Sonuç: sunucunun gözünden tüm migrate edilen e-postalar aynı alış tarihini taşır.

(Bu arada imapsync ya da MigrationWiz günlüklerini hiç incelediyseniz, INTERNALDATE'i korumaya çalışmak için özel seçenekler olduğunu bilirsiniz. Bu seçenekler her zaman işe yaramaz; bazı hedef sunucular bunları kabul etmeyi reddeder.)

Klasik Outlook: tarihleri nasıl okur

Klasik Outlook, yani yerel olarak kurulan COM tabanlı sürümler (Outlook 2016, 2019, 2021 ve Microsoft 365 Apps masaüstü istemcisi), mesaj listesinde hangi tarihin gösterileceğini belirlemek için biraz daha karmaşık bir mekanizma kullanır.

Gönderilmiş klasöründeki e-postalar için Date: başlığına başvurur. Gelen e-postalar için önce sunucunun INTERNALDATE'ini kullanır; ancak belirli bağlamlarda (özellikle OST önbelleği devredeyken ya da okuma bölmesinde ilk görüntülemede) yaklaşık bir kaynak tarih oluşturmak için Received: başlık zincirini de okuyabilir.

Tutarsız davranışın nedeni tam olarak budur: klasik Outlook, ayrıntılı önizleme için orijinal Date: başlığını okuduğundan, okuma bölmesinde zaman zaman doğru tarihi gösterebilir; oysa e-posta listesinin kendisi bozulmuş INTERNALDATE'i kullanmaya devam eder. Ama dikkat, bu güvenilir değil ve hiçbir şeyi düzeltmiyor. Sıralama bozuk kalmaya devam eder, tarihe göre aramalar yanıltıcı sonuç vermeye devam eder.

Yeni Outlook: köklü biçimde farklı bir mimari

2023 sonu itibarıyla kademeli olarak dağıtılan yeni Outlook for Windows artık bir COM uygulaması değil. Temelde, Outlook on the web (OWA) ile aynı kod tabanına dayanan bir Progressive Web App (PWA). Bu yeniden tasarımın derin sonuçları var.

Yeni Outlook, tarihlerin görüntülenmesini tamamen Microsoft 365 API'sine bırakıyor. Received: başlıklarını okumuyor, kaynak tarihi bulmak için başlık zincirini kazımıyor ve istemci tarafında herhangi bir yeniden yapılandırma girişiminde bulunmuyor. Sunucunun döndürdüğünü, yani INTERNALDATE'i, doğrudan gösteriyor.

Sonuç: INTERNALDATE migrasyon sırasında bozulduysa, yeni Outlook hiç tereddüt etmeden etkilenen her e-posta için migrasyon tarihini gösteriyor; istisna yok, nüans yok. Klasik Outlook'a kıyasla daha tutarlı ve öngörülebilir bir davranış bu, ama migrasyon sorununu anında görünür kılıyor ve görmezden gelmeyi imkansız hale getiriyor.

Cuma akşamı 300 posta kutusunu migrate eden bir admin, Pazartesi sabahı yeni Outlook kullanan tüm kullanıcıların tüm arşivlerinin geçen hafta sonu tarihli göründüğünü keşfeder. Destek talepleri hızla birikir.

İstemci tarafı geçici çözümler neden işe yaramaz

Pek çok admin, sorunun sunucu verilerinde yattığını anlamadan önce istemci taraflı çözümler dener. Klasik girişimler ve neden başarısız oldukları şöyle:

"Alış tarihi" yerine "Gönderim tarihi"ne göre sıralama

Outlook'ta gönderim tarihine göre sıralama, mesajın içindeki sağlam kalan Date: başlığını kullanır. Yani bu sıralama işe yarayabilir. Ama bu bir bant-yara çözümü, kalıcı bir düzeltme değil. Tarihe göre aramalar bozuk kalmaya devam eder. Tarihe dayalı kurallar kullanılamaz hale gelir. Üstelik kullanıcının her klasörü, her posta kutusunu tek tek yeniden yapılandırması gerekir. 300 posta kutusunda bu gerçekçi değil. Gönderim tarihine göre sıralama bir çözüm değildir ve son kullanıcılar alışkanlıklarını neden değiştirmeleri gerektiğini anlamaz.

Outlook önbelleğini temizleme veya profili yeniden oluşturma

Bu, sunucu tarafındaki INTERNALDATE'e hiç dokunmaz. Profil yeniden oluşturulduktan sonra Outlook, e-postaları sunucudan yeniden eşitler ve tamamen aynı bozulmuş metaveriyi alır. Sorun önbellekten kaynaklanmıyor.

OWA kullanımına geçmek

OWA ve yeni Outlook aynı veritabanını paylaşıyor. Exchange Online'daki INTERNALDATE bozulduysa OWA da aynı yanlış tarihi gösterir. İstemciyi değiştirmek veriyi değiştirmiyor.

Sorun sunucuda, her mesajın metaverisinde. İstemci tarafında yapılacak hiçbir işlem, sunucu tarafında depolanan veriyi düzeltemez.

Received başlık tuzağı: her şeyi neden daha karmaşık hale getirir

Bir migrasyon aracı IMAP üzerinden bir e-postayı bir sunucudan diğerine kopyaladığında, hedef sunucu zincirin en üstüne otomatik olarak bir Received: başlığı ekler; ekleme tarihi ve saatiyle birlikte. RFC'yle uyumlu SMTP ve IMAP sunucularının normal davranışı budur.

Bu başlıklar, e-postanın izlediği yolun ters sırasında birikerek yığılır. En yenisi en üsttedir. Bazı posta istemcileri alış tarihini tahmin etmek için ilk Received: başlığını okur; bu da orijinal tarih yerine migrasyon tarihini verir.

Önemli bir not: bu davranış tek bir araca özgü değil. BitTitan MigrationWiz, CloudM, imapsync, GSMMO ve hatta iki Thunderbird istemcisi arasında yapılan manuel IMAP kopyalaması da aynı sonucu üretir. Orijinal Date: başlığı mesaj içinde sağlam kalır. Teknik olarak düzeltmeyi mümkün kılan da tam olarak budur. Oysa INTERNALDATE, sunucu tarafından yönetilen ayrı bir metaveridir ve yalnızca istemci tarafında mesaj başlıklarını değiştirerek düzeltilemez.

Bu mekanizma hakkında daha fazla bilgi için IMAP INTERNALDATE ve bozulan tarihler makalesine bakabilirsiniz; bu metaverinin sunucuya göre nasıl işlendiğini ayrıntılı biçimde açıklıyor.

Microsoft 365'te bu soruna yol açan migrasyon araçları

Sık sorulan bir soru: tüm migrasyon araçları bu soruna neden oluyor mu?

Kısa yanıt, yapılandırmaya ve hedef platforma bağlı olduğu. Exchange Online / Microsoft 365'te sunucu, INTERNALDATE yönetimi konusunda özellikle katıdır. INTERNALDATE'i korumaya çalışan araçlar bile zaman zaman başarısız olur; çünkü Graph API ve EWS (Exchange Web Services), kullanılan ekleme yoluna göre farklı davranır.

BitTitan MigrationWiz, Microsoft 365'e migrasyon için en yaygın kullanılan araçlardan biridir ve tarih sorunları en iyi belgelenmiş araçların da başında gelir. Microsoft 365'te BitTitan taşıma tarihlerini düzeltme sayfası, izlenecek özel yapılandırmaları ele alıyor. CloudM ve imapsync'in kendilerine özgü durumları için sırasıyla Microsoft 365'te CloudM taşıma tarihlerini düzeltme ve Microsoft 365'te imapsync taşıma tarihlerini düzeltme sayfalarına başvurabilirsiniz.

Tüm bu araçlar için ortak olan şu: orijinal Date: başlığı migrasyondan sağ çıkar. Bir düzeltmenin mümkün olmasının temeli de budur.

Neden elle yazılmış bir betik burada kötü bir fikir

Sorunu anlamak, çözümün basit olduğu yanılgısını zaman zaman yaratır. Üretim ortamı ölçeğinde değil.

Exchange Online'da depolanan e-postaların metaverisini değiştirmek basit değil. Microsoft'un Graph API'si katı hız sınırları uygular (gece toplu işlemde 429 Too Many Requests hatası hızla karşınıza çıkar). S/MIME imzalı veya PGP şifreli e-postalar, imzaları geçersiz kılmamak için özel dikkat gerektirir. Büyük ekler içeren multipart yapıları ağ zaman aşımı konusunda ek kısıtlar getirir. En önemlisi: içeriği veya ekleri değiştirmeksizin düzeltmenin başarıyla tamamlandığını e-posta bazında nasıl doğrularsınız?

50 test e-postasında sorunsuz çalışan bir betik, 8 yıllık geçmişe sahip 40.000 mesajlık bir posta kutusunda aynı şekilde davranmayacaktır. Her ek bin mesajla birlikte bir kenar durumun bir şeyleri bozma olasılığı artar. Geri alma mekanizması olmadan, işlemin ortasında oluşan bir hata posta kutusunu tutarsız bir durumda bırakır.

Kapsamlı bir genel bakış için Microsoft 365 migrasyonu sonrası e-posta tarihlerini düzeltme makalesine bakabilirsiniz.

Redate.io somut olarak ne yapar

Redate.io, her kullanıcı kendi Microsoft hesabıyla oturum açtığında ilgili posta kutusunu bu oturum açma işleminin verdiği erişimle açar, yanlış tarihlere sahip e-postaları ücretsiz olarak tarar, ardından tespit edilen mesajlara özel bir düzeltme motoru uygular. Çok aşamalı analiz pipeline'ı, yüzlerce bilinen migrasyon aracı imzasıyla eşleşme, RFC uyumluluk doğrulaması ve doğru tarih metaverisini yeniden oluşturmak için başlık zinciri analizi gerçekleştirir.

Düzeltilen her e-posta tek tek doğrulanır. Orijinal mesajlar hiçbir zaman silinmez, kendi posta kutunuzda görünür bir yedekleme klasöründe siz silene kadar durur. Fiyatlandırma modeli, abonelik olmaksızın posta kutusu başına tek seferlik ödemeye dayanır.

Yeni Outlook, sunucu verileri düzeltildiğinde doğru tarihleri gösterir; gizlenemez, gerçekten düzeltilmiş olur.

Yeni Outlook'ta etkilenen posta kutularınız mı var? Redate.io'da ücretsiz tarama başlatın ve nasıl devam edeceğinize karar vermeden önce kaç e-postanın etkilendiğini tam olarak öğrenin.