Outlook: IMAP Migrasyonunda Alınan Tarih vs Gönderim Tarihi

Herkesin Tanıdığı Belirti

Microsoft 365 veya Google Workspace'e bir IMAP migrasyonu tamamladınız. Pazartesi sabahı ticketlar gelmeye başladı: "Tüm e-postalarım aynı tarihi gösteriyor", "Geçmişim mahvoldu", "Kutumda hiçbir şey bulamıyorum". Outlook'u açtığınızda gerçekten de binlerce e-postanın geçen haftasonu tarihini gösterdiğini görüyorsunuz. Gönderildiği tarihi değil. Migrasyon yapıldığı tarihi.

Bu bir Outlook hatası değil. IMAP protokolünün ve migrasyon araçlarının çalışma biçiminin doğrudan bir sonucu. Ama nedenini anlamak için kaputu açmak gerekiyor.

Tek Bir E-postada Üç Farklı Tarih

Bir e-posta, göründüğünden çok daha karmaşık bir yapıya sahiptir. Başlık, mesaj gövdesi, ekler... ve bir arada bulunan birden fazla zaman damgası. (E-posta ham başlıklarını okumaya çalıştıysanız, bunun plaj kitabı olmadığını zaten biliyorsunuzdur.)

Date: Başlığı (RFC 2822)

Bu, gönderenin mesajı iletirken eklediği tarihtir. RFC 2822 ile tanımlanmış olup şöyle görünür:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Bu başlık mesajın içine kazınmıştır. Birisi mesajın ham içeriğini değiştirmedikçe hiç değişmez. Katı anlamıyla "gönderim tarihi" budur.

Received: Başlığı (Her Ağ Atlamasında Eklenir)

Bir e-postaya geçiş sırasında dokunan her sunucu, kendi tarihiyle birlikte mesajın başına bir Received: başlığı ekler. Üç sunucudan geçen bir e-posta, üç adet Received: başlığı biriktirir. En güncel olan her zaman en başta yer alır. Görünümü şöyle olur:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Sonuç olarak, BitTitan MigrationWiz, CloudM, imapsync veya GSMMO gibi bir migrasyon aracı kaynak sunucudan hedef sunucuya e-posta taşıdığında, kendisi de bir "ağ atlaması" gibi davranır. Yığının en üstüne migrasyon tarihi ve saatiyle birlikte yeni bir Received: başlığı ekler.

IMAP INTERNALDATE

Üçüncü tarih budur ve sorunun asıl kaynağı da buradadır. INTERNALDATE, mesaj içeriğinden bağımsız olarak IMAP sunucu tarafında saklanan bir meta veridir. E-postanın posta kutusuna ulaştığı (veya eklendiği) tarihi temsil eder. Bir migrasyon aracı IMAP APPEND komutuyla e-posta eklediğinde, INTERNALDATE değerini kendisi belirler. Pek çok durumda araçlar, orijinal tarihi değil migrasyon anının tarihini kullanır.

Her şey işte burada bozulur.

Outlook Neden Migrasyon Tarihini Gösteriyor

Outlook, "Alındı" sütununu göstermek için INTERNALDATE değerini kullanır. Bu, varsayılan davranıştır ve IMAP spesifikasyonuyla tutarlıdır: INTERNALDATE'in posta kutusuna alınma tarihini temsil etmesi gerekir. Normal bir akışta (gerçekten gelen bir e-postada) INTERNALDATE, Date: başlığındaki tarife yakın olur. İkisi de tutarlıdır.

Başarısız bir migrasyon sonrasında ise içe aktarılan tüm e-postaların INTERNALDATE değeri 14-15 Haziran 2024 gecesini (veya hangi migrasyon tarihi ise onu) gösterir. Outlook bu değeri okur, "Alındı" sütununda gösterir ve sonuç felaket olur: 45.000 e-posta aynı akşam alınmış gibi görünür.

Daha doğru bir ifadeyle, yığındaki ilk Received: başlığı da bazı yapılandırmalarda görüntüyü etkiler. Ancak IMAP eşitlemeli modda Outlook'un "Alındı" sütunu için belirleyici olan yine INTERNALDATE'tir.

