Takeout mbox: E-postalar Bugünün Tarihini Gösteriyor

Google Takeout arşivinizi açtınız, mbox dosyasını Thunderbird'e ImportExportTools NG ile (ya da Apple Mail'e) aktardınız, ardından klasörleri yeni IMAP hesabınıza sürükleyip bıraktınız. İstemcide e-postalar yıl yıl sıralıydı. Hedef hesapta ise hepsi bugünün tarihini taşıyor. Bu yazı, içe aktarılmış bir Takeout mbox'ta tam olarak neler olduğunu, görünen tarihin neden kopyalama tarihi çıktığını, bunu birkaç dakikada nasıl doğrulayacağınızı ve sunucu tarafında nasıl düzelteceğinizi anlatıyor.

Önce şunu bilin: e-postalarınız zarar görmedi. Orijinal tarih hâlâ mesajın içinde. Hedef hesap yalnızca artık onu öne çıkarmıyor.

İçe Aktarılmış Bir Takeout mbox'ta Tipik Senaryo

On beş yıllık kişisel Gmail hesabınızı yeni kapattınız. takeout.google.com üzerinden dışa aktarma istediniz, Google'ın mesajını beklediniz (büyük bir posta kutusu için iki gün), dört zip arşivi indirdiniz. Her birinde etiket başına bir .mbox dosyası var. Bunları Thunderbird'e aktarıyorsunuz: yerel klasör doluyor, tarihe göre sıralama kusursuz, 2009 en altta, dün en üstte.

Sonra herkesin yapacağını yapıyorsunuz. Klasörleri seçip hedef IMAP hesabına sürüklüyorsunuz; hedef bir Microsoft 365, bir hosting sağlayıcısı ya da bir Google Workspace olabilir. Aktarım koca bir akşam sürüyor. Pazartesi sabahı web posta arayüzünü açıyorsunuz.

Sorun mu? 18.400 e-postanın hepsi hafta sonuna, birkaç saatlik bir aralığa tarihlenmiş. 2014'ten bir sözleşme geçen haftanın bülteninin yanında duruyor ve kimse artık hiçbir şeyi kronolojik sırayla bulamıyor.

Durum, tüm eski e-postaların aynı tarihi göstermesi sorununa çok yakın, ama önemli bir farkla: burada suçlu bir e-posta taşıma aracı yok. Sürükle-bırak yeterli.

Tek E-postada Üç Tarih

Anlamak için bir e-postanın "tarihi" diye konuşmayı bırakmak gerekiyor. Bir mbox dosyasından içe aktarılan mesaj en az üç tarih taşır ve bunlar aynı iş için kullanılmaz.

Date üstbilgisi: gönderenin tarihi

Bu, RFC 2822 (ve onu devralan RFC 5322) ile tanımlanan Date: üstbilgisidir. Gönderenin istemcisi bunu gönderim anında yazar, örneğin Date: Tue, 14 Mar 2017 09:12:45 +0100. Mesajın parçasıdır, mesajla birlikte yolculuk eder ve Takeout onu olduğu gibi korur. Düzeltmeyi mümkün kılan da budur, çünkü yerinde ve bozulmamış durumdadır.

mbox dosyasındaki From satırı: göstermelik bir tarih

Bir mbox dosyasında her mesajın önünde From ile başlayan bir satır bulunur (boşluklu, iki noktasız). Bu bir üstbilgi değildir: dosya biçimine özgü bir ayırıcıdır ve mesajın parçası sayılmaz. Ciddi hiçbir araç bir e-postayı tarihlemek için buna güvenmemeli.

INTERNALDATE: sunucuya bırakılma tarihi

Üçüncü tarih ve en sessiz olanı: RFC 3501'in tanımladığı INTERNALDATE (IMAP Dahili Tarih). IMAP sunucusu bu özniteliği mesajın yanında (içinde değil) saklar ve mesajın posta kutusuna bırakıldığı anı gösterir. Outlook, web posta arayüzleri ve telefonlar alınma tarihini göstermek ve sıralamak için bunu kullanır. Mekanizmanın ayrıntısı için IMAP INTERNALDATE ve yanlış tarihler yazısı daha derine iniyor.

