imapsync Tarih Sorunlarını Düzeltme

--syncinternaldates Vaadi (ve Neden Bozulur)

imapsync komutunu çalıştırdınız. Belgeleri okuyup dikkatli davrandığınız için --syncinternaldates parametresini de eklediniz. Taşıma tamamlandı, günlük her şeyin aktarıldığını söylüyor, sıfır hata. Sonra Outlook'ta posta kutusunu açtınız ve her e-posta dünün tarihini gösteriyor.

Bu imapsync'in en yaygın hayal kırıklıklarından biri ve en az 2017'den beri sistem yöneticilerinin kafasını karıştırıyor. --syncinternaldates parametresi, taşıma sırasında IMAP INTERNALDATE değerini korumak için tasarlanmıştır. Teknik olarak denemeyi de deniyor. Ama "denemek" o cümlede çok fazla iş yapıyor.

imapsync, Gilles Lamiral tarafından yazılmış açık kaynaklı bir Perl aracıdır ve yaptığı işi gerçekten iyi yapar. IMAP'tan IMAP'a posta kutusu aktarımlarını çoğu ticari aracın kıskandığı bir güvenilirlik düzeyinde yönetir. Ama tarih koruması tamamen imapsync'in elinde değildir ve işlerin karmaşıklaştığı yer burası.

IMAP Tarihleri Aslında Nasıl Çalışır

Her e-postada üç farklı "tarih" bulunur ve çoğu kişi (bazı BT yöneticileri dahil) bunları birbirine karıştırır:

Date: başlığı (RFC 2822) - gönderenin e-posta istemcisinin mesaj oluşturulduğunda üzerine damgaladığı tarih. Mesaj gövdesinin içinde yaşar ve posta sunucuları tarafından asla değiştirilmez.
Received: başlıkları - mesajı işleyen her posta sunucusu kendi zaman damgasıyla bir tane ekler. Gönderenden alıcıya uzanan bir zincir oluştururlar. En üstteki (en yeni) Received başlığı, bazı e-posta istemcilerinin görüntüleme için kullandığı şeydir.
INTERNALDATE - mesajların posta kutusunda nasıl sıralandığını kontrol eden IMAP sunucu tarafı zaman damgası. Mesaj ilk kez IMAP APPEND ile depolandığında ayarlanır.

imapsync bir mesajı taşırken, kaynak sunucudan (INTERNALDATE dahil) mesajı okur ve IMAP APPEND kullanarak hedef sunucuya yazar. --syncinternaldates parametresi, imapsync'e APPEND sırasında kaynak INTERNALDATE değerini hedef sunucuya iletmesini söyler.

Sorun şu: hedef sunucu bu tarihi kabul etmek zorunda değil.

Hedef Sunucular Neden INTERNALDATE'i Yok Sayar

IMAP spesifikasyonu (RFC 3501), APPEND komutuyla bir tarih-saat sağlanırsa sunucunun bunu kullanması GEREKTİĞİNİ söylüyor. RFC dilinde "SHOULD" (GEREKİR), "bunu yapın, iyi bir nedeniniz yoksa" anlamına gelir. Birçok büyük e-posta platformu iyi bir nedenleri olduğuna karar vermiştir.

Microsoft 365 en büyük sorun kaynağı. IMAP APPEND ile bir mesaj geldiğinde, Exchange taşıma hattı mesaja güncel tarihi içeren yeni bir Received başlığı ekler, ardından INTERNALDATE'i bu teslim zaman damgasına göre ayarlar. imapsync'in hangi tarihi istediği fark etmez. M365 sunucusu onu geçersiz kılar.

Google Workspace (Gmail) farklı davranır ama yine de sorun yaratabilir. Gmail'in IMAP uygulaması çoğu durumda APPEND'den gelen INTERNALDATE'i kabul eder, ama kendi Received başlığını ekler. Posta kutusunu okuyan e-posta istemcisi, görüntüleme için INTERNALDATE yerine Received başlıklarını önceliklendiriyorsa (ve Outlook tam da bunu yapar) tarihler yine yanlış görünür.

İki en yaygın açık kaynaklı IMAP sunucusu olan Dovecot ve Cyrus, genellikle APPEND'den gelen INTERNALDATE'i kabul eder. Dolayısıyla iki Dovecot sunucusu arasındaki imapsync taşımaları genellikle tarihleri doğru korur. Sorunlar hedef kendi taşıma işlemesi olan barındırılan bir platform olduğunda başlar.

