eM Client: Import Sonrası Yanlış E-posta Tarihleri

Belirti: Tüm e-postalarınız aynı tarihi gösteriyor

eM Client'a bir PST dosyası aktardınız ya da Thunderbird'den yeni posta kutunuza geçiş yaptınız. Import hatasız tamamlandı. Ama gelen kutusunu açtığınızda bir şeyler yanlış görünüyor: yüzlerce, hatta binlerce e-posta import günündeki tarihi gösteriyor. 2019'dan kalma bir e-posta dün alınmış gibi görünüyor. Üç yıl önce imzalanan bir sözleşme sanki yeni gelmiş gibi listelenmiş.

İlk tepki genellikle eM Client'ı suçlamak oluyor. Yanlış ayar, yanlış sıralama sütunu, görüntüleme hatası... Tercihler inceleniyor, "Alınma Tarihi" ile "Gönderim Tarihi" arasında gidip geliniyor. Hiçbir şey değişmiyor. Ya da bir şeyler değişiyor ama asıl sorun çözülmüyor.

Çünkü sorun eM Client'ta değil. Sunucudaki metadata'da.

Gerçek neden: Import sırasında ezilen IMAP INTERNALDATE

Ne olduğunu anlamak için bir seviye aşağı inip IMAP protokolünün e-postaları nasıl sakladığına bakmak gerekiyor.

Bir IMAP sunucusundaki her mesajın iki farklı tarih türü vardır:

• Date: başlığı (RFC 2822 ile tanımlı): Gönderenin, mesajı oluştururken eklediği tarihtir. Mesaj gövdesinin içine gömülüdür, teoride dokunulamaz.
• INTERNALDATE: Mesaj içeriğinin dışında, sunucu tarafında tutulan bir metadata değeridir. Mesajın posta kutusuna teslim edildiği tarih ve saati gösterir. E-posta istemcileri, e-postaları sıralamak ve görüntülemek için öncelikli olarak bu değeri kullanır.

Bir PST import işleminde ya da Thunderbird'den yapılan bir geçişte, import aracı (eM Client'ın yerleşik modülü, üçüncü taraf bir araç veya manuel IMAP kopyası) mesajları hedef IMAP sunucusuna bırakır. Bu noktada araç, orijinal INTERNALDATE'i açıkça belirtmezse sunucu otomatik olarak o anki tarihi atar, yani import tarihini ve saatini.

Sonuç: 2017'den bu yana arşivlenen 8.000 e-posta, hepsi migration anında "alınmış" gibi görünüyor.

(Bu arada eM Client'ta Kaynağı Görüntüle ile ham başlıkları hiç inceledinizse, orijinal Date: başlığının hâlâ orada, sağlam şekilde durduğunu görmüşsünüzdür. Bu, sorunun mesajın kendisinden değil sunucudaki INTERNALDATE'ten kaynaklandığının işaretidir.)

Sıralama sütununu değiştirmek neden işe yaramıyor

Karışıklık, çok az kişinin farkında olduğu bir ayrımdan kaynaklanıyor. eM Client'ta, Outlook'ta veya Thunderbird'de genellikle iki tarih sütunu bulunur:

• "Alınma Tarihi": Sunucudaki INTERNALDATE değerine dayanır.
• "Tarih" veya "Gönderim Tarihi": Mesajın Date: başlığına dayanır.

Pek çok yönetici bunu keşfedince çözümü bulduğunu sanıyor: "Gönderim Tarihi"ne geçince sorun eM Client'ta görsel olarak kayboluyor. Ama bu tam olarak doğru değil.

Düzeltme: eM Client'ta gönderim tarihine göre sıralasanız bile, aynı posta kutusuna erişen tüm diğer istemciler ve arayüzler için sorun devam ediyor. Kullanıcılarınız e-postalarını OWA'dan, iş yerindeki Outlook'tan, mobil Gmail uygulamasından veya IMAP ile yapılandırılmış herhangi bir istemciden açıyorsa import tarihlerini görmeye devam edecekler. eM Client'taki sıralama ayarı yalnızca eM Client için geçerli olup sunucu tarafındaki metadata'yı hiç etkilemiyor.

