cPanel Migrasyonu: Yanlış Tarihler

Pazartesi Sabahı Gelen Şok

cPanel paylaşımlı hostinginizi Google Workspace veya Microsoft 365'e taşıma işlemini henüz tamamladınız. Her şey yolunda görünüyor: posta kutularına erişilebiliyor, kullanıcılar giriş yapabiliyor. Sonra saat 09:15'te ilk talep geliyor: "Eski e-postalarım hepsi aynı tarihi gösteriyor, geçen hafta sonu tarihini." Ardından bir tane daha. Sonra on tane.

Bu izole bir hata değil. cPanel migrasyonlarının e-posta tarih meta verilerini nasıl işlediğinin (ya da aslında işlemediğinin) doğrudan bir sonucu.

cPanel, Roundcube, Horde: Kendine Özgü Bir IMAP Ortamı

cPanel paylaşımlı hosting, Roundcube veya Horde gibi bir webmail arayüzüyle birlikte çalışan bir IMAP sunucusu (genellikle Dovecot) barındıran Linux tabanlı bir sunucudur. Teknik açıdan alışılmadık bir yapı değil. Ama bu ortamın bazı özellikleri, kurumsal platformlara yapılan migrasyonları göründüğünden çok daha hassas bir hale getiriyor.

Her şeyden önce, cPanel posta kutuları yıllarca, hatta on yıl boyunca e-posta biriktirebilir. Domainini 2013'ten beri paylaşımlı bir hostingde barındıran bir müşterinin çok derin arşivleri olabilir. Bu hacim, migrasyonun yapılma biçimiyle birleşince tarih sorununa zemin hazırlıyor.

Bir de kullanılan araçlar meselesi var. Bu migrasyonlarda genellikle WHM'nin yerleşik "Migrations" aracı, hosting sağlayıcısının komut satırından çalıştırdığı imapsync ya da Google Workspace'e geçiş için GSMMO gibi genel amaçlı çözümler tercih ediliyor.

cPanel Migrasyonundan Sonra Tarihler Neden Bozuluyor

Sorunu anlamak için iki farklı kavramı kavramak gerekiyor: bir e-postanın Date: başlığı ve IMAP INTERNALDATE değeri.

Date: başlığı, RFC 2822 standardına uygun olarak gönderildiğinde mesajın ham içeriğine yazılır. E-postanın ne zaman oluşturulduğunu ve gönderildiğini gösterir. Bu başlık, mesajda bilinçli bir değişiklik yapılmadığı sürece hiç değişmez.

INTERNALDATE ise IMAP sunucusunun her depolanan mesajla ilişkilendirdiği bir meta veridir. Mesajın içeriğinden tamamen bağımsızdır. Bir e-posta sunucuya normal yollarla ulaştığında, INTERNALDATE mesajın Received: başlıklarından ya da doğrudan teslim edilmişse o anın tarihinden türetilir. Outlook, Thunderbird ve pek çok e-posta istemcisi mesajları sıralamak için bu değeri kullanır.

IMAP migrasyonunda mesajlar bir sunucudan diğerine kopyalanır. Sorun şu: migrasyon aracı her mesajı hedef sunucuda yeniden oluşturmak zorunda. Pek çok araç için yeni oluşturulan mesajın INTERNALDATE değeri, orijinal tarihi değil, migrasyon tarihini yansıtıyor. Bunun yanı sıra başlık zincirinin en üstüne migrasyon tarihiyle damgalanmış bir Received: başlığı ekleniyor. Bu durum, görüntülenecek tarihi hesaplamak için bu başlığa bakan e-posta istemcilerini daha da fazla karıştırıyor.

Sonuç: 2019 tarihli bir e-posta, Google Workspace'e migrasyon günü damgalı bir INTERNALDATE değeriyle ve dünün tarihini taşıyan bir Received: başlığıyla ulaşıyor. Outlook bunu yeni gelen bir mesaj olarak gösteriyor. Tüm arşiv kronolojisi altüst oluyor.

WHM / cPanel Migrasyon Aracı

