E-postalar Neden Migrasyon Sonrasi Yanlış Tarih Gösteriyor

Sorun: tüm e-postalar aynı tarihi gösteriyor

Bir IMAP migrasyonu sonrasında kullanıcılar posta kutularini açtıklarında tedirgin edici bir manzarayla karşılaşıyor: her e-posta tam olarak aynı tarihi gösteriyor. Orijinal gönderim veya alim tarihi yerine, tüm mesajlar migrasyonun yapildiği tarihi taşıyor. Yıllarca suren yazismalar tek bir günde gelmiş gibi görünüyor.

Bu, IT yöneticileri için bir kabus. Destek talepleri akıyor, kullanıcılar tarihe gore hiçbir şey bulamıyor ve posta kutusunun kronolojik geçmişi aslinda yok edilmiş oluyor.

Outlook'ta nasıl görünüyor

Microsoft Outlook'ta "Alindi" sutunu her e-posta için migrasyon tarihini gösteriyor. Bir mesaj 2018'de mi yoksa 2023'te mi gönderilmiş olursa olsun, Outlook aynı tarihi, yani migrasyon aracinin posta kutusunu işlediği tarihi gösteriyor. Gelen kutusu, gönderilen ögeler, her klasör etkilenmiş durumda. Tarihe gore sıralama yapan kullanıcılar is akislarinin tamamen bozuldugunu goruyor.

Apple Mail'de nasıl görünüyor

macOS ve iOS'taki Apple Mail de benzer şekilde davranıyor. Her mesajın yanında görüntülenen tarih, orijinal tarih yerine migrasyon zaman damgasini yansıtıyor. Apple Mail, görüntüleme tarihlerini belirlemek için IMAP sunucu meta verilerini kullandığından, aynı altta yatan sorun aynı görünür sonucu üretiyor. Gelen kutusunda gezinirken yalnızca bir aynı tarih duvari görülüyor.

Gmail'de (web arayüzü) nasıl görünüyor

Gmail web arayüzü biraz farklı bir durum sunuyor. Gmail'in web istemcisi genellikle e-postanin kendi "Date" başlığını kullanır, dolayısıyla mesajlar Gmail'de doğru tarihle görünebilir. Ancak IMAP INTERNALDATE yine de yanlış kalıyor, bu da bu Gmail hesabina bağlanan herhangi bir IMAP istemcisinin (Outlook, Thunderbird, Apple Mail) migrasyon tarihini göstereceği anlamina geliyor. Aynı posta kutusu bir istemcide doğru gorunurken digerinde yanlış. Oldukça kafa karıştırıcı.

Neden böyle oluyor: teknik neden

Temel neden, IMAP migrasyon araclarinin e-posta başlıklarını nasıl işlediği ve e-posta istemcilerinin hangi tarihi goruntuleyeceğini nasıl belirlediği arasındaki etkileşimde yatıyor. Bunu anlamak için IMAP protokolune ve başlık yapısına kisa bir bakış gerekiyor.

IMAP migrasyon araçları başlıkları nasıl işliyor

Bir e-posta bir sunucudan diğerine migrate edildiginde, migrasyon aracı ham mesajı kaynak sunucudan indirir ve IMAP APPEND komutu aracılığıyla hedef sunucuya yükler. Bu işlem sırasında IMAP protokolu, hedef sunucunun mesaja bir "Received" başlığı eklemesini zorunlu kılar. Bu başlık, mesajın yeni sunucuya eklendiği anin zaman damgasini içerir, yani migrasyon tarihini.

Her seyi bozan "Received" başlığı

E-posta mesajları genellikle birden fazla "Received" başlığı içerir; her biri, mesajın orijinal teslimatinda işlenmesini sağlayan bir e-posta sunucusu tarafından eklenir. Outlook gibi istemciler "alim tarihini" zincirdeki en üst "Received" başlığını okuyarak belirler. Bir migrasyon aracı migrasyon zaman damgasiyla yeni bir "Received" başlığı ekleyince, bu en yeni başlık haline gelir ve e-posta istemcileri orijinal tarih yerine bu tarihi gösterir.

Bu, migrasyon aracinin veya e-posta istemcisinin bir hatasi değil. Her ikisi de IMAP ve e-posta standartlarini doğru şekilde takip ediyor. Sorun, bu standartlarin toplu migrasyon için tasarlanmamis olmasindan kaynaklanıyor ve IMAP APPEND ile tarih görüntüleme mantigi arasındaki etkileşim bu istenmeyen sonucu üretiyor.

INTERNALDATE ve Date başlığı karsilastirmasi

IMAP sunucuları her mesaj için iki farklı tarih değeri depolar. "Date" başlığı e-posta mesajinin kendisinin bir parcasidir ve mesajın orijinal olarak ne zaman yazilip gönderildiğini kaydeder. INTERNALDATE ise IMAP sunucusu tarafından depolanan bir meta veri olup, mesajın o sunucuya ne zaman teslim edildigini veya eklendigi gösterir.

