Zoho'dan Microsoft 365'e Geçişte Yanlış E-posta Tarihleri

Posta kutunuzda ne oldu

Zoho Mail'den Microsoft 365'e domain migrasyonunuzu tamamladınız. Exchange Online altyapısı kurulu, posta kutuları hazır, MX kayıtları güncellenmiş. Sonra Pazartesi sabahı bir kullanıcı Outlook'u açıyor ve 2021'den kalma tüm e-postalarının bugünün tarihini gösterdiğini fark ediyor. Bir diğeri geçen yılki mesajların gelen kutusunun en üstünde sıralandığını, sanki yeni gelmiş gibi göründüğünü bildiriyor. Destek talepleri yağmaya başlıyor.

Bu bir Outlook hatası değil. Zoho'ya özgü bir sorun da değil. Exchange Online'a yapılan herhangi bir IMAP migrasyonunun beklenen ama pek belgelenmemiş davranışı bu. Tam olarak neden yaşandığını anlamak, düzgün bir düzeltmenin ilk adımı.

Teknik kök neden: INTERNALDATE ve Received başlıkları

Bir IMAP sunucusunda saklanan e-posta aslında iki ayrı şeyden oluşur: mesajın ham içeriği (RFC 2822 başlıkları, gövde, ekler) ve sunucunun yönettiği depolama meta verileri. Bu meta verilerden en önemlisi INTERNALDATE'tir. Posta istemcileri mesajları görüntüleyip sıralarken bu değeri kullanır.

Ham mesaj içindeki Date: başlığı (RFC 2822), mesajın gönderici tarafından yazıldığı veya gönderildiği tarihi temsil eder. INTERNALDATE ise IMAP sunucusunun mesajı aldığı veya depoladığı tarihtir. Sağlıklı bir sunucuda bu iki değer birbirine yakındır. Migrasyon sonrasında durum çok farklı.

IMAP migrasyonu tarihleri nasıl bozuyor

Bir migrasyon aracı (Zoho Migration Wizard, imapsync, BitTitan veya başka herhangi biri) Zoho Mail'den Exchange Online'a mesaj aktarırken IMAP protokolünü kullanır. Araç Zoho'ya bağlanır, mesajı alır ve bir IMAP APPEND komutuyla Exchange Online'a ekler. İşte sorun tam burada başlıyor.

Exchange Online her mesajı alırken mesajın başına yeni bir Received: başlığı ekler. Bu başlık, ekleme anının tarih ve saatini taşır; yani migrasyonun yapıldığı tarihi. Bazı migrasyon araçları APPEND komutuna parametre olarak orijinal INTERNALDATE'i geçmeye çalışır. Bazıları bunu hiç yapmaz ya da hatalı yapar; bu durumda Exchange Online otomatik olarak alım tarihini INTERNALDATE olarak atar.

Sonuç: 2019'da gönderilmiş de olsa, 2022'de de olsa, artık her mesajın INTERNALDATE'i migrasyon haftasını gösteriyor. Outlook bu değeri öncelikli okur. Sıralama tamamen çöker.

Zoho Migration Wizard'ın özel davranışı

Zoho, kendi platformundan çıkmak isteyenler için Zoho Migration Wizard'ı sunuyor. Basit migrasyonlar için kullanışlı bir araç, ancak yönetici forumlarında belgelenmiş bir davranışı var: hedef sunucuya ekleme sırasında orijinal INTERNALDATE'i her zaman doğru aktarmıyor.

Açıkçası sorun, gelen her mesaja sistematik olarak Received: başlığı ekleyen sunuculara yapılan migrasyonlarda ortaya çıkıyor. Exchange Online tam da böyle davranıyor. Zoho Migration Wizard APPEND parametresiyle orijinal tarihi geçse bile, Exchange Online'ın oluşturduğu Received: başlığı başlık zincirinin başına geçiyor ve Outlook bu başlıktan "e-postanın ne zaman geldiğini" belirliyor.

