Alınan E-postanın Tarihi Değiştirilebilir mi?

Herkesin sorduğu soru (ve neden iki çok farklı durumu gizlediği)

"Alınan e-postanın tarihi değiştirme" diye Google'a yazın. Microsoft Q&A forumlarında, Reddit thread'lerinde, Quora sorularında düzinelerce sonuçla karşılaşırsınız. Talep açık, ama arkasındaki nedenler soruyu soran kişiye göre köklü biçimde farklılaşıyor.

Bir yanda geriye dönük olarak tarihi tahrif etmek isteyenler var, hayal etmek bile istemediğimiz amaçlarla. Öte yanda ise IMAP migrasyonunun ardından tüm e-postalarının aynı tarihi (migration günü) gösterdiğini fark eden BT yöneticileri var; bunlar sadece gerçek tarihleri geri istiyorlar. Bu iki durum birbirinden tamamen farklı, ama arama motorlarında aynı ifadeyle aranıyorlar.

Bu makale her ikisini de yanıtlıyor. Kısa cevap: birinci durumda değişikliği tespit edilemez hale getirmek mümkün değil. İkincisinde ise son derece meşru bir işlem söz konusu ve Redate.io tam da bunu yapıyor.

Önce: e-postanın "tarihi" nedir?

Bir e-postada tek bir tarih yoktur. Farklı yerlerde depolanan, farklı taraflar tarafından kontrol edilen birden fazla tarih bulunur.

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

Bu, gönderenin istemcisinin mesajı gönderirken yazdığı tarihtir. Ham başlıklarda şu şekilde görünür:

Date: Mon, 14 Oct 2024 09:32:11 +0200

Bu başlık mesajın gövdesinin bir parçasıdır. Ham dosyaya erişirseniz teknik olarak değiştirilebilir. Ama "teknik olarak" burada anahtar ifade.

Received: başlıkları

Bir e-postanın geçtiği her posta sunucusu, kendi zaman damgasını içeren bir Received: başlığı ekler. Bu başlıklar, gönderenin sunucusundan gelen kutunuza uzanan kronolojik bir zincir oluşturur. (Bir e-postanın ham başlıklarını okumaya çalıştıysanız, bunun plaj kitabı gibi bir deneyim olmadığını bilirsiniz. Yeni olandan eskiye doğru sıralanmış onlarca satır teknik meta veri.)

IMAP INTERNALDATE

Bazı değişikliklerin neden hiçbir görünür etkisi olmadığını anlamak için en önemli meta veri budur. INTERNALDATE, mesajın içeriğinden bağımsız olarak IMAP sunucusu tarafında depolanan bir özelliktir. E-posta istemcilerinin büyük çoğunluğu klasörlerdeki e-postaları sıralamak için bunu kullanır. Outlook kullanır. Gmail de öyle. Apple Mail de büyük ölçüde aynı şekilde davranır.

INTERNALDATE mesajın içinde değildir. Sunucunun veritabanındadır. Diskinizde bir .eml dosyasını düzenleyerek değiştiremezsiniz.

Yerel olarak düzenleme yapınca gerçekte ne olur?

.eml dosyasını düzenlemek

Teknik olarak bir .eml dosyası düz metin dosyasıdır. Bir editörde açıp Date: satırını değiştirip kaydedebilirsiniz. Bu dosyayı yerel bir e-posta istemcisine yeniden aktarırsanız, istemciye göre gösterilen tarih değişebilir.

Ama şunlar değişmez:

• IMAP sunucusundaki INTERNALDATE (hep aynı kalır)
• Ara sunucular tarafından eklenen Received: başlıkları
• Google, Microsoft veya sağlayıcınızdaki teslimat logları
• Mesajda varsa DKIM imzası

Sonuç: yerel makinenizde farklı bir tarih görebilirsiniz. Exchange Online'a bağlı Outlook'ta ya da tarayıcıdaki Gmail'de ise hiçbir şey değişmemiştir.

Sistem saatini değiştirmek

Bazı forumlar, e-posta istemcisini "kandırmak" için iş istasyonunun saatini değiştirmeyi öneriyor. Bu işe yaramaz. Outlook ve Gmail, alınan e-postaların tarihlerini göstermek için sistem saatini okumaz. Sunucudaki INTERNALDATE'i ya da mesaj başlıklarını okurlar. Yerel saat bu süreçte hiçbir rol oynamaz.

Thunderbird üzerinden manipülasyon

Thunderbird, çoğu istemciye kıyasla daha esnek bir yapıya sahip. Uzantılar veya profil dosyalarını (mbox dosyaları, .msf dosyaları) doğrudan düzenleyerek bazı kullanıcılar tarih gösterimini değiştirmeye çalışıyor. POP3 modunda yerel olarak depolanan e-postalar için Thunderbird içinde işe yarayabilir. Ama Thunderbird IMAP'e bağlandığı anda sunucuyla yeniden senkronize olur. Bir sonraki senkronizasyonda "düzeltme" kaybolur.

DKIM: kimsenin bahsetmediği görünmez bariyer

2018'den bu yana gönderilen e-postaların büyük çoğunluğu DKIM (DomainKeys Identified Mail) ile imzalanıyor. Başlıklarda bir DKIM imzası şöyle görünür:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

h= alanı imzanın kapsadığı başlıkları listeler. Yukarıdaki örnekte Date imzalı. Mesajın Date: başlığını değiştirirseniz DKIM doğrulaması başarısız olur. Herhangi bir posta sunucusu, herhangi bir adli analiz aracı imzayı yeniden hesaplayarak değişikliği tespit edebilir.

