Exchange IMAP Import: Mengapa Tanggal Email Salah

Impor IMAP Exchange dan Tanggal Email Anda

Exchange Online memberikan tanggal untuk setiap pesan di kotak surat, dan itulah tanggal yang ditampilkan dan digunakan untuk mengurutkan oleh Outlook. Untuk email yang tiba dari internet, itu adalah saat pengiriman. Untuk email yang disalin oleh migrasi, itu adalah tanggal apa pun yang diberikan migrasi ke salinan tersebut: tanggal asli jika migrasi meneruskannya, tanggal impor jika tidak.

Dari sinilah kerusakan tanggal selama impor IMAP Exchange berasal. Exchange Online tidak menimpa tanggal yang diberikan kepadanya. Namun ketika impor tidak membawa tanggal asli setiap email, salinan pesan berumur 7 tahun mendapatkan tanggal impor, seolah baru saja dikirim.

Hasilnya? Anda mengimpor 4.000 email dari server IMAP lama ke Exchange Online, dan email menampilkan tanggal impor bukan tanggal aslinya. Email dari 2018, 2020, 2023, bertanggal hari ini. Pengguna Anda membuka Outlook pada Senin pagi dan melihat deretan pesan dengan tanggal yang identik.

Cara Kerja Wizard Migrasi Exchange Admin Center

Exchange Admin Center (EAC) menyediakan wizard migrasi bawaan untuk impor IMAP. Ini adalah antarmuka grafis yang biasanya dituju lebih dulu oleh administrator Exchange: Anda membuka Recipients, lalu Migration, membuat batch baru, memilih "Migrate to Exchange Online", memilih IMAP sebagai sumber, mengunggah CSV dengan pemetaan kotak surat, dan menjalankan batch tersebut.

Di balik layar, wizard migrasi EAC membuat New-MigrationBatch dengan jenis endpoint diatur ke IMAP. Exchange terhubung ke server IMAP sumber Anda, membaca setiap pesan, dan menuliskannya ke kotak surat Exchange Online target. Cukup sederhana di atas kertas.

Namun inilah yang dihadapi administrator. Microsoft tidak mendokumentasikan bagaimana migrasi menetapkan tanggal setiap pesan yang disalin, dan administrator melaporkan email yang keluar dengan tanggal sinkronisasi bukan tanggal saat diterima. Outlook, OWA, dan setiap klien lain yang terhubung ke kotak surat itu kemudian menggunakan tanggal tersebut untuk tampilan dan pengurutan.

Header Date: asli dari 2019? Masih ada, tersembunyi di antara header pesan. Namun Exchange tidak menggunakannya untuk urutan tampilan di kotak masuk Anda.

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

PowerShell: New-MailboxImportRequest dan Masalah yang Sama

Administrator yang lebih memilih baris perintah sering menggunakan New-MailboxImportRequest untuk mengimpor file PST, atau New-MigrationBatch dengan endpoint IMAP untuk migrasi antar server. Harapannya, PowerShell memberikan kendali lebih besar. Dan memang begitu, untuk beberapa hal. Tidak untuk tanggal.

New-MailboxImportRequest mengimpor file PST ke kotak surat Exchange Online. File PST berisi stempel waktu asli untuk setiap pesan. Tetapi cmdlet PowerShell ini tidak memiliki parameter yang mengatur tanggal apa yang didapat setiap pesan yang diimpor. Tidak ada flag -PreserveDates (dan percayalah, administrator sudah mencarinya).

New-MigrationBatch -SourceEndpoint dengan endpoint IMAP bekerja mirip dengan wizard EAC, hanya tanpa antarmuka grafis. Koneksi IMAP yang sama, hasil yang sama untuk tanggal. Cmdlet ini menawarkan parameter untuk memfilter berdasarkan rentang tanggal (-StartAfter, -CompleteAfter) dan mengecualikan folder, tetapi tidak ada yang mengatur bagaimana Exchange menangani stempel waktu pesan yang masuk.

