Exchange Online Migrasyonu Sonrası Yanlış E-posta Tarihleri

Klasik Pazartesi Sabahı Senaryosu

IMAP'tan Exchange Online'a migrasyonu tamamladınız. Batch, Exchange yönetim merkezinde hatasız bitti; posta kutuları senkronize, kullanıcılar bağlanabiliyor. Cuma akşamı bilgisayarınızı kapatırken işi bitirmenin rahatlığıyla evine gidiyorsunuz.

Pazartesi sabahı biletler gelmeye başlıyor. "Tüm e-postalarım Cuma tarihli görünüyor." "Gelen kutusu geçmişim kullanılamaz hale geldi." "Eski e-postalar kaybolmuş." Aslında hiçbir şey kaybolmadı: e-postalar orada, ama Outlook onları orijinal gönderim tarihleri yerine migrasyon tarihiyle gösteriyor. 2019'dan kalma bir e-posta geçen Cuma tarihli görünüyor. Sonuç: posta kutusu sanki yalnızca son birkaç günün mesajlarını içeriyormuş gibi duruyor.

Bu, IMAP'tan Exchange Online'a migrasyonların en sinir bozucu sorunlarından biridir ve Microsoft tarafından neredeyse hiç belgelenmemiştir.

EAC Migrasyonu Neden Tarihleri Bozuyor

Exchange yönetim merkezini (EAC) kullanarak yerel bir sunucudan (Dovecot, Courier, Cyrus, UW-IMAP, hangisi olursa olsun) IMAP migrasyonu yapılandırdığınızda, Exchange Online kaynak sunucunuza IMAP üzerinden bağlanır, mesajları alır ve bunları kendi dahili taşıma hattı aracılığıyla hedef posta kutularına aktarır.

Sorun tam burada başlıyor.

Exchange taşıma hattından geçen her e-posta otomatik olarak zaman damgalı bir Received: başlığı alır. Bu, SMTP ve IMAP sunucularının onlarca yıldır uyguladığı standart bir davranıştır: bir mesaja dokunan her sunucu kendi zaman imzasını ekler. Sorun şu ki Outlook (özellikle son sürümlerde Windows için Outlook), diğer meta veriler belirsiz olduğunda görüntüleme referansı olarak en son Received: başlığını kullanır.

Orijinal Date: başlığı (e-postanın gerçekten ne zaman gönderildiğini gösteren, RFC 2822 anlamında) mesajın içinde hâlâ mevcut. Silinmedi. Ama Exchange'in enjeksiyon sırasında eklediği yeni Received: başlığının gölgesinde kalıyor.

Bir de IMAP INTERNALDATE meselesi var: IMAP sunucularının mesajları dahili olarak tarihlendirmek için kullandığı ve çoğu istemcideki sıralamayı yöneten bu meta veri, enjeksiyon tarihine ayarlanıyor, orijinal e-posta tarihine değil. Exchange Online'ın, EAC üzerinden toplu migrasyon yaparken kaynak sunucunun INTERNALDATE'ini koruyacak yerleşik bir yöntemi yok.

EAC ile Üçüncü Taraf Araçlar: Önemli Bir Fark

İki durumu birbirinden ayırt etmek gerekiyor. BitTitan MigrationWiz veya CloudM Migrate gibi araçlarla da sorun yaşanıyor, ancak bu araçların zaman zaman belirli tarih meta verilerini korumaya çalışan yapılandırma seçenekleri bulunuyor (kısmen belgelenmiş, çoğunlukla gelişmiş ayarlara gömülmüş).

EAC üzerinden yapılan yerel migrasyon ise bu tür hiçbir seçenek sunmuyor. Microsoft, toplu migrasyon hattında INTERNALDATE korumasını kontrol edecek herhangi bir parametre açığa çıkarmıyor. Bir kara kutu gibi: batch'i yapılandırıyorsunuz, başlatıyorsunuz, Exchange içeride istediğini yapıyor. Ve sistematik olarak yaptığı şey, mesajları enjeksiyon tarihiyle tarihlendirmek.