Ayrıca Microsoft 365 ve Google Workspace'in yerleşik web görünümleri INTERNALDATE'e göre sıralıyor. Bu davranışı istemci tarafından değiştirmeniz mümkün değil.

Gönderim tarihine göre sıralama bir çözüm değil. Gerçek bir sorunu düzeltmeksizin maskeleyen geçici bir yama.

PST importu: özel bir durum

PST dosyası importu ayrıca ele almayı hak ediyor. PST (Personal Storage Table), Microsoft'un e-postaları, kişileri ve takvimleri yerel olarak depolayan özel formatıdır. Bir PST'yi eM Client'a aktardığınızda iki senaryo mümkün:

• IMAP hesabına yerel import: eM Client PST'yi okuyup mesajları hedef IMAP sunucusuna gönderir. Teslim tarihi korunmazsa INTERNALDATE ezilir. En yaygın durum budur ve tarihlerin bozulduğu asıl senaryo da bu.
• Yerel klasöre import: Mesajlar sunucu dışında, makinede kalır. Bu bağlamda INTERNALDATE mevcut değildir ve eM Client mesajın Date: başlığını gösterebilir. Tarih sorunu daha az görülür ama pratik kullanım da sınırlıdır.

Thunderbird için durum benzer. eM Client'ın yerleşik import işlevini (Thunderbird profillerini okuyarak) veya mbox klasörlerini IMAP üzerinden kopyaladıysanız, mesajlar INTERNALDATE'in korunacağına dair hiçbir güvence olmaksızın sunucuya bırakılıyor. Tarih talimatı içermeyen bir mesaj alan sunucu da sistematik olarak alındığı anın zaman damgasını kullanıyor.

Hangi platformlar etkileniyor?

Sorun, IMAP protokolünün standart bir davranışı olduğu için hedef platformdan bağımsız olarak aynı şekilde ortaya çıkıyor:

• Microsoft 365 / Exchange Online: Açık bir tarih parametresiyle IMAP APPEND komutu kullanılmayan her import işleminde INTERNALDATE eziliyor. Exchange on-premise'den yapılan geçişlerde de aynı durum geçerli.
• Google Workspace: Aynı davranış. eM Client veya üçüncü taraf araçlarla aktarılan e-postalar Gmail'de ve yönetim konsolunda import tarihini gösteriyor.
• Klasik IMAP barındırıcıları (OVH, Infomaniak, Ionos, vb.): APPEND ile alınan mesajlarda tarih için özel bir işlem yapılmıyor. INTERNALDATE, mesajın bırakıldığı an olacak.

Bir müşteri, Exchange 2013'ten Microsoft 365'e yaklaşık yüz posta kutusunu taşıdıktan sonra bize ulaştı; bazı VIP hesaplar için geçiş aracı olarak eM Client kullanılmıştı. Sonuç: MigrationWiz ile düzgün taşınan posta kutuları sorunsuzdu, ama eM Client üzerinden geçenler import tarihlerini gösteriyordu. Etkilenen kullanıcıların memnun olmadığını söylemeye gerek yok.

Neden ev yapımı bir script bunu kolayca çözmez

IMAP protokolünü anlayan biri, INTERNALDATE'leri düzeltmek için bir script yazabileceğini düşünebilir. Orijinal Date: başlığı her mesajda sağlam biçimde duruyor. Onu okuyup sunucu metadata'sını buna göre yeniden oluşturmak yeterli olur, değil mi?

Teoride evet. Pratikte bu bir mayın tarlası.

Her şeyden önce, üretim ortamındaki bir posta kutusunda edge case'ler hızla birikiryor. Dijital olarak imzalanmış S/MIME mesajları yapısal müdahaleye özellikle hassas. PGP şifreli mesajlar da öyle. Büyük ekler, standart dışı MIME sınırları veya alışılmadık Content-Transfer-Encoding değerleri içeren e-postalar, işlem titizlikle yürütülmezse sessizce bozulabilir. 50 test e-postasında çalışan bir script, 6 yıllık geçmişe sahip 20.000 mesajlık bir posta kutusunda güvenilir biçimde çalışmaz.

