Tüm eski e-postalarım aynı tarihi gösteriyor

Belirti: tüm eski e-postalarınız aynı tarihte gruplanmış

Bir sabah Outlook, Gmail veya Apple Mail'i açıyorsunuz. Bir şeyler yanlış. Yüzlerce, hatta binlerce eski e-posta aynı tarihi gösteriyor: birkaç gün önce ya da birkaç hafta önce. 2021'den, 2019'dan, 2016'dan kalma mesajlar dün gönderilmiş gibi görünüyor. Tarihe göre sıralama artık hiçbir anlam ifade etmiyor. Geçen yıldan önemli bir e-posta arıyorsunuz ve aynı günden gelmiş gibi görünen binlerce mesajın arasında kaybolup gidiyor.

Yeni e-postalar doğru tarihleri gösteriyor. Sorun yalnızca eski mesajlarda.

Ne olmuş olabilir?

İlk içgüdü: yazılımı suçlamak

Doğal olarak bir hata düşünüyorsunuz. Outlook çökmüş olabilir. Bir güncelleme kötü gitmiş olabilir. Dosya bozulmuş olabilir. Ve işte burada çoğunlukla uzun bir arayış başlıyor: "Outlook tarih hatası" diye arıyorsunuz, OST dosyalarından, SCANPST.exe'den, Outlook profilini sıfırdan yeniden oluşturmaktan söz eden forumlara denk geliyorsunuz...

İki saat her şeyi deniyorsunuz. Sorun devam ediyor.

Aslında SCANPST, yerel Outlook veri dosyalarını (bilgisayarınızda depolanan .pst veya .ost dosyaları) onarmak için bir araçtır. Belirli dosya bozulmalarını düzeltebilir, ancak posta sunucusunda depolanan verilere dokunmaz. Yani OST dosyanızı mükemmel şekilde onarsamanız bile tarihler yanlış kalmaya devam eder, çünkü sorun sizin tarafınızda değildir.

Sorun, sunucudaki e-postaların kendisindedir.

Gerçekte ne oldu: bir geçiş (migrasyon)

Neredeyse tüm vakalarda bu belirti bir e-posta migrasyonundan sonra ortaya çıkar. Şirketiniz eski bir sistemden Google Workspace'e, Microsoft 365'e ya da yeni bir sunucuya geçiş yaptı. Bir yerde biri, tüm e-postalarınızı bir yerden bir yere aktarmak için bir araç kullandı.

Bundan haberdar edilmemiş olabilirsiniz. Ya da haberdardınız ama tarih sorunuyla bağlantı kuramadınız. Bu tamamen normal.

Migrasyon araçları ciddi bir iş yapar: binlerce mesajı, klasörlerin tamamını, ekli dosyaları kopyalarlar. Ama oldukça sinsi bir yan etkileri var. Bir e-posta bir sunucudan diğerine aktarıldığında araç, e-postaya "Received:" (Alındı) adı verilen küçük bir teknik satır ekler. Bu satır mesajın yeni sunucuya ne zaman ulaştığını, yani migrasyon tarihini gösterir.

İşte sorunun kaynağı tam olarak bu.

E-posta istemciniz hangi tarihi göstereceğine nasıl karar veriyor?

Bir e-posta aslında teknik verilerinin içinde birden fazla farklı tarih barındırır. Orijinal gönderim tarihi (normalde gördüğünüz tarih) vardır, bir de mesajın internet üzerindeki her aktarım adımını kaydeden "Received:" başlıkları.

(Bir e-postada "Kaynağı görüntüle" ya da "Tam başlıkları gör" seçeneğine tıkladıysanız, anlaşılması güç bir metin bloğuna benzeyen bu gizemli satırları görmüş olabilirsiniz. Tam olarak bunlar.)

Normal koşullarda e-posta yazılımınız, e-postanın ne zaman gösterileceğini belirlemek için en son "Received:" başlığına bakar. Bu mantık mükemmel çalışır: son "Received:" başlığı her zaman mesajın gelen kutunuza ulaşmasına karşılık gelir, gönderimden birkaç saniye sonrasına.

Ancak migrasyonun ardından bu mantık aleyhinizdönüşür. Migrasyon aracı en üste, aktarım tarihiyle birlikte yeni bir "Received:" başlığı eklemiştir. E-posta yazılımınız bu başlığı ilk okuduğunda migrasyon tarihini görür ve onu gösterir. Orijinal gönderim tarihi hâlâ orada, e-postanın verilerinde daha aşağıda, sağlam şekilde duruyor. Ama yazılımınız ilk başlıkta durduğu için onu görmüyor.

Sonuç: 8.000 e-posta, hepsi aynı Kasım Salısı'ndan gelmiş gibi görünüyor.

Bu soruna hangi araçlar yol açıyor?

En yaygın migrasyon araçlarının hepsinde bu davranış var. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (Google'ın Outlook'tan geçiş için sunduğu ücretsiz araç) ve daha birçoğu. Bu aslında gerçek anlamda bir kusur değil: e-posta protokolünün teknik işleyişinin bir sonucu. Bu araçlar söz konusu başlığı ekliyor çünkü bir mesaj bir sunucudan diğerine aktarıldığında protokol bunu öngörüyor.

Sorun şu ki kullanıcılar bunun olacağı konusunda önceden uyarılmıyor.

Şirketiniz yakın zamanda e-posta sistemini değiştirdiyse ya da bilgi işlem departmanı "buluta geçiş" yaptıysa, sorunun kaynağı büyük ihtimalle bu. Etkilenen tarihlere bakarak doğrulayabilirsiniz: hepsi yaklaşık olarak aynı döneme denk geliyor mu? Eğer öyleyse, o dönem migrasyon tarihidir.

