Exchange IMAP Aktarımı: Tarihler Neden Bozulur

Exchange IMAP Aktarımları ve E-posta Tarihleriniz

Exchange Online, bir posta kutusundaki her mesaja bir tarih verir ve Outlook bu tarihi gösterir, buna göre sıralar. İnternetten gelen bir e-posta için bu, teslim anıdır. Bir taşıma ile kopyalanan bir e-posta için ise bu, taşımanın kopyaya verdiği tarihtir: taşıma orijinal tarihi ilettiğinde bu tarih, iletmediğinde ise aktarım günüdür.

Exchange IMAP aktarımlarında tarih sorununun kaynağı bu. Exchange Online, kendisine verilen bir tarihin üzerine yazmaz. Ama bir aktarım her e-postanın orijinal tarihini iletmediğinde, 7 yıllık bir mesajın kopyası, sanki az önce teslim edilmiş gibi aktarım tarihini alır.

Sonuç? Eski bir IMAP sunucusundan Exchange Online'a 4.000 e-posta aktarırsınız ve e-postalar kendi tarihleri yerine aktarım tarihini gösterir. 2018, 2020, 2023'ten e-postalar, hepsi bugünün tarihiyle görünür.

Exchange Yönetim Merkezi Taşıma Sihirbazı Nasıl Çalışır

Exchange Admin Center (EAC) IMAP aktarımları için yerleşik bir taşıma sihirbazı içerir. Çoğu Exchange yöneticisinin ilk ulaştığı grafiksel arayüz: Recipients, ardından Migration'a gidip yeni bir toplu iş oluşturursunuz, "Migrate to Exchange Online" seçip kaynak olarak IMAP'ı seçersiniz, posta kutusu eşlemeleriyle bir CSV yüklersiniz ve toplu işi başlatırsınız.

Perde arkasında EAC taşıma sihirbazı, uç nokta türü IMAP olarak ayarlanmış bir New-MigrationBatch oluşturur. Kopyaya verilen tarih dışında hiçbir şey değişmez, ve kullanıcıya görünen her şeyin arkasında o tarih vardır.

Ama yöneticilerin karşılaştığı şu: Microsoft, taşımanın kopyalanan her mesaja hangi tarihi verdiğini belgelemez ve yöneticiler, e-postaların alındıkları tarih yerine eşitlemenin yapıldığı tarihle çıktığını bildirir. Ardından Outlook, OWA ve o posta kutusuna bağlı diğer tüm istemciler bu tarihi görüntüleme ve sıralama için kullanır.

Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest ve Aynı Sorun

Komut satırını tercih eden yöneticiler genellikle PST dosyalarını içe aktarmak için New-MailboxImportRequest'e veya sunucudan sunucuya taşımalar için IMAP uç noktalarıyla New-MigrationBatch'e yönelir. Ama IMAP bağlantısı aynı, tarihler için sonuç da aynı.

PowerShell komutunun, aktarılan her mesajın hangi tarihi alacağını denetleyen bir parametresi yok. -PreserveDates diye bir flag yok (ve inanın, yöneticiler aramış).

Doğrudan IMAP Aktarımı ve Üçüncü Taraf Araçlar

Exchange'in yerel IMAP aktarımını mı yoksa BitTitan MigrationWiz veya CloudM gibi üçüncü taraf bir aracı mı kullandığınız fark eder mi? Kısa cevap: tarih sorunu her iki şekilde de olur, ama biraz farklı nedenlerle.

Yerel Exchange IMAP aktarımında her kopyaya hangi tarihin verildiğini Microsoft belirler ve bu belgelenmez. Araç IMAP üzerinden yazdığında, Exchange Online aracın gönderdiği tarihi korur: araç her e-postanın orijinal tarihini gönderirse kopya bu tarihi korur, göndermezse kopya taşımanın tarihini alır. Bazı araçlar aktarım sırasında kendi Received: başlığını da ekler. Araçtan araca farklı başlıklar kalabileceğinden, bir düzeltme sabit bir örüntüye dayanamaz. Temel sorun aynı: gösterilen tarih, e-postanın orijinal tarihi değildir.

