imapsync: מניעת אובדן דואר בהעברה

imapsync הוא הכלי המקובל להעברת דואר IMAP בלי לגרור משתמשים דרך יצוא PST, יישומי מחשב או סוף שבוע של ניחושים. הבעיה מתחילה בשלב הבא. אפשרות שגויה, מיפוי תיקיות גרוע או הנחה מוטעית לגבי אימות, וההעברה מסתיימת בדואר נשלח חסר, תיקיות כפולות או הודעות חדשות שנמחקו בזמן המעבר. לתהליך הרחב קראו את המדריך המעשי הזה ל-imapsync.

לכן המאמר מתמקד בכוונה באפשרויות imapsync שמשנות תוצאות: זמני המתנה, keepalive, מיפוי תיקיות, הגבלת קצב, מניעת כפילויות ואפשרויות מחיקה שעלולות לפגוע בתיבה פעילה. בהעברת חשבון אחד הן חוסכות הרצה חוזרת מבולגנת. בהעברת חמישים הן חוסכות הסבר ללקוחות מדוע תיקיית הדואר הנשלח התפצלה לשלושה עותקים.

בקצרה: הגדרות ברירת המחדל של imapsync אינן תוכנית העברה, אלא נקודת התחלה. העברה אמיתית דורשת שלבים, כללי תיקיות מפורשים ואימות לפני שינוי MX. אם היעד הוא TrekMail, אשף היבוא המובנה בתוכניות בתשלום יכול לנהל את צד הקבלה מתוך לוח הבקרה, מהר יותר מניהול ידני של כל תיבה באמצעות סקריפטים. TrekMail מתחילה ב-$3.50/month, משתמשת במאגר אחסון משותף במקום חיוב לכל משתמש ותומכת ביבוא IMAP בצד השרת מ-Gmail, Outlook, Yahoo, iCloud ושירותי IMAP כלליים.

מדוע imapsync נשברת כאשר סומכים על ברירות המחדל

imapsync מעתיקה דואר בין מאגרי IMAP פעילים, לא בין קבצים שטוחים. עליה להתמודד עם היררכיות תיקיות שונות, מאפייני שרת, מזהי הודעות ושיטות אימות בזמן שהרשת עלולה לקטוע את החיבור. לכן פקודות בטוחות תמיד מפורטות יותר מדוגמאות שמעתיקים מפורומים.

התקלות הנפוצות פשוטות ויקרות:

העלאת הודעות גדולות מגיעה לזמן הקצוב.
שמות תיקיות ממופים באופן שגוי והמשתמשים חושבים שהדואר נעלם.
הספק מגביל את המשימה ומתחיל לסרב לחיבורים.
אימות מודרני חוסם סיסמאות רגילות.
שינויים במצב UID יוצרים כפילויות בהרצות מאוחרות.
`--delete2` מוחקת דואר חדש מהיעד לאחר המעבר.

אם הייתה לכם העברה ש"הייתה בסדר חוץ מ-Sent Items", זה לא היה אקראי. הפרוטוקול אפשר את הבעיה, והגדרות ברירת המחדל לא הגנו מפניה.

אפשרויות חיבור ששומרות על imapsync פעילה

בתיבות גדולות imapsync נכשלת בדרך כלל משום שהחיבור מת לפני סיום כתיבת ההודעה. פעולות APPEND ארוכות, שרתי Exchange איטיים וחומות אש עם מעקב מצב הם הגורמים הרגילים. הפתרון הוא להאריך את הזמן הקצוב, לשלוח keepalive ולשמור מצב במטמון כדי שהרצה חוזרת לא תתחיל מאפס.

בהרצה הרצינית הראשונה השתמשו באפשרויות הבאות:

imapsync \
  --host1 imap.source.tld --user1 user@source.tld --passfile1 ./pass1 \
  --host2 imap.dest.tld   --user2 user@dest.tld   --passfile2 ./pass2 \
  --timeout 120 \
  --keepalive1 --keepalive2 \
  --usecache

תפקיד כל אפשרות:

אפשרות	מדוע היא חשובה	מה מתקלקל בלעדיה
`--timeout 120`	נותנת להעלאות איטיות ולקבצים גדולים זמן להסתיים.	הודעות מדולגות לאחר תום זמן החיבור.
`--keepalive1 --keepalive2`	משאירה את שני חיבורי IMAP פעילים בזמן המתנה ארוכה.	חומות אש או מאזני עומס מנתקים את החיבור.
`--usecache`	שומרת מקומית את מצב השוואת ההודעות להרצה חוזרת מהירה.	המשך הפעולה נעשה איטי ובודק הכול מחדש.