Outlook'ta "Gönderildi Sütunu Ekle" Geçici Çözümü

BT yöneticilerinin çoğunun sorunu fark ettiğinde yaptığı ilk şey, istemci tarafında bir geçici çözüm aramaktır. Ve gerçekten böyle bir çözüm var.

Outlook'ta bir klasörün sütun görünümünü değiştirerek "Alındı" sütununun yerine (veya yanına) "Tarih" ya da "Gönderildi" sütununu ekleyebilirsiniz. "Tarih" sütunu, INTERNALDATE'i değil mesajın Date: başlığını doğrudan okur. Date: başlığına migrasyon dokunmadığından, orijinal tarihler yeniden görünür hale gelir.

Bunu Outlook'ta yapmak için (masaüstü, Microsoft 365 sürümü): mesaj listesindeki sütun başlığına sağ tıklayın, "Görünüm Ayarları"na girin, ardından sütunları düzenleyerek "Alındı"yı kaldırın ve "Tarih" ekleyin. Toplu dağıtım için GPO üzerinden yapılabilir.

Kağıt üzerinde görsel sorunu çözer gibi görünür. Pratikte ise bu, bir atardamar üzerine yapıştırılan banttan farklı değildir.

Bu Geçici Çözümün Somut Sınırları

Mobil ve Web İstemcileri

iOS, Android'deki Outlook ve Outlook Web App (OWA), aynı özelleştirme seçeneklerine sahip değildir. Windows bilgisayarlara dağıttığınız görünüm değişikliği diğer platformlara yansımaz. Telefonundan e-postalarına bakan kullanıcılarınız migrasyon tarihini görmeye devam eder. Orta büyüklükteki bir şirkette bu, kullanıcıların yaklaşık yarısı demektir.

Arama

Outlook araması, Windows Search dizinini (veya sunucu tarafında Exchange/Microsoft 365 dizinini) kullanır. Bu dizin, Date: başlığından değil INTERNALDATE'ten oluşturulur. Bir kullanıcı "Ocak 2022'deki e-postalar" diye arama yaptığında, sonuçlar INTERNALDATE değeri Ocak 2022 olan e-postaları getirir. Date: başlığı Ocak 2022 olan e-postaları değil. Sonuç: eski e-postalar tarih filtrelerinde artık çıkmaz. Görünüm sütununu değiştirmek bunu hiç etkilemez.

Mesaj Kuralları

Outlook kuralları ("e-posta şu tarihten önce alındıysa...", "şu tarihten sonra alındıysa...") da INTERNALDATE kullanır. Tarih aralıklarına dayalı sıralama veya arşivleme kuralı, INTERNALDATE düzeltilmezse migrasyondan sonra doğru çalışmaz.

Uyumluluk ve eDiscovery

Bu belki de en kritik noktadır. Uyumluluk, yasal arşivleme ve eDiscovery araçları (örneğin Microsoft Purview) yasal sorgular için INTERNALDATE'i referans tarih olarak kullanır. Şirketinizin veri saklama yükümlülükleri varsa veya KVKK kapsamında incelemeye tabi olabilecekseniz, bozuk INTERNALDATE değerleri ciddi hukuki sorunlara yol açabilir. "Şu iki tarih arasındaki tüm e-postalar" talep eden bir denetim, doğru sonuçları getirmez.

Üçüncü Taraf Araçlar

CRM sistemleri, ticketing araçları, arşivleyiciler... posta sunucunuza IMAP veya Microsoft 365/Google Workspace API'leri üzerinden bağlanan her şey INTERNALDATE'i okur. Outlook görünümünü değiştirmek bu sistemlerde hiçbir şeyi düzeltmez.

Tek Gerçek Çözüm: Sunucu Düzeyinde Düzeltme

Outlook'ta gönderildi tarihine göre sıralama bir çözüm değildir. Bir banttan ibarettir. Gerçek düzeltme, istemci görünümünde değil sunucu meta verilerinde yapılmalıdır.

