iCloud'dan Office 365 Migrasyonunda Yanlış E-posta Tarihleri

Tarihleri Sistematik Olarak Bozan Bir Migrasyon Senaryosu

iCloud Mail'den Office 365'e aktarımı tamamladınız. E-postalar yerli yerinde, klasörler doğru, her şey yolunda görünüyor. Pazartesi sabahı ilk şikayet geliyor: "Tüm eski e-postalarım bugünün tarihini gösteriyor." Ardından bir tane daha. Sonra on tane.

Bu izole bir hata değil. iCloud Mail'den Office 365'e migrasyon, e-posta tarihi bozulmasının en sık belgelenen senaryolarından biridir. Bunun çok somut teknik nedenleri var: Apple Mail'in davranışı, IMAP protokolü ve Microsoft 365'in gelen mesajları işleme biçiminin kesiştiği noktada ortaya çıkan bir sorun bu.

iCloud'dan Office 365 Migrasyonu Neden Tarihleri Bozuyor?

Sorunu anlamak için birçok IT yöneticisinin (deneyimliler dahil) birbirine karıştırdığı üç kavramı ayırt etmek gerekiyor: Date: başlığı, IMAP INTERNALDATE ve dosya oluşturma tarihi.

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

Her e-posta, mesajın ne zaman gönderildiğini belirten bir Date: başlığı içerir. Bu başlık, mesajın ham gövdesine gömülüdür ve teoride hiç değişmez. Kelimenin tam anlamıyla "orijinal" tarih budur.

IMAP INTERNALDATE

IMAP protokolü (RFC 3501 ile tanımlanmış), her mesaja INTERNALDATE adı verilen ayrı bir meta veri ekler. E-posta istemcilerinin çoğu, gelen kutusundaki mesajları sıralamak ve görüntülemek için Date: başlığını değil bu değeri kullanır. Outlook ise görüntüleme ve sıralama için INTERNALDATE'e özellikle güçlü biçimde bağımlıdır.

Peki sorun ne? Bir migrasyon aracı, e-postayı bir IMAP sunucusundan diğerine kopyalarken INTERNALDATE'i korumak gerekir. Ama pratikte bu her zaman böyle olmaz.

Apple Mail'in Kendine Özgü Davranışı

Apple Mail, iCloud'dan mesajları senkronize ederken zaman zaman sunucu tarafındaki dosya oluşturma tarihini INTERNALDATE için referans olarak kullanır. Bu teknik anlamda bir hata değil; IMAP spesifikasyonunun diğer istemcilerden farklı yorumlanması. (Aslında ham IMAP RFC'lerini okuyarak bir INTERNALDATE sorununu çözmeye çalışmak oldukça yorucu bir deneyimdir, spesifikasyon bu konuda oldukça geniş bir yorum alanı bırakıyor.)

Sonuç: iCloud'dan Apple Mail üzerinden dışa aktarım veya migrasyon yaptığınızda, mesajların INTERNALDATE'leri Office 365'e ulaşmadan önce zaten hatalı olabilir.

iCloud Migrasyonunun Üç Yöntemi ve Tuzakları

Doğrudan IMAP Migrasyonu

En yaygın yöntem, iCloud'u IMAP kaynağı ve Office 365'i hedef olarak yapılandırıp bir migrasyon aracı kullanmaktır (imapsync, MigrationWiz veya başka bir araç). Araç iki sunucuya bağlanır ve mesajları kopyalar.

Buradaki sorun ikidir. Birincisi, Apple'ın IMAP sunucularında hız sınırları var, bu durum araçları duraklamaya zorluyor; bağlantılar kapanıp yeniden açılıyor ve bu süreçte sahte INTERNALDATE'ler oluşabiliyor. İkincisi, Exchange Online'a IMAP APPEND komutuyla kopyalanan her mesaj, araç orijinal INTERNALDATE'i açıkça belirtmediği sürece varsayılan olarak migrasyon anındaki tarihi alıyor.

Bazı araçlar bunu doğru yapıyor. Diğerleri sistematik biçimde yapmıyor. 40.000 mesajlık bir posta kutusunda %2'lik bir hata oranı bile 800 e-postanın yanlış tarih göstermesi demek.

