Sorun: tum e-postalar ayni tarihi gosteriyor
Bir IMAP migrasyonu sonrasinda kullanicilar posta kutularini actiklarinda tedirgin edici bir manzarayla karsilasiyor: her e-posta tam olarak ayni tarihi gosteriyor. Orijinal gonderim veya alim tarihi yerine, tum mesajlar migrasyonun yapildiği tarihi tasiyor. Yillarca suren yazismalar tek bir gunde gelmis gibi gorunuyor.
Bu, IT yoneticileri icin bir kabus. Destek talepleri akiyor, kullanicilar tarihe gore hicbir sey bulamiyor ve posta kutusunun kronolojik gecmisi aslinda yok edilmis oluyor.
Outlook'ta nasil gorunuyor
Microsoft Outlook'ta "Alindi" sutunu her e-posta icin migrasyon tarihini gosteriyor. Bir mesaj 2018'de mi yoksa 2023'te mi gonderilmis olursa olsun, Outlook ayni tarihi, yani migrasyon aracinin posta kutusunu islediği tarihi gosteriyor. Gelen kutusu, gonderilen ögeler, her klasor etkilenmis durumda. Tarihe gore siralama yapan kullanicilar is akislarinin tamamen bozuldugunu goruyor.
Apple Mail'de nasil gorunuyor
macOS ve iOS'taki Apple Mail de benzer sekilde davraniyor. Her mesajin yaninda goruntulenen tarih, orijinal tarih yerine migrasyon zaman damgasini yansitiyor. Apple Mail, goruntuleme tarihlerini belirlemek icin IMAP sunucu meta verilerini kullandigindan, ayni altta yatan sorun ayni gorunur sonucu uretiyor. Gelen kutusunda gezinirken yalnizca bir ayni tarih duvari goruluyor.
Gmail'de (web arayuzu) nasil gorunuyor
Gmail web arayuzu biraz farkli bir durum sunuyor. Gmail'in web istemcisi genellikle e-postanin kendi "Date" basligini kullanir, dolayisiyla mesajlar Gmail'de dogru tarihle gorunebilir. Ancak IMAP INTERNALDATE yine de yanlis kaliyor, bu da bu Gmail hesabina baglanan herhangi bir IMAP istemcisinin (Outlook, Thunderbird, Apple Mail) migrasyon tarihini gosterecegi anlamina geliyor. Ayni posta kutusu bir istemcide dogru gorunurken digerinde yanlis. Oldukca kafa karistirici.
Neden boyle oluyor: teknik neden
Temel neden, IMAP migrasyon araclarinin e-posta basliklarini nasil islediği ve e-posta istemcilerinin hangi tarihi goruntuleyeceğini nasil belirledigi arasindaki etkilesimde yatiyor. Bunu anlamak icin IMAP protokolune ve baslik yapisina kisa bir bakis gerekiyor.
IMAP migrasyon araclari basliklari nasil isliyor
Bir e-posta bir sunucudan digerine migrate edildiginde, migrasyon araci ham mesaji kaynak sunucudan indirir ve IMAP APPEND komutu araciligiyla hedef sunucuya yukler. Bu islem sirasinda IMAP protokolu, hedef sunucunun mesaja bir "Received" basligi eklemesini zorunlu kilar. Bu baslik, mesajin yeni sunucuya eklendiği anin zaman damgasini icerir, yani migrasyon tarihini.
Her seyi bozan "Received" basligi
E-posta mesajlari genellikle birden fazla "Received" basligi icerir; her biri, mesajin orijinal teslimatinda islenmesini saglayan bir e-posta sunucusu tarafindan eklenir. Outlook gibi istemciler "alim tarihini" zincirdeki en ust "Received" basligini okuyarak belirler. Bir migrasyon araci migrasyon zaman damgasiyla yeni bir "Received" basligi ekleyince, bu en yeni baslik haline gelir ve e-posta istemcileri orijinal tarih yerine bu tarihi gosterir.
Bu, migrasyon aracinin veya e-posta istemcisinin bir hatasi degil. Her ikisi de IMAP ve e-posta standartlarini dogru sekilde takip ediyor. Sorun, bu standartlarin toplu migrasyon icin tasarlanmamis olmasindan kaynaklaniyor ve IMAP APPEND ile tarih goruntuleme mantigi arasindaki etkilesim bu istenmeyen sonucu uretiyor.
INTERNALDATE ve Date basligi karsilastirmasi
IMAP sunuculari her mesaj icin iki farkli tarih degeri depolar. "Date" basligi e-posta mesajinin kendisinin bir parcasidir ve mesajin orijinal olarak ne zaman yazilip gonderildigini kaydeder. INTERNALDATE ise IMAP sunucusu tarafindan depolanan bir meta veri olup, mesajin o sunucuya ne zaman teslim edildigini veya eklendigi gosterir.
Bazi migrasyon araclari APPEND komutu sirasinda orijinal INTERNALDATE'i korumaya calisiyor. Ancak INTERNALDATE dogru sekilde ayarlansa bile, eklenen "Received" basligi, INTERNALDATE yerine "Received" tarihine oncelik veren istemcilerde hala sorunlara neden oluyor.
Hangi migrasyon araclari bu soruna neden oluyor?
Neredeyse tum IMAP migrasyon araclari bu soruna neden olabilir. Sorun, belirli bir araca ozgu degil, IMAP protokolune icekin bir durum. Ancak bazi araclar yaygin kullanimlari nedeniyle sorunla daha sik iliskilendiriliyor.
BitTitan MigrationWiz
BitTitan MigrationWiz, MSP'ler ve IT danismanlari tarafindan en cok kullanilan ticari migrasyon araclarindan biri. MigrationWiz, migrasyon sureci sirasinda "mx.migrationwiz.com" iceren bir "Received" basligi ekliyor. Bu baslik zincirdeki en yeni haline gelir ve Outlook ile diger IMAP istemcilerinde migrasyon tarihinin goruntulenmesine neden olur. Ayrintili kilavuzlar icin Outlook'ta BitTitan tarihlerini duzeltme, Microsoft 365, Google Workspace ve Exchange Online sayfalarini inceleyin.
CloudM Migrate
CloudM Migrate (eski adiyla Cloud Migrator) Google Workspace migrasyonlari icin yaygin kullaniliyor. Diger araclar gibi CloudM de IMAP eklemesi sirasinda kendi "Received" basligini ekler. CloudM ile migrate edilen e-postalar, "Received" basligina dayanan istemcilerde migrasyon tarihini gosterir. Kilavuzlar icin Gmail'de CloudM tarihlerini duzeltme, Outlook, Google Workspace ve Microsoft 365 sayfalarini inceleyin.
imapsync
imapsync, Linux yoneticileri ve hosting saglayicilari arasinda populer bir acik kaynak arac. imapsync INTERNALDATE'i korumaya calissa da, hedef sunucu APPEND islemi sirasinda yine de bir "Received" basligi ekler. imapsync'in SSS bolumu bu kisitlamayi kabul etmekle birlikte, migrasyon sonrasi eklenen basligi kaldirmak icin yerlesik bir cozum sunmuyor. Kilavuzlar icin Outlook'ta imapsync tarihlerini duzeltme, 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 dosyalarindan Google Workspace'e migrasyon icin kendi araci. GSMMO, ozellikle migrasyonun bir ara IMAP adimi icerdigi durumlarda ayni tarih sorununa yol acabilir. Kilavuzlar icin Outlook'ta GSMMO tarihlerini duzeltme, Gmail ve Apple Mail sayfalarini inceleyin.
Exchange Yonetim Merkezi (yerel IMAP icerik aktarma)
Microsoft'un Exchange Yonetim Merkezi, Exchange Online'a (Microsoft 365) migrasyon icin yerel bir IMAP icerik aktarma ozelligi iceriyor. Bu yerlesik migrasyon araci da icerik aktarma sirasinda "Received" basliklari ekleyerek ayni tarih goruntuleme sorununa neden oluyor. Kilavuzlar icin Outlook'ta Exchange IMAP migrasyon tarihlerini duzeltme ve OWA sayfalarini inceleyin.
Manuel IMAP kopyalama
Thunderbird gibi bir istemci araciligiyla IMAP sunuculari arasinda e-postalarin manuel olarak kopyalanmasi bile bu tarih sorununa yol acabilir. Bir e-posta istemcisi IMAP uzerinden bir mesaji kopyaladiginda, hedef sunucu bunu yeni bir ekleme olarak isler ve guncel zaman damgasiyla kendi "Received" basligini ekler. Kilavuzlar icin Outlook'ta manuel IMAP kopyalama tarihlerini duzeltme, Gmail, Thunderbird ve Apple Mail sayfalarini inceleyin.
Yaygin cozum yollarinin neden ise yaramadigi
Bu sorunla karsilasinca kullanicilar ve yoneticiler genellikle hicbirinin sorunu gercekten cozmedigi cesitli yaklasimlari deniyorlar.
"Gonderim tarihine gore siralay" - neden yeterli degil
En yaygin oneri, e-posta istemcisinde "alim" tarihinden "gonderim" tarihine gecis yapmak. Bu gorunum sirasini degistiriyor ancak altta yatan verileri duzeltmiyor. Arama sonuclari hala yanlis tarihi gosteriyor. Takvim entegrasyonlari, uyumluluk araclari ve alim tarihine bagli otomatik is akislari bozuk kalmaya devam ediyor. Ve kullanicilarin bu ayari her cihazda ve her klasorde degistirmeyi dusunmesi gerekiyor.
Yeniden migrasyon: pahali ve riskli
Bazi yoneticiler, ikinci seferde tarih sorununu onleme umuduyla migrasyonu yeniden calistirmayi dusunuyor. Bu yaklasim pahali (posta kutusu sayisina gore 500 ila 5000 EUR arasi), zaman alici ve riskli. Ikinci bir migrasyon ayni "Received" basligi sorununu olusturuyor, veri kaybi riskini ikiye katliyor ve onemli bir kesinti suresi gerektiriyor. Migrasyon araci temel olarak degistirilmedikce yeniden migrasyon tarih sorununu cozmuyor.
Manuel baslik duzenleme: sunucu erisimi gerektiriyor
Teknik olarak duzeltme, her e-postadan migrasyon "Received" basliginin kaldirilmasini iceriyor. Ancak bunu manuel yapmak dogrudan sunucu erisimi, e-posta baslik yapisi bilgisi ve ozel betik yazimi gerektiriyor. 10.000 e-postalik bir posta kutusu icin manuel duzenleme pratik degil ve tehlikeli olcude hataya acik. S/MIME imzali e-postalar, PGP sifreli mesajlar, ic ice MIME sinirlariyla cok parcali yapilar, Content-Transfer-Encoding sorunlari, ASCII disii basliklar (RFC 2047), aşiri buyuk ekler, bozulmus MIME sinirlari: bunlarin her biri basit bir betiğin verileri geri donusumsuz bicimde bozmasina neden olabilir. 10.000 duzeltilmis e-postanin hepsinin saglam olduğunu nasil doğrularsınız? Yapamazsiniz, bunun icin ozel olarak tasarlanmis bir dogrulama sistemi olmadan.
Gercek cozum: orijinal tarihleri geri yuklemek
Dogru yaklasim, her e-postanin baslik zincirindeki migrasyon izlerini tanimlamak ve tum e-posta istemcilerinde orijinal kronolojik sirayi geri yukleyen hedefli duzeltmeler uygulamaktir. Bu basit bir baslik duzenlemesi değil. Surec, RFC uyumluluk dogrulamasi, mesaj yapisi korumasi ve bilinen arac profillerinden olusan bir veri tabani uzerinden migrasyon imza eslemesi iceriyor.
Redate.io bu sorunu nasil duzeltiyor
Redate.io posta kutusuna baglanir (Google Workspace, Microsoft 365 veya herhangi bir IMAP sunucusu) ve migrasyon basliklarindan etkilenen mesajlari tanimlamak icin her e-postayi analiz eder. Analiz ucretsizdir ve herhangi bir odeme yapilmadan once tam olarak kac e-postanin etkilendigini gosterir.
Etkilenen her e-posta icin Redate.io'nun tescilli duzeltme motoru, mesaji cok asamali bir analiz hattindan gecirir. Motor, gercek e-posta verilerinin buyuk hacimlerinin islenmesinden olusturulmus yuezlerce bilinen migrasyon araci profili uzerinde imza eslemesi uygular. Kodlama sorunlarini, cok parcali yapilari, satir ici ekleri ve bir kendin-yap betiğinin verileri bozacagi onlarca ozel durumu yonetiyor (pazartesi sabahi kesfetmek isteyeceginiz turden bir surpriz degil). Duzeltilen her e-posta, sonuclandirilmadan once bir butunluk dogrulamasindan geciyor. Orijinal mesaj gorunur bir "Redate.io - Originals" klasorune tasiniyor (silinmiyor) ve 30 gun boyunca saklanıyor.
Sonuc mu? E-postalar tum istemcilerde dogru orijinal tarihlerini gosteriyor. Siralama tekrar calisiyor. Posta kutusunun kronolojik gecmisi geri yuklendi.
Sik sorulan sorular
Tarihler migrasyondan aylar sonra duzeltileblir mi?
Evet. Orijinal "Date" basligi, migrasyonun ne zaman yapildigina bakilmaksizin e-posta mesajinin icinde korunur. Redate.io tarihleri migrasyondan haftalar, aylar hatta yillar sonra duzeltebilir. Orijinal e-posta basliklari saglam oldugu surece duzeltme calisiyor.
Tarihleri duzeltmek e-postalarimi siler mi?
Hayir. Redate.io asla e-posta silmez. Orijinal mesajlar, posta kutusunda "Redate.io - Originals" adli gorunur bir klasore tasinir ve burada 30 gun boyunca erisilebilir kalir. Duzeltilen her e-posta, surecin sonuclandirilmasindan once orijinaliyle karsilastirilarak dogrulanir. Bir mesaj icin dogrulama basarisiz olursa, orijinal dokunulmadan kalir.
Paylasimli posta kutulariyla calisiyor mu?
Evet. Redate.io Google Workspace ve Microsoft 365'teki paylasimli posta kutulariyla calisiyor. Paylasimli posta kutulari icin baglanti yetkilendirmesi amaciyla yonetici duzeyi erisim gereklidir. Surec bireysel posta kutulariyla aynidir: analiz, duzeltme, dogrulama.
Dogru tarihleri geri yuklemek icin hazir misiniz? Ucretsiz bir analiz baslatın ve her posta kutusunda kac e-postanin etkilendigini oğrenin.