IMAP INTERNALDATE: Tarihler Neden Bozulur

Her E-Postanın İçindeki Üç Tarih

Bir IMAP sunucusunda saklanan her e-posta en az üç ayrı tarih değeri taşır. Bu tarihlerin nasıl çalıştığını ve e-posta istemcilerinin hangisini görüntülemeyi seçtiğini anlamak, göç işleminin tarihleri neden bozduğunu kavramanın anahtarıdır. Bu makale, IMAP tarih sistemine dair teknik bir inceleme sunar; IT yöneticilerine ve göç sonrası tarih sorunlarının temel nedenini anlamak isteyen herkese hitap eder.

1. RFC 2822 "Date" Başlığı

"Date" başlığı RFC 2822'de (Internet Message Format) tanımlanır. Mesaj yazılıp gönderildiği anda, gönderenin e-posta istemcisi tarafından ayarlanır. Bu başlık mesaj gövdesinin kendisinin bir parçasıdır, mesajla birlikte hareket eder ve teslim yolundaki e-posta sunucuları tarafından asla değiştirilmez. Tipik bir Date başlığı şöyle görünür:

Date: Mon, 15 Jan 2024 09:32:17 +0100

Date başlığı mesajın "gönderim tarihini" temsil eder. En güvenilir tarihtir çünkü bir kez ayarlanır ve asla değiştirilmez. Ancak gönderenin saatini yansıtır, bu saat yanlış ayarlanmış olabilir. Bazı durumlarda Date başlığı tamamen eksik olabilir (özellikle otomatik sistem bildirimlerinde veya hatalı biçimlendirilmiş mesajlarda).

2. IMAP INTERNALDATE

INTERNALDATE, RFC 3501'de (IMAP4rev1 protokolü) tanımlanır. Mesajın sunucuya teslim edildiği tarih ve saati temsil eden, sunucu tarafında tutulan bir meta veri değeridir. Date başlığının aksine, INTERNALDATE e-posta mesajının kendisinin bir parçası değildir. IMAP sunucusu tarafından ayrı olarak meta veri şeklinde saklanır.

Bir e-posta normal şekilde teslim edildiğinde (göç yapılmadan), IMAP sunucusu INTERNALDATE'i teslim anındaki geçerli zamana ayarlar. Bu değer, Date başlığına genellikle saniyeler veya dakikalar içinde yakınlık gösterir. E-posta istemcileri, sunucunun mesajı gerçekten ne zaman aldığını yansıttığı için INTERNALDATE'i çoğunlukla "alınma tarihi" olarak kullanır.

İşte burada iş ilginçleşiyor. Bir mesaj IMAP APPEND komutuyla eklendiğinde (göç araçlarının kullandığı yöntem budur), APPEND komutu istemcinin INTERNALDATE'i açıkça belirtmesine izin verir. İyi tasarlanmış göç araçları, kaynak sunucudaki orijinal INTERNALDATE'i korumak için bu özelliği kullanır. Ancak INTERNALDATE doğru şekilde ayarlanmış olsa da, aşağıda açıklanan "Received" başlığı sorunu birçok e-posta istemcisinde görüntülenen tarihi hâlâ geçersiz kılabilir.

3. "Received" Başlık Zinciri

Bir e-posta her e-posta sunucusundan geçtiğinde, o sunucu mesajın başına bir "Received" başlığı ekler. Bu, e-postanın gönderenden alıcıya kadar izlediği yolu kaydeden bir Received başlık zinciri oluşturur. En yeni (en üstteki) Received başlığı mesajı son işleyen sunucuyu, en eski (en alttaki) ise ilk sunucuyu gösterir.

Normal bir e-postada, gönderenin giden sunucusundan olası aktarma sunucuları üzerinden alıcının gelen sunucusuna kadar olan yolculuğu belgeleyen 3 ila 6 Received başlığı bulunabilir. Her Received başlığı bir zaman damgası içerir. Basitleştirilmiş bir örnek:

Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100

E-Posta İstemcileri Görüntülenecek Tarihi Nasıl Seçer

Outlook (Masaüstü, Web, Mobil)

Microsoft Outlook, gelen kutusunda görüntülenen "Alındı" tarihini belirlemek için INTERNALDATE ile en üstteki "Received" başlığının bir kombinasyonunu kullanır. Pratikte Outlook, "Alındı" sütunu için en son Received başlığındaki zaman damgasına öncelik verme eğilimindedir. "Gönderildi" sütunu ise Date başlığını kullanır. Outlook varsayılan olarak "Alındı" sütununa göre sıraladığından, kullanıcıların önce gördüğü şey Received başlığındaki zaman damgasıdır.

Apple Mail

macOS ve iOS'taki Apple Mail, tarih görüntüleme için öncelikli olarak IMAP INTERNALDATE'i kullanır. INTERNALDATE göç sırasında doğru şekilde korunduysa, Apple Mail doğru tarihi gösterebilir; ancak bu, INTERNALDATE'in APPEND işlemi sırasında açıkça ayarlanmış olması koşuluyla geçerlidir. Göç aracı INTERNALDATE'i ayarlamadıysa, sunucu varsayılan olarak ekleme zamanını (göç tarihini) kullanır. Bunun Apple Mail kullanıcılarını nasıl etkilediğine dair ayrıntılar için Apple Mail: göç sonrası yanlış tarih makalesine bakın.

Thunderbird

Mozilla Thunderbird en fazla esnekliği sunar. Hem "Tarih" (Date başlığından) hem de "Alındı" (Received başlıklarından) görüntüleyebilir. Varsayılan olarak Thunderbird, Date başlığındaki değeri gösterir; bu da tarihlerin Outlook'ta yanlış görünse bile Thunderbird'de doğru görünebileceği anlamına gelir. Ancak Thunderbird'deki "Alındı" sütunu hâlâ göç tarihini gösterir. Ayrıntılar için Thunderbird: göç sonrası yanlış tarih makalesine bakın.

