Outlook Profili Yeniden Oluşturma: Tarihler Neden Bozulur?

Tarihleri bozan klasik sorun giderme hamlesi

Bir kullanıcı Outlook'un artık senkronize olmadığından şikayet eder. E-postalar gelmiyor, Gönderilmiş klasörü güncellenmiyor, yükleme çarkı dönüp duruyor. Teknisyen bozuk bir profil teşhis eder, OST dosyasını siler, Outlook profilini sıfırdan yeniden oluşturur. Sonuç: Outlook yeniden bağlanır, e-postalar tekrar görünür, her şey çalışıyor gibi görünür.

Ertesi sabah kullanıcı gelen kutusunu açana kadar. 8 yıllık yazışmanın tamamı aynı tarihi gösteriyor: bugün.

Bu, başarısız bir IMAP migrasyonuyla tamamen aynı belirti. Ve aynı nedenlerle.

Teknik olarak ne oluyor?

Profil yeniden oluşturmanın neden bu sonucu doğurduğunu anlamak için, teknisyenlerin çoğunun pek iyi bilmediği bir ayrıma geri dönmek gerekiyor: bir e-postanın Date: başlığı ile IMAP INTERNALDATE değeri arasındaki fark.

Her e-posta, RFC 2822 başlıklarında mesajın ne zaman gönderildiğini belirten bir Date: alanı taşır. Bu alan, gönderenin e-posta istemcisi tarafından gönderim anında yazılır ve tüm sunucular üzerinden değişmeden gelen kutunuza ulaşır. Hiçbir zaman değişmez. 14 Mart 2019'da 09:32'de gönderilmiş bir e-posta, sonrasında ne olursa olsun her zaman o Date: alanını korur.

IMAP INTERNALDATE ise bambaşka bir şey. Bu, mesajın içeriğinden bağımsız olarak posta sunucusunun yönettiği bir meta veri. Mesajın gelen kutusuna ne zaman "bırakıldığını" gösterir. Normal koşullarda, bir e-posta SMTP üzerinden geldiğinde sunucu alma saatini INTERNALDATE olarak kaydeder. Bu yüzden 14 Mart 2019'da alınan bir e-postanın INTERNALDATE'i gönderim tarihiyle tutarlıdır.