Secara tepat, ini terutama memengaruhi tanggal tampilan dan urutan pengurutan. Konten pesan, termasuk header Date asli, tiba dengan utuh. Hanya tanggal yang diberikan pada salinan yang salah, dan itulah yang berada di balik semua yang terlihat oleh pengguna.

Impor IMAP Langsung vs Tool Pihak Ketiga

Apakah penting apakah Anda menggunakan impor IMAP asli Exchange atau tool pihak ketiga seperti BitTitan MigrationWiz atau CloudM? Jawaban singkatnya: masalah tanggal terjadi pada kedua cara, tetapi dengan alasan yang sedikit berbeda.

Dengan impor IMAP asli Exchange (wizard EAC atau PowerShell), Exchange sendiri terhubung ke server IMAP sumber dan menarik pesan. Bagaimana Exchange menetapkan tanggal setiap salinan bergantung pada Microsoft, dan tidak didokumentasikan.

Dengan tool pihak ketiga, tool migrasi berperan sebagai perantara. Tool tersebut membaca dari sumber, mungkin mengubah pesan, dan menulisnya ke Exchange Online. Ketika tool menulis melalui IMAP, Exchange Online mempertahankan tanggal yang diteruskan oleh tool: jika tool mengirimkan tanggal asli setiap email, salinannya mempertahankan tanggal itu; jika tidak, salinannya mendapatkan tanggal migrasi. Beberapa tool juga menambahkan header Received: mereka sendiri selama proses relay.

Perbedaan praktisnya? Header yang tertinggal tidak sama dari satu tool ke tool lain, jadi perbaikan tidak bisa mengandalkan satu pola yang tetap. Masalah dasarnya identik: tanggal yang ditampilkan bukan tanggal asli email.

Mengapa Aturan Transport Exchange Online Memperburuk Keadaan

Ada hal yang mengejutkan bahkan administrator Exchange yang berpengalaman. Exchange Online memiliki aturan transport (sekarang disebut "aturan alur email" di admin center) yang dapat aktif pada pesan yang diimpor. Jika organisasi Anda memiliki aturan yang menambahkan stempel header, disclaimer, atau mengubah pesan berdasarkan kondisi tertentu, aturan tersebut mungkin juga memproses email yang diimpor.

Ini berarti email dari 2020 mungkin mendapat tambahan footer disclaimer, atau header X yang ditambahkan oleh aturan kepatuhan yang belum ada saat email asli dikirim. Kerusakan tanggal adalah gejala yang paling terlihat, tetapi aturan transport dapat menciptakan modifikasi tak terduga lainnya.

Bisakah Anda menonaktifkan aturan transport selama impor? Bisa, sementara. Tetapi kebanyakan administrator tidak berpikir untuk melakukannya karena mereka tidak menduga pipeline transport akan memproses pesan yang dimigrasikan sejak awal. Ketika mereka menyadari apa yang terjadi, batch impor sudah selesai dan kerusakan sudah terjadi.

Apa Arti Tanggal Salah bagi Lingkungan Exchange

Lingkungan Exchange cenderung merupakan lingkungan bisnis. Firma hukum, lembaga keuangan, organisasi kesehatan, instansi pemerintah. Ini bukan akun Gmail pribadi tempat tanggal yang salah hanya sedikit mengganggu. Ini adalah kotak surat tempat stempel waktu email memiliki makna hukum dan regulasi.

Litigation hold di Exchange menyimpan email berdasarkan rentang tanggal. Jika setiap email yang diimpor menampilkan tanggal impor bukan tanggal aslinya, hold tersebut menangkap kumpulan pesan yang salah. Pencarian eDiscovery untuk "semua komunikasi antara Januari dan Maret 2022" tidak menghasilkan apa pun karena email tersebut kini menampilkan April 2026.

