POP'tan IMAP'a Geçiş: Eski E-postalar Bugünün Tarihini Gösteriyor

Klasik Pazartesi Sabahı Senaryosu

E-posta hesabınızı POP3'ten IMAP'a geçirdiniz. Yapılandırma basitti, barındırma sağlayıcınız size yol gösterdi, her şey sorunsuz ilerledi. Ta ki gelen kutunuzu yeniden açana kadar. 2019'dan, 2021'den gelen e-postalarınız, geçen yılın arşivleri... hepsi aynı tarihi gösteriyor: bugün. Hatta çoğu zaman birkaç saniyelik farkla aynı saati.

Bu, e-posta istemcinizin bir hatası değil. Saat dilimi sorunu da değil. IMAP protokolünün beklenen davranışı bu; yerel olarak depolanan e-postaları bu yöntemle bir sunucuya yükleyen herkes bu sorunla karşılaşır.

POP3 ve IMAP: Depolama Açısından Temel Fark

Sorunun neden yaşandığını anlamak için önce POP3'ün nasıl çalıştığını, IMAP'tan ne kadar farklı olduğunu kavramak gerekiyor.

POP3'te sunucu yalnızca geçici bir posta kutusu işlevi görür. İstemciniz (Outlook, Thunderbird, Apple Mail) bağlanır, mesajları indirir, ardından yapılandırmanıza göre onları sunucudan siler ya da bırakır. E-postalar bundan sonra yalnızca yerel ortamda yaşar: Outlook için bir .pst dosyasında, Thunderbird'ün yerel profilinde ya da sabit diskinizde bir veritabanında.

IMAP'ta ise tam tersi geçerlidir: e-postalar sunucuda yaşar. İstemci yalnızca uzakta depolananları görüntüler. Tüm cihazlarınız arasındaki sorunsuz senkronizasyon da buradan gelir.

Sorun iki sistem arasındaki geçişte ortaya çıkıyor. Yani eski POP yerel e-postalarınızı IMAP sunucusuna yüklediğinizde.

IMAP APPEND: Her Şeyi Değiştiren Komut

E-posta istemcisi yerel bir mesajı IMAP sunucusuna yüklerken IMAP APPEND komutunu kullanır. Bu komut sunucuya şunu söyler: "Bu mesajı şu klasörde sakla."

Sunucu mesajı alır, kaydeder ve bir zaman damgası atar. Bu zaman damgası, INTERNALDATE'tir. IMAP'ın temel meta verisi olan bu değer, mesajın sunucuya ne zaman yüklendiğini gösterir. Ve istemci APPEND komutunda açıkça bir tarih belirtmezse sunucu varsayılan olarak... o anki zamanı kullanır.

Yani şunu söylemek gerekirse: mesajın başlıklarında 2018 tarihi yazıyor olsa bile, sunucuya "bu e-posta 2018'den" denmezse, sunucu mesajın az önce yüklendiği sonucuna varır ve ona bugünün INTERNALDATE değerini atar.

(Bir e-postanın ham başlıklarına baktıysanız, onlarca Received: satırının arasında Date: satırını görmüşsünüzdür. RFC 2822 tarafından tanımlanan bu Date: alanı gerçek gönderim tarihini içerir. Ancak IMAP INTERNALDATE, mesajın içeriğiyle hiçbir ilgisi olmayan, sunucu tarafında saklanan ayrı bir meta veridir.)

IMAP'tan IMAP'a Migrasyondan Farkı

Bir IMAP sunucusundan diğerine yapılan klasik migrasyonlarda (BitTitan, CloudM, imapsync vb. ile) sorun biraz farklıdır. Migrasyon aracı mesajları bir sunucudan diğerine kopyalar; bu durumda teorik olarak APPEND komutuyla orijinal INTERNALDATE'i hedef sunucuya aktarabilir. Oradaki sorun ise bazı araçların migrasyon tarihini taşıyan bir Received: başlığı eklemesi ve bunun Outlook gibi istemcilerde görüntülemeyi bozmasıdır.