המטמון חשוב מפני שהעברה טובה היא הדרגתית. מריצים שלב עיקרי, מתקנים בעיות אימות או מיפוי ואז מריצים שלב השלמה אחד או שניים. עם `--usecache` imapsync משקיעה פחות זמן בקריאה מחדש של שני הצדדים. בלעדיה כל הרצה חוזרת כבדה מהנדרש.

יש הסתייגות. התיעוד הרשמי מזהיר ש-`--usecache` אינו בטוח בחלק מהשילובים של סינון לפי גודל וגיל. אל תוסיפו מסננים אקראיים רק מפני שהם נשמעים יעילים. שמרו על השלב הראשון פשוט.

אפשרויות מיפוי שמונעות בהלה של "תיקייה חסרה"

כאשר משתמשים אומרים ש-imapsync איבדה תיקיות, הדואר בדרך כלל עדיין קיים. היעד פירש את נתיב המקור אחרת, או שתיקייה מיוחדת מקומית לא מופתה לתיקיית הדואר הנשלח הפעילה. כאשר הספקים אינם מסכימים, imapsync זקוקה לתרגום מפורש.

שתי המלכודות הגדולות הן מפרידי היררכיה ותיקיות מיוחדות.

שרתים מסוימים משתמשים בנקודות לקינון ואחרים בקווים נטויים. אם המקור כולל INBOX.Clients.ProjectA והיעד מצפה ל-INBOX/Clients/ProjectA, צריך לשכתב את הנתיב בזמן ההעתקה.

imapsync \
  --host1 old.example.com --user1 user@old.example.com --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@example.com --passfile2 ./pass2 \
  --regextrans2 's/\./\//g'

גם לתיקיית הדואר הנשלח יש שמות שונים. למשתמשים חשוב רק שהודעותיהם יופיעו בתצוגת הדואר הנשלח הפעילה.

תיקיית מקור	תיקיית יעד	אפשרות שימושית
`[Gmail]/Sent Mail`	`Sent Items`	`--regextrans2 's/^\[Gmail\]\/Sent Mail/Sent Items/'`
`Sent`	`Sent Items`	`--regextrans2 's/^Sent/Sent Items/'`
`Gesendete Elemente`	`Sent Items`	`--regextrans2 's/^Gesendete Elemente/Sent Items/'`

בתיבה עם תיקיות מיוחדות תקניות נסו תחילה --automap. בתיבות cPanel מבולגנות, מקומיות או ישנות, המרות regex מפורשות בטוחות יותר. ל-TrekMail יש גם מדריכים לפי מקור בנושא התחלת יבוא בלוח הבקרה והכנת היעד באמצעות הוספת דומיין.

דוגמה רעיונית: התיקייה לא נעלמה. היא עברה מהתיקייה הצפויה לשם גולמי של ארכיון שהיישום אינו מזהה כ"דואר נשלח". אותם נתונים במקום הלא נכון יוצרים אותה פניית תמיכה.

הגבילו את imapsync לפני Google או Microsoft

imapsync עלולה להיראות כתעבורה פוגענית לספקי דואר. רצפים מהירים של פקודות APPEND ו-FETCH בתיבות רבות מפעילים מגבלות קצב, השעיות זמניות או שגיאות שנראות כמו כשל אימות אך נובעות ממגבלת קיבולת. קצב איטי ויציב לעיתים מהיר יותר מחסימה.

בעבודה מול Google Workspace או Microsoft 365, שלטו בקצב:

imapsync \
  --host1 imap.gmail.com --user1 user@source.tld --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@dest.tld --passfile2 ./pass2 \
  --maxbytespersecond 500000 \
  --maxmessagespersecond 2

הדבר מפחית קפיצות תעבורה שמפעילות הגנות, וגם מונע עומס של הודעות קטנות בסביבה משותפת. זה חשוב בשרתי cPanel ישנים ובחשבונות Office 365 עמוסים.

