PST İçe Aktarma: Outlook'ta Tarihler Neden Bozulur?

Belirti: Tüm e-postalarınız bugünün tarihini gösteriyor

Outlook'ta PST içe aktarma işlemini yeni tamamladınız. İlerleme çubuğu %100'e ulaştı, her şey yolunda gitti. Gelen kutusunu açtınızda ise... içe aktarılan her e-posta bugünün tarihini gösteriyor. 2019'dan bir mesaj, 2021'den bir başkası, beş yıllık bir arşiv: hepsi aynı tarihi taşıyor. İçe aktarma gününün tarihini.

Bu bir görüntüleme hatası değil. Saat dilimi sorunu da değil. IMAP'ın tarih meta verilerini yönetme biçimiyle tamamen tutarlı, iyi belgelenmiş bir davranış. Ama eski e-postalarını tarihe göre bulmaya çalışan herkes için tam anlamıyla bir felaket.

Yerel PST ve IMAP: Birbirinden Çok Farklı İki Dünya

Tarihlerin neden bozulduğunu anlamadan önce, tarih yönetimi açısından bir PST dosyasının ne olduğunu kavramak gerekiyor.

PST (Personal Storage Table) dosyası, Microsoft'a ait tescilli bir formattır. E-postaları tüm meta verileriyle birlikte depolar: gönderim tarihi, alım tarihi, ekler, kategoriler, okundu göstergeleri. Bu meta veriler, herhangi bir mesajlaşma protokolü dışında, doğrudan Outlook tarafından yönetilir. Outlook'ta bir PST dosyasını sunucuya bağlanmadan açtığınızda, görüntülenen tarihler doğrudan PST dosyasının iç alanlarından gelir. Buraya kadar her şey yolunda.

Sorun, bu içeriği Microsoft 365, Google Workspace ya da herhangi bir klasik barındırıcı olsun, IMAP sunucusunda barındırılan bir posta kutusuna aktarmaya çalıştığınızda ortaya çıkıyor. PST dünyasından çıkıp IMAP dünyasına giriyorsunuz ve kurallar kökten değişiyor.

IMAP APPEND ve INTERNALDATE: Sorunun Özü

IMAP'ta sunucuda depolanan her mesajın iki tür tarih verisi vardır:

• Mesajın kendisinin içeriğinin bir parçası olan Date: başlığı (RFC 2822). Bu, gönderici tarafından mesaja yazılan tarihtir.
• IMAP sunucusu tarafından yönetilen bir meta veri olan INTERNALDATE. Mesajın sunucuya ne zaman teslim edildiğini temsil eder. Outlook'un "Alınma Tarihi" görünümünde mesajları sıralamak için kullandığı değer budur.

(Aslında, bir e-postanın ham başlıklarını okumayı hiç denedinizse, bunun pek de kolay bir okuma olmadığını bilirsiniz. Ama her şey orada gerçekleşiyor.)

Sunucunuza normal yollarla bir e-posta ulaştığında, posta sunucusu INTERNALDATE'i tam olarak alım anına otomatik olarak ayarlar. Sonuç olarak Outlook'ta görüntülenen tarih, mesajı gerçekten ne zaman aldığınızla örtüşür.

Outlook bir PST dosyasını IMAP posta kutusuna aktarırken, her mesajı sunucuya göndermek için IMAP APPEND komutunu kullanır. IMAP standardı, bir APPEND işlemi sırasında açık bir INTERNALDATE değeri iletilmesine izin verir. Ama Outlook bunu yapmıyor. Mesajları INTERNALDATE belirtmeden gönderiyor. IMAP sunucusu ise talimat olmadığında varsayılan kuralını uyguluyor: INTERNALDATE geçerli saat olarak, yani içe aktarma anı olarak ayarlanıyor.

Sonuç: 8.000 içe aktarılan e-posta, 8.000 e-postanın hepsi bugünün tarihiyle.

Outlook Neden Böyle Davranıyor?

Bu Microsoft'un bir unutması değil. Büyük ihtimalle o dönemde makul görünen bir uygulama tercihidir: PST içe aktarmanın orijinal kullanım senaryosunda, kullanıcı mesajları yerel olarak arşivler ve bunları mevcut posta kutusuna "aktarır". Sıralama için önemli olan tarih aslen orijinal alım tarihidir... ama Microsoft, içe aktarma işlemi sırasında INTERNALDATE'i iletmemeyi tercih etmiş.