Tarihleri Bozan Yaygın imapsync Komut Satırı Hataları

Hedef sunucu iş birliği yapsa bile yöneticiler sık sık imapsync'in komut satırı seçeneklerinde tökezler. En sık gördüğüm hatalar:

--syncinternaldates'i tamamen unutmak

Parametre varsayılan olarak etkin değildir. Onsuz temel bir imapsync --host1 kaynak --host2 hedef --user1 kullanıcı --user2 kullanıcı çalıştırırsanız, imapsync tarihleri korumayı denemez bile. Hedef sunucu her mesaj için güncel zaman damgasını kullanır. Bu en yaygın neden ve imapsync bu konuda sizi uyarmadığı için gözden kaçırması en kolay olan.

--syncinternaldates ile --addheader kullanmak

Bazı kılavuzlar taşıma sırasında özel bir başlık eklemek için --addheader kullanmayı önerir. Başlık ekliyorsanız mesajı değiştiriyorsunuz demektir ve bu, hedef sunucunun mesajı "yeni" olarak değerlendirip buna göre damgalamasına neden olabilir. Bu iki parametre arasındaki etkileşim yetersiz belgelenmiştir.

--minage ve --maxage'i tarih korumasıyla karıştırmak

--minage ve --maxage parametreleri hangi mesajların taşınacağını yaşlarına göre filtreler. Tarihlerin hedefte nasıl işlendiğini etkilemezler. Yöneticilerin bu parametreleri tarih sorununu düzelteceğini düşünerek saatlerce ayarladığını gördüm. Düzeltmezler.

SSL müzakeresinin zaman damgası kaymasına neden olması

--ssl1 ve --ssl2 ile TLS üzerinden taşıma yaparken bağlantı kurulumu gecikme ekler. Büyük taşımalarda (50.000+ mesaj) bu gecikme birikir. Tarihleri günlerle değiştirmese de dakikalar arayla gönderilen mesajların hedefte aynı zaman damgasıyla gelmesine ve göreli sıralamalarını kaybetmelerine neden olabilir.

imapsync Günlüklerini Okumak: Çıktı Gerçekten Ne Söylüyor

imapsync ayrıntılı günlükler üretir, bu harika. Ama tarihler söz konusu olduğunda günlük çıktısı yanıltıcı olabilir.

Tipik bir başarılı aktarım satırı şöyle görünür:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

Her iki tarih de eşleşiyor. Bu, imapsync'in hedefe doğru INTERNALDATE'i gönderdiği anlamına gelir. Ama hedef sunucunun o tarihi gerçekten saklayıp saklamadığı anlamına gelmez. imapsync ne istediğini raporlar, sunucunun ne kabul ettiğini değil.

Gerçekte ne olduğunu doğrulamak ister misiniz? Taşıma sonrası hedefe bir IMAP istemcisiyle bağlanın ve INTERNALDATE'i doğrudan kontrol edin:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Dönen tarih 2019-01-15 yerine taşıma tarihiyse, hedef sunucu imapsync'in isteğini yok saymış demektir. Günlük size yalan söyledi (aslında ne istediğini söyledi, ne aldığını değil).

imapsync'in raporladığı ile gerçekte olan arasındaki bu boşluk, tarih sorunlarını ayıklamanın en sinir bozucu yönlerinden biri. Temiz bir günlük dosyasına saatlerce bakıp diğer tarafta tarihlerin yanlış olduğunu hiç fark etmeyebilirsiniz.

Büyük Ölçekli imapsync Taşımaları: Tarih Sorunlarının Katlandığı Yer

Tek bir posta kutusu taşımasında tarihler bozulduğunda imapsync can sıkıcıdır. Ama yüzlerce posta kutusunda imapsync çalıştıran MSP'ler ve BT departmanları tamamen farklı bir ölçekte sorunla karşılaşır.

Tipik bir kurumsal taşıma senaryosu düşünün. 200 posta kutusunu Zimbra sunucusundan Microsoft 365'e taşıyorsunuz. Kullanıcılar CSV'si üzerinden döngüde imapsync çağıran bir sarmalayıcı betik yazıyorsunuz. Taşıma hafta sonu boyunca çalışıyor. Pazartesi sabahı elinizde bozuk tarihli 200 posta kutusu ve toplamda taşıma zaman damgasını gösteren yaklaşık 1,2 milyon e-posta var.

