E-posta Tarihi Değiştirme: Teknik Sınırlar

Bir e-postanın üç "tarihi" vardır. Tek değil.

"Alınan e-postanın tarihini değiştirme" konusundan söz edildiğinde, çoğu kişi Windows'ta bir dosyanın oluşturulma tarihini düzenler gibi bir yerde bir alanı değiştirmeyi hayal eder. Gerçek biraz daha karmaşık. Bir e-posta aslında üç ayrı tarihleme katmanı taşır; her birinin kendine özgü kuralları, sahipleri ve üzerinde yapılan değişikliklerin sonuçları vardır.

Bu üç katmanı anlamak, hangi düzeltmelerin teknik açıdan sağlıklı olduğunu, hangilerinin ise ya imkânsız ya da anında sahtekarlık olarak tespit edilebilir olduğunu kavramak demektir.

Katman 1: IMAP INTERNALDATE

INTERNALDATE, mesajın kendisinin dışında, sunucu tarafında depolanan bir meta veridir. E-posta içeriğinin bir parçası değildir. IMAP sunucusu tarafından belirlenir ve e-posta istemcilerinin büyük çoğunluğu mesajları listede sıralamak için bu değeri kullanır.

Outlook, varsayılan olarak mesajları INTERNALDATE'e göre sıralayarak görüntüler. Gmail de bazı durumlarda aynı şekilde davranır. Dolayısıyla INTERNALDATE yanlışsa, mesajın iç başlıklarında ne yazıyor olursa olsun, tüm e-postalar arayüzde aynı tarihi gösterir.

INTERNALDATE, mesaj sunucuya teslim edildiği anda belirlenir. IMAP protokolü üzerinden bu değeri "değiştirmenin" tek yolu dolaylıdır: istenen tarihle birlikte mesajın yeni bir kopyasını göndermek için APPEND komutu kullanılmalıdır. SETINTERNALDATE adında bir IMAP komutu yoktur. Bu ayrıntı birazdan önem kazanacak.

Katman 2: Date: başlığı (RFC 2822)

Bu, mesajın ham başlıklarındaki Date: alanıdır. Gönderim sırasında e-posta istemcisi tarafından belirlenir ve mesajla birlikte sunucudan sunucuya aktarılır. Gönderenin bildirdiği gönderim tarihidir.