Bu mükemmel bir koruma değil (kötü niyetli bir gönderici kendi DKIM anahtarını kontrol eder ve gönderirken istediğini imzalayabilir). Ama zaten alınmış ve imzalanmış bir e-postada Date: başlığını değiştirmek iz bırakır, tespit edilebilir bir iz.

Sunucu logları: gerçeğin kaynağı

Bir e-postanın görünür tüm meta verilerini (başlıklar, INTERNALDATE, her şey) değiştirmeyi başarsanız bile, sağlayıcılar kendi loglarını tutar.

Google Workspace, Admin Console'un denetim loglarında her mesajı kaydeder. Microsoft 365, Uyumluluk Merkezi'nde (Purview) aynı şeyi yapar. Bu loglar, istemcilerde neyin gösterildiğinden bağımsız olarak teslimat zaman damgalarını içerir. Bir avukat, hukuk birimi ya da BT güvenlik ekibi bu verilere erişebilir. Outlook'ta görünen tarih, mahkemede veya bir güvenlik denetiminde geçerli değildir.

Açıkça belirtmek gerekirse: alan temsilcisi yetkisiyle posta kutusuna erişimi olan bir yönetici bile bu logları geriye dönük olarak değiştiremez. Ayrıcalıklı kullanıcıların bile erişimi dışındadır.

Meşru durum: migrasyon sonrası düzeltme

Şöyle bir senaryo düşünün: bir Exchange on-premise ortamından Microsoft 365'e 150 posta kutusunu taşıdınız. Ertesi hafta Pazartesi sabahı talepler gelmeye başlar: "tüm eski e-postalarım geçen Cuma'yı gösteriyor". Yani migration günü.

Bu, iyi bilinen bir sorun ve az önce anlattığımız durumdan tamamen farklı. Burada kimse herhangi bir şeyi tahrif etmeye çalışmıyor. Gerçek orijinal tarihler hâlâ mevcut, her mesajın Date: başlığında bozulmadan duruyor. Sorun başka bir yerden geliyor: migration aracı (BitTitan MigrationWiz, CloudM, imapsync ya da başka biri) zincirin başına migration tarihi içeren bir Received: başlığı ekledi. Outlook, bazı bağlamlarda INTERNALDATE yerine en son Received: başlıklarına güvendiği için bu tarihi gösteriyor.

Bu durumda "düzeltme", mesajın söylediği şey (hâlâ orada olan orijinal Date: başlığı) ile sunucunun düşündüğü şey (migration sırasında ayarlanmış INTERNALDATE) arasındaki tutarsızlığı gidermekten ibarettir. Bu tahrif değil. Bu, geri yükleme.

Bu sorunun neden binlerce posta kutusunu etkilediğini anlamak için e-postaların migrasyon sonrası neden yanlış tarih gösterdiğini açıklayan makalemize bakabilirsiniz. Redate.io tam da bunu çözüyor.

Neden kendiniz yapmak büyük ölçekte işe yaramaz?

Sorunu anlamak bir şeydir. 150 posta kutusuna dağılmış 40.000 e-postayı tek bir tanesini bile kaybetmeden düzeltmek bambaşka bir şeydir.

GitHub veya Stack Overflow'da bulunan scriptler 20 test e-postasında çalışır. Üretim ortamında ise script yazarının öngörmediği sorunlarla karşılaşırlar:

• S/MIME imzalı veya PGP şifreli e-postalar, sıradan mesajlar gibi işlenemeyen yapılara sahiptir
• Standart dışı MIME sınırlarına sahip çok parçalı mesajlar ayrıştırma hatalarına yol açar
• RFC 2047 kodlu başlıklar (From: veya Subject: alanlarında ASCII dışı karakterler) basit ayrıştırıcıları bozar
• Google ve Microsoft API'leri hız sınırlaması (rate limiting) uygular: 30.000 e-postalık bir batch sırasında gece 3'te gelen 429 Too Many Requests hatası yönetilmediğinde script durur, nerede durduğunu kimse bilmez
• Geri alma mekanizması yoktur: işlem sırasında bir mesaj bozulursa geri dönüş mümkün değildir

Redate.io, her orijinal e-postanın bir kopyasını 30 gün boyunca görünür bir yedekleme klasöründe saklar. Her düzeltme ayrı ayrı doğrulanır. Analiz pipeline'ı, yüzlerce bilinen migration aracı imzasını ve ev yapımı bir scriptin hiç ele alamayacağı tüm uç durumları kapsar.

Kullanılan araca göre daha fazla ayrıntı için: BitTitan MigrationWiz ve e-posta tarihleri veya CloudM Migrate: yanlış tarihleri düzeltme.

Neyin değiştiği, neyin asla değişmediği

Ayrım nettir. Tablodaki ilk üç satır yüzeysel veya tespit edilebilir değişiklikleri anlatıyor. Sonuncusu ise migrasyon kaynaklı bir tutarsızlığın ardından mesajın orijinal içeriğiyle hizalanmış, meşru bir meta veri düzeltmesini anlatıyor.

Tablonun alt kısmında anlatılan durumla karşı karşıyaysanız, yani imapsync, BitTitan, CloudM veya başka bir araçla yapılan migration sonrasındaysanız, Redate.io bunun için tasarlandı.

E-postalarınız gerçek tarihler yerine migration tarihini mi gösteriyor? Redate.io ile posta kutularınızı ücretsiz tarayın ve karar vermeden önce kaç e-postanın etkilendiğini tam olarak görün.