(Konu dışına çıkayım ama: EAC üzerinden migrate edilmiş bir e-postanın ham başlıklarını okumayı denediniz mi? Hiç de eğlenceli değil. Exchange'in eklediği Received: alanı binlerce arasında tanınabilir: *.protection.outlook.com veya *.prod.exchangelabs.com gibi Microsoft dahili sunucu referansları içeriyor ve zaman damgası tam migrasyon penceresine denk geliyor.)

Batch'i Yeniden Oluşturmak Neden İşe Yaramıyor

Pek çok IT yöneticisinin ilk içgüdüsel tepkisi şu oluyor: "Migrate edilmiş posta kutularını silip batch'i sıfırdan yeniden başlatsam, belki bu sefer tarihler doğru olur."

Anlaşılır bir düşünce. Ama işe yaramıyor.

Sorun batch yapılandırmasında değil. İşaretlemeyi unuttuğunuz bir parametre de yok. Sorun, her migrasyonda aynı şekilde çalışan Exchange taşıma hattının mimarisinde. Batch'i yeniden başlatmak tam olarak aynı sonucu üretecek: yeni migrasyon tarihini içeren aynı Received: başlıkları ve aynı yanlış INTERNALDATE değerleri. Zaman kaybedeceksiniz, kullanıcılar ikinci kez rahatsız edilecek, sonuç değişmeyecek.

Bazı yöneticiler Outlook'taki sıralama parametrelerini değiştirmeyi deniyor ("alınma tarihi" yerine "gönderim tarihine göre sırala"). Bu bir çözüm değil, geçici bir yama. Date: başlığı ve INTERNALDATE, bu ayarı desteklemeyen istemciler için, OWA için, Outlook Mobile için ve posta kutusuna IMAP veya EWS üzerinden erişen her üçüncü taraf uygulama için hâlâ yanlış kalıyor.

Başlıklarda Gerçekte Neler Oluyor

EAC üzerinden migrate edilmiş bir e-postanın içerdiği şeyin basitleştirilmiş bir örneği. Orijinal başlık:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@eskidomain.com
Subject: Q1 2019 Raporu

Migrasyondan sonra mesaj, zincirin başına şuna benzer bir şey alıyor:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook bu Received: başlığını ilk sırada görüyor (başlık bloğunun en üstüne ekleniyor), mesajın en son işlenme tarihi olarak yorumluyor ve alınma tarihi olarak gösteriyor. 2019'a ait orijinal Date: başlığı birkaç satır aşağıda, sağlam bir şekilde duruyor. Ama Outlook mesaj listesinde görüntüleme için onu kullanmıyor.

Kesin olmak gerekirse: davranış Outlook sürümüne göre hafifçe değişiyor. 2021 sonrası sürümler (ve özellikle 2023 sonu itibarıyla kullanıma sunulan yeni Windows için Outlook) bu soruna özellikle duyarlı, çünkü ham Date: başlığından çok Exchange Graph meta verilerine dayanıyor. Yani Outlook 2016'da sorun yaratmayan migrasyonlar artık yeni Outlook'ta sorun çıkarabiliyor.

Gerçekte Kimler Etkileniyor

Bu tür migrasyonlarda en yaygın IMAP kaynak sunucuları Dovecot (Linux/cPanel ortamlarında çok yaygın) ve Courier. Her ikisi de IMAP üzerinden INTERNALDATE sunuyor ama EAC bunları korumuyor. Exchange on-premises'ten Exchange Online'a geçiş yapıyorsanız (hibrit veya cutover migrasyonu), durum farklı: Microsoft bu senaryoda meta verileri daha iyi koruyan dahili bir taşıma protokolü (MAPI/EWS) kullanıyor. EAC üzerinden yapılan genel IMAP migrasyonu sorun yaratıyor.

En çok etkilenenler, uzun geçmişe sahip (5 yıl ve üzeri) ve yüksek hacimli posta kutularına sahip kullanıcılar. 300 e-postası olan biri durumu hızla toparlayabilir. Ama günlük olarak müşteri yazışmalarını bulmak için tarih sıralamasına güvenen, 12.000 e-postası olan bir satış direktörü, felç olmuş hissedecek.

El Yapımı Bir Script Neden Kötü Bir Fikir

Teknik sorunu anlayan bazı IT yöneticileri başlıkları manuel olarak düzeltmek için PowerShell veya Python script'i yazmaya yönelebiliyor. Mekanizmayı kavradıktan sonra temel fikir basit görünebilir. Ama production ortamında düzeltme yapmak bambaşka bir iş.

Önce uç durumlar. S/MIME imzalı e-postalar ve PGP şifreli mesajlar, imzayı geçersiz kılmadan başlık değişikliğine izin vermeyen bir yapıya sahip. Hatalı biçimlendirilmiş MIME sınırlarına sahip multipart/alternative mesajlar (eski Courier sunucularında sık görülür), yapıyı düzgün yeniden oluşturmadan mesajı değiştiren bir script tarafından bozulabilir. RFC 2047'ye göre kodlanmış ASCII dışı başlıklar (aksanlı karakterler veya Japonca içeren gönderici adları) klasik bir hata kaynağı.

Sonra hacim. Geliştirme ortamında 50 test e-postasında çalışan bir script, production'da Exchange Online API'sinin hız sınırlarıyla başa çıkamaz. 8.000 mesajlık bir batch sırasında sabah 2'de gelen 429 Too Many Requests hatası, kurtarma mekanizması olmadan, beyaz bir geceye ve potansiyel olarak çift ya da kayıp mesajlara yol açıyor.

En önemlisi: düzeltilen her e-postanın sağlam olduğunu nasıl doğrularsınız? Hiçbir ekin kesilmediğini, hiçbir konuşma dizisinin kırılmadığını, etiket ve klasörlerin korunduğunu? Bireysel doğrulama mekanizması olmadan sadece her şeyin yolunda gittiğini umabilirsiniz.

Migrasyon sonrası tarih düzeltmesi, 50 satırlık bir script gibi görünen ama production ortamında güvenilir olması için binlerce satır gerektiren bir problem.

Redate.io Bunu Nasıl Çözüyor

Redate.io, Microsoft 365 API'leri (Azure Active Directory, tenant düzeyinde yetkilendirme izinleri) aracılığıyla Exchange Online'a bağlanır ve migrasyon nedeniyle tarih meta verileri bozulan e-postaları belirlemek için ilgili posta kutularını tarar. Bu tarama adımı ücretsizdir ve sorunun boyutunu tam olarak ortaya koyar: etkilenen mesaj sayısı, ilgili posta kutuları, bozulan tarih aralığı.

Redate.io'nun özel düzeltme motoru, ardından her e-postayı bilinen migrasyon aracı imzaları üzerinde desen eşleştirme (Exchange Online taşıma hattı dahil), RFC uyumluluk doğrulaması ve düzeltme öncesi/sonrası mesaj yapısı bütünlük denetimi içeren çok aşamalı bir analiz hattı aracılığıyla tek tek işler. S/MIME imzalı e-postalar, karmaşık MIME yapıları, standart dışı kodlamalar: hepsi özel işleme yollarıyla yönetilir.

Düzeltilen her mesaj ayrı ayrı doğrulanır. Orijinaller 30 gün boyunca görünür bir yedekleme klasöründe saklanır. Belirli bir mesajda bir sorun varsa, o mesaj değiştirilmez: Redate.io bozulmayı riske atmak yerine anomaliyi raporlar.

Fiyatlandırma hacme dayalı, posta kutusu başına tek seferlik ödeme. Abonelik yok, tekrarlayan ücret yok. Sorunu bir kez düzeltiyorsunuz, iş bitiyor.

Exchange Online migrasyonları için özellikle, Redate.io Azure AD uygulama izinleri üzerinden bağlantıyı destekliyor (posta kutusu başına ayrı kimlik bilgisi oluşturmak zorunda kalmadan), bu da büyük posta kutusu filolarının yönetimini IT yöneticisi veya MSP için çok daha kolay hale getiriyor.

Bu tür migrasyondan etkilenen birden fazla müşteriniz varsa, kapsanan farklı senaryolara genel bir bakış için Microsoft 365 migrasyonu sonrası tarih düzeltme rehberine de göz atın.

E-postalar orada, orijinal tarihler de. Redate.io'da ücretsiz bir tarama başlatın ve Exchange Online posta kutularınızda tam olarak kaç mesajın etkilendiğini görmek için harekete geçin.