imapsync Tarih Sorunlarını Düzeltme

--syncinternaldates Vaadi (ve Nerede Durur)

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. Ve gerçekten de bunu yapar: her kopyaya kaynak sunucunun tuttuğu dahili tarihi verir. İşte tuzak tam olarak burada.

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 imapsync yalnızca bulduğu tarihleri kopyalayabilir 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.

İyi haber şu: Microsoft 365, Outlook.com ve Gmail kendilerine verilen tarihi korur. Dolayısıyla tarihler yanlış çıktığında, sorun başka bir yerdedir.

Tarihler Neden Yine de Yanlış Olabilir

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. Microsoft 365, Outlook.com ve Gmail bunu yapar: orijinal tarihini taşıyan bir kopya bu tarihi korur.

Ama imapsync'in ilettiği tarih, kaynak sunucunun her mesaj için tuttuğu tarihtir, e-postanın gönderildiği tarih değil. Sağlıklı bir posta kutusunda ikisi örtüşür. Daha önce bir kez taşınmış veya bir yedekten geri yüklenmiş bir posta kutusunda ise kaynak, o önceki işlemin tarihini tutabilir ve imapsync bunu olduğu gibi kopyalar.

Gmail'in farklı bir durumu vardır: kopyalama IMAP yerine Gmail'in kendi içe aktarma API'si üzerinden yapıldığında, bu API kopyanın yapıldığı günün tarihini taşıyan bir Received: satırı ekler ve Outlook bu tarihi gösterebilir. imapsync IMAP kullandığı için bundan etkilenmez.

İki en yaygın açık kaynaklı IMAP sunucusu olan Dovecot ve Cyrus, APPEND'den gelen tarihi de korur. Dolayısıyla hedef ne olursa olsun soru aynıdır: kaynak hangi tarihi tutuyordu?

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

Kaynaktaki tarihlerin dışında, yöneticiler sık sık imapsync'in komut satırı seçeneklerine takılır ya da yanlış seçenekleri suçlar. En sık gördüğüm hatalar:

Tarihleri zaten yanlış olan bir kaynaktan kopyalamak

--syncinternaldates varsayılan olarak açıktır: imapsync her kopyaya kaynak sunucunun tuttuğu dahili tarihi verir (belgelerinde geçtiği gibi, "host2 üzerindeki dahili tarihleri host1 ile aynı yapar"). Kaynak posta kutusu daha önceki bir taşımanın veya bir geri yüklemenin sonucuysa, dahili tarihleri zaten o işlemin tarihi olabilir ve imapsync bu yanlış tarihi sadakatle kopyalar. Bu en yaygın neden ve gözden kaçırması en kolay olan, çünkü günlükte iki tane aynı tarih görünür.

--syncinternaldates ile --addheader kullanmak

Bazı kılavuzlar taşıma sırasında özel bir başlık eklemek için --addheader kullanmayı önerir. Bir başlık eklemek mesajı değiştirir (üste bir satır daha eklenir) ama imapsync'in ilettiği tarihi değiştirmez, dolayısıyla yanlış tarihleri açıklamaz. Kopya artık orijinaliyle birebir aynı değildir, bu da ikisini karşılaştırırsanız önem taşır.

--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.

Kaymış tarihleri TLS'e yormak

TLS üzerinden (--ssl1, --ssl2) bağlantı kurmak gecikme ekler ve büyük bir taşımada (50.000+ mesaj) bu gecikme birikerek saatlere ulaşabilir. Tarihlere dokunmaz: her kopya, gerçekte hangi saatte ulaştığından bağımsız olarak imapsync'in ilettiği tarihi taşır.

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. Ve Microsoft 365, Outlook.com ve Gmail kendilerine verilen tarihi korur. Ama iki aynı tarih yalnızca kopyanın KAYNAĞA sadık olduğunu kanıtlar: kaynaktaki tarih zaten yanlışsa, her iki sütun da aynı yanlış tarihi gösterir.

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 e-postanın gönderildiği tarih değilse, aynı mesaja kaynakta bakın: orada da aynı yanlış tarihi bulursunuz. Günlük yalan söylemedi, kendisine verileni kopyaladı.

Bu, tarih sorunlarını ayıklamanın en sinir bozucu yönlerinden biri: temiz bir günlük dosyası, iki aynı tarih ve yine de Outlook'ta yanlış bir tarih, çünkü hata imapsync çalışmadan önce zaten oradaydı.

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.

imapsync'i yeniden çalıştırıp sorunu düzeltebilir 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 sorun kaynaktaki tarihlerse, ikinci bir çalıştırma aynı yanlış tarihleri yeniden kopyalar.

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 yalnızca aktarımı simüle eder: imapsync'in ileteceği tarihleri gösterir, e-postaların gönderildiği tarih olup olmadıklarını değil. Kaynaktaki tarihlerin zaten yanlış olduğu konusunda hiçbir şey sizi uyarmaz.

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; yanlış tarih mesajın içinde değil, kopyanın aldığı meta verilerdedir. 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. Taşımayı hangi aracın yaptığını bilmesi gerekmez: görüntülenen tarihi orijinal tarihiyle eşleşmeyen e-postaları bulur.

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 saklanır ve siz silmediğiniz sürece orada kalı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