Bazi migrasyon araçları APPEND komutu sırasında orijinal INTERNALDATE'i korumaya çalışıyor. Ancak INTERNALDATE doğru şekilde ayarlansa bile, eklenen "Received" başlığı, INTERNALDATE yerine "Received" tarihine öncelik veren istemcilerde hala sorunlara neden oluyor.

Hangi migrasyon araçları bu soruna neden oluyor?

Neredeyse tüm IMAP migrasyon araçları bu soruna neden olabilir. Sorun, belirli bir araca özgü değil, IMAP protokolune icekin bir durum. Ancak bazi araçlar yaygin kullanimlari nedeniyle sorunla daha sik iliskilendiriliyor.

BitTitan MigrationWiz

BitTitan MigrationWiz, MSP'ler ve IT danismanlari tarafından en çok kullanılan ticari migrasyon araclarindan biri. MigrationWiz, migrasyon süreci sırasında "mx.migrationwiz.com" içeren bir "Received" başlığı ekliyor. Bu başlık zincirdeki en yeni haline gelir ve Outlook ile diğer IMAP istemcilerinde migrasyon tarihinin goruntulenmesine neden olur. Ayrintili kılavuzlar için Outlook'ta BitTitan tarihlerini düzeltme, Microsoft 365, Google Workspace ve Exchange Online sayfalarini inceleyin.

CloudM Migrate

CloudM Migrate (eski adiyla Cloud Migrator) Google Workspace migrasyonlari için yaygin kullaniliyor. Diğer araçlar gibi CloudM de IMAP eklemesi sırasında kendi "Received" başlığını ekler. CloudM ile migrate edilen e-postalar, "Received" başlığına dayanan istemcilerde migrasyon tarihini gösterir. Kılavuzlar için Gmail'de CloudM tarihlerini düzeltme, Outlook, Google Workspace ve Microsoft 365 sayfalarini inceleyin.

imapsync

imapsync, Linux yöneticileri ve hosting sağlayıcıları arasında popüler bir açık kaynak araç. imapsync INTERNALDATE'i korumaya çalışsa da, hedef sunucu APPEND işlemi sırasında yine de bir "Received" başlığı ekler. imapsync'in SSS bölümü bu kısıtlamayı kabul etmekle birlikte, migrasyon sonrasi eklenen başlığı kaldirmak için yerleşik bir çözüm sunmuyor. Kılavuzlar için Outlook'ta imapsync tarihlerini düzeltme, Gmail, Microsoft 365 ve Google Workspace sayfalarini inceleyin.

GSMMO (Google Workspace Migration)

Google Workspace Migration for Microsoft Outlook (GSMMO), Google'in Exchange veya Outlook PST dosyalarından Google Workspace'e migrasyon için kendi aracı. GSMMO, özellikle migrasyonun bir ara IMAP adimi içerdiği durumlarda aynı tarih sorununa yol açabilir. Kılavuzlar için Outlook'ta GSMMO tarihlerini düzeltme, Gmail ve Apple Mail sayfalarini inceleyin.

Exchange Yönetim Merkezi (yerel IMAP içerik aktarma)

Microsoft'un Exchange Yönetim Merkezi, Exchange Online'a (Microsoft 365) migrasyon için yerel bir IMAP içerik aktarma özelliği içeriyor. Bu yerleşik migrasyon aracı da içerik aktarma sırasında "Received" başlıkları ekleyerek aynı tarih görüntüleme sorununa neden oluyor. Kılavuzlar için Outlook'ta Exchange IMAP migrasyon tarihlerini düzeltme ve OWA sayfalarini inceleyin.

Manuel IMAP kopyalama

Thunderbird gibi bir istemci aracılığıyla IMAP sunucuları arasında e-postalarin manuel olarak kopyalanmasi bile bu tarih sorununa yol açabilir. Bir e-posta istemcisi IMAP üzerinden bir mesajı kopyaladiginda, hedef sunucu bunu yeni bir ekleme olarak işler ve güncel zaman damgasiyla kendi "Received" başlığını ekler. Kılavuzlar için Outlook'ta manuel IMAP kopyalama tarihlerini düzeltme, Gmail, Thunderbird ve Apple Mail sayfalarini inceleyin.

Yaygin çözüm yollarinin neden ise yaramadigi

Bu sorunla karşılaşınca kullanıcılar ve yöneticiler genellikle hicbirinin sorunu gerçekten çözmediği çeşitli yaklaşımları deniyorlar.

"Gönderim tarihine gore sırala" - neden yeterli değil

En yaygin öneri, e-posta istemcisinde "alim" tarihinden "gönderim" tarihine geçiş yapmak. Bu görünüm sirasini degistiriyor ancak altta yatan verileri duzeltmiyor. Arama sonuçları hala yanlış tarihi gösteriyor. Takvim entegrasyonlari, uyumluluk araçları ve alim tarihine bağlı otomatik is akislari bozuk kalmaya devam ediyor. Ve kullanıcıların bu ayari her cihazda ve her klasorde değiştirmeyi düşünmesi gerekiyor.

Yeniden migrasyon: pahali ve riskli