Kesin olmak gerekirse, bu davranış Outlook'un yerleşik sihirbazı aracılığıyla yapılan PST içe aktarma işlemlerini etkiliyor (Dosya > Aç ve Dışarı Aktar > İçeri/Dışarı Aktar). Bazı üçüncü taraf araçlar ya da Exchange yönetim merkezi üzerinden gerçekleştirilen geçişler gibi diğer içe aktarma yöntemleri, IMAP APPEND uygulamalarına bağlı olarak farklı davranabilir.

Bu davranış yıllardır Microsoft forumlarında biliniyor ve belgelenmiş durumda. Outlook 2016 ile değişmedi, Outlook 2019 ile de değişmedi, şu anki Microsoft 365 sürümleriyle de değişmedi. Bugün PST içe aktaran bir kullanıcı, 2015'tekiyle tamamen aynı sorunla karşılaşıyor.

Klasik IMAP Migrasyonundan Farkı Nedir?

İşte bu noktada ilginçleşiyor, çünkü PST içe aktarma, bozuk tarihli klasik IMAP migrasyonuyla benzer bir sonuç üretiyor, ama farklı bir mekanizmayla.

Tipik bir IMAP migrasyonunda, örneğin BitTitan MigrationWiz veya imapsync ile gerçekleştirilende, e-postalar kaynak IMAP sunucusundan hedef IMAP sunucusuna taşınır. Migrasyon aracı mesajları alır ve IMAP APPEND aracılığıyla yeniden enjekte eder. Bazı araçlar INTERNALDATE'i doğru şekilde korur, bazıları korumaz. Ama her durumda, mesajların geçiş tarihiyle eklenen bir Received: başlığı zaten vardır; bu da INTERNALDATE'ten bağımsız olarak Outlook'taki görüntülemeyi bozabilir.

PST içe aktarmada mekanizma daha basittir: migrasyon sırasında eklenen Received: başlığı yoktur (PST dosyaları ara bir posta sunucusundan geçmez), ama INTERNALDATE hiçbir zaman doğru değere ayarlanmaz. Görünür sonuç aynıdır, altta yatan neden biraz farklıdır.

Bu farkın düzeltme üzerinde doğrudan bir sonucu var: IMAP migrasyonu mu yoksa PST içe aktarma mı işlediğinize göre benimsenmesi gereken yaklaşım tamamen aynı değil. Her iki durumun ayrıntılı açıklaması için INTERNALDATE'in tarihleri neden bozduğuna da bakabilirsiniz.

Outlook Görünüm Seçenekleri Neden Hiçbir Şeyi Düzeltmiyor

Sorunu keşfedince ilk tepki, Outlook ayarlarını kurcalamak oluyor. Gerçekten de umut verici görünen bir ayar var: e-postaları "Alınma Tarihi" yerine "Tarih" sütununa göre sıralama seçeneği.

Gönderim tarihine göre sıralama bir çözüm değil. Sadece bir yara bandı.

İşte nedeni: "Tarih" sütununu görüntüleyecek şekilde sıralamayı değiştirseniz bile (bu, mesajın Date: başlığına karşılık gelir, yani orijinal tarihe), birkaç sorun devam eder:

• Outlook araması INTERNALDATE üzerinden indeksler. "Ocak 2020'den e-postalar" araması, Ocak 2020'den içe aktarılmış e-postalarınızı döndürmez, çünkü bunların INTERNALDATE değeri içe aktarma gününü gösterir.
• Outlook arayüzündeki "Bugün", "Bu Hafta", "Bu Ay" klasörleri, Date: başlığına değil INTERNALDATE'e dayanır.
• Web arayüzlerinde (Outlook Web App, Gmail) ve mobil istemcilerde, görüntülenen tarih ve sıralama davranışı neredeyse her zaman sunucu INTERNALDATE'ine bağlıdır.
• Alım tarihine uygulanan otomatik kural ve filtreler düzgün çalışmaz.

Kısacası, görünümü değiştirmek yalnızca belirli bir kullanıcı için, belirli bir istemcide, belirli bir yapılandırmada görüntü sorununu çözer. Sorunu kaynağında düzeltmez. Daha ayrıntılı bir tartışma için gönderim tarihine göre sıralama neden çözüm değil yazısına bakın.

OST Yeniden Senkronizasyonu da İşe Yaramaz

Bir diğer klasik girişim: OST önbelleğini temizleyip sunucudan tam yeniden senkronizasyonu zorlamak. Sorunun sunucu değil, Outlook'un yerel önbelleğinden kaynaklandığı fikri.