WHM'nin cPanel hesaplarını başka bir platforma taşımak için kullandığı yerleşik araç, hedef bir harici IMAP sunucusu (Google Workspace, Microsoft 365) olduğunda bu sorunu neredeyse sistematik biçimde üretiyor. Maildir içeriklerini orijinal INTERNALDATE değerini korumadan IMAP APPEND yöntemiyle yeni sunucuya kopyalıyor. Böylece her mesaj, işlemin gerçekleştiği andaki zaman damgasını alıyor.

imapsync ile cPanel'den Manuel Migrasyon

imapsync güçlü bir araç; ama varsayılan davranışı her zaman tarihleri korumaz. Doğru parametreler (ve doğru sürüm) kullanılmadığında 40.000 mesajı hepsine script'in çalıştırıldığı tarihi atayarak kopyalayabilir. (25.000 mesajlık bir posta kutusunda tarih sorununu teşhis etmek için imapsync loglarını satır satır taradıysanız, bu deneyimi bir daha yaşamak istemediğinizi çok iyi biliyorsunuzdur.)

Daha doğrusu, imapsync tarihleri korumaya çalışan seçenekler sunuyor; ancak bu seçenekler kaynak ve hedef sunuculara göre farklı davranıyor. Tüm cPanel / Dovecot yapılandırmalarında etkinlikleri garanti edilmiyor.

GSMMO ve Genel Amaçlı Araçlar

Google Workspace Migration for Microsoft Outlook (GSMMO) aslında Outlook'tan geçiş için tasarlanmış; ham bir IMAP sunucusundan değil. Outlook'ta yapılandırılmış bir IMAP hesabı üzerinden cPanel'den geçiş yapmak için kullanıldığında, tarihler aynı sonuca uğruyor: Google Workspace'teki INTERNALDATE migrasyon tarihine ayarlanıyor. GSMMO ve yanlış e-posta tarihleri sorunu o kadar yaygın ki ayrı bir konuya dönüşmüş durumda.

Hangi E-posta İstemcileri Etkileniyor?

Tarih bozulması, kullanılan istemciye göre farklı biçimlerde kendini gösteriyor.

Outlook, en çok etkilenen istemci. Klasörler için ana sıralama ölçütü olarak INTERNALDATE değerini (ya da migrasyon Received: başlığını) kullanıyor. Kötü yönetilen bir cPanel migrasyonunun ardından Outlook kullanan bir posta kutusu, arşivlenmiş binlerce e-postayı migrasyon haftasonunun tarihiyle gösterebilir. Outlook'ta imapsync tarihlerini düzeltme en sık talep edilen düzeltmeler arasında yer alıyor.

Gmail (Google Workspace) genellikle e-posta listesinde Date: başlığındaki tarihi gösteriyor; ancak INTERNALDATE değerine bağlı olarak sıralama yine de bozulabiliyor. Kullanıcılar, tarih bazlı arama ve sıralamada tutarsız davranışlar bildiriyor.

Apple Mail ve Thunderbird daha nüanslı davranışlar sergiliyor; ama başlık zincirinin en üstünde migrasyon Received: başlığı olduğunda her ikisi de sorundan payını alıyor.

İyi Haber: Orijinal Tarih Hala Orada

Her şeyi değiştiren teknik detay bu. Mesajın orijinal Date: başlığı, e-postanın ham içeriğine yazılmış durumda. Migrasyon buna dokunmuyor. Etkilenen bir e-postayı açıp ham başlıklara baktığınızda (Gmail'de "Orijinali göster", Outlook'ta Dosya > Özellikler), orijinal Date: değerinin sağlam durduğunu görüyorsunuz; hemen ardından biri migrasyon tarihini taşıyan bir veya birkaç Received: başlığı geliyor.

Bu bilgi her zaman orada. Meta verileri düzeltmek için kullanılabilir. Redate.io'nun düzeltme motoru tam olarak bunu yapıyor.

"Bunu Kendim Düzelteyim" Sandığınızdan Riskli

Cazibesi anlaşılır. Sorun basit görünüyor: orijinal tarihi oku, meta verileri düzelt, sonrakine geç. Ama mekanizmayı anlamak ayrı şey, 12.000 e-postayı prodüksiyon ortamında tek bir kayıp vermeden düzeltmek ayrı şey.

