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, kopya yazılırken ortaya çıkar. Hedef, kendisine verilen tarihi korur: Microsoft 365 ve Gmail, kopya bu tarihi taşıdığında orijinal tarihi korur. Taşımadığında, kopya ekleme anını tarih olarak alır. Google Workspace'te ise Gmail API üzerinden yazılan her mesaja, ekleme anına tarihli yeni bir Received: başlığı da eklenir.

CloudM ile Microsoft 365'e taşıma sonrasında bu e-postalardan birinin başlıkları hala şunu taşır:

Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

Orijinal Date: başlığı hala 2019'dan kalma, 23 Eylül 2019 diyor, ve orijinal Received: zinciri de hala orada. Ama Microsoft 365'te Outlook'un alındı olarak gösterdiği tarih, her e-postanın posta kutusuna ne zaman ulaştığına dair kendi kaydıdır: CloudM orijinal tarihi iletmediyse, bu kayıt 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 bu ayarın önemi daha azdır: Microsoft 365, kendisine verilen tarihi korur, dolayısıyla görüntülenen tarihi belirleyen şey CloudM'in her e-postanın orijinal tarihini iletip iletmediğidir.

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, ve her e-posta kopyanın tarihini alır.
• 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: Gmail API üzerinden yazılan her mesaja taşıma tarihli bir Received: başlığı eklenir.
• Şirket içi Exchange - Microsoft 365: Kopya IMAP veya EWS üzerinden geçsin, her şey CloudM'in ilettiği tarihe bağlıdır.
• Genel IMAP kaynağı - herhangi bir hedef: Aynı kural geçerlidir: CloudM kaynağa genel bir IMAP sunucusu olarak bağlandığında, orijinal tarih hedefe iletilmediğinde kopya taşıma tarihini gösterir.

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. Tarihi belirleyen şey, taşıma motorunun her mesajla birlikte ilettiği bilgidir ve bu motor nerede çalışırsa çalışsın aynıdır. Taşıma çiftliğiniz CloudM'in bulutunda veya kendi Azure VM'inizde çalışsın, tarihler için sonuç aynıdır.

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ı orijinal tarihi taşımayan bir kopya 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 görüntülenen tarihi orijinal tarihiyle uyuşmayan 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, tescilli bir başlık zinciri analiz motoru kullanır ve taşımayı hangi aracın yaptığını bilmesine gerek yoktur. 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 saklanır; siz silmediğiniz sürece orada kalı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.