(Aslında, bir e-postanın ham başlıklarına hiç bakmadıysanız, oldukça ilginç bir okuma deneyimi sizi bekliyor. Her mesaj, kullanıcıların %99'unun hiç görmediği yaklaşık yirmi satır teknik bilgi taşır.)

Teknik olarak, geçmişe ya da geleceğe tarihlenmiş bir Date: alanıyla e-posta göndermek mümkündür. SMTP sunucuları bu alanı doğrulamaz. Ancak alıcı sunucular gerçek varış saatini Received: başlıklarına kaydeder; bu durum, herhangi bir e-posta istemcisi veya analiz aracı tarafından hemen fark edilebilir bir tutarsızlık yaratır.

Katman 3: Birikmiş Received: başlıkları

Bir SMTP sunucusu bir mesajı her ilettiğinde, zaman damgasıyla birlikte yığının üstüne bir Received: başlığı ekler. Üç sunucudan geçen bir e-postada üç adet Received: başlığı bulunur. Bunlar alttan üste doğru okunur: en eski altta, en yeni üsttedir.

Migrasyon araçlarının sorunu tam da burada yaratması tesadüf değil. BitTitan MigrationWiz, CloudM, imapsync veya GSMMO bir e-postayı taşıdığında, mesajı yeni sunucuya IMAP üzerinden yeniden enjekte eder. Bu işlem, migrasyon anıyla damgalanmış yeni bir Received: girişi oluşturur. Sonuç: posta kutunuzdaki en eski mesaj, 2019 tarihli bir e-posta, Kasım 2024 tarihli bir Received: başlığıyla karşınıza çıkar. Bazı e-posta istemcileri (başta Outlook) en güncel Received: başlığını görüntüleme tarihi olarak kullandığından...

İşte sorun bu. 15.000 e-postanın tamamı aynı migrasyon tarihini gösterir.

Bu tarihleri gerçekten "değiştirmek" mümkün mü?

Teknik olarak, INTERNALDATE için evet (belirli kısıtlamalarla). Date: için teknik olarak mümkün ama anlamsız. Received: başlıkları içinse biraz daha dikkatli bakmak gerekiyor.

Received: başlığını yeniden yazmak kolay. Ve anında tespit edilebilir.

Bir Received: başlığı, mesaj içindeki bir metin satırından ibarettir. Herhangi bir metin dosyası gibi düzenlenebilir. Göründüğü kadar basit, evet.

Ama bundan sonra ne olduğuna bakalım.

Birinci sorun: DKIM. DKIM (DomainKeys Identified Mail) imzası, mesajın bazı başlıkları üzerinden hesaplanır; buna zaman zaman Received: başlıkları da dahildir. İmzalanmış bir başlığı değiştirmek imzayı geçersiz kılar. DKIM doğrulaması yapan herhangi bir alıcı sunucu, mesajın değiştirildiğini anında görür. Bu, ince bir sahtecilik değil, doğrudan bir alarm zilidir.

İkinci sorun: dahili tanımlayıcılar. Modern e-posta sunucuları (Google Workspace, Microsoft 365), her mesaja artan ve benzersiz bir dahili tanımlayıcı atar. Bu tanımlayıcılar INTERNALDATE ve alım sırasıyla ilişkilidir. Received: başlığını bu tanımlayıcılarla uyumsuz biçimde değiştirmek, denetim araçlarının kolaylıkla tespit ettiği tutarsızlıklar yaratır.

Üçüncü sorun, daha pratik bir açıdan: mesaj içeriğindeki Received: başlığını değiştirseniz bile, IMAP teslim anına ait INTERNALDATE'e dokunmamış olursunuz. E-posta istemcisi sıralama için yanlış tarihi göstermeye devam eder. Mesajı boşuna değiştirmiş olursunuz.

Kısacası, kötü niyetle e-posta tarihini tahrif etmek amacıyla Received: başlıklarını yeniden yazmak: teknik olarak çocuk oyuncağı, bir uzman tarafından saniyeler içinde tespit edilebilir. Ciddiye alınacak bir yol değil.

Date: başlığı: kağıt üzerinde geçmişi değiştirmek

Aynı mantık Date: için de geçerli. Mesaj gövdesinde değiştirilebilir. Ancak aracı sunucular tarafından doğrulanmış Received: başlıkları yerli yerinde durur ve farklı bir hikâye anlatır. Zaman çizelgesi tutarsızdır. Bu alanları karşılaştıran herhangi bir analist veya mahkeme bunu anında görür.

Daha net söylemek gerekirse, bu durum bazı e-posta istemcilerinin değiştirilmiş Date: alanını .eml dosyası doğrudan açıldığında göstermesini engellemez. Ancak kimlik doğrulama ve günlüklerin bulunduğu canlı bir e-posta sunucusu ortamında değişiklik gözle görülür biçimde ortadadır.

IMAP Migrasyonu: Tarihleri Düzeltmenin Tek Meşru Bağlamı

Bir e-postanın alım tarihini değiştirmenin yalnızca mümkün değil, teknik açıdan haklı da olduğu tek bir durum vardır: kötü yönetilen bir IMAP migrasyonunun yol açtığı hasarı onarmak.

Somut senaryoya bakalım. Exchange'den Microsoft 365'e 80 posta kutusunu taşıdınız. Migrasyon bir Cuma akşamı tamamlandı. Pazartesi sabahı ilk destek talepleri gelmeye başladı: "Tüm e-postalarım aynı tarihi gösteriyor", "Geçen yılki bir e-postayı bulamıyorum", "Bu müşteriyle yazışma geçmişim tamamen bozuldu". 80 kullanıcı çaresiz bekliyor ve yöneticiniz cevap istiyor.

Bu bağlamda sorun belgelenmiş, tanımlanabilir ve nedeni açıktır: migrasyon aracı, migrasyon günüyle damgalı bir Received: başlığı eklemiş ve bazı e-posta istemcileri bu yeni başlığı görüntüleme tarihi olarak kullanmıştır. Orijinal Date: başlığı ise her mesajda sağlam durmaktadır. Hiç değiştirilmemiştir. Doğru olan orijinal gönderim tarihini hâlâ içerir.

Dolayısıyla düzeltme bir sahtekarlık değil, bir restorasyon işlemidir. Gerçek verilerden (orijinal Date:) yola çıkılarak tutarlı meta veriler yeniden oluşturulur. Bu, 2024 tarihli bir e-postayı 2019'a aitmiş gibi göstermeye çalışmaktan temelden farklıdır.

Her araca özgü mekanizmalar hakkında daha fazla bilgi için şu kılavuzlar somut vakaları ayrıntılı biçimde ele almaktadır: Microsoft 365'te BitTitan tarihlerini düzeltme, Outlook'ta CloudM tarihlerini düzeltme veya Google Workspace'te imapsync tarihlerini düzeltme.

Kendi Scriptinizi Yazmamanızın Nedenleri

Temel mantık erişilebilir düzeyde. IMAP forumlarında vakit geçirmiş herhangi bir BT yöneticisi genel yaklaşımı yeniden kurabilir. Sorun bu değil.

Asıl sorun, 50 test e-postasında çalışan bir script ile 40.000 üretim mesajı üzerinde tek bir e-posta kaybetmeden, tek bir eki bozmadan ve tek bir konuşma dizisini kırmadan çalışan bir script arasındaki derin uçurumdur.

Ev yapımı scriptlerin genellikle baş edemediği somut durumlar:

• S/MIME imzalı e-postalar: İmza içerik ve başlıkları kapsar. Mesaj yapısında yapılan herhangi bir değişiklik imzayı geçersiz kılar. Beceriksizce düzeltilmiş imzalı bir e-posta alıcılara "geçersiz imza" uyarısıyla ulaşır.
• PGP şifreli mesajlar: Aynı sorun ailesi, uygulamaya bağlı olarak potansiyel daha ağır sonuçlarla.
• Başlıklarda ASCII dışı kodlamalar: RFC 2047, başlıklardaki özel karakterlerin kodlanmasını tanımlar. Bu durumları işlemeden başlıkları düzenleyen bir script, aksan içeren konu satırlarını, Japonca karakterleri veya Arapça isimleri sessiz sedasız bozar.
• API hız sınırları: Google Workspace ve Microsoft 365 agresif kısıtlamalar uygular. Sabah 3'te, üstel geri çekilme yönetimi olmaksızın 429 Too Many Requests hatasıyla karşılaşan 10.000 e-postalık bir toplu işlem, posta kutularının yarısını yarım düzeltilmiş halde bırakır.
• Bozuk MIME sınırları: Ekleri olan çok parçalı mesajların kesin MIME sınırları vardır. Bunları hatalı yeniden oluşturmak ekleri okunamaz hale getirir.

Hiçbir ev yapımı scriptin yanıt veremediği soru şudur: düzeltilen her e-postanın sağlam olduğunu nasıl doğrularsınız? 40.000 mesajı bireysel doğrulama olmaksızın değiştiren bir script bir kumar oynar. Üstelik kullanıcıların çoğu zaman vazgeçilmez saydığı veriler üzerinde.

Migrasyon sonrası tarihleri düzeltmek için mevcut seçenekleri ele alan bu makale, her birinin sınırlamaları da dahil olmak üzere farklı yaklaşımları inceliyor.

Redate.io Bu Bağlamda Ne Yapar?

Redate.io tam olarak bu senaryo için tasarlanmıştır: IMAP migrasyonunun bozduğu tarihleri büyük ölçekte ve mesaj bütünlüğü için herhangi bir risk oluşturmadan düzeltmek.

Hizmet, etkilenen posta kutularına doğrudan bağlanır (Google Workspace için alan adı yetkisi, Microsoft 365 için Azure AD veya doğrudan IMAP), yanlış tarihli mesajları ücretsiz olarak tarar, ardından yukarıda belgelenen uç durumları işleyen özel bir düzeltme motoru uygular. Her e-posta, düzeltme sonrasında tek tek doğrulanır. Orijinaller 30 gün boyunca görünür bir yedekleme klasöründe saklanır.

Örüntü eşleştirme, yüzlerce bilinen migrasyon aracı imzasını kapsar: BitTitan MigrationWiz, CloudM, imapsync, GSMMO ve varyantları. Tespit hassastır: Redate.io, tarihi doğru olan e-postalara dokunmaz.

Fiyatlandırma modeli basittir: abonelik yok, posta kutusu başına tek seferlik ödeme. Tanılama taraması ücretsizdir; bu sayede herhangi bir karar vermeden önce hasarın boyutunu ölçmek mümkün olur.

Bu sorundan etkilenen posta kutularını yönetiyorsanız, migrasyon sonrası Outlook'ta yanlış tarihler hakkındaki bu makale en yaygın belirtileri ve bunları diğer nedenlerden ayırt etmeyi ayrıntılı biçimde ele alıyor.

Posta kutularınızdaki sorunun boyutunu ölçmeye hazır mısınız? Redate.io'da ücretsiz tarama başlatın ve herhangi bir düzeltme yapmadan önce kaç e-postanın etkilendiğini tam olarak görün.