Yanlış yön. OST dosyası, IMAP sunucusunun durumunu yansıtan yerel bir önbellektir. INTERNALDATE sunucuda hatalıysa, yeniden senkronizasyondan sonra OST'de de hatalı olacaktır. OST'yi silmek, Exchange Online veya Google Workspace sunucusunda depolanan verileri hiçbir şekilde değiştirmez. Yetkili olan sunucudur.

Tarihleri düzeltmenin tek yolu, meta verileri doğrudan sunucu tarafında, mesaj mesaj düzeltmektir. Ve işte tam burada manuel olarak yapmak karmaşık bir hal alıyor.

Ölçek Sorunu: 1 E-posta Önemsiz, 15.000 E-posta Bambaşka Bir Şey

Teknik olarak, sorunu anlayan biri her mesajın Date: başlığını okuyup INTERNALDATE'i buna göre düzelten bir betik yazmayı hayal edebilir. Sorunu anlamak ayrı bir şeydir. 15.000 e-postayı tek bir tanesini kaybetmeden düzeltmek ise bambaşka bir şeydir.

Pratikte karşılaşılan birkaç gerçeklik:

• Microsoft Graph ve Gmail API'leri hız sınırları (rate limit) uygular. Kaba bir betik 429 Too Many Requests hatalarını tetikler, düzeltme işleminin ortasında çalışmayı durdurur ve size hangi e-postaların işlenip hangilerinin işlenmediğini bilmeden kısmen düzeltilmiş bir posta kutusu bırakır.
• PST içindeki bazı e-postalar bozuk veya eksik Date: başlıklarına sahip olabilir. Bu uç durumları yönetemeyen bir betik bu mesajları bozabilir ya da sessizce atlayabilir.
• İmzalı (S/MIME) veya şifreli (PGP) e-postalar ek bütünlük kısıtlamalarına sahiptir. Meta verilerini dikkatsizce değiştirmek kriptografik imzayı geçersiz kılabilir.
• Karmaşık MIME sınırlarına sahip multipart/alternative yapıları, değiştirme işlemlerine zaman zaman öngörülemeyen tepkiler verir.
• Geri alma mekanizması yok. İşlem ortasında bir şeyler ters giderse başlangıç durumuna nasıl döneceksiniz?

10 test e-postasında çalışan bir betik, 50.000 mesajlık bir üretim posta kutusunda çalışmaz. Geçen yıl, 40 GB'lık bir PST arşivine sahip bir müşteri bunu Stack Overflow'dan alınan bir Python betiğiyle düzeltmeye çalıştı. Sonuç: 3.000 yinelenen e-posta, 200 erişilemeyen eki olan mesaj ve iki haftalık manuel temizlik.

Redate.io Bu Durumda Ne Yapıyor?

Redate.io, hedef posta kutusundaki her mesajın meta verilerini analiz eder, tarihleri hatalı olan e-postaları (PST içe aktarmadan gelenler dahil) tespit eder ve tescilli motoru aracılığıyla düzeltme uygular. Çok aşamalı analiz pipeline'ı her mesajın başlık zincirini karşılaştırır, orijinal tarihi RFC uyumluluk doğrulamasıyla çıkarır ve mesaj içeriğini değiştirmeden hedeflenmiş meta veri düzeltmesi gerçekleştirir.

Düzeltilen her e-posta tek tek doğrulanır. Orijinaller, herhangi bir kalıcı değişiklikten önce 30 gün boyunca görünür bir yedek klasöründe saklanır. Düzeltme üç ana platformda çalışır: Microsoft 365 (Azure AD aracılığıyla), Google Workspace (alan adı delegasyonu aracılığıyla) ve klasik barındırıcılar için doğrudan IMAP.

İlk tarama ücretsizdir. Herhangi bir karar vermeden önce kaç e-postanın etkilendiğini ve hatalı tarihlerin dağılımının ne olduğunu tam olarak görmenizi sağlar.

Ayrıca bakın:

• Microsoft 365 Migrasyonu Sonrasi Tarihleri Düzeltme
• Outlook: IMAP Migrasyonunda Alınan Tarih vs Gönderim Tarihi
• E-posta Tarihleri Migrasyondan Sonra Düzeltilebilir mi?

PST içe aktarma tüm e-postalarınızın tarihlerini mi ezdi? Redate.io üzerinde posta kutunuzu ücretsiz tarayın ve harekete geçmeden önce sorunun boyutunu ölçün.