אל תתייחסו למספרים כערכים מוחלטים, אלא כנקודת התחלה. הגבול הנכון תלוי בגודל התיבה, במקביליות ובסובלנות הספק למשימות IMAP ארוכות. הכלל פשוט: אם ההעברה מתחילה היטב ואז מתדרדרת לשגיאות מזדמנות, האטו לפני שתניחו שהסיסמה שגויה.

כאן מתברר גם ההבדל בין הדרך הישנה לחדשה.

הדרך הישנה: לכתוב סקריפט לכל תיבה, לכוון מגבלות בניסוי וטעייה ולשמור על הכשלים בשעה 2 בלילה.

הדרך החדשה: להשתמש ביבוא המובנה בצד השרת של TrekMail בתוכניות בתשלום, לשמור על יעד אחיד ולהימנע מתמחור לכל משתמש. לסוכנויות עם דומיינים רבים חשוב יותר לא לבזבז שלושה ימים על ניסיונות חוזרים מאשר לסיים תיבה אחת עשר דקות מוקדם יותר. אם זו סביבתכם, קראו את המדריך לאחסון דוא"ל למספר דומיינים.

אפשרויות אימות עבור 2025-2026: הסיסמה מפסידה ו-OAuth מנצח

ב-Google Workspace וב-Microsoft 365 כבר אי אפשר להניח שאימות IMAP בשם משתמש וסיסמה יעבוד. Google מציינת שהחל מ-1 במאי 2025, חשבונות Workspace אינם תומכים עוד ב"יישומים פחות מאובטחים" שנכנסים רק כך. גם ההנחיות של Exchange Online מפנות לקוחות IMAP אל OAuth.

הדבר משנה את אופן הפעלת imapsync. אם המקור תומך ב-XOAUTH2, נדרש אסימון גישה במקום הסיסמה הרגילה של המשתמש.

imapsync \
  --host1 outlook.office365.com \
  --user1 user@source.tld \
  --authmech1 XOAUTH2 \
  --oauthaccesstoken1 "ACCESS_TOKEN" \
  --host2 imap.trekmail.net \
  --user2 user@dest.tld --passfile2 ./pass2

ב-Google Workspace, סיסמאות יישומים עדיין עשויות להיות חלופה מעשית להעברה חד פעמית כאשר אימות 2-Step מופעל. ב-Microsoft 365 השתמשו בתהליך OAuth המתועד לפרוטוקולים ותיקים. אם הסקריפט עדיין מניח ש"סיסמה נכונה פירושה אימות נכון", הוא אינו מתאים למציאות הנוכחית.

מקורות מוסמכים: הנחיות Google Workspace ליישומים פחות מאובטחים והוראות Microsoft ל-OAuth עבור IMAP.

אפשרויות שלמות שמונעות דילוג על דואר פגום

חלק מההודעות פגומות, וזה רגיל בשרתים ישנים. כותרות Message-ID חסרות, MIME פגום, קבצים מצורפים ענקיים וגופי הודעה ריקים מופיעים בהעברות אמיתיות. imapsync יכולה לעקוף חלק מהבעיות אם מנחים אותה.

האפשרות השימושית הראשונה היא --addheader. לפי התיעוד הרשמי היא מוסיפה כותרת Message-Id שנוצרה כאשר היא חסרה. זה חשוב מפני שזהות ההודעה קובעת מה כבר קיים.

השנייה היא --maxsize. אם תיבת היעד או המדיניות דוחה הודעות גדולות, אין לאפשר להודעה חריגה אחת לעכב את כל המשימה.

imapsync \
  --host1 old.example.com --user1 user@old.example.com --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@example.com --passfile2 ./pass2 \
  --addheader \
  --maxsize 35000000

אין כאן התעלמות מהודעות גדולות. מעבירים קודם את 99%, ואז מטפלים בחריגים ידנית לפי רשימה מבוקרת.

בפריסה מקבילה של תיבות רבות, שלבו זאת בתהליך הקצאה נקי. כדאי לקרוא את מדריך TrekMail על יצירת חשבונות דוא"ל בכמות, מפני שבעיות גדלות כאשר יצירת תיבות, מסירת סיסמאות ושינויי DNS מתנהלים בגיליונות שונים.

האפשרות המסוכנת ביותר ב-imapsync: --delete2

`--delete2` מורה ל-imapsync להסיר מהיעד הודעות שאינן קיימות במקור. זה נשמע מועיל לשיקוף מדויק, אך בזמן הלא נכון זו הדרך הקלה ביותר למחוק דואר חדש ותקין לאחר שינוי MX.