El yapımı scriptlerin genellikle hesaba katmadığı birkaç gerçek:

S/MIME imzalı veya PGP şifreli e-postalar: mesajın yapısında yapılan herhangi bir değişiklik kriptografik imzayı geçersiz kılıyor. Düzeltme öncesinde imza doğrulamasını geçen bir e-posta, sonrasında geçemiyor. Hukuk büroları, finans sektörü ve sağlık gibi uyumluluk gereksinimleri olan kullanıcılar bu sorunla en kötü anda yüzleşiyor.
Non-ASCII başlıklar ve RFC 2047 kodlaması: cPanel posta kutuları, çok farklı istemcilerden gelen yıllarca birikmiş e-postalar barındırıyor. Bazı başlıklar RFC 2047 standardına göre kodlanmış karakterler içeriyor. Başlıkları yeniden oluşturan kötü yazılmış bir script bu kodlamaları görünmez biçimde bozabilir.
İç içe geçmiş MIME yapıları: üç eki ve alternatif HTML gövdesi olan bir e-posta karmaşık bir multipart yapısına sahip. MIME sınırlarında yapılan en ufak bir hata mesajı okunamaz hale getiriyor; ya da daha kötüsü, ekler hata mesajı bile vermeden kayboluyor.
API kotaları ve rate limiting: Google Workspace ve Microsoft 365, dakika başına IMAP işlem sayısına katı sınırlar koyuyor. Üstel geri çekilmeyi (exponential backoff) doğru uygulamayan bir script gece 03:00'te 429 hataları alıyor; sabah kalkıp yarım kalmış, tam olarak nerede takıldığını bilmediğiniz bir migrasyon buluyorsunuz.
Geri alma imkansız: bir şeyler yarıda ters giderse hangi duruma geri döneceksiniz? Orijinaller hala orada mı? Kopyalar oluştu mu? Redate.io orijinalleri tam olarak bu duruma düşmemek için 30 gün boyunca görünür bir yedekleme klasöründe saklıyor.

Bir geliştirme ortamında 50 test e-postasında çalışan bir script, 2011'den kalma bir cPanel hostinginden taşınan 18.000 mesajlık prodüksiyon posta kutusunda aynı şekilde çalışmayabilir.

Redate.io, cPanel Migrasyonu Sonrası Tarihleri Nasıl Düzeltiyor

Redate.io doğrudan hedef posta kutusuna bağlanıyor (Google Workspace için domain delegasyonu, Microsoft 365 için Azure AD ya da doğrudan IMAP sunucusu) ve ücretsiz bir tarama yaparak tarih meta verileri orijinal Date: başlığıyla tutarsız olan e-postaları tespit ediyor.

Çok aşamalı analiz pipeline'ı daha sonra Received: başlıkları üzerinde imza eşleştirmesi yaparak migrasyon araçlarının eklediği başlıkları tespit ediyor ve meşru başlıklardan ayırt ediyor. Mesaj içeriğinde herhangi bir değişiklik yapılmadan hedeflenmiş meta veri düzeltmesi gerçekleştiriliyor: metin, ekler, orijinal başlıklar... hepsi bozulmadan kalıyor. Her düzeltilen e-posta, işlem onaylanmadan önce tek tek doğrulanıyor.

Özellikle cPanel migrasyonları söz konusu olduğunda, motor Dovecot'tan IMAP'a geçiş migrasyonlarının ve imapsync scriptlerinin tipik imzalarını tanıyor; Türkiye ve Avrupa'daki paylaşımlı hosting sağlayıcılarında yaygın olan yapılandırma varyantları da dahil.

Hedefe Göre Özel Kılavuzlar

cPanel migrasyonunuzun hedef platformuna bağlı olarak aşağıdaki kılavuzlar tam adımları açıklıyor:

cPanel'den geçiş yaptınız ve kullanıcılarınız yanlış tarihler mi görüyor? Redate.io'da ücretsiz tarama başlatın: onayınız olmadan hiçbir değişiklik yapılmadan kaç e-postanın etkilendiğini tam olarak öğrenin.

cPanel Migrasyonu Sonrası Yanlış E-posta Tarihleri