İlk seferde unuttuysanız --syncinternaldates ile imapsync'i yeniden çalıştırabilir misiniz? Teknik olarak evet, ama imapsync hedefte zaten var olan mesajları atlar (idempotent olacak şekilde tasarlanmıştır). Hedef mesajları silip yeniden aktarmak için --delete2 gerekir, bu da üretim posta kutusunda risklidir. Ve hedef sunucu INTERNALDATE'i yok sayıyorsa bile başa dönersiniz.

Bazı yöneticiler karma bir yaklaşım dener: önce test için --dry ile imapsync çalıştırıp ardından gerçek taşımayı yapmak. Ama --dry hedef sunucunun INTERNALDATE ile ne yaptığını test etmez. Sadece aktarımı simüle eder. Tarih sorunu mesajlar gerçekten hedefe yazılana kadar görünmezdir.

Kendiniz Yapın Düzeltmeleri ve Sınırları

Forum ve posta listelerinde ararsanız (SourceForge'daki imapsync-devel listesi 2026 başı itibarıyla hala aktif) yaratıcıdan tehlikeliye kadar öneriler bulursunuz.

Bazıları hedef sunucuda INTERNALDATE'i doğrudan değiştirmek için tek satırlık Perl komutu önerir. Başkaları tüm mesajları mbox formatına aktarıp tarihleri manipüle edip yeniden içe aktarmayı tavsiye eder. Birkaçı mesajları getirmek, değiştirmek ve yeniden eklemek için imaplib kullanan Python betikleri yazmıştır.

Bu yaklaşımların hepsinde aynı temel sorunlar var. S/MIME imzalı mesajları imzayı bozmadan nasıl ele alırsınız? İç içe sınırları olan çok parçalı MIME yapıları ne olacak? RFC 2047 ile kodlanmış ASCII dışı başlıklar? İçeriği bile inceleyemediğiniz PGP şifreli mesajlar? Geliştirme ortamında 50 test mesajını işleyen bir betik, 30.000 mesajlık bir üretim posta kutusunun uç durumlarında tıkanacaktır.

Ve kimsenin çok geç olana kadar sormadığı en büyük soru: değiştirilen her mesajın hala bozulmadığını nasıl doğrularsınız? Eklerin bozulmadığını, ileti dizisinin çalıştığını, 2020'de birinin gönderdiği 85 MB'lık tablonun manipülasyondan sağ çıktığını?

(Ham e-posta başlıklarını Perl'de ayrıştırmayı denediyseniz, bunun tam olarak rahatlatıcı bir öğleden sonra aktivitesi olmadığını bilirsiniz.)

Redate.io imapsync Tarih Sorunlarını Nasıl Düzeltir

Orijinal Date: başlığı bir imapsync taşımasından sonra her zaman bozulmamış haldedir. imapsync ham mesajı sadık bir şekilde aktarır; görüntüleme sorununa neden olan hedef sunucunun meta veri işlemesidir. Bu orijinal başlık, düzeltmeyi mümkün kılan şeydir.

Redate.io posta kutusuna doğrudan bağlanır (Google Workspace, Microsoft 365 veya herhangi bir IMAP sunucusu), tarih anomalileri olan e-postaları tarar ve tescilli bir başlık zinciri analizi ve tarih yeniden yapılandırma hattı aracılığıyla hedefli meta veri düzeltmesi uygular. Düzeltme, INTERNALDATE'i geçersiz kılan hedef sunuculardan gelen karakteristik Received başlık imzaları dahil olmak üzere imapsync taşımalarının geride bıraktığı belirli kalıpları ele alır.

Düzeltilen her e-posta tek tek doğrulanır: mesaj bütünlüğü, ek koruması, klasör yerleşimi, ileti dizisi, etiketler. Orijinaller, posta kutusunda görünür bir Redate.io - Originals yedek klasöründe 30 gün boyunca saklanır. Herhangi bir şey yanlış görünürse geri alma tek bir tıkla yapılır.

Ücretsiz tarama posta kutusuna bağlanır, tarih anomalisi olan her e-postayı tespit eder ve tam sayıyı ve maliyeti raporlar. Kredi kartı gerekmez, kurulacak yazılım yok. Platformunuzun ayrıntıları için:

Redate.io aylar veya yıllar önce gerçekleşen taşımalar için de çalışır. Date: başlığının süresi dolmaz ve bozulan şeyi düzeltme yeteneğinin de.

imapsync ile taşıma yaptınız ve yanlış tarihlerle mi kaldınız? Kaç e-postanın etkilendiğini görmek için ücretsiz tarama başlatın.

imapsync Tarihleri Korunmadı mı? Nasıl Düzeltilir