Exchange Online Taşıma Kuralları Neden İşleri Kötüleştirir

Deneyimli Exchange yöneticilerini bile şaşırtan bir şey var. Exchange Online'ın taşıma kuralları (şimdi yönetim merkezinde "posta akışı kuralları" olarak adlandırılır) aktarılan mesajlar üzerinde de tetiklenebilir. Kuruluşunuzda başlık ekleyen, sorumluluk reddi notu ekleyen veya koşullara göre mesajları değiştiren kurallar varsa, bu kurallar aktarılan e-postaları da işleyebilir.

Bu, 2020'den bir e-postaya, orijinal e-posta gönderildiğinde var olmayan bir uyumluluk kuralı tarafından sorumluluk reddi notu eklenebileceği anlamına gelebilir.

Exchange Ortamlarında Yanlış Tarihlerin Anlamı

Exchange ortamları genellikle iş ortamlarıdır. Hukuk firmaları, finans kuruluşları, sağlık organizasyonları, devlet kurumları. E-posta zaman damgalarının yasal ve düzenleyici önemi olan posta kutuları bunlar.

Exchange'de bir dava bekletmesi tarihe göre e-postaları korur. Aktarılan her e-posta orijinal tarih yerine aktarım tarihini gösteriyorsa, bekletme yanlış mesaj setini yakalar. "Ocak-Mart 2022 arasındaki tüm iletişimler" için bir eKeşif araması, bu e-postalar artık Nisan 2026 gösterdiği için hiçbir şey döndürmez.

Saklama politikaları da aynı sorunla karşılaşır. 3 yıllık saklama politikası olan bir kuruluş, 2026'dan görünen (dolayısıyla "yeni" olan) ama aslında 2019'dan olan ve korunması gereken e-postaları yanlışlıkla silebilir.

Exchange IMAP Aktarım Tarihlerini Düzeltme

Orijinal Date: başlığı aktarımdan sağ çıkıyor. Aktarım, mesajın içindeki orijinal RFC 2822 başlıklarını değiştirmez. Bu orijinal tarih, düzeltme için çıpa noktasıdır.

Redate.io Exchange Online posta kutusuna bağlanır (her kişi kendi Microsoft hesabıyla oturum açar), IMAP aktarımının neden olduğu tarih anomalileri olan mesajları tarar ve RFC uyumluluğu doğrulaması, mesaj yapısı koruması ve hedefli meta veri yeniden yapılandırması gerçekleştiren tescilli bir düzeltme motoru uygular. Redate, aktarımı hangi aracın yaptığını bilmesine gerek kalmadan, görüntülenen tarihi orijinal tarihiyle uyuşmayan e-postaları bulur.

Düzeltilen her mesaj tek tek doğrulanır: içerik bütünlüğü, ek sağlamaları, klasör yerleşimi ve konuşma ileti dizisi. Orijinaller, kendi posta kutunuzdaki görünür bir yedek klasöründe, siz silmediğiniz sürece saklanır.

Platforma Özel Kılavuzlar

• Outlook'ta Exchange IMAP aktarım tarihlerini düzeltme
• OWA'da Exchange IMAP aktarım tarihlerini düzeltme (Outlook on the Web)

Farklı taşıma araçlarında Microsoft 365 tarih sorunları hakkında daha geniş bir bakış için Microsoft 365 taşıması sonrası e-posta tarihlerini düzeltme rehberine bakın.

Exchange IMAP aktarımı posta kutularınızı yanlış tarihlerle mi bıraktı? Kaç e-postanın etkilendiğini ve düzeltme maliyetini görmek için ücretsiz tarama başlatın, kredi kartı gerekmez.