Zoho'dan çıkmak için imapsync gibi genel IMAP araçlarını kullanan yöneticiler de tamamen aynı sorunla karşılaşıyor, hatta kimi zaman daha kötü sonuçlarla. imapsync'in varsayılan yapılandırması Exchange Online için optimize edilmiş değil. (Bu arada, gece 2'de bir senkronizasyon hatasını bulmak için imapsync loglarını satır satır tararken kendinizi buldunuzsa, bunun güçlü ama kenar durumlar için pek affedici olmayan bir araç olduğunu zaten biliyorsunuzdur.)

Outlook neden yanlış tarihi gösteriyor

Outlook bir e-postanın tarihini göstermek için yalnızca Date: başlığını kullanmıyor. Gelen kutusu sıralamasi dahil çoğu görünümde, IMAP/Exchange sunucusunun sağladığı INTERNALDATE kullanılıyor. Orijinal Date: başlığı mesajın içinde sağlam biçimde duruyor, ama INTERNALDATE lehine görmezden geliniyor.

Bu yüzden Outlook'ta "Gönderim tarihine göre sırala" seçeneği sorunu gerçek anlamda çözmüyor. Farklı bir tarih gösteriyor evet, ama sıralama davranışı Outlook sürümüne ve görünüm moduna (konuşmalar gruplanmış ya da değil) göre tutarsız kalmaya devam ediyor. Gönderim tarihine göre sıralama bir çözüm değil. İlk istemci güncellemesinde düşen bir yara bandı.

Sorunun gerçek boyutu

Orta ölçekli bir Zoho'dan Microsoft 365 migrasyonunda, posta kutularının yaşına ve organizasyonun büyüklüğüne bağlı olarak kolayca 50.000 ile 500.000 arasında etkilenen mesajdan söz edilebilir. Migrasyon penceresi boyunca aktarılan her e-posta aynı bozuk tarihi taşıdığı için kullanıcılar Outlook'u ilk açışlarında sorunu hemen görüyor.

Gönderilmiş öğeler klasörleri genellikle en sorunlu olanlar. Mart 2022'de gönderilen bir teklifi arayan bir satış temsilcisi, hepsinin migrasyon tarihini gösterdiği yüzlerce e-posta arasında didiniyor. Operasyonel etki gerçek, sadece görsel değil.

Birçok kişinin sandığının aksine sorun zamanla ortadan kalkmıyor. INTERNALDATE ekleme anında sabitlenir. Kendi kendine düzelmez. Aktif bir müdahale olmadan e-postalar bozuk tarihlerini sonsuza kadar korur.

Bunu kendiniz düzeltmeye çalışmak neden göründüğünden riskli

Cazip görünüyor: orijinal Date: başlığı mesajın içinde duruyor, o zaman meta verileri düzeltsek yeter... Kağıt üzerinde mantıklı. Pratikte, 80.000 e-postalık bir üretim posta kutusunda bu işlem felaket biçimde sonuçlanabilir.

El yapımı bir scriptin muhtemelen iyi yönetemeyeceği bazı kenar durumlar:

• S/MIME imzalı e-postalar: imza tüm başlıkları kapsıyor. Mesaj yapısında herhangi bir şeyi değiştirmek kriptografik imzayı geçersiz kılıyor.
• PGP şifreli mesajlar: içerik opak ve MIME zarflarında yapılacak herhangi bir müdahale mesajı bozabilir.
• RFC 2047 ile kodlanmış ASCII olmayan başlıklar (özel karakterli gönderici adları): script kodlamayı doğru yönetmezse kırılıyor.
• Base64 kodlanmış ekler, standart dışı MIME sınırları veya iç içe multipart yapılar.
• Geçerli Date: başlığı olmayan e-postalar (eski Zoho dışa aktarmalarında bu gerçekten var), scriptin ne yapacağına karar vermesi gerekiyor.

50 test e-postasında çalışan bir script, yıllarca geçmişi olan bir Zoho üretim posta kutusunda çalışmaz. Üstelik her düzeltmenin sağlam olduğunu ve eklerin kesilmediğini mesaj mesaj nasıl doğrularsınız? Doğrulama, düzeltmenin kendisi kadar karmaşık bir iş.

Bir de kota meselesi var. Microsoft Graph üzerinden Exchange Online API'si katı hız sınırları uyguluyor (o meşhur 429 Too Many Requests hataları). Throttling mekanizması olmayan bir 100.000 mesajlık batch, geçici bloklamalara veya sonradan teşhis edilmesi güç sessiz hatalara yol açabiliyor. Bir hata kurtarma mekanizmanız yoksa baştan başlıyorsunuz.

Redate.io, Zoho migrasyonu sonrası tarihleri nasıl düzeltiyor

Redate.io, standart Azure AD izinleri aracılığıyla Microsoft 365 tenant'ınıza bağlanır; global yönetici erişimi gerekmez. İlk tarama ücretsizdir: Redate.io, her mesajın başlık zincirindeki değerlerle INTERNALDATE'i karşılaştırarak etkilenen posta kutularını belirler ve hatalı tarihli e-postaların hacmini tahmin eder.

Düzeltme işlemi, her mesajın başlık zincirini bütünüyle analiz eden, Zoho migrasyon araçlarına özgü imzaları (Zoho Migration Wizard veya Zoho'dan çıkış için yapılandırılmış imapsync) tespit eden ve çok aşamalı bir doğrulama pipeline'ı aracılığıyla tarih meta verilerini yeniden oluşturan tescilli bir düzeltme motoru kullanıyor. Düzeltilen her e-posta tek tek doğrulanıyor: içerik bütünlüğü, ek koruması, RFC uyumluluğu. Orijinaller 30 gün boyunca erişilebilir bir yedek klasörde tutuluyor.

Yeniden migrasyon yok. Kesinti yok. Kullanıcılar düzeltme arka planda çalışırken Outlook'u kullanmaya devam ediyor.

Fiyatlandırma, abonelik olmaksızın hacme dayalı tek seferlik bir ödeme. Ayrıntılar doğrudan site üzerinde mevcut.

Bilmeniz gereken benzer durumlar

Birden fazla migrasyonu paralel yönetiyorsanız veya Zoho'dan ayrılan müşterileri olan bir MSP'yseniz, aynı sorunun başka platformlardan Exchange Online'a yapılan migrasyonlarda da ortaya çıktığını bilin. Mekanik aynı: Exchange'in oluşturduğu Received: başlığı kaynaktan bağımsız olarak INTERNALDATE'i eziyor.

Google Workspace'ten, şirket içi Exchange'den veya BitTitan MigrationWiz ya da CloudM gibi araçlar üzerinden yapılan migrasyonlar için Redate.io blogundaki ilgili makaleler her araca özgü davranışları ayrıntılı olarak ele alıyor. Exchange Online migrasyonu sonrası yanlış e-posta tarihleri sayfası bu tenant'a ulaşan tüm senaryolara genel bir bakış sunuyor.

Migrasyonunuz paylaşılan posta kutularını veya Exchange kaynaklarını (toplantı odaları, ekipmanlar) içeriyorsa sorun aynı, aynı düzeltme araçları geçerli. OWA'da Exchange IMAP taşıma tarihlerini düzeltme rehberi tenant bağlantısı adımlarını ayrıntılı açıklıyor.

Özellikle Zoho'dan çıkmak için imapsync kullanan ekipler için imapsync tarihleri korunmadı sayfası imapsync yapılandırma seçeneklerini ve bunların neden Exchange Online'daki sorunu önlemekte yetersiz kaldığını belgeliyor.

Zoho migrasyonunuzdan kalma tarihler Outlook'ta hâlâ yanlış mı görünüyor? Redate.io'da posta kutularınızı ücretsiz tarayın ve nasıl hareket edeceğinize karar vermeden önce sorunun tam boyutunu ölçün.