Bazi yöneticiler, ikinci seferde tarih sorununu önleme umuduyla migrasyonu yeniden çalıştırmayı düşünüyor. Bu yaklaşım pahali (posta kutusu sayisina gore 500 ila 5000 EUR arasi), zaman alici ve riskli. Ikinci bir migrasyon aynı "Received" başlığı sorununu oluşturuyor, veri kaybi riskini ikiye katlıyor ve önemli bir kesinti süresi gerektiriyor. Migrasyon aracı temel olarak değiştirilmedikçe yeniden migrasyon tarih sorununu çözmüyor.

Manuel başlık düzenleme: sunucu erisimi gerektiriyor

Teknik olarak düzeltme, her e-postadan migrasyon "Received" başlığının kaldırılmasını içeriyor. Ancak bunu manuel yapmak doğrudan sunucu erisimi, e-posta başlık yapısı bilgisi ve özel betik yazimi gerektiriyor. 10.000 e-postalik bir posta kutusu için manuel düzenleme pratik değil ve tehlikeli ölçüde hataya açık. S/MIME imzali e-postalar, PGP şifreli mesajlar, ic ice MIME sinirlariyla çok parçalı yapilar, Content-Transfer-Encoding sorunları, ASCII disii başlıklar (RFC 2047), aşiri büyük ekler, bozulmus MIME sınırları: bunlarin her biri basit bir betiğin verileri geri dönüşümsüz biçimde bozmasina neden olabilir. 10.000 düzeltilmiş e-postanin hepsinin sağlam olduğunu nasıl doğrularsınız? Yapamazsiniz, bunun için özel olarak tasarlanmis bir doğrulama sistemi olmadan.

Gerçek çözüm: orijinal tarihleri geri yüklemek

Doğru yaklaşım, her e-postanin başlık zincirindeki migrasyon izlerini tanımlamak ve tüm e-posta istemcilerinde orijinal kronolojik sirayi geri yukleyen hedefli düzeltmeler uygulamaktir. Bu basit bir başlık duzenlemesi değil. Süreç, RFC uyumluluk dogrulamasi, mesaj yapısı korumasi ve bilinen araç profillerinden olusan bir veri tabani üzerinden migrasyon imza eslemesi içeriyor.

Redate.io bu sorunu nasıl düzeltiyor

Redate.io posta kutusuna bağlanır (Google Workspace, Microsoft 365 veya herhangi bir IMAP sunucusu) ve migrasyon basliklarindan etkilenen mesajları tanımlamak için her e-postayi analiz eder. Analiz ucretsizdir ve herhangi bir odeme yapılmadan önce tam olarak kac e-postanin etkilendiğini gösterir.

Etkilenen her e-posta için Redate.io'nun tescilli düzeltme motoru, mesajı çok asamali bir analiz hattindan geçirir. Motor, gerçek e-posta verilerinin büyük hacimlerinin islenmesinden oluşturulmuş yuezlerce bilinen migrasyon aracı profili üzerinde imza eslemesi uygular. Kodlama sorunlarini, çok parçalı yapilari, satir ici ekleri ve bir kendin-yap betiğinin verileri bozacagi onlarca özel durumu yonetiyor (pazartesi sabahi kesfetmek isteyeceginiz turden bir surpriz değil). Duzeltilen her e-posta, sonuçlandırılmadan önce bir bütünlük dogrulamasindan geçiyor. Orijinal mesaj görünür bir "Redate.io - Originals" klasorune taşınıyor (silinmiyor) ve 30 gün boyunca saklanıyor.

Sonuç mu? E-postalar tüm istemcilerde doğru orijinal tarihlerini gösteriyor. Sıralama tekrar çalışıyor. Posta kutusunun kronolojik geçmişi geri yuklendi.

Sik sorulan sorular

Tarihler migrasyondan aylar sonra duzeltileblir mi?

Evet. Orijinal "Date" başlığı, migrasyonun ne zaman yapildigina bakilmaksizin e-posta mesajinin içinde korunur. Redate.io tarihleri migrasyondan haftalar, aylar hatta yillar sonra duzeltebilir. Orijinal e-posta başlıkları sağlam olduğu süreçe düzeltme çalışıyor.

Tarihleri düzeltmek e-postalarimi siler mi?

Hayir. Redate.io asla e-posta silmez. Orijinal mesajlar, posta kutusunda "Redate.io - Originals" adli görünür bir klasore tasinir ve burada 30 gün boyunca erisilebilir kalir. Duzeltilen her e-posta, sürecin sonuçlandırılmasından önce orijinaliyle karsilastirilarak doğrulanır. Bir mesaj için doğrulama başarısız olursa, orijinal dokunulmadan kalir.

Paylaşımlı posta kutulariyla çalışıyor mu?

Evet. Redate.io Google Workspace ve Microsoft 365'teki paylaşımlı posta kutulariyla çalışıyor. Paylaşımlı posta kutulari için bağlantı yetkilendirmesi amaciyla yönetici düzeyi erisim gereklidir. Süreç bireysel posta kutulariyla aynidir: analiz, düzeltme, doğrulama.

Doğru tarihleri geri yüklemek için hazir misiniz? Ücretsiz bir analiz başlatın ve her posta kutusunda kac e-postanin etkilendiğini oğrenin.