Received: üstbilgileri hakkında bir not; burada çoğu zaman haksız yere suçlanırlar. Dışa aktarılmış bir Gmail e-postasındaki Received satırları mesajın 2017'deki gerçek yolculuğunu anlatır: eski ve meşru tarihler taşırlar. Yani bu özel durumda yanlış tarih mesajın içinde değil, sunucunun kopyaya atadığı meta verilerde yaşıyor.

Hedef Hesap Neden Kopyalama Tarihini Gösteriyor

Bir istemci IMAP sunucusuna mesaj bıraktığında APPEND komutunu kullanır. Bu komut isteğe bağlı olarak mesaja verilecek bir tarihi kabul eder. İstemci tarihi gönderirse sunucu onu INTERNALDATE olarak tutar. Göndermezse sunucu RFC 3501'in öngördüğü kuralı uygular: o anın tarihi ve saati. Başka bir deyişle görünen tarih, aracın e-postayı nasıl yazdığına bağlıdır. Orijinal tarihi iletmeyen bir araç, kopyanın tarihini alır.

Sonuç: klasörleri sürüklerken her mesaj kendi bırakılma anının tarihini alıyor. 40 dakikada kopyalanan 3.000 e-postalık bir klasör, 40 dakikalık bir pencereye sığıyor.

Peki Thunderbird'ün yerel klasörü neden kusursuz görünüyordu? Çünkü Thunderbird orada bir sunucu tarihine göre değil Date üstbilgisine göre sıralıyor; yerel klasörün sunucusu yok. Apple Mail'in içe aktarılmış posta kutularındaki davranışı da benzer: mesajlar Mac'te kaldıkça her şey yolunda. Gerçek, başka bir yazılım (örneğin Outlook) IMAP posta kutusunu okuduğu anda ortaya çıkıyor.

Aslında her istemcinin her seferinde yanıldığını söylemek tam doğru değil. Bazı sürümler tarihi iletiyor, bazıları iletmiyor ve davranış güncellemelerle değişti. Bu yüzden aynı yöntemi izleyen iki iş arkadaşı farklı sonuçlar alabilir ve tanı koymak göründüğünden daha kafa karıştırıcı hale gelir.

Sürükle-bırak bir taşıma değildir. Bu bir kopyadır ve kopya, yapıldığı günün tarihini taşır.

Bu Durumu Beş Dakikada Nasıl Tanırsınız

Çözüm aramadan önce başka bir senaryoda değil de gerçekten bunda olduğunuzu doğrulayın. Dört kontrol yeterli.

• İki yeri karşılaştırın. Thunderbird'ün yerel klasörü (ya da Apple Mail'in içe aktarılmış posta kutusu) doğru tarihleri, IMAP hesabı aynı mesajlar için yakın tarihleri gösteriyor.
• Aralığa bakın. IMAP hesabındaki bir klasörde alınma tarihleri, klasörleri taşıdığınız anın çevresinde birkaç saate, hatta birkaç dakikaya sığıyor.
• Bir mesajın kaynağını açın. Thunderbird'de Görünüm menüsünden mesaj kaynağına, Outlook'ta mesaj özelliklerinden internet üstbilgilerine ulaşırsınız. Ekranda yeni bir tarih görünürken orada eski bir Date: satırı bulmalısınız.
• Sıraya bakın. Mesajlar kronolojik sırayla değil, istemcinin kopyaladığı sırayla görünüyor.

Gerçek bir mesajda karşılaştırma şöyle görünür:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (mesajın içinde, bozulmamış)
IMAP hesabında görünen tarih: kopyalama günü   (sunucunun meta verisi)

Bu iki satır aynı hikayeyi anlatmıyorsa doğru yerdesiniz. Görünen tarihler yanlışken Date: da yanlışsa, bu başka ve daha nadir bir sorundur; bu yazının konusu değil.

(Bu arada, ham e-posta üstbilgilerini hiç okumadıysanız yanınıza bir kahve alın: tam bir plaj okuması sayılmaz.)

Gönderim Tarihine Göre Sıralamak: Geçici Bir Çözüm

