CloudM Migrate: Yanlış E-posta Tarihlerini Düzeltme

CloudM Migrate'in Kimsenin Sizi Uyarmadığı Tarih Sorunu

CloudM Migrate işini bitirdi. Panelde %100 tamamlandı, tüm kullanıcılar taşındı, sıfır hata. Proje kaydını kapatıp bir sonraki müşteriye geçtiniz.

Sonra bir hafta sonra BT direktörü aradı. "Gelen kutusundaki her e-posta neden 2 Nisan tarihini gösteriyor?"

Bazı e-postalar değil. Hepsi. Beş yıllık müşteri yazışmaları, hukuki belgeler, İK kayıtları, 2020'den satın alma siparişleri, hepsi CloudM'in taşıma yaptığı tarihi gösteriyor. Mesajlar yerinde, içerik bozulmamış, ekler sorunsuz. Ama her bir e-postada tarihler yanlış.

Bu bir CloudM hatası değil. CloudM'in kendi destek belgeleri bunu açıkça kabul ediyor. Sorun, taşıma araçlarının mesajları aktarma biçimi ile hedef posta sunucularının gelen e-posta meta verilerini işleme şekli arasındaki kesişim noktasında yatıyor. Ama bunu bilmek, gelen kutusu artık sıralanamaz hale gelen müşterinize pek yardım etmiyor.

CloudM Aslında E-posta Mesajlarını Nasıl Aktarıyor?

CloudM Migrate kaynak ve hedef platformlara API'leri üzerinden bağlanır. Google Workspace için bu, alan genelinde yetkilendirmesi olan bir hizmet hesabı anlamına gelir (Google Yönetici Konsolu'nda Güvenlik > API Kontrolleri altında yapılandırılır). Microsoft 365 için taşıma yoluna bağlı olarak Exchange Web Services veya Microsoft Graph API kullanır.

CloudM kaynaktan bir mesaj okuduğunda, tüm orijinal başlıklar ve mesaj gövdesi dahil tam RFC 2822 içeriğini alır. Orijinal Date: başlığı (gönderenin posta sunucusunun e-posta ilk gönderildiğinde damgaladığı tarih) bozulmadan gelir. Mesajın teslim yolunu izleyen tüm orijinal Received: başlıkları da öyle.

