E-posta Tarihini Geriye Almak: Mümkün mü, Tespit Edilebilir mi?

E-posta Tarihini Geriye Almak: Tam Olarak Ne Anlama Gelir?

Bu soru sistem yönetimi forumlarında ve MSP'lerin Slack gruplarında düzenli olarak ortaya çıkıyor: bir e-postanın gönderildikten sonra tarihini değiştirmek mümkün mü? Kısa cevap: evet, teknik olarak mümkün. Ama bunu şüpheli amaçlarla yapmak isteyenler için tam cevap çok daha az yatıştırıcı.

Bir e-posta yekpare bir dosya değildir. Metin tabanlı başlıklardan ve ardından gelen mesaj gövdesinden oluşur. Bu başlıkların birkaçı tarih bilgisi taşır. Ve bazıları diğerlerinden çok daha kolay değiştirilebilir.

Her e-postada üç farklı tarihleme katmanı bir arada bulunur:

• Gönderim anında posta istemcisi tarafından yazılan Date: başlığı (RFC 2822)
• İletiyi aktaran her sunucu tarafından eklenen Received: başlıkları
• Sunucu tarafında depolanan, mesaj içeriğinden bağımsız bir meta veri olan IMAP INTERNALDATE

Bu katmanların her biri değiştirilebilir. Ama hiçbiri iz bırakmadan değiştirilemez.

Date: Başlığını Değiştirmek: En Belirgin Manipülasyon

.eml dosyasındaki Date: başlığı düz metinden ibarettir. Teknik olarak, herhangi bir hex editörü ya da Python betiği bunu birkaç saniyede yeniden yazabilir. Gmail'de bir e-postanın ham başlıklarını açtıysanız (küçük "Orijinali göster" menüsü), bunun herkes tarafından okunabilir olduğunu biliyorsunuzdur.

Sorun şu ki: 2004'ten bu yana büyük çoğunluğu posta sunucusu giden e-postaları DKIM (DomainKeys Identified Mail) ile imzalamaktadır. Bu kriptografik imza açıkça birçok başlığı kapsar: Date:, From:, Subject: ve mesaj gövdesi. İmza, DKIM-Signature: başlığında saklanır.

İmzalandıktan sonra Date: değerini değiştirmek DKIM doğrulamasını mekanik olarak geçersiz kılar. Herhangi bir alıcı sunucu, gönderen alan adının DNS kaydındaki açık anahtarı alarak imzayı doğrulayabilir. İmza artık eşleşmiyorsa ileti değiştirilmiş olarak işaretlenir. Gmail, Outlook.com ve tüm büyük sağlayıcılar bu doğrulamayı otomatik olarak yapar.