Outlook, varsayılan olarak e-postaları Date: başlığına göre değil, IMAP sunucusundan gelen INTERNALDATE değerine göre sıralar ve görüntüler. (Outlook'ta bir e-postanın ham başlıklarını görmek için tam özelliklerini açtıysanız, bunun pek de kolay okunur bir şey olmadığını bilirsiniz.)

OST dosyasını silmek ne tetikler?

Outlook bir IMAP hesabı kullandığında yerel bir veritabanı tutar: OST (Offline Storage Table) dosyası. Bu dosya, sunucuda depolanan e-postaların meta verileri, okunma durumları, kategorileri ve içerikleriyle birlikte yerel bir kopyasıdır.

OST dosyasını silmek, bu yerel kopyayı silmek demektir. Outlook'un her şeyi IMAP sunucusundan yeniden indirmesi gerekir.

Sorun şu: Outlook bir mesajı IMAP üzerinden yeniden indirirken içeriği almak için FETCH komutunu kullanır. Ancak orijinal IMAP tarihini alıp korumak için FETCH INTERNALDATE komutunu her zaman sistematik biçimde kullanmaz. Bazı Outlook yapılandırmalarında ve sürümlerinde istemci, sunucuda kayıtlı INTERNALDATE değerini değil, mesajı yeniden indirdiği tarihi kullanarak yerel dizinini yeniden oluşturur.

Ve böylece gelen kutusundaki tüm e-postalar, yeniden yükleme günü tarihini gösterir.

Tüm Outlook sürümleri aynı davranmıyor

Açıkçası, bu davranış Outlook'un tüm sürümlerini aynı şekilde etkilemiyor. İşte bu yüzden tanı koymak zorlaşıyor.

IMAP modunda Outlook 2016 ve 2019, önbellek silindikten sonra yanlış dizin yeniden oluşturma konusunda belgelenmiş davranışlara sahip. 2023 sonundan itibaren kademeli olarak dağıtılan yeni Outlook (web tabanlı), önbelleği farklı yönetiyor ve değişken sonuçlar üretebiliyor. Exchange/Microsoft 365 üzerinden Exchange modunda yapılandırılmış bir hesapla kullanılan Outlook ise bu soruna daha az maruz kalıyor; MAPI/Exchange protokolü senkronizasyonu IMAP'tan farklı biçimde yönetiyor.

Ama kullanıcınız klasik Outlook'ta IMAP hesabı kullanıyorsa ve bir teknisyen OST dosyasını sildiyse ya da profili yeniden oluşturduysa, risk gerçek.

Bu durumu gerçek bir migrasyondan nasıl ayırt edersiniz?

Profil yeniden oluşturmanın ardından "tarihlerim yanlış" ticketları alan bir IT yöneticisi, bunu yanlışlıkla migrasyon sorunu sanabilir. İki durumu ayırt etmenin yolu şu.

IMAP migrasyonu durumu

Bir IMAP migrasyonunda (BitTitan, CloudM, imapsync vb.) migrasyon aracı e-postaları bir sunucudan diğerine kopyalar. Kopyalanan her mesaj için hedef sunucuda IMAP APPEND komutuyla yeni bir kayıt oluşturur. Araç bu komutta orijinal INTERNALDATE'i açıkça belirtmezse, hedef sunucu o anki saati INTERNALDATE olarak kaydeder. Bazı araçlar ayrıca migrasyon tarihini taşıyan bir Received: başlığı ekler; bu da bazı istemcilerde sorunu daha da kötüleştirir. Bu mekanizmanın ayrıntısını IMAP INTERNALDATE ve bozuk tarihler yazımızda bulabilirsiniz.

Profil yeniden oluşturma durumu

Burada e-postalar hala aynı sunucuda, orijinal INTERNALDATE değerleriyle duruyor. Sunucu tarafında hiçbir şey değişmedi. Yanlış tarihlerle yeniden oluşturulan yalnızca Outlook'un yerel önbelleği. Görünür belirti aynı (tüm e-postalar aynı yakın tarihi gösteriyor) ama köken farklı.

Doğrulamak için: gelen kutusuna webmail üzerinden bağlanın (Gmail, Outlook.com ya da barındırıcınızın webmail arayüzü). Webmail'de görüntülenen tarihler doğruysa sorun yalnızca Outlook'ta yerel. Tarihler webmail'de de yanlışsa, sorun sunucu tarafında (migrasyon veya sunucuda INTERNALDATE değişikliği).

Orijinal tarihler neden kurtarılabilir?

İyi haber şu: her iki durumda da (migrasyon veya profil yeniden oluşturma), orijinal tarihler kaybolmadı.

RFC 2822 Date: başlığı mesajın ayrılmaz bir parçası. Mesajın gövdesi ya da ekleri kadar değişmez. 2017'de gönderilmiş bir e-postanın ham metninde şuna benzer bir satır yer alır:

Date: Mon, 12 Jun 2017 14:23:41 +0200

Bu satır sunucuda depolanan mesajın içinde mevcut. Değiştirilmedi. Outlook'un (hatalı biçimde) görüntülediği şey, mesaj içeriğinin dışındaki bir meta veri.

Bu düzeltmeyi mümkün kılan da bu. Redate.io'nun motoru, her mesajın başlık zincirini analiz ederek gerçek orijinal tarihi çıkarır, ardından mesaj içeriğine dokunmadan meta verilere hedefli bir düzeltme uygular. Outlook tarafından görülen INTERNALDATE, mesajda her zaman mevcut olan bu özgün bilgiden yeniden oluşturulur.

"Temiz" yeniden oluşturma tuzağı

Bir kullanıcının senkronizasyon sorununu az önce çözdünüz. Outlook'u yeniden çalışıyor, yeni e-postalar geliyor. Ticketı kapatıyorsunuz.

Üç gün sonra kullanıcı geri arıyor: geçen yıl bir tedarikçiden gelen bir e-postayı arıyor, ama Outlook'ta 2023'teki tüm e-postaları "dün" alınmış gibi görünüyor. Hiçbir şey bulamıyor. Otomatik arşivleme belki de yeni e-postaları eski olarak işleyerek sınıflandırmış olabilir. Ve yöneticisi bir anlaşmazlık için Eylül 2022'deki bir e-posta yazışmasını istiyor.

Bu senaryo sık karşılaşılıyor. Teknisyen işini yanlış yaptığı için değil, Outlook'un bu davranışı standart sorun giderme kılavuzlarında açıkça belgelenmiyor.

İşe yaramayan sahte çözümler

Outlook'ta e-postaları "Alınma Tarihi" yerine "Gönderim Tarihi"ne göre sıralamak, kullanıcıların denediği ilk şey. Ve işe yarıyor gibi görünüyor... ta ki gönderim tarihine göre sırelamanın yalnızca belirli klasörlerde kullanılabildiğini, görünüm değiştirildiğinde kaybolduğunu ve diğer uygulamaların (mobil, webmail, otomatik sıralama kuralları) hatalı INTERNALDATE'i kullanmaya devam ettiğini fark edene kadar.

Gönderim tarihine göre sıralama bir çözüm değil. Altta yatan soruna dokunmadan belirtiyi maskeleyen bir yama. Bunu Gönderim Tarihine Göre Sıralama Bir Çözüm Değil yazımızda ayrıntılı açıklıyoruz.

Profili ikinci kez yeniden oluşturmak? Outlook'un önbelleği yine o anki tarihle yeniden oluşturursa hiçbir şey değişmez.

PST olarak dışa aktarıp yeniden içe aktarmak? Dikkat. Tarihleri bozulmuş bir Outlook'tan yapılan PST dışa aktarımı, bozuk meta verileri de dışa aktarır. PST dosyası yanlış tarihleri içerecek. Bu dosyayı yeniden içe aktarmak hiçbir şeyi düzeltmez, hatta tutarsız tarihlerle yinelenen mesajlar oluşturarak durumu kötüleştirebilir. Bu konu PST içe aktarma ve tarih bozulması yazımızda ayrı olarak ele alınıyor.

Redate.io bu özel durumda ne yapıyor?

Sorun IMAP migrasyonundan ya da Outlook profili yeniden oluşturmaktan kaynaklanıyor olsun, sunucu tarafındaki sonuç benzer: tarih meta verileri gerçek içerikleriyle tutarsız olan e-postalar.

Redate.io doğrudan posta kutusuna bağlanır (Google Workspace, Microsoft 365 veya doğrudan IMAP), meta verileri yanlış olan mesajları tespit etmek için tüm içeriği tarar, ardından her e-postayı ayrı ayrı düzeltmek için çok aşamalı analiz pipeline'ını çalıştırır. Her düzeltme doğrulanır. Orijinal mesajlar hiçbir zaman silinmez, siz silmediğiniz sürece görünür bir yedek klasöründe kalır.

Bu süreç, ev yapımı scriptlerin sistematik olarak başarısız olduğu uç durumları yönetir: S/MIME imzalı mesajlar, başlıklarda ASCII dışı kodlamalar içeren e-postalar (RFC 2047), karmaşık çok parçalı yapılar, standart dışı veya hatalı biçimlendirilmiş zaman dilimleri içeren Date: başlıkları. Geliştirme ortamındaki bir test kutusunda 50 e-posta üzerinde düzgün çalışan bir script, üretimdeki 2.000 mesajı onarılamaz biçimde bozabilir. IMAP'ta önceden yedek alınmadan değiştirilen bir mesaj için yerel geri alma mekanizması yoktur.

Outlook'a özgü durumlar için Outlook'ta manuel IMAP kopyalama tarihlerini düzeltme sayfası, posta kutunuzu bağlamak ve analizi başlatmak için adımları ayrıntılarıyla açıklıyor.

Sonraki müdahalelerde sorunu önleme

Outlook profillerini düzenli olarak ele alan bir teknisyen veya IT yöneticisiyseniz, birkaç alışkanlık bu durumdan kaçınmanızı sağlar.

OST dosyasını silmeden veya profili yeniden oluşturmadan önce webmail'de görüntülenen tarihleri kontrol edin. Tarihler doğruysa bunu ticketa not düşün. Yeniden oluşturmadan sonra webmail'e tekrar bağlanın ve tarihler ile Outlook'ta gösterilen tarihleri karşılaştırın. Bir farklılık görünürse sorun hemen tespit edilir, kullanıcı üç gün sonra şikayet etmeden.

Planlı migrasyonlar için e-posta migrasyonu kontrol listesi, bu tür sorunları operasyon tamamlandığında tespit etmek üzere öncesinde ve sonrasında yapılması gereken kontrolleri sıralıyor.

Outlook profilini yeniden oluşturdunuz ve posta kutunuzdaki tüm tarihler yanlış mı? Redate.io'da ücretsiz tarama başlatın ve mesajlarınızın içeriğine dokunmadan etkilenen e-postaları tespit edip meta verileri düzeltin.