Somut olarak bu, her e-postanın INTERNALDATE değerinin orijinal Date: başlığına karşılık gelecek şekilde düzeltilmesi anlamına gelir. Orijinal Date: başlığı mesajın içinde hâlâ mevcuttur (migrasyon tarafından silinmemiştir), bu da düzeltmeyi mümkün kılar. Gerçek tarih bilgisi orada durmaktadır.

Google Workspace'te Gmail API, bu meta veri üzerinde doğrudan işlem yapmayı sağlayan bir internalDate parametresi sunar. Microsoft 365'te mekanizma farklıdır ama beklenen sonuç aynıdır. Standart bir IMAP sunucusunda ise norm, mesaj eklenirken tarihin belirtilebileceğini öngörür.

Pratikte, onlarca binlerce e-postayı üretim ortamında, veri kaybı olmadan, tekrar eden mesajlar oluşturmadan, iş parçacıklarını veya etiketleri bozmadan, uç durumları yöneterek (S/MIME imzalı mesajlar, karmaşık MIME yapıları, RFC 2047 uyarınca ASCII dışı kodlamalar, büyük ekler) gerçekleştirmek bambaşka bir iştir. 50 test e-postasında çalışan bir script, 40.000 mesajlık bir kutuda dayanamaz. Sabah 2'de gece yarısı oluşan 429 hataları (API kotası aşımı), ağ zaman aşımları, migrasyondan sonra MIME yapısı kısmen bozulmuş mesajlar... tüm bunlar ciddi bir mühendislik gerektirir.

Redate.io tam da bunu yapar. Tescilli düzeltme motoru, her e-postanın başlık zincirini analiz eder, güvenilir orijinal tarihi tespit eder ve mesaj içeriğine dokunmadan hedefe yönelik meta veri düzeltmesi uygular. Düzeltilen her e-posta tek tek doğrulanır. Orijinaller 30 gün boyunca yedekleme klasöründe saklanır; bu, her zaman geri alma imkânı sağlar. Bir ev yapımı scriptin hiçbir zaman sunmadığı bir güvence.

Sorumlu Migrasyon Aracını Belirleme

Sorun, migrasyonun kaynağından bağımsız olarak aynı şekilde ortaya çıkar. Ancak ayrıntılar kullanılan araca göre değişir. BitTitan MigrationWiz, CloudM, imapsync ve GSMMO'nun her birinin Received: başlıklarına enjekte ettikleri kendine özgü bir imzası vardır. Redate.io'nun analiz motoru, migrasyon başlığını geçerli transit zincirinin geri kalanından ayırt etmek için yüzlerce bilinen migrasyon aracı imzasını kapsayan bir eşleştirme veritabanı tutar.

Migrasyonda hangi aracın kullanıldığını bilmiyorsanız (özellikle başka bir MSP'den devralınan bir altyapıda bu normaldir), Redate.io'nun ücretsiz taraması etkilenen kutuları tespit eder ve herhangi bir taahhüt olmaksızın düzeltilmesi gereken e-posta hacmini tahmin eder.

Belirli durumlar için ayrıntılı kılavuzlar mevcuttur: Outlook'ta imapsync tarihlerini düzeltme, Outlook'ta BitTitan tarihlerini düzeltme veya Outlook'ta CloudM tarihlerini düzeltme.

Şimdi Ne Yapmalısınız

Bu makaleyi bir migrasyonun ardından okuyorsanız, iyi haber şudur: orijinal Date: başlığı her e-postanızın içinde sağlam durmaktadır. Gerçek tarih bilgisi her mesajda mevcuttur. Sorun içerikte değil, meta verilerdedir. Meta veriler ise düzeltilebilir.

Sorunun mekaniğini daha ayrıntılı anlamak için IMAP INTERNALDATE: Tarihler Neden Bozulur makalesine göz atabilirsiniz. Olası senaryolara genel bir bakış için ise Migrasyon Sonrası Outlook'ta Yanlış Tarihleri Düzeltme kılavuzu size kapsamlı bir değerlendirme sunar.

Posta kutularınızın tarihlerini düzeltmeye hazır mısınız? Redate.io'da ücretsiz tarama başlatın; etkilenen e-postaları tespit edin ve herhangi bir düzeltme yapmadan önce hacmi tahmin edin.