Sorun hedef tarafta ortaya çıkar. CloudM bu mesajı hedef posta kutusuna yazdığında, hedef sunucu bunu yeni bir teslim olarak değerlendirir. Güncel tarih ve saati içeren yeni bir Received: başlığı ekler ve INTERNALDATE değerini (IMAP'ın sıralama için kullandığı zaman damgası) ekleme anına ayarlar.

CloudM ile Microsoft 365'e taşıma sonrası başlık zinciri şöyle görünür:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

2019'dan başlık orada. Orijinal Date: başlığı hala 23 Eylül 2019 diyor. Ama Outlook görüntüleme sırasını belirlemek için en üstteki Received: başlığını okur ve o artık 2 Nisan 2026 diyor.

CloudM'in "Strip Received Headers" Ayarı

CloudM bu sorunu ele almak için bir ayar sunuyor. Hedef platformun Gelişmiş Ayarları'nda, Mesaj Seçenekleri altında bir "Strip Received Headers" seçeneği var. Etkinleştirildiğinde CloudM, mesajı eklemeden önce received başlıklarını kaldırır ve bunları e-postanın Date: başlığıyla eşleşen tek bir başlıkla değiştirir.

Her şeyi çözüyor gibi görünüyor, değil mi? Tam olarak değil.

Birincisi, taşımayı çalıştırmadan önce bu ayarı bilmeniz gerekiyor. Çoğu yönetici tarih sorununu taşıma tamamlandıktan sonra keşfeder. O noktada mesajlar zaten yanlış tarihlerle hedefte duruyor. CloudM'i bu ayar etkinleştirilmiş olarak yeniden çalıştırmak sadece kopyalar oluşturur, mevcut mesajları düzeltmez.

İkincisi, hedef Google Workspace olduğunda bu ayarın ciddi bir sınırlaması var. Google'ın kendi belgeleri bunu doğruluyor: Gmail, API üzerinden eklenen mesajlarda Received: başlıklarını her zaman yeniden yazar ve ekleme zaman damgasını kullanır. Bu, CloudM'in geçersiz kılamadığı platform düzeyinde bir kısıtlama. "Strip Received Headers" etkin olsa bile Google Workspace, taşıma tarihiyle kendi Received: başlığını ekler.

Microsoft 365 hedefleri için ayar teoride daha iyi çalışır, ama M365 taşıma hattının kendi davranışı var. Exchange Online, mesajın sisteme nasıl girdiğine bağlı olarak INTERNALDATE değerini kendi teslim işleme sürecine göre ayarlayabilir.

Hangi CloudM Taşımaları Tarihleri Bozar (Hangileri Bozmaz)

Her CloudM taşıması yanlış tarih üretmez. Sonuç, kaynak-hedef kombinasyonuna ve CloudM'in kullandığı API yoluna bağlıdır:

• Google Workspace - Microsoft 365: Tarihler bozulur. CloudM, Gmail API üzerinden okur ve Exchange'e yazar. M365 taşıma katmanı yeni Received başlıkları ekler.
• Microsoft 365 - Google Workspace: Tarihler bozulur. Strip Received Headers etkin olsa bile Google'ın API'si Received başlığını ekleme tarihiyle yeniden yazar. CloudM'in destek belgeleri bunu "katı platform sınırlaması" olarak tanımlıyor.
• Google Workspace - Google Workspace: Tarihler bozulur. Alan değişiklikleri, kiracı birleştirmeleri, satın alma birleşmeleri, hedef Google kiracısı gelen mesajlara her zaman taşıma tarihini damgalar.
• Şirket içi Exchange - Microsoft 365: IMAP yoluyla genellikle bozulur. CloudM her iki tarafta da EWS kullanırsa tarih koruması daha güvenilir ama garanti değil.
• Genel IMAP kaynağı - herhangi bir hedef: Tarihler bozulur. CloudM kaynağa genel IMAP sunucusu olarak bağlandığında hedef yine kendi teslim başlıklarını ekler.

Zor olan kısım? CloudM'in taşıma paneli bunların hiçbirini işaretlemiyor. İlerleme çubuğu doluyor, durum sütunu "Tamamlandı" diyor, öğe sayıları eşleşiyor. CloudM açısından taşıma başarılı oldu. Teknik olarak doğru da. Mesajlar aktarıldı. Ama tarihler yolculuğa dayanamadı.

CloudM Yönetilen ve Self-Servis: Aynı Tarih Sorunu

CloudM iki dağıtım modeli sunuyor. SaaS versiyonu (barındırılan CloudM Migrate) tamamen CloudM'in altyapısında çalışır. Kendi barındırdığınız versiyon ise birincil ve ikincil taşıma sunucularını kendi ağınızda, Google Cloud, Azure veya AWS'de dağıtmanıza olanak tanır.

Bazı MSP'ler, taşıma sunucularını doğrudan yönettiğiniz için kendi barındırdığınız seçeneğin tarih işleme üzerinde daha fazla kontrol sağlayacağını varsayar. Sağlamaz. Tarih sorunu hedef sunucuda olur, CloudM'in işleme düğümlerinde değil. Taşıma çiftliğiniz CloudM'in bulutunda veya kendi Azure VM'inizde çalışsın, hedef posta sunucusu aldığı her mesaja taşıma tarihini damgalar.

CloudM ayrıca ekiplerinin projeyi baştan sona yönettiği "Serviced Migration" hizmeti de sunuyor. Tarihler için aynı sonuç. Mühendislik aynı, sadece klavyedeki eller farklı. Aslında premium bir hizmet için ödeme yapıp ücretsiz katmanla aynı sınırlamayı almak tam da böyle bir his.

Geçersiz Date Başlığı Komplikasyonu

CloudM'e özgü bir başka davranış daha var ve bu işleri daha da kötü yapıyor. CloudM, kaynak bir e-postada RFC 822'ye uymayan bir Date: başlığıyla karşılaştığında (hatalı biçimlendirilmiş saat dilimi, eksik haftanın günü, standart dışı format) mesajın taşınabilmesi için başlığı değiştirir.

Bu da bazı e-postaların orijinal tarih referanslarını bile kaybetmesi anlamına geliyor. Değiştirilmiş Date: başlığı gerçek gönderim tarihiyle hiç eşleşmeyebilir. CloudM'in destek belgeleri bunu "Taşınan Öğelerdeki Olası Değişiklikler" başlığı altında bilinen bir davranış olarak belirtiyor ama değiştirilen tarihin ne olacağını açıklamıyor.

Sekiz yıl boyunca birikmiş 12.000 mesajlık bir posta kutusu için, biraz standart dışı Date başlıklarına sahip yüzlerce e-posta olabilir (özellikle eski posta sunucularından, otomatik sistemlerden veya saat dilimi biçimlendirme farklılıkları olan uluslararası gönderenlerden gelen mesajlar). CloudM'in değişikliği artı hedef sunucunun Received başlığı yeniden yazması sonrasında bu mesajlar gerçeklikle hiç alakası olmayan tarihlerle sonuçlanır.

CloudM Sonrası Manuel Düzeltmeler Neden Ölçeklenmiyor

Bunu kendiniz düzeltebilir misiniz? Teknik olarak, orijinal Date: başlığı çoğu mesajın içinde hala gömülü durumda (CloudM'in RFC uyumluluğu için değiştirdikleri hariç). Bazı yöneticiler CloudM taşıması sonrası tarihleri düzeltmek için betikler yazmayı denemiş.

Bu yaklaşımın gerçekliği şu: Potansiyel olarak binlerce posta kutusuna bağlanmanız, her birinde binlerce mesajla uğraşmanız gerekiyor. Her e-posta için tam başlık zincirini ayrıştırmanız, CloudM'in veya hedef sunucunun eklediği Received: başlıklarını tespit etmeniz, uç durumları ele almanız gerekiyor. S/MIME imzalı mesajlarda başlık değişikliği imzayı bozar. PGP şifreli içerik var. İç içe sınırları olan çok parçalı MIME yapıları var. Japonca veya Korece gönderenlerden RFC 2047 kodlu ASCII dışı başlıklar var. Ve tüm bunları tek bir ek kaybetmeden veya e-posta ileti dizisini bozmadan yapmanız gerekiyor.

Temiz bir posta kutusundan 50 test e-postasında çalışan bir betik, 10 yıla yayılan 40.000 mesajlık bir üretim ortamıyla karşılaştığında ayakta kalmayacak. İç içe altı eki olan 47 MB'lık bir e-postaya denk geldiğinizde ne olur? API hız sınırlarına (Google'ın kullanıcı başına saniyede 250 kota birimi, Microsoft'un 10 dakikada yaklaşık 10.000 isteklik kısıtlaması) ne olur? 8.347 numaralı mesajda bir şeyler ters gittiğinde geri dönüş planınız ne?

Ve çoğu yöneticinin çok geç olana kadar sormadığı asıl soru: düzeltilen her mesajın gerçekten bozulmadığını nasıl doğrularsınız?

CloudM Taşıma Tarihlerini Redate.io ile Düzeltme

Redate.io etkilenen posta kutularına doğrudan bağlanır (Google Workspace, Microsoft 365 veya IMAP) ve CloudM'in taşıma tarihi imzasını taşıyan e-postaları tarar. Tarama ücretsizdir ve posta kutusu başına birkaç dakika sürer, herhangi bir taahhütten önce etkilenen mesajların tam sayısını gösterir.

Düzeltme, Received başlık zincirindeki CloudM'e özgü taşıma kalıplarını tespit eden tescilli bir başlık zinciri analiz motoru kullanır. Redate.io, mesaj içeriğini değiştirmeden hedefli meta veri düzeltmesi yapar, ekleri, ileti dizisini, etiketleri, klasörleri ve dijital imzaları korur. Düzeltilen her mesaj, süreç ilerlemeden önce orijinale karşı mesaj bütünlüğü kontrol edilerek tek tek doğrulanır.

Orijinal e-postalar posta kutusunda görünür bir Redate.io - Originals yedek klasöründe 30 gün boyunca saklanır. Herhangi bir şeyin geri alınması gerekirse orijinaller tam orada duruyor, harici bir arşivde gömülü değil.

Müşteri ortamlarında CloudM kullanan MSP'ler için Redate.io, ister 1 posta kutusu ister 500 posta kutusu düzeltin aynı mesaj bazında doğrulamayla çoklu posta kutusu düzeltmelerini yönetir. CloudM'in geride bıraktığı tarih sorununun müşterinizin posta ortamının kalıcı bir özelliği olması gerekmiyor.

CloudM Taşımaları İçin Platforma Özel Kılavuzlar

Düzeltme süreci hedef platforma göre uyarlanır. Redate.io her platformun özelliklerini otomatik olarak yönetir, ama kurulumunuz hakkında ayrıntı istiyorsanız:

• Gmail'de CloudM taşıma tarihlerini düzeltme
• Outlook'ta CloudM taşıma tarihlerini düzeltme
• Google Workspace'te CloudM taşıma tarihlerini düzeltme
• Microsoft 365'te CloudM taşıma tarihlerini düzeltme

Tüm taşıma araçlarında (sadece CloudM değil) bunun neden olduğuna dair daha derin bir açıklama için taşıma sonrası e-postaların neden yanlış tarih gösterdiği yazısına bakın.

CloudM ile taşıma yaptınız ve her e-postada yanlış tarihlerle mi kaldınız? Kaç mesajın etkilendiğini ve düzeltme maliyetini görmek için ücretsiz tarama başlatın.