Kaçınılması gereken yanlış yöntemler

Forumlarda sıkça karşılaşılan ama işe yaramayan birkaç çözüm önerisi:

SCANPST ile veri dosyasını onarmak

Yukarıda belirttiğimiz gibi: SCANPST, yerel Outlook dosyalarını (.pst veya .ost) onarır. Sunucudaki e-postaları değiştirmez. Onarımdan sonra e-postalarınız hâlâ aynı yanlış tarihleri taşıyacak, çünkü bu tarihler e-postaların kendisinde, yerel dosyada değil.

Outlook profilini yeniden oluşturmak

Aynı mantık geçerli. Outlook profilini yeniden oluşturmak, yerel olarak sıfırdan başlamak ve ardından tüm e-postalarınızı sunucudan yeniden indirmek demektir. Yeniden indirilen e-postalar öncekiyle tamamen aynı yanlış tarihleri taşıyacak. Sadece her şeyi yeniden yapılandırmak için zaman harcamış olursunuz.

"Gönderim tarihi"ne göre sıralamak

Bazı forumlar Outlook'ta sıralama ölçütünü alım tarihinden gönderim tarihine geçirmeyi öneriyor. Bazı durumlarda yardımcı olabilir... ama her zaman değil. Ve başka yazılımlar, başka cihazlar ya da posta kutunuza erişen başka kişiler için hiçbir şey çözmez. Altta yatan neden hâlâ orada. Gönderim tarihine göre sıralama bir çözüm değil, geçici bir bant.

E-posta yazılımını yeniden yüklemek

Hayır. E-postalar sunucuda, yazılımın içinde değil. Outlook, Gmail, Apple Mail veya Thunderbird'ü yeniden yüklemek, çevrimiçi depolanan verilerde hiçbir şeyi değiştirmez.

İyi haber: gerçek tarihler hâlâ orada

Düzeltmeyi mümkün kılan önemli bir şeyi anlamak gerekiyor: her e-postanın orijinal gönderim tarihi silinmemiş. Hâlâ orada, e-postanın içinde, gönderen tarafından seçilen gönderim tarihine karşılık gelen "Date:" adlı bir başlıkta. Bu, tüm migrasyon araçlarının uyduğu bir e-posta standardıdır (RFC 2822 adlı teknik bir spesifikasyonla tanımlanmıştır), çünkü onu değiştirmek standartların ciddi bir ihlali olurdu.

Yani 14 Mart 2022'de bir e-posta aldıysanız, o e-posta verilerinin bir yerinde hâlâ o tarihi barındırıyor. Sadece yazılımınızın artık önce gösterdiği tarih bu değil.

Düzeltmeyi mümkün kılan tam olarak bu. Sorun bir veri kaybı değil. Bu bir meta veri okuma meselesi: e-posta yazılımınız yanlış tarihi okuyor, oysa doğru tarih hâlâ mevcut.

Bunu kendiniz düzeltmeye çalışmamalısınız

Bir BT uzmanının sorunu düzeltmek için basit bir script yazıp yazamayacağını merak ediyor olabilirsiniz. Ne olduğunu anlamak bir şey. Binlerce e-postayı tek birini kaybetmeden düzgünce düzeltmek bambaşka bir şey.

Bir e-posta düz bir metin dosyası değildir. Ekler, dijital imzalar, karmaşık formatlarda kodlanmış içerikler barındırabilir. Böyle bir mesajın meta verilerini yapısını bozmadan değiştirmek, onlarca özel durumu yönetmeyi gerektirir: elektronik imzalı mesajlar (S/MIME), şifreli e-postalar (PGP), standart dışı kodlamalar, çok parçalı yapılar... 20 test e-postasında çalışan bir script, 15.000 mesajlık bir üretim kutusunda büyük ihtimalle doğru çalışmayacaktır. Ve bir şeyler ters giderse, hiçbir e-postanın zarar görmediğini ya da kaybolmadığını nasıl doğrularsınız? Ev yapımı bir script'le: imkânsız.

Her e-posta için bireysel yedekleme ve doğrulama mekanizması olmadan gerçek bir yan hasar riski söz konusudur.

Redate.io ne yapıyor?

Redate.io tam olarak bu sorun için tasarlanmış bir hizmettir. Posta kutunuza (Google Workspace, Microsoft 365 veya bir IMAP sunucusu) bağlanır, tarihleri migrasyon nedeniyle bozulmuş e-postaları tespit eder ve her mesaj için başlık zincirinin tamamını analiz eden ve tarih meta verilerini yeniden oluşturan özel bir düzeltme motoru aracılığıyla bunları düzeltir.

Düzeltilen her e-posta tek tek doğrulanır. Orijinaller 30 gün boyunca görünür bir yedekleme klasöründe saklanır. Bir şeyler yanlış giderse geri dönebilirsiniz.

İlk tarama ücretsizdir: Redate.io posta kutunuzu analiz eder ve herhangi bir karar vermeden önce tam olarak kaç e-postanın etkilendiğini gösterir. Sürpriz yok.

Fiyatlandırma, düzeltilecek e-posta hacmine göre belirlenen tek seferlik bir ödemedir. Abonelik yok. Bir kez ödersiniz, sorun çözülür.

Taahhütte bulunmadan önce hasarın boyutunu görmek ister misiniz? Posta kutunuzun ücretsiz taramasını Redate.io'da başlatın ve kaç e-postanın etkilendiğini birkaç dakika içinde öğrenin.