Kebijakan retensi menghadapi masalah yang sama. Organisasi dengan kebijakan retensi 3 tahun mungkin secara tidak sengaja menghapus email yang tampak berasal dari 2026 (dan karenanya "baru") padahal sebenarnya berasal dari 2019 dan seharusnya dipertahankan. Atau sebaliknya: email yang seharusnya dihapus sesuai kebijakan retensi tetap ada karena tanggal tampilannya terlihat baru.

Salah satu skenario dari akhir 2025: sebuah MSP memigrasikan sekitar 200 kotak surat dari penyedia Exchange yang dihosting ke Microsoft 365 menggunakan wizard migrasi EAC. Tiga minggu kemudian, petugas kepatuhan klien menandai bahwa laporan pengarsipan email kuartalan menunjukkan setiap pesan yang diarsipkan dengan tanggal yang sama. Seluruh arsip email, hingga 5 tahun ke belakang, tampak tiba pada satu hari Selasa yang sama di bulan November.

Memperbaiki Tanggal Impor IMAP Exchange

Header Date: asli bertahan utuh melewati impor. Impor tidak mengubah header RFC 2822 asli di dalam pesan. Tanggal asli itulah titik acuan untuk perbaikan.

Redate.io terhubung ke kotak surat Exchange Online (setiap orang masuk dengan akun Microsoft masing-masing), memindai pesan dengan anomali tanggal yang disebabkan oleh impor IMAP, dan menerapkan mesin koreksi milik sendiri yang melakukan validasi kepatuhan RFC, pelestarian struktur pesan, dan rekonstruksi metadata yang tertarget. Redate tidak perlu tahu tool mana yang melakukan impor: Redate menemukan email yang tanggal tampilannya tidak sesuai dengan tanggal aslinya.

Setiap pesan yang diperbaiki diverifikasi satu per satu: integritas konten, checksum lampiran, penempatan folder, dan alur percakapan. Email asli tetap berada di folder cadangan yang terlihat di kotak surat Anda sendiri sampai Anda menghapusnya sendiri. Jika ada yang terlihat salah, pembatalan hanya perlu satu klik.

Mengapa tidak memperbaikinya dengan skrip PowerShell? Karena memahami masalah header Received hanyalah bagian yang mudah. Memperbaiki 8.000 email di 50 kotak surat tanpa merusak pesan yang ditandatangani S/MIME, merusak struktur MIME bersarang, mengacaukan header RFC 2047 non-ASCII, atau kehilangan penempatan folder, itulah bagian yang sulit. Bagaimana Anda memverifikasi bahwa setiap pesan yang diperbaiki di lingkungan produksi tetap utuh, bahwa tidak ada lampiran yang hilang, bahwa tidak ada alur percakapan yang rusak? Skrip yang berhasil pada kotak surat uji dengan 30 pesan akan gagal pada kasus dunia nyata yang rumit. Kontrak dengan lampiran 42 MB dan tiga gambar inline yang tertanam dalam struktur multipart/mixed di dalam wrapper multipart/alternative itu? Semoga berhasil.

Panduan Khusus Platform

Perbaikan tanggal berlaku di tingkat kotak surat Exchange Online, tetapi pengguna mengakses email mereka melalui klien yang berbeda. Setiap klien menampilkan tanggal secara berbeda:

• Perbaiki tanggal impor IMAP Exchange di Outlook
• Perbaiki tanggal impor IMAP Exchange di OWA (Outlook on the Web)

Mencari konteks yang lebih luas tentang masalah tanggal Microsoft 365 di berbagai tool migrasi? Lihat panduan lengkap memperbaiki tanggal email setelah migrasi Microsoft 365.

Impor IMAP Exchange membuat kotak surat Anda memiliki tanggal yang salah? Mulai dengan pemindaian gratis untuk melihat berapa banyak email yang terdampak dan berapa biaya perbaikannya, tanpa perlu kartu kredit.