İlk refleks sıralamayı gönderim tarihine çevirmek. Outlook'ta bu kabaca işe yarar, ama her klasörde ve her cihazda yeniden yapmanız gerekir. Arama, bildirimler, e-postanın yaşına dayalı kurallar ve mobil görünümler ise alınma tarihini kullanmaya devam eder. Telefonunda "geçen eylülün e-postasını" arayan bir kullanıcı mantıklı hiçbir şey görmez. Konuyu gönderim tarihine göre sıralamanın neden çözüm olmadığı yazısında ayrıntılı ele aldık.

Cazip bir başka yol da kopyalamayı baştan yapmak. Zaten kullanılan bir hesapta bu, çoğunlukla mevcut mesajların yanında aynı yanlış tarihli (ya da başka yanlış tarihli) kopyalar üretir. Yüz kadar klasör sonra elinizde tek bir temiz posta kutusu kalmaz.

Sunucu Tarafında Düzeltme

İyi haber şu: orijinal tarih hâlâ orada. Düzeltme, mesajlarınızın içeriğine dokunmadan hedef hesabın onu göstermesini sağlamaktan ibaret.

Redate tam olarak bunu yapar. Hizmet posta kutusuna bağlanır (Google Workspace için alan genelinde yetkilendirmeyle, Microsoft 365 için, Outlook.com ve Hotmail için herkesin kendi Microsoft hesabıyla, ya da doğrudan IMAP ile adres ve parola üzerinden). Sorunu hangi aracın yarattığını bilmesi gerekmez: görünen tarihi orijinal tarihiyle uyuşmayan e-postaları bulur; neden bir Takeout mbox'tan sürükle-bırak olsun, neden başka bir şey. Ücretsiz tarama, herhangi bir karardan önce sorunun boyutunu gösterir.

Düzeltmenin kendisi için Redate, tescilli bir düzeltme motoruna dayanır: her mesajın üstbilgi zincirini inceleyen çok aşamalı bir analiz hattı, her e-postaya orijinal tarihini geri verir. Düzeltilen her e-posta ardından tek tek doğrulanır; RFC uyumluluk denetimi yapılır ve mesaj yapısı korunur. Orijinaller asla silinmez: siz kendiniz silene kadar posta kutunuzda görünür bir klasörde kalırlar.

Kendi Başınıza Uğraşmak Neden Riskli

Sorunu anlamak bir şey. 15.000 e-postayı tek bir tanesini kaybetmeden düzeltmek bambaşka bir şey.

On deneme mesajında çalışan bir betik, 30.000 mesajlık bir üretim posta kutusunda ayakta kalamaz. İmzalı S/MIME e-postalarına rastlar; en küçük değişiklik imzayı bozar. Şifreli PGP mesajlarına. İç içe multipart/alternative yapılarına, tutarsız MIME sınırlarına, beklenmedik Content-Transfer-Encoding değerlerine, RFC 2047 ile kodlanmış ASCII dışı üstbilgilere, 40 MB'lık eklere. Sonra API kotaları gelir, sabaha karşı 3'te toplu işlemin ortasında 429 Too Many Requests hatası, işlemi 11.874. mesajda yarıda kesen ağ zaman aşımları.

Peki sonra? Her mesajın sağlam olduğunu nasıl anlayacaksınız? Geri alma mekanizması olmadan tek bir hata çift mesaj, kaybolan ekler, kopan konuşma zincirleri, silinen etiketler bırakır. Redate her e-postayı otomatik olarak denetler ve orijinali elinizin altında tutar; tam da bu konuda kumar oynamak zorunda kalmayasınız diye.

Bedava bir son öğüt: posta kutusu doğrulanana kadar orijinal Takeout arşivlerinizi saklayın. Hedef hesap doğru görünse bile referans kopya mbox dosyasıdır.

İstemcinize Özel Rehberler

Kopyalamayı hangi istemciyle yaptığınıza göre, aşağıdaki ayrıntılı rehberler özel durumu anlatıyor: Thunderbird'de yapılan bir IMAP kopyasının tarihlerini düzeltme ve aynı durumun Apple Mail'deki hali.

Takeout'unuz IMAP hesabına zaten kopyalandı ve tarihler yanlış mı? Kaç e-postanın etkilendiğini görmek için Redate'in ücretsiz taramasını başlatın, ardından tek seferlik ödemeyle, posta kutusu boyutu sınırı olmadan düzeltin.