(Aslında, DKIM imzasının somut olarak nasıl göründüğünü merak ediyorsanız, Gmail veya Office 365'ten gelen bir e-postanın ham başlıklarını açın: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... şeklinde bir satır göreceksiniz. Gürültü gibi görünse de bu aslında tüm mesajın kriptografik bir özetinden ibarettir.)

Sonuç: DKIM imzalı bir e-postada Date: değerini değiştirmek mührü kırmak demektir. Değişiklik, nereden bakacağını bilen herhangi bir yönetici tarafından görülür.

Received: Başlıklarını Yeniden Yazmak: Taklit Edilmesi Zor Bir Zincir

Received: başlıkları, bir e-postanın gönderenden alıcıya uzanan yolculuğunu izler. İletiyle temas eden her SMTP sunucusu kendi adını, IP adresini ve zaman damgasını içeren bir başlık ekler. İki ya da üç röle üzerinden geçen bir e-posta, üst üste yığılmış iki ya da üç Received: başlığı içerir.

Bunlar değiştirilebilir mi? Teknik olarak, kendi mesaj kopyanızda evet. Ama işte asıl tuzak: alıcının da bir kopyası var. Ve alıcının sunucusu en sona kendi Received: başlığını ekledi. Bu başlık alıcının kontrolündedir, gönderenin değil. Dışarıdan taklit etmek imkansızdır.

Zincirin tutarlılığı doğrulanabilir. Ardışık Received: zaman damgaları tutarsızsa (örneğin bir ara rölenin mesajı gönderenden önce almış gibi görünmesi), bu durum hemen şüphe uyandırır. MXToolbox gibi adli e-posta analiz araçları ya da güvenlik ekiplerinin dahili araçları tam olarak bunu kontrol eder.

Aslında, Received: başlıklarının bütünüyle taklit edilemeyeceğini söylemek tam olarak doğru değil: kendi posta altyapısını kontrol eden bir saldırgan, yönettiği röleler için inandırıcı başlıklar üretebilir. Ama son halkayı hiçbir zaman kontrol edemez: alıcının sunucusunu.

IMAP INTERNALDATE: En Teknik Durum

INTERNALDATE, sunucu tarafında depolanan bir IMAP meta verisidir. Mesajın kendisindeki bir başlık değildir; sunucunun iç veritabanında mesajla ilişkilendirdiği bir değerdir. Posta istemcilerinin büyük çoğunluğu, gelen kutusundaki iletileri sıralamak için bu değeri kullanır.

IMAP APPEND komutu, bir sunucuya mesaj yüklerken INTERNALDATE değerini açıkça belirtmeye olanak tanır. Bu, RFC 3501'de belgelenmiş meşru bir protokol özelliğidir. Göç araçları bunu sürekli kullanır: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... hepsi hedef sunucuya e-postaları belirlenmiş bir INTERNALDATE ile yükler.

Teorik olarak, kendi posta kutusuna IMAP erişimi olan biri herhangi bir INTERNALDATE ile e-posta yükleyebilir. Ama bu manipülasyon mesajın başlıklarını değiştirmez. Orijinal Date: başlığı yerli yerinde kalır, Received: başlıkları yerli yerinde kalır, DKIM imzası yerli yerinde kalır. Değişen yalnızca sunucu tarafındaki sıralama meta verisidir.

Ham mesajı inceleyen bir uzman için INTERNALDATE ile Date: arasındaki tutarsızlık hemen fark edilir. Mesaj DKIM ile imzalanmışsa, orijinal tarih kriptografik olarak tasdiklenmiştir.

Message-ID: Taklit Edilmesi Güç Bir Parmak İzi

Her e-posta, Message-ID: başlığı adı verilen benzersiz bir tanımlayıcı üretir. Bu tanımlayıcı, gönderici SMTP sunucusu tarafından gönderim anında oluşturulur; genellikle bir zaman damgası, rastgele bir tanımlayıcı ve sunucunun alan adı birleştirilerek yapılır.

Tipik bir Message-ID şu şekilde görünür: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Zaman damgası çoğu zaman doğrudan tanımlayıcının içine kodlanır. Mesajın tarihini değiştirirken uyumsuz bir zaman damgasına sahip Message-ID bırakmak, hemen fark edilebilir bir tutarsızlık yaratır.

Üstelik Message-ID'ler büyük mesajlaşma sistemleri tarafından dizinlenir. Google, Microsoft ve diğer büyük oyuncular, bir iletinin kendi altyapılarında gerçekte ne zaman dolaştığını geriye doğru izlemeyi sağlayan kayıtlar tutar. Hukuki veya adli bir bağlamda bu kayıtlara yargısal prosedürler aracılığıyla erişilebilir.

Pratikte: Kim Manipülasyon Girişimini Tespit Edebilir?

Soruyu somut biçimde soralım. Tarihinin değiştirildiğinden şüphelendiğiniz bir e-posta aldınız. Minimal teknik bilgiye sahip bir IT yöneticisi ya da avukat ne yapabilir?

• DKIM Doğrulaması: Gmail'de "Orijinali göster" menüsü, sayfanın üstünde DKIM doğrulama sonucunu doğrudan gösterir. "PASS" sonucu, mesajın gönderimden bu yana bütünlüğünü koruduğunu onaylar. "FAIL" veya "SOFTFAIL" ise bir değişikliğe işaret eder.
• Başlık Analizi: MXToolbox Header Analyzer veya Google Admin Toolbox gibi araçlar, Received: zincirini otomatik olarak ayrıştırır ve zamansal tutarsızlıkları işaretler.
• Message-ID / Date Tutarlılığı: Bir analist, Message-ID içine kodlanmış zaman damgasını bildirilen Date: değeriyle karşılaştırabilir.
• Sunucu Kayıtları: E-posta yöneticisi olduğunuz bir sunucudan geçtiyse, SMTP kayıtları herhangi bir başlıktan bağımsız olarak mesajın gerçek kabul tarihini ve saatini içerir.

Kısacası, tespit araçları erişilebilir, ücretsiz ve ileri düzey adli uzmanlık gerektirmiyor. Biraz meraklı bir IT yöneticisi, iki dakikadan kısa sürede bir e-postanın bütünlüğünü doğrulayabilir.

Toplu Tarih Düzeltmesinin Tek Meşru Durumu: IMAP Migrasyonu

Yüz binlerce e-postanın herhangi bir kötü niyet olmaksızın yanlış tarihlerle karşımıza çıktığı bir senaryo var: IMAP migrasyonu.

150 Exchange posta kutusunu Google Workspace'e taşıyan bir migrasyon henüz tamamladınız. Pazartesi sabahı talepler gelmeye başladı. Kullanıcılar eski e-postalarının tamamının aynı tarihi, yani migrasyon hafta sonunun tarihini gösterdiğini bildiriyor. Gelen kutuları okunamaz hale geldi.

Yaşanan şey belgelenmiş ve öngörülebilir bir durumdur: migrasyon aracı (BitTitan, CloudM, imapsync, hangisi olursa olsun) e-postaları IMAP APPEND aracılığıyla Google Workspace'e yükledi. Orijinal e-posta tarihini değil, migrasyon tarihine karşılık gelen bir INTERNALDATE belirledi. Sonuç olarak varsayılan olarak INTERNALDATE'e göre sıralayan Outlook, tüm iletiler için migrasyon tarihini gösteriyor. E-postalar neden migrasyondan sonra yanlış tarih gösteriyor adlı yazı bu mekanizmayı ayrıntılı biçimde açıklamaktadır.

Her mesajdaki orijinal Date: başlığı yerli yerinde durmaktadır. DKIM imzaları bozulmadan kalmıştır. İçerik hiç değişmemiştir. Yalnızca sunucu tarafındaki INTERNALDATE hatalıdır.

Bu sorun BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO ve INTERNALDATE'i doğru korumadan IMAP APPEND kullanan tüm araçları etkiler. BitTitan MigrationWiz'e adanmış yazı bu aracın özelliklerini ele almaktadır. E-posta migrasyonu kontrol listesi ise bu tür sorunları önlemek için migrasyon öncesinde ve sonrasında kontrol edilmesi gereken noktaları sıralar.

Düzeltmek ile Sahte Veri Oluşturmak Arasındaki Fark

Redate.io'nun gerçekleştirdiği düzeltme, bir sahtecilik girişiminin tam karşıtıdır. Tescilli düzeltme motoru her mesajın başlık zincirini analiz eder, hiç değişmemiş olan Date: başlığında (RFC 2822) kodlanmış orijinal tarihi tespit eder ve tarih meta verilerini mesajda zaten mevcut olan bu özgün bilgiyle uyumlu hale getirir.

Date: başlığı gerçeğin kaynağıdır. Gönderim anında gönderenin posta istemcisi tarafından yazılmıştır. DKIM imzasının kapsamındadır. Redate.io tarafından değiştirilmez. Düzeltilen şey, orijinal tarih değil, migrasyon aracının yarattığı tutarsızlıktır.

Başarısız bir migrasyondan sonra 47.000 e-postayı tek bir tanesini bile kaybetmeden, tartışma dizilerini kırmadan, ekleri bozmadan, sabah 3'te Google API'sinde 429 hatası tetiklemeden düzeltmek (S/MIME, PGP, RFC 2047 ASCII dışı kodlamalar, karmaşık multipart yapılar gibi uç durumları yöneten) çok aşamalı bir analiz pipeline'ı gerektiriyor. Beş satırlık bir Python betiği ilk üretim posta kutusunda dayanamaz. Migrasyondan sonra e-posta tarihleri düzeltilebilir mi adlı yazı, gerçek hacimlerde kendin yap yaklaşımının neden riskli olduğunu ayrıntılı biçimde ele almaktadır.

Redate.io posta kutularını ücretsiz tarar, yanlış tarihli e-postaları tespit eder ve her iletiyi ayrı ayrı doğrulayan bir pipeline aracılığıyla düzeltir. Orijinaller 30 gün boyunca görünür bir yedekleme klasöründe saklanır. Bir şeyler ters giderse geri alma mümkündür.

Migrasyonunuz e-postalarınızın tarihlerini kaydırdı mı? Redate.io'da ücretsiz tarama başlatın ve ne yapacağınıza karar vermeden önce sorunun boyutunu ölçün.