Gmail Web Arayüzü

Gmail'in web istemcisi, birincil tarih görünümü için Date başlığını kullanır. Bu, Gmail web'in göç sonrasında bile genellikle doğru tarihleri göstermesi anlamına gelir. Ama Gmail sunucusundaki IMAP INTERNALDATE yine de yanlıştır ve bu, o Gmail hesabına bağlanan her IMAP istemcisini etkiler. Gmail web ile Outlook veya Apple Mail arasındaki bu tutarsızlık, yaygın bir karışıklık kaynağıdır ve yöneticilerin sorun giderme sürecinde çok zaman kaybetmesine yol açar.

IMAP APPEND Tarihleri Neden Bozar

Göç Sırasında Ne Olur

Bir göç aracı bir e-postayı Sunucu A'dan Sunucu B'ye taşıdığında, araç IMAP üzerinden Sunucu A'ya bağlanır ve ham mesajı indirir, ardından Sunucu B'ye bağlanır ve mesajı eklemek için APPEND komutunu kullanır. Bu ekleme sırasında Sunucu B gelen mesajı işler ve geçerli zaman damgasıyla, yani göç tarihiyle yeni bir Received başlığı ekler. Bu, birçok IMAP sunucusunda karşılaşılan yaygın bir davranıştır; sunucu her APPEND işlemini yeni bir mesaj teslimatı olarak değerlendirir.

Sonuç: Kirlenmiş Bir Başlık Zinciri

Göç sonrasında e-postanın Received başlıkları şöyle görünür:

Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100

Göç aracının Received başlığı artık en üstteki giriştir. Görüntülenecek tarihi belirlemek için en üstteki Received başlığını kullanan herhangi bir e-posta istemcisi (özellikle Outlook) "15 Ocak 2024" yerine "11 Nisan 2025" gösterecektir. Orijinal Date başlığı ve orijinal Received başlıkları hâlâ altta sağlam durur, ancak artık e-posta istemcilerinin öncelik verdiği konumda değildirler.

İyi Bir INTERNALDATE Yönetimi Bile Bunu Önlemez

Bazı göç araçları APPEND sırasında INTERNALDATE'i doğru şekilde ayarlar. Örneğin imapsync, kaynak sunucudaki INTERNALDATE'i açıkça korur. Ama Received başlığı, göç aracı tarafından değil hedef sunucu tarafından eklenir. Göç aracının bu davranış üzerinde hiçbir kontrolü yoktur. INTERNALDATE mükemmel şekilde korunmuş olsa bile, en üstteki Received başlığı yine de göç tarihini içerir ve Outlook gibi istemciler yanlış tarihi göstermeye devam eder.

O zaman gerçekte ne yapılabilir?

Hangi Göç Araçları Received Başlığı Ekler

Her IMAP göç aracı bu soruna yol açar, çünkü Received başlığını göç aracının kendisi değil hedef sunucu ekler. Eklenen başlığın içeriği ise araca ve sunucuya göre değişir.

BitTitan MigrationWiz, içeriğinde "mx.migrationwiz.com" geçen bir Received başlığı ekler. CloudM Migrate, "cloudm.io" referansı içeren başlıklar ekler. imapsync, hedef sunucudan gelen genel bir Received başlığını tetikler. GSMMO, "gmailapi.google.com" referansları içeren başlıklar ekler.

Çözüm: Doğru Tarihleri Geri Yükleme

İyi haber şu ki doğru tarih bilgisi hâlâ her e-postanın içinde mevcuttur. Orijinal Date başlığı sağlamdır. Orijinal Received başlıkları sağlamdır. Sorun, kirletici bir başlığın bunların üstünde yer almasıdır.

Redate.io'nun özel geliştirilmiş düzeltme motoru, etkilenen her e-postanın tam başlık zincirini analiz eder ve hangi başlıkların düzeltilmesi gerektiğini, e-posta kutusundaki tarih anormalliklerini tespit ederek belirler. Bu yaklaşım, herhangi bir göç aracıyla çalışır; belirli bir aracın imzasına bağlı değildir. Çok aşamalı analiz hattı, basit yaklaşımları başarısız kılan sınır durumlarını da yönetir: S/MIME imzalı mesajlar, PGP şifreli içerik, multipart/alternative yapılar, Content-Transfer-Encoding sorunları, ASCII dışı başlıklar (RFC 2047), aşırı büyük ekler ve bozuk MIME sınırları.

Düzeltme sonrasında her e-posta, mesaj yapısının, içeriğin ve eklerin tam olarak korunduğunu doğrulamak için bir bütünlük denetiminden geçer. Orijinal mesajlar otomatik olarak silinmez: e-posta kutusundaki görünür bir yedek klasörüne taşınır ve müşteri onları kaldırana kadar orada kalır.

Bunu kendi başınıza bir betikle yapmayı deneyebilir misiniz? Teknik olarak evet. Ama "e-postaların çoğunda çalışıyor" ile "tek bir tanesini bile bozmadan tümünde çalışıyor" arasındaki fark, aylarca süren mühendislik çalışmasında ortaya çıkar. Bir kişinin tüm posta kutusundan söz ederken, küçük bir hata oranı bile ne olduğunu doğrulamanın mümkün olmadığı yüzlerce sessizce zarar görmüş mesaj anlamına gelebilir.

Posta kutunuzda kaç e-postanın yanlış tarihe sahip olduğunu öğrenmek ister misiniz? Redate.io ile ücretsiz bir analiz başlatın, ödeme gerekmeden etkilenen e-postaların anlık sayımını alın.