imapsync ile yapılan migrasyonlar için ayrıca şu kaynağa bakabilirsiniz: Microsoft 365'te imapsync taşıma tarihlerini düzeltme.

.mbox veya .eml Dışa Aktarımı ve İçe Aktarma

Bazı kullanıcılar iCloud e-postalarını Apple Mail aracılığıyla .mbox formatında dışa aktarıp Outlook'a içe aktarmayı dener. Bu el yapımı bir yöntemdir ve değişken sonuçlar üretir.

.mbox formatı, e-postaları bir metin mesajları dizisi olarak kodlar. Tarihler bireysel Date: başlıklarında yer alır; ancak mesajlar arasındaki ayraç satırı ("From ") bazı içe aktarıcılar tarafından oluşturma tarihi olarak yorumlanabilir. Outlook, .mbox'ı .pst'ye dönüştürerek içe aktarırken zaman zaman mesajın kendi Date: başlığı yerine bu ayraç tarihini kullanır.

Outlook'ta Sürükle-Bırak

En çok hasar yaratan yöntem bu. Kullanıcı Outlook'ta her iki hesabı da (iCloud ve Office 365) yapılandırır, ardından mesajları bir klasörden diğerine sürükleyip bırakır. Basit görünür. Tarihler açısından tam bir felaket.

Outlook, iki IMAP hesabı arasında sürükle-bırak ile mesaj taşırken aslında yeni bir .EML dosyası oluşturur, hedef hesaba ekler ve orijinali siler. Bu yeni dosya, Windows dosya oluşturma tarihini, yani tam sürükle-bırak anını miras alır. Orijinal Date: başlığı mesajın gövdesinde hala mevcuttur, ama Exchange Online sunucusuna kaydedilen INTERNALDATE işlemin yapıldığı tarihe karşılık gelir. Outlook daha sonra taşınan tüm mesajlar için bu migrasyon tarihini gösterir.

Açıkçası bu davranış Outlook sürümüne göre değişiyor. 2023 sonbaharındaki Outlook güncellemesinden bu yana bazı senaryolarda hafif iyileştirme oldu, ama hesaplar arası sürükle-bırak hala belgelenmiş bir tarih bozulması kaynağı olmaya devam ediyor.

Office 365 ve Outlook Sonunda Ne Gösteriyor?

Exchange Online, e-postaları INTERNALDATE'leriyle birlikte saklar. Outlook Desktop, gelen kutusundaki "Alındı" sütununu ve sıralamayı oluştururken bu INTERNALDATE'i okur. Migrasyon sırasında INTERNALDATE üzerine yazıldıysa Outlook migrasyon tarihini gösterir, nokta.

Outlook Web App (OWA) da aynı şekilde davranır. Orijinal Date: başlığını gösteren bir "alternatif görünüm" yoktur. Tarih sütununda gördüğünüz şey INTERNALDATE'tir.

Orijinal Date: başlığı hala orada, bozulmamış, bir mesajın ham başlıklarını görüntülerseniz okunabilir durumda. Ama hiçbir normal görünüm onu göstermiyor. İşte bu sorunun can sıkıcı özü bu: doğru bilgi var, sadece teknik düzeltme olmadan erişilemiyor.

Microsoft Desteğinin Çözemediği Şey

Bu sorun için Microsoft Destek'e ticket açarsanız büyük ihtimalle şunları alırsınız: gösterilen tarihlerin saklanan INTERNALDATE'lere karşılık geldiğinin onayı, Outlook'taki sıralama ayarlarını kontrol etme önerisi ve kullandığınız migrasyon aracına yönlendirme.

Bu kötü niyet değil. Microsoft'un, Exchange Online'a alınmış binlerce mesajın INTERNALDATE'ini geriye dönük olarak düzeltecek yerel bir aracı basitçe yok. Düzeltme işlemi, mesajlara tek tek erişmeyi, başlıklarını analiz etmeyi ve tarih meta verilerini yeniden oluşturmayı gerektiriyor; bu da standart destek kapsamının dışında.

iCloud desteği ise mesajların doğru biçimde dışa aktarıldığını ve sorunun hedef tarafta olduğunu savunuyor. İki destek birbirini suçlarken kullanıcı, migrasyon gününün tarihini gösteren 12.000 e-postayla baş başa kalıyor.

Ölçek Sorunu

Tarihlerin neden bozulduğunu anlamak bir şey. Bunları canlı ortam posta kutusunda elle düzeltmek bambaşka bir şey.

Bazı IT yöneticileri düzeltmeyi betikle çözmeye çalışıyor. Temel fikri kavramak zor değil, ama gerçek hacimlerde uygulamak ev yapımı betiklerin pek iyi baş edemediği sorunlar doğuruyor:

• S/MIME ile imzalanmış veya PGP ile şifrelenmiş e-postalar, kriptografik imza geçersiz kılınmadan değiştirilemez
• Karmaşık multipart/alternative yapısına sahip mesajlar (HTML + düz metin + iç içe ekler) manipüle edilmeye karşı kırılgandır
• ASCII dışı kodlamaya sahip başlıklar (RFC 2047, özellikle Japonca, Arapça veya Kiril karakterleri için) bu kodlamaları doğru işlemeyen araçlarla bozulabilir
• Microsoft Graph API kotaları ve Exchange Online hız sınırları (429 Too Many Requests hatası) üstel geri çekilme yönetimi için tasarlanmamış betikleri durduruyor
• 500 test e-postasında sorunsuz çalışan bir betik, gerçek bir posta kutusunun 8.000. mesajında gece 3'te durup herhangi bir kurtarma mekanizması olmadan takılı kalıyor

Ve şu kritik soru: düzeltme sonrasında her e-postanın sağlam olduğunu nasıl doğrularsınız? Ekin hala orada olduğunu? Konu dizisinin kırılmadığını? Ev yapımı bir betik genellikle bu doğrulamayı yapmaz.

Redate.io, iCloud'dan Office 365 Migrasyonlarını Nasıl İşliyor?

Redate.io, iCloud sunucularına erişim gerektirmeksizin Microsoft 365 izinleri (Azure AD) üzerinden doğrudan Office 365'e bağlanır. Redate devreye girdiğinde e-postalar zaten Exchange Online'dadır.

Redate'in düzeltme motoru, her mesajın başlık zincirini analiz ederek orijinal tarihi tespit eder; migrasyon sırasında eklenen Received: başlıklarını meşru tarih meta verilerinden ayırt eder. Bu analiz, bilinen migrasyon aracı imzalarıyla desen eşleştirmesi içerdiğinden, parazit başlıklar hemen göze çarpmasa bile tespit edilebilir.

Düzeltilen her e-posta işlem sonrasında tek tek doğrulanır. Orijinaller, hiçbir ev yapımı betiğin varsayılan olarak yapmadığı şekilde, 30 gün boyunca görünür bir yedek klasöründe saklanır. İlk tarama ücretsizdir ve düzeltmeye karar vermeden önce etkilenen e-posta sayısını tam olarak ölçmenizi sağlar.

Redate ayrıca Google Workspace'ten Office 365'e ve cPanel migrasyonlarından kaynaklanan tarihleri de düzeltebilir. Daha fazla bilgi için: Microsoft 365 migrasyonu sonrası e-posta tarihlerini düzeltme veya Exchange Online migrasyonu sonrası yanlış e-posta tarihleri.

Önce Tara, Sonra Düzelt

Yanlış tarihler üreten her iCloud'dan Office 365'e migrasyon için önerilen başlangıç noktası: etkilenen posta kutularında Redate.io'nun ücretsiz taramasını çalıştırmak. Tarama, hangi e-postaların şüpheli INTERNALDATE'e sahip olduğunu ve hangi klasörlerde bulunduklarını tam olarak tespit eder.

Hacme bağlı olarak 12 ile 45 dakika arasında sürer ve herhangi bir müdahaleden önce sorunun boyutu hakkında net bir tablo ortaya koyar. Migrasyon sonrasında birden fazla posta kutusunu yöneten MSP'ler için bu toplu tarama, düzeltmeye ihtiyacı olmayan posta kutularına zaman harcamayı önler.

iCloud'dan migrasyon sonrası e-posta tarihleriniz yanlışsa, Office 365 posta kutularınızdaki sorunun boyutunu ölçmek için Redate.io üzerinden ücretsiz taramayla başlayın.