רצף הכשל:

מעבירים מראש דואר ישן מהמקור ליעד.
משנים MX לספק החדש.
דואר חדש מתחיל להגיע ליעד.
מריצים שוב imapsync עם --delete2.
imapsync מזהה דואר שקיים רק ביעד ומוחקת אותו כי לא היה במקור.

זו אינה תקלה, אלא בדיוק ההוראה שנתתם.

השתמשו ב-`--delete2` רק בשיקוף מבוקר לפני המעבר, כאשר שני הצדדים עדיין קשורים למקור האמת הישן. לאחר שינוי MX הסירו אותה מהפקודה. אם היעד פעיל ומקבל דואר, התייחסו אליו כמקור המוסמך להודעות חדשות.

כאשר UIDs מטעים, השתמשו בהתאמה לפי כותרות

UIDs של IMAP אמינים רק בתוך מצב השרת שאליו הם שייכים. RFC 3501 מגדיר UIDVALIDITY מפני שהנחות UID נשברות כאשר מצב התיבה משתנה. אם תיקיית מקור נבנית או מאונדקסת מחדש, imapsync עלולה לחשוב שכל הודעה חדשה ולשכפל את כולן בהרצה מאוחרת.

במצב כזה התאמה לפי כותרות עוזרת:

imapsync \
  --host1 old.example.com --user1 user@old.example.com --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@example.com --passfile2 ./pass2 \
  --useheader 'Message-Id'

השיטה איטית יותר מהסתמכות על UIDs של השרת, אך בטוחה יותר כאשר המקור אינו יציב, נבנה מחדש או אינו עקבי. התיעוד הרשמי מציין שבעיות כפילות נפתרות לעיתים באמצעות --useheader "Message-Id".

לאימות הסופי עדיף לבצע הרצה יבשה עם התאמה שמרנית לפני שינוי DNS, ואז סנכרון הפרשים קצר לאחר שהמשתמשים מפסיקים לכתוב במערכת הישנה.

תבנית בטוחה לפקודת imapsync

הרצה בטוחה מגדירה במפורש חיבור, מיפוי, החרגות ומצב בדיקה. התחילו בהרצה יבשה, אשרו את התנהגות התיקיות ורק אז הפעילו את ההעברה האמיתית. אל תנסו טיוטת פקודה ראשונה על דואר ייצור.

imapsync \
  --host1 imap.gmail.com --user1 user@source.com --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@dest.com --passfile2 ./pass2 \
  --timeout 120 --keepalive1 --keepalive2 \
  --usecache \
  --automap \
  --regextrans2 's/^\[Gmail\]\/Sent Mail/Sent Items/' \
  --exclude '^\[Gmail\]/All Mail' \
  --maxbytespersecond 500000 \
  --maxmessagespersecond 2 \
  --dry

שלוש הערות מעשיות:

השתמשו תמיד קודם ב---dry.
החריגו תיקיות ארכיון ענקיות שאינן דרושות בשלב הראשון.
שמרו את היומן ונהלו גרסאות של שורות הפקודה לכל קבוצת העברה.

לאחר שהתיבה מגיעה ל-TrekMail, המשתמשים מתחברים ב-IMAP רגיל אל imap.trekmail.net ביציאה 993. TrekMail היא IMAP בלבד ולא POP3, בחירה נכונה לסנכרון מצב בין מכשירים.

סיכום: imapsync פועלת היטב כאשר מנהלים אותה ככלי העברה

imapsync עדיין מתאימה להעברות דוא"ל רבות, בתנאי שמתייחסים אליה כתוכנת העברה עם מצב ולא כפקודת העתקה פשוטה. הגדירו זמני המתנה, השתמשו ב-keepalive, מפו תיקיות בכוונה, האטו כשהספק מגביל, השתמשו באימות מודרני והרחיקו את `--delete2` מדואר שלאחר המעבר. כאשר מצב UID חשוד, כפו התאמה לפי כותרות.

לניהול פשוט יותר של צד הקבלה, TrekMail מספקת יעד למספר דומיינים במחיר קבוע, עם מאגר אחסון משותף, יבוא מובנה בצד השרת בתוכניות בתשלום וללא תוספת לכל תיבה. לאחר המעבר, מומלץ להמשיך למאמר על דוא"ל לעסקים.