Bir de API kota yönetimi var. Microsoft 365'te sabah 3'te 8.000 mesajlık bir düzeltme batch'inde Graph API veya EWS üzerindeki hız sınırları yönetilebilir, ama kendiliğinden yönetilmiyor. Denetimsiz bir script 3.741. mesajda 429 Too Many Requests hatasıyla karşılaştığında devam edebilir ya da etmeyebilir. Hangi mesajların işlendiğini de her zaman bilemezsiniz.

Asıl meseleye gelince: işlemden sonra düzeltilen her e-postanın sağlam olduğunu nasıl doğrularsınız? Ev yapımı bir script'in genellikle bireysel doğrulama mekanizması olmaz. Redate.io bunu her mesaj için otomatik olarak yapıyor.

Redate.io ile tarihleri kaynağında düzeltme

Redate.io sorunu nerede başlıyorsa orada ele alıyor: e-posta istemcisinde değil, sunucu metadata düzeyinde.

Süreç ücretsiz bir tarama aşamasıyla başlıyor. Redate.io ilgili posta kutusuna bağlanıyor (Microsoft 365 için Azure AD üzerinden, Google Workspace için domain delegasyonuyla veya klasik barındırıcılar için doğrudan IMAP) ve tarih metadata'sı mesaj içeriğiyle tutarsız olan e-postaları tespit ediyor. Herhangi bir ödeme yapmadan önce sonucu görüyorsunuz.

Düzeltme, her mesajın başlık zincirini analiz eden, bilinen yüzlerce import aracının imzasında (eM Client, Thunderbird ve PST import davranışları dahil) desen eşleştirmesi yapan ve mesaj içeriğine, eklerine ya da MIME yapısına dokunmaksızın tarih metadata'sını hedefe yönelik şekilde yeniden oluşturan özel bir motor kullanıyor.

Düzeltilen her e-posta ayrı ayrı doğrulanıyor. Orijinaller 30 gün boyunca görünür bir yedek klasöründe tutuluyor; ev yapımı hiçbir script bunu varsayılan olarak yapmaz.

Fiyatlandırma basit: düzeltilecek e-posta hacmine göre posta kutusu başına tek seferlik ödeme. Abonelik yok, tekrarlayan ücret yok. Ayrıntılar için başlangıç sayfasını ziyaret edin.

Bir sonraki migrasyon için: neye dikkat edilmeli

Bir geçiş planlıyorsanız ve bu sorunu önceden önlemek istiyorsanız, kontrol noktası nettir: kullandığınız araç, mesajları hedef sunucuya bırakırken INTERNALDATE'i açıkça koruyor mu?

Microsoft 365'e PST importları için Microsoft onaylı araçlar (MigrationWiz'in yerel modları veya Exchange Online Migration Tool gibi) genellikle bu korumayı sağlıyor. eM Client veya Thunderbird üzerinden yapılan manuel importlarda ise bu nadiren böyle. Üretim posta kutularında bir import başlatmadan önce aracınızın dokümantasyonunu kontrol edin.

İyi bir e-posta geçiş kontrol listesi, örnek posta kutularında geçiş sonrası tarih doğrulamasını her zaman içerir. E-posta Migrasyonu Kontrol Listesi bu konuyu ayrıntılı ele alıyor.

Müşterileri için düzenli olarak geçiş yöneten yöneticiler için MSP'ler için e-posta tarih sorunlarını düzeltme ve IMAP INTERNALDATE'in nasıl çalıştığı hakkındaki makaleler sorunun daha kapsamlı bir resmini sunuyor.

eM Client import sonrası e-posta tarihleriniz bozuldu mu? Redate.io'da ücretsiz tarama başlatın ve ne yapacağınıza karar vermeden önce sorunun boyutunu ölçün.