Sizin durumunuzda ise tamamen yerel verilerden başlıyorsunuz. Kopyalanacak bir kaynak INTERNALDATE yok. .pst dosyası ya da Thunderbird profili, mesajları kendi tescilli formatında ve kendi dahili meta verileriyle saklar. E-posta istemcisi bu mesajları IMAP sunucusuna yüklemek için yeniden okuduğunda, APPEND komutunu mesajın içeriğinden yeniden oluşturur. Çoğu durumda açık bir tarih iletmez.

Sonuç: IMAP sunucusu, birkaç dakika içinde yüzlerce hatta binlerce mesaj alır ve hepsine aynı zaman dilimini atar: şimdi.

Sorunun tüm cihazlarınıza anında yayılmasının tam da nedeni bu. Telefonunuz, tabletiniz, ikinci bilgisayarınız: hepsi aynı IMAP sunucusuna bağlanır ve tamamen aynı şeyi görür. İstemci tarafında hiçbir düzeltme mümkün değildir.

Hangi İstemci Neyi Gösteriyor ve Neden

Tüm e-posta istemcileri aynı şekilde davranmaz. Bu, pek çok BT yöneticisinin sonradan keşfettiği bir noktadır.

Outlook (özellikle 2023-2024 güncellemelerinden bu yana) "Alındı" sütununda sunucunun INTERNALDATE değerini kullanır. Dolayısıyla orijinal gönderim tarihini değil, yükleme tarihini gösterir. Bu Outlook'a özgü davranış hakkında daha fazla bilgi için şu makale faydalı olacaktır: Outlook: IMAP Migrasyonunda Alınan Tarih vs Gönderim Tarihi.

Gmail / Google Workspace ve Thunderbird biraz daha nüanslı davranır. Gmail, zaman zaman görüntüleme için mesaj başlığındaki Date: alanını kullanabilir; bu da her şeyin yolunda gittiği izlenimini verir... ta ki tarihe göre sıralamayı deneyin ve sıralamanın tamamen rastgele olduğunu fark edene kadar.

Apple Mail genellikle Date: başlığından çekilen tarihi gösterir, ancak sıralama ve arama arka planda INTERNALDATE üzerinden çalışır. Bu yüzden e-postalarınız görsel olarak doğru tarihlere sahip gibi görünebilir, ama sıralama işlevi artık düzgün çalışmaz. Apple Mail'in bu davranışının ayrıntıları için Apple Mail: Geçiş Sonrası Yanlış Tarih Sorunu makalesine bakabilirsiniz.

İyi Haber: Orijinal Tarih Sağlam

Her e-postanın Date: başlığı, yani gerçek gönderim (ya da alım) tarihini içeren alan, dokunulmadan duruyor. Hâlâ mesajın içinde, tam da olması gereken yerde. Bir e-postayı açıp ayrıntılara baktığınızda gördüğünüz tarih bu.

IMAP sunucusunun "bozduğu" şey yalnızca INTERNALDATE, yani mesajın dışındaki bu meta veri. Mesajın kendisi bütünüyle sağlam.

Düzeltmenin mümkün olmasının nedeni de bu. Sorunun bir süre fark edilmemesinin nedeni de aynı: e-postaları tek tek açtığınızda doğru görünürler. Sorun ancak gelen kutunuzu tarihe göre sıralı listede incelerken belirginleşir. 2019'dan kalma e-postalar, yeni gelmiş gibi en üstte görünür. Hepsi aynı tarihle.

Ölçek Sorunu: 3.000 E-posta, 3 E-postadan Farklıdır

Belki şunu düşünüyorsunuz: "Sil ve bu sefer doğru şekilde yeniden içe aktar." 5 ya da 10 test e-postası için evet, işe yarar. İç içe geçmiş klasörler, büyük ekler, S/MIME imzalı mesajlar ve 2015'e uzanan e-posta zincirleri içeren 8.000 mesajlık bir posta kutusu için ise durum çok farklı.

50 e-postalık bir test grubunda çalışan ev yapımı bir betik, üretim posta kutusunda çok rahatlıca kopyalar oluşturabilir, ekleri kaybedebilir ya da konuşma zincirlerini bozabilir. API kota yönetimi, ağ zaman aşımı sorunları, alışılmışın dışında MIME yapısına sahip mesajlar... bunların hepsi, özelleşmemiş bir aracın üstesinden gelemeyeceği sınır durumlarıdır.

Peki bir şeyler yarı yolda ters giderse? Yedekleme ve geri alma mekanizması olmadan, veri kaybı geri döndürülemez hale gelir.

Bu sorun, yoğun migrasyon yöneten yöneticiler arasında iyi bilinir. Tarihlerin neden bozulduğunu anlamak ayrı bir şeydir. 15.000 e-postayı her mesaj yapısını koruyarak düzgünce düzeltmek ise bambaşka. Bu konuyu daha ayrıntılı incelemek için E-posta Tarihleri Migrasyondan Sonra Düzeltilebilir mi? makalesi farklı yaklaşımları ve sınırlarını ele alıyor.

Redate.io Bu Özel Durumu Nasıl Ele Alır

Redate.io tam olarak bu tür durumlar için tasarlandı. Analiz motoru, INTERNALDATE'i mesaj başlıklarındaki tarihle eşleşmeyen e-postaları tespit eder; ister POP'tan IMAP'a geçiş, ister IMAP sunucuları arasında migrasyon, isterse yerel arşivlerin elle yüklenmesi olsun.

Çok aşamalı analiz hattı her mesajın başlık zincirini inceler, RFC uyumluluğunu doğrular ve mesaj içeriğine dokunmadan tarih meta verilerini yeniden oluşturur: ne metin, ne ekler, ne MIME yapısı ne de dijital imzalar etkilenir. Düzeltilen her e-posta, onaylanmadan önce tek tek doğrulanır.

Orijinaller 30 gün boyunca görünür bir yedekleme klasöründe saklanır. Bir şey beğenmezseniz geri yükleyebilirsiniz.

İlk tarama ücretsizdir: Redate posta kutunuzu analiz eder, etkilenen e-postaları belirler ve herhangi bir karar vermeden önce size kesin sayıyı bildirir. Körlemesine bir taahhüt yok.

Redate.io, Google Workspace (domain delegation), Microsoft 365 (Azure AD) veya doğrudan IMAP üzerinden posta kutularınıza bağlanır. Yerel kurulum gerekmez. Elle taşımanız gereken .pst dosyası yok.

Birden fazla posta kutusunu yöneten ve bu tür vakalar hakkında pratik bilgi edinmek isteyen yöneticiler için MSP'ler İçin E-posta Tarih Sorunlarını Düzeltme makalesi tamamlayıcı bir okuma. Thunderbird'ün POP/IMAP geçişinde kendine özgü davranışları ve düzeltme sürecindeki ayrıntılar için ise Thunderbird Migrasyon Sonrası Yanlış Tarih makalesine bakabilirsiniz.

Henüz Yapmadıysanız: Sorunu Önceden Önleyin

Yerel arşivlerinizi henüz IMAP sunucusuna yüklemediyseniz ya da kuruluşunuzda başka POP hesaplarının geçişini planlıyorsanız, aşağıdakileri göz önünde bulundurun.

• E-posta istemcinizin APPEND komutunda açık tarih geçirmeyi destekleyip desteklemediğini kontrol edin. Thunderbird, bu konuda sürüme göre değişken davranışlar sergilemiştir.
• Önce bir doğrulama hesabında 50-100 temsili mesajla test yapın: eski e-postalar, ekli mesajlar, imzalı e-postalar. Farklı istemcilerde görüntülenen tarihleri doğrulayın.
• Son kullanıcılar, taşınan posta kutusunda çalışmaya başlamadan önce düzeltmeyi planlayın. Aktif bir posta kutusundaki tarihleri düzeltmek, migrasyon sonrası henüz kullanılmamış bir posta kutusundakinden daha karmaşıktır.
• Migrasyon öncesinde ve sonrasında e-posta sayısını belgeleyin. Sessiz kayıpları tespit etmenin tek yolu budur.

Migrasyondan önce ve sonra kontrol edilmesi gereken noktaların eksiksiz bir listesi için E-posta Migrasyonu Kontrol Listesi: Tarih Sorunlarını Önleyin makalesi tüm vakaları kapsıyor.

POP'tan IMAP'a geçiş sonrası eski e-postalarınız bugünün tarihini mi gösteriyor? Redate.io'da ücretsiz bir tarama başlatın, sorunun boyutunu ölçün ve mesaj içeriğinize dokunmadan tarih meta verilerini düzeltin.