GWS'ten GWS'e Migrasyon: Tarihler Neden Bozulur?

Kimsenin Beklemediği Senaryo

Bir Google Workspace kiracısından diğerine migrasyonu az önce tamamladınız. Bir şirket satın alımı, domain değişikliği, yıllarca ayrı G Suite hesaplarında çalışan iki birimin birleşmesi. İşlem sorunsuz geçti, posta kutuları yerli yerinde, kullanıcılar giriş yapabiliyor. Pazartesi sabahı ilk ticket: "Tüm e-postalarımın tarihi aynı." Sonra bir tane daha. Sonra on tane.

İlk aklınıza gelen şey şu olur: bu kesinlikle bir IMAP sorunu, yanlış yapılandırılmış bir araç, alışılmadık bir şey. Google'dan Google'a yapılan bir migrasyon değil. Oysa sorun tam da orada başlıyor.

Bu senaryo, sektörün en az belgelenen sorunlarından biri. Bu durumla karşılaşan BT yöneticilerinin büyük çoğunluğu, sorunun e-postaların başlıklarında olduğunu anlamadan önce saatlerce mail istemcisi ayarlarını, Outlook'u ve hesap konfigürasyonlarını karıştırıyor.

Google'dan Google'a Migrasyon Tarihleri Neden Bozar

Olanı anlamak için e-posta başlıklarının nasıl çalıştığına bakmak gerekiyor. Her RFC 2822 mesajı, gönderildiği anda istemci veya gönderen sunucu tarafından eklenen bir Date: alanı içerir. Bu, e-postanın "gerçek" tarihidir; yani mesajın yazılıp gönderildiği an.

Ama bir mekanizma daha var: IMAP INTERNALDATE. Bu, mesajın posta kutusuna ne zaman teslim edildiğini belirten, sunucu tarafında saklanan bir meta veridir. Ve işte burada ilginçleşiyor.

Bir migrasyon aracı, e-postayı bir Google Workspace kiracısından diğerine aktarırken IMAP protokolünü kullanır (her iki sunucu da Google'da olsa bile). Mesaj kaynaktan okunur, ardından hedefe yeniden eklenir. Bu yeniden ekleme sırasında hedef sunucu, otomatik olarak migrasyon işleminin tarih ve saatini içeren bir Received: başlığı ekler.

Outlook gibi mail istemcileri ise bir mesajı görüntülerken özgün Date: alanını değil, başlık zincirinin en üstündeki Received: değerini kullanır. Sonuç: tüm e-postalar migrasyon gününün tarihini gösterir.

Bu Soruna Yol Açan Araçlar

Google Workspace kiracılar arası migrasyonlarda kullanılan neredeyse tüm araçlar bu sorundan etkileniyor. Kayda değer bir istisna yok:

• GSMMO (Google Workspace Migration for Microsoft Outlook): temel olarak Exchange'den yapılan migrasyonlar için tasarlanmış, ancak bazı GWS'ten GWS'e akışlarda da kullanılıyor.
• CloudM Migrate: MSP'ler arasında Google'dan Google'a migrasyonlarda yaygın olarak kullanılır, her seferinde bir migrasyon Received: başlığı ekler. Ayrıntılı analiz için CloudM tarih sorunları makalesine bakabilirsiniz.
• BitTitan MigrationWiz: aynı durum geçerli. BitTitan için bu yazıda davranış belgelenmiştir.
• imapsync: iki Google kiracısı arasında da kullanılabilen, IMAP migrasyonlarını betikleştirmeye yarayan açık kaynaklı araç.
• Takeout + manuel IMAP yeniden içe aktarma: daha az yaygın, ama tam olarak aynı sonucu üretiyor.

Bunun nedeni basit: tüm bu araçlar standart IMAP istemcileri gibi davranır. Meta verileri koruyacak "native" bir Google kanalına erişimleri yoktur. Her iki kiracı da Google'da olsa bile, aktarım IMAP katmanından geçer ve bu katman karşısındakinin yine kendisi olduğunu bilmez.

Received Başlıklarının Mekaniği

(Bir e-postanın ham başlıklarını Gmail veya Outlook üzerinden okumayı denediyseniz, bunun pek de keyifli bir okuma olmadığını bilirsiniz. Ama tüm gerçek orada saklı.)

Normal yolculuğunu tamamlamış bir e-posta, yolculuğun tersine sıralanmış Received: başlıkları içerir: mesaja en son dokunan sunucu en üstte yer alır. Migrasyondan sonra ise migrasyon başlığı bu yığının en tepesine yerleşir.

CloudM aracılığıyla bir GWS kiracısından diğerine aktarılan bir mesajda bu şöyle görünür:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <kullanici@yeni-domain.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

Date: alanı 2019'u gösteriyor. İlk Received: ise Ekim 2024'ü. Outlook ilk Received: değerini okuyor. Kullanıcı, 2019'dan kalma bir e-posta için Ekim 2024 tarihini görüyor.

Özgün Date: alanı sağlam duruyor. Hiçbir şey değişmemiş. Bu iyi haber: veri orada, sadece doğru şekilde kullanılmayı bekliyor.

Outlook ile Gmail Aynı Davranmıyor

Bu önemli bir ayrım. Gmail web arayüzü üzerinden e-postalarına erişen kullanıcılar genellikle doğru tarihleri görür, çünkü Gmail mesajları görüntülerken öncelikli olarak RFC 2822 Date: alanına başvurur. Sorun web tarafında daha az göze çarpar.

Öte yandan, Google Workspace posta kutusunu IMAP üzerinden Outlook'ta (veya Exchange ActiveSync senkronizasyonuyla) yapılandıran kullanıcılar yanlış tarihi doğrudan yaşar; çünkü Outlook, migrasyon sırasında eklenen ilk Received: başlığını yansıtan IMAP INTERNALDATE değerine güvenir.

Doğru bir not düşeyim: Outlook'un davranışı sürüme ve bağlantı moduna göre farklılık gösterir. Outlook 2019 ve Microsoft 365 (güncel sürümler), IMAP bağlantısında INTERNALDATE'i kullanır. Daha eski sürümlerde davranış biraz farklılaşabilir. Ama üretim ortamlarında gözlemlenen tüm vakalarda, IMAP üzerinden gerçekleştirilen GWS'ten GWS'e migrasyon, Outlook'ta yanlış tarihlere yol açıyor.

Dolayısıyla yeni bir kiracıya geçiş yapan ve karma kullanıcı profili barındıran kuruluşlarda (bir kısmı Gmail web'de, bir kısmı Outlook'ta) ticket başvuruları tutarsız görünür. BT ekipleri "neden bazıları etkilenip bazıları etkilenmiyor" sorusunun peşinde zaman harcar. Yanıt aslında basit: farkı yaratan mail istemcisi.

Satın Almalar, Birleşmeler, Domain Değişiklikleri: En Sık Rastlanan Durumlar

Bu tür migrasyon hiç de nadir değil. En çok ticket üreten senaryolar şunlar:

Şirket Satın Alımı

Satın alınan şirketin kendi Google Workspace kiracısı vardı (@eskisirket.com). Satın alımın ardından her şey ana şirketin kiracısına taşınması gerekiyor (@grup.com). 250 posta kutusu, arşivler, 8 yıllık e-posta geçmişi. BitTitan ya da CloudM bu iş için görevlendiriliyor. Sonuç: 2,4 milyon e-posta migrasyon hafta sonunun tarihini gösteriyor.

Domain Değişikliği

Yeniden markalanan bir şirket @eskiad.com'dan @yeniad.com'a geçiyor. Aynı Google kiracısı, ama yapılandırma kalıntılarından temiz başlamak için yeni bir kiracı oluşturma kararı alınıyor (yaygın bir tercih). Posta kutuları imapsync veya GSMMO ile taşınıyor. Tarihler birebir aynı şekilde bozuluyor.

Bağlı Ortaklıkların Konsolidasyonu

Her biri kendi tarihi G Suite kiracısında çalışan 4 bağlı ortaklığa sahip bir grup, her şeyi tek bir kiracıda toplamaya karar veriyor. Dört paralel migrasyon, dört ayrı bozuk tarih grubu.

Bu üç senaryoda da sorun aynı, çözüm de aynı. E-posta migrasyonu kontrol listesi, migrasyon başlamadan önce bu tür sorunları öngörmenize yardımcı olur.

Neden Kendi Yazdığınız Bir Betik Çözüm Değil

Sorunu anlamak bir şey. "Python ile başlıkları temizleyen bir betik yazarım" diyerek bunu 30.000 üretim e-postasına uygulamak bambaşka bir şey.

Uç durumlar sayısızdır. Temiz bir test ortamında 50 e-postada sorunsuz çalışan bir betik, gerçek ölçekteki bir üretim posta kutusunda kaçınılmaz olarak şunlarla karşılaşır:

• S/MIME imzalı veya PGP şifreli mesajlar: mesaj yapısında yapılan herhangi bir değişiklik kriptografik imzayı geçersiz kılar.
• Onlarca megabaytlık ekler içeren karmaşık iç içe MIME yapıları (multipart/mixed içinde multipart/alternative).
• Kötü yapılandırılmış ayrıştırıcıların sessizce yuttuğu RFC 2047 kodlamalı başlıklar (ASCII olmayan karakterler).
• Gece 2'de, bir düzeltme işlemi toplu çalışırken gelen 429 Too Many Requests Google API hataları. Bunlar süreci belirsiz bir durumda bırakır.
• Received: zincirinin belirsiz olduğu e-postalar: birden fazla ardışık migrasyon aracının her biri kendi başlığını eklemiş ve hangisinin kaldırılması gerektiğini belirlemek kolay değil.

En önemli soru şu: her düzeltilmiş e-postanın, e-posta e-posta, sağlam olduğunu ve hiçbir şeyin kaybolmadığını veya bozulmadığını nasıl doğrulayacaksınız? Kendi yazdığınız bir betik bu doğrulamayı genellikle yapmaz. Redate.io bunu otomatik olarak yapar ve orijinalleri 30 gün boyunca görünür bir yedekleme klasöründe saklar.

Redate.io Bu Tür Migrasyonlarda Ne Yapar

Redate.io, hedef Google Workspace kiracısına domain yetkisi (domain delegation) aracılığıyla bağlanır; posta kutusu bazında manuel müdahale gerekmez. Tarih meta verileri mesaj içeriğiyle tutarsız olan e-postaları taramak için bu bağlantıyı kullanır. Bu tarama aşaması ücretsizdir ve herhangi bir düzeltme yapılmadan önce sorunun boyutunu tam olarak ortaya koyar.

Özel düzeltme motoru, her mesajın başlık zincirini analiz eder; bilinen migrasyon araçlarının imzaları (BitTitan, CloudM, imapsync, GSMMO ve daha az yaygın olanlar) üzerinde örüntü eşleştirmesi uygular ve mesaj içeriğini değiştirmeden hedeflenmiş meta veri düzeltmesi gerçekleştirir. Her düzeltilen e-posta ayrı ayrı doğrulanır. Orijinaller korunur.

Özellikle Google Workspace'ten Google Workspace'e kiracılar arası migrasyonlar için pipeline, birden fazla migrasyon geçişinin yaşandığı durumları da yönetir (örneğin 2021'de bir kez, 2024'te tekrar taşınan posta kutuları) ve üst üste yığılmış başlık katmanlarını çözer.

CloudM'den Google Workspace'e ve BitTitan'dan Google Workspace'e özgü düzeltme rehberleri, bu tür yapılandırmalar için bağlantı adımlarını ayrıntılı biçimde açıklamaktadır.

Kullanıcılar Şikayet Etmeden Sorunu Tespit Etmek

Bozuk tarihleri tespit etmenin en iyi zamanı, go-live'dan hemen önce, migrasyonun hemen ardından. Thunderbird gibi bir IMAP istemcisi üzerinden birkaç pilot posta kutusu üzerinde hızlı bir kontrol yaparak tarih görüntüsünü beklenen değerlerle karşılaştırabilirsiniz. İçe aktarılan tüm e-postalar aynı yakın tarihi gösteriyorsa, bu sorunun karakteristik işaretidir.

Ama pratikte sorun, migrasyondan haftalar sonra, bir kullanıcının eski bir sözleşmeyi aradığında fark edilir. Gmail kutusunun eksiksiz sıralandığını görür... migrasyon tarihine göre. Binlerce e-posta aynı zaman damgasında yığılmış. Tarihe göre arama artık çalışmıyor. Konuşma zincirleri dağınık. Geçmiş sanki ortadan kalkmış gibi.

Google Workspace kiracılar arası migrasyonları düzenli olarak yöneten MSP'ler için, migrasyon sonrası kontrol listesine (müşteri onayından önce) bir Redate.io taraması eklemek bu tür sürprizlerin önüne geçer.

İki Google Workspace kiracısı arasında migrasyon yaptınız ve e-posta tarihleriniz yanlış mı görünüyor? Redate.io üzerinde ücretsiz tarama başlatın ve herhangi bir düzeltme yapmadan önce sorunun boyutunu ölçün.