Paylaşımlı Hosting'den M365'e Geçişte Tarih Sorunu

Kimsenin size söylemediği sorun

OVH, Infomaniak, Ionos veya o2switch'ten Microsoft 365'e e-posta migrasyonunuzu tamamladınız. EAC (Exchange Admin Center) migration sihirbazı gece boyunca çalıştı, her şey yeşil, posta kutuları dolu. Pazartesi sabahı ilk ticket: "Tüm eski e-postalarım bugünün tarihini gösteriyor." Sonra bir tane daha. Sonra on tane.

Bu bir Microsoft 365 hatası değil. Tesadüf de değil. IMAP migrasyonunun mekanik bir sonucu bu; paylaşımlı hosting'den gelen migrasyonlarda sorun genellikle klasik bir migrasyona kıyasla iki kat daha ağır oluyor. İşte nedeni.

IMAP tarihleri nasıl çalışır (ve nerede bozulur)

Bir IMAP sunucusunda saklanan her e-postanın iki farklı tarihleme türü vardır. Bir yanda mesajın gövdesinde yer alan Date: başlığı (RFC 2822 ile tanımlanmış) - mesajın ne zaman gönderildiğini veya alındığını gösterir. Öte yanda INTERNALDATE, yani sunucu düzeyindeki bir meta veri - bu mesajın posta kutusuna hangi tarihte yerleştirildiğini belirtir. Outlook gibi e-posta istemcilerinin e-postaları sıralamak ve göstermek için varsayılan olarak kullandığı değer işte budur.

(Bu arada, EAC'de bir e-postanın ham başlıklarını okumaya çalıştıysanız bunun pek de kolay bir iş olmadığını bilirsiniz. İçeriğe ulaşmadan önce kolayca yirmi otuz satır başlık geçiyor.)

Bir IMAP migration aracı mesajı bir posta kutusundan diğerine aktardığında, hedef sunucuda bu INTERNALDATE değerini yeniden oluşturması gerekir. Bazı araçlar bunu doğru yapıyor. Pek çoğu yapmıyor ya da kısıtlamalarla yapıyor. Alıcı sunucu da kendi payına, kendisine verileni koruyor: bir kopya orijinal tarihini taşıyorsa, Exchange Online bu tarihi koruyor. Yani tarihler yanlış çıktığında bakılması gereken araçtır, Microsoft 365 değil.

Sonuç: her migrate edilen e-posta, migration günü "alınmış" gibi görünüyor. 2019'dan kalma olması hiç fark etmiyor.

İki aşamalı bozulma: paylaşımlı hosting her şeyi neden daha da kötüleştirir

İşte bu noktada OVH, Infomaniak, Gandi, Ionos veya o2switch gibi paylaşımlı hosting sağlayıcılarından yapılan migrasyonlar gerçekten sorunlu hale geliyor.

Bu sağlayıcılar genellikle standart IMAP yapılandırmalı Postfix, Dovecot veya cPanel tabanlı paylaşımlı sunucular kullanır. Pek çok küçük ve orta ölçekli işletme, bazen 2010 veya 2012'den bu yana yıllarca e-posta biriktirmiştir bu sunucularda. Microsoft 365'e geçmeye karar verdiklerinde migrasyon çoğunlukla iki aşamada gerçekleşir.

Aşama 1: ilk bozulma (Microsoft 365'ten önce bile)

Pek çok durumda e-postalar zaten bir ilk migrasyondan geçmiştir. Şirket yıllar içinde bir ya da iki kez paylaşımlı hosting sağlayıcısı değiştirmiştir: 2018'de Gandi'den OVH'ye, ardından 2022'de OVH'den Infomaniak'a, örneğin. Her IMAP aktarımı, araç orijinal tarihi iletmediğinde orijinal INTERNALDATE değerini aktarım gününe sıfırlamış olabilir ve bazı araçlar o gün damgalı kendi migration başlıklarını da eklemiş olabilir.

E-postalar Microsoft 365'e ulaştığında üzerlerinde zaten izler taşıyorlar. Orijinal Date: başlığı sağlam (mesajın gövdesinin bir parçası, kimse ona dokunmuyor), ama tarih meta verileri daha önce bir kez bozulmuş durumda.

Aşama 2: Exchange Online'a geçişte ikinci bozulma

EAC'nin IMAP migration aracı ya da IMAP modunda yapılandırılmış BitTitan MigrationWiz gibi üçüncü taraf bir araç, bu zaten hasarlı e-postaları alıyor. Bu araç da her e-postanın orijinal tarihini iletmiyorsa, Exchange Online e-postayı aktarım gününe kaydediyor ve Outlook'ta gösterilen "alım tarihi" de bu oluyor.

Mart 2017'de gönderilmiş bir e-posta iki katmanlı yanlış tarih taşıyabilir: 2022'deki taşımadan kalan migration başlıkları ve 2024'teki Microsoft 365 migrasyonundan gelen alım tarihi. Outlook 2024 gösteriyor. Kullanıcı 2024 görüyor. Ve bu iki ayrı düzeyde yanlış.

Açıkçası, tam olarak doğru söylemek gerekirse, her zaman en son Received: başlığının kullanıldığı söylenemez. Outlook görüntüleme tarihini Exchange Online posta kutusundaki INTERNALDATE ile mevcut başlıkların bir kombinasyonundan belirliyor. Ama migration aracı orijinal tarihleri iletmediğinde, Exchange Online'a geçiş eski yanlışların üzerine yeni bir yanlış tarih katmanı ekliyor.

Migration araçları ve hosting'ler: riskli kombinasyonlar

Paylaşımlı hosting'den yapılan migrasyonlarda sıkça karşılaşılan kombinasyonlar şunlar:

• OVH / Infomaniak / Ionos + EAC'nin IMAP aracı: Microsoft'un yerleşik aracı pratik, ama hacimli IMAP migrasyonlarında tarihleri doğru korumadığıyla biliniyor.
• cPanel (o2switch, LWS, vb.) + BitTitan MigrationWiz IMAP modunda: IMAP modundaki MigrationWiz kendi migration başlıklarını ekliyor. Sonuç belgelenmiş; daha fazlası için Microsoft 365'te BitTitan taşıma tarihlerini düzeltme sayfamıza bakabilirsiniz.
• Gandi / Mailcow + imapsync: imapsync güçlü bir araç ama INTERNALDATE yönetimi yapılandırmaya bağlı. Doğru seçenek olmadan tarihler korunmuyor. Ayrıca bkz. imapsync tarihleri korunmadı mı?
• Outlook'ta sürükle-bırak ile yapılan manuel migrasyon: Outlook'ta iki hesap arasında klasörleri sürükleyip bırakan biri olduysa, her e-postanın INTERNALDATE değeri kopyalama tarihiyle yeniden yazılmış demektir. İstisnasız.

Ortak payda: bu yöntemlerin hepsi Exchange Online'a, Outlook'ta görüntülenen tarihi gerçeklikle örtüşmeyen e-postalarla ulaşıyor.

"Bunu kendin düzeltmeye çalışmak" neden büyük ölçekte kötü bir fikir

Sorunu anlamak bir şey. 40 Exchange Online posta kutusuna dağılmış 8.000 e-postayı, karmaşık klasör yapıları, S/MIME imzalı e-postalar, büyük ekler ve iç içe geçmiş konuşma zincirleriyle birlikte düzeltmek bambaşka bir şey.

On test e-postasında çalışıyor gibi görünen bir PowerShell betiği, bozuk bir MIME sınırı veya RFC 2047 kodlamalı bir başlık (gönderici adlarındaki ASCII dışı karakterler için kullanılan =?UTF-8?B?...?= biçimi) yüzünden 4237. mesajda sessizce çökebilir. Bireysel doğrulama mekanizması olmadan bunu fark etmezsiniz. Sadece bir e-posta kaybolmuş olur.

Bu tür bir migrasyonda DIY'nin somut riskleri:

• Ekleme mantığı yarı yolda başarısız olursa yinelenen mesajlar
• Çok parçalı yapı yanlış kurulursa eksik ekler
• Outlook'ta kopuk konuşma zincirleri (konuşmalar, değiştirilebilen References: ve In-Reply-To: başlıklarına dayanıyor)
• Gece 3'te Microsoft Graph API'sinden gelen 429 (Too Many Requests) hataları - rollback olmadan işlemi kesiyor
• 8.000 düzeltmenin tamamının doğru uygulandığını doğrulamanın kolay bir yolu yok

Paylaşımlı hosting'den yapılan migrasyonlara özgü bir zorluk daha var: e-postalar sadece bir değil, birden fazla katmanlı fazla Received: başlığı taşıyor. "Son Received: başlığını kaldır" diyen basit bir betik yetmiyor. Hangi başlığın hangi migrasyona karşılık geldiğini ve hangisinin gerçek orijinal alım tarihini temsil ettiğini bulmak için başlık zincirinin tamamını analiz etmek gerekiyor.

Redate.io'nun farkı ne

Her kullanıcı kendi Microsoft hesabıyla oturum açıyor ve Redate.io bu oturum açmanın verdiği erişimle o posta kutusunu açıyor. İlk tarama ücretsiz: Redate.io görüntülenen tarihi gerçek tarihle örtüşmeyen tüm e-postaları tespit ediyor ve her posta kutusu için kesin bir tahmin sunuyor.

Düzeltme, her mesajın başlık zincirinin tamamını analiz eden, kullanılan migration aracı ne olursa olsun, birden fazla bozulma katmanı üst üste binmiş olsa bile tarih meta verilerini doğru biçimde yeniden oluşturan özel bir motor üzerine kurulu. Her düzeltilen e-posta ayrı ayrı doğrulanıyor. Orijinaller Redate.io tarafından hiçbir zaman silinmiyor: kendi posta kutunuzdaki görünür bir klasörde, siz silene kadar saklanıyor.

Paylaşımlı hosting'den yapılan migrasyonlarda Redate.io'nun çok aşamalı analiz pipeline'ı çift bozulma senaryolarını açıkça ele alıyor: sadece son Received: başlığına bakmakla kalmıyor, gerçek alım tarihini bulmak için tam geçmişi geriye doğru izliyor. Genel olarak Microsoft 365 migrasyonu sonrası tarihleri düzeltme yazısına ve altta yatan mekanizmayı anlamak için IMAP INTERNALDATE: Tarihler Neden Bozulur rehberine de göz atabilirsiniz.

Migrate etmeden önce veya sonra: iki farklı eylem noktası

İki farklı durum, iki farklı yaklaşım.

Henüz migrate etmediyseniz. İyi haber: hasarı sınırlamak mümkün. Bazı migration araçları (Exchange modunda MigrationWiz, doğru seçeneklerle CloudM) tarihleri diğerlerinden daha iyi koruyor. Ama en iyi senaryoda bile temiz bir geçmişi olmayan paylaşımlı hosting'den yapılan bir migrasyon büyük ihtimalle iz bırakacak. Migration sonrasında, posta kutularını kullanıcılara teslim etmeden önce Redate.io'dan geçirmeyi planlayın.

Zaten migrate ettiniz ve ticketlar gelmeye başladı. Redate.io, migrasyonun üzerinden ne kadar zaman geçmiş olursa olsun Microsoft 365'teki mevcut posta kutularını düzeltiyor. Tarama, herhangi bir müdahaleden önce her posta kutusunun gerçek durumunun net bir görüntüsünü verecek. Aynı sorunları gelecekte yaşamamak için e-posta migrasyonu kontrol listesine de bakmanızı öneririz.

OVH, Infomaniak, Ionos veya o2switch'ten Microsoft 365'e geçiş yaptınız ve tarihler yanlış mı? Redate.io hesabı oluşturun, posta kutularınızı ücretsiz tarayın ve ne yapacağınıza karar vermeden önce hasarın tam boyutunu görün.