כלי להעברת תיבות דואר: רשימת השוואה לשנת 2026

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

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

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

מהו כלי להעברת תיבות דואר?

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

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

ארבע הבדיקות שבאמת חשובות

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

1. ניהול מצב

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

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

2. מיפוי תיקיות

היסטוריית הדואר נעשית חסרת תועלת כששמות התיקיות אינם תואמים. מערכת אחת משתמשת ב-“Sent Messages” ואחרת מצפה ל-“Sent Items”. Gmail מוסיפה תיקיות מיוחדות ול-Exchange יש הנחות משלו. הכלי זקוק לנרמול תיקיות או למיפוי באמצעות ביטויים רגולריים, ולא להתנהגות של העתקה עיוורת.

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

3. הגבלת קצב ולוגיקת ניסיונות חוזרים

עבודה בכמויות גדולות מגיעה במהירות למגבלות הספק. Google מתעדת מגבלת הורדת IMAP יומית של 2,500 MB לכל חשבון, ו-Microsoft מתעדת הגבלות שעשויות להאט או לחסום תעבורת העברה כבדה. הכלי חייב לזהות את האותות האלה ולהאט אוטומטית, במקום לנסות שוב ושוב מול אותה מגבלה.

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

4. אימות מודרני

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

אין פירוש הדבר שכל העברת IMAP חייבת להשתמש ב-OAuth מתחילתה ועד סופה. פירוש הדבר שיש לבדוק כיצד הכלי מאמת את עצמו מול המקור ומה קורה כשהספק חוסם שיטות ישנות. צוות Exchange של Microsoft הודיע על הוצאת ApplicationImpersonation משימוש ב-Exchange Online ואישר שחלון ההסרה הסתיים בפברואר 2025.

טבלת הערכה לכלי העברת תיבות דואר

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

אם כלי טוען לשיעור הצלחה של 99% אך אינו יכול להראות אילו פריטים נמצאים ב-1% שנכשלו, המספר חסר תועלת. רישום ביומן אינו תוספת נחמדה. הוא ההבדל בין השלמת המשימה לבין ניחוש.

איך לבדוק כלי לפני שמתחייבים אליו?

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

1. הריצו תיבת פיילוט עם היסטוריית תיקיות אמיתית, ולא חשבון בדיקה ריק.
2. אמתו את מספר הפריטים בכל תיקייה, ולא רק את נפח האחסון הכולל.
3. בדקו שהדואר שנשלח מגיע לתיקיית נשלח בפועל ביעד.
4. שלחו הודעה חדשה לתיבת המקור והריצו את המשימה שוב.
5. קראו את פלט השגיאות וודאו שכל הודעה שדולגה מצוינת בנפרד.

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

דואר נכנס במקור: 4,102 פריטים
דואר נכנס ביעד: 4,102 פריטים

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

איזה כלי מתאים לכל משימה?

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

העברות קטנות ומדויקות

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

imapsync \
  --host1 old.example.com --user1 old@example.com --password1 'source-pass' \
  --host2 imap.trekmail.net --user2 new@example.com --password2 'dest-pass' \
  --automap \
  --exclude "\\[Gmail\\]/All Mail" \
  --syncinternaldates \
  --nofoldersizes

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

פרויקטים גדולים לסוכנויות או לספקי שירות מנוהל

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

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

הדרך של TrekMail

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

ההבדל בין הדרך הישנה לחדשה ברור.

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

הדרך החדשה: לעבור לפלטפורמה הבנויה על אחסון משותף ותמחור קבוע. תוכנית Starter של TrekMail מתחילה ב-$3.50 לחודש, כלי ההעברה כלול בתוכניות בתשלום, מוצעת תקופת ניסיון חינמית של 14 יום, ועדיין קיימת תוכנית חינמית באמת ללא כרטיס וללא תקופת ניסיון. המחירים מופיעים בדף התמחור של TrekMail.

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

מה הייבוא המובנה של TrekMail עושה היטב?

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

תיעוד המוצר מבהיר את הגבולות. TrekMail מייבאת דוא״ל ותיקיות שנבחרו, שומרת על מצב הקריאה כאשר המקור מספק אותו, ואינה מייבאת אנשי קשר, לוחות שנה, מסננים או כללים. הכנות הזאת חשובה. כלי טוב מסביר מה לא יעשה לפני תחילת הפרויקט, ולא אחרי שהמעבר נכשל. תיעוד רלוונטי: ייבוא מ-Gmail ויצירת תיבת דואר.

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

מסגרת ההחלטה הסופית

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

אם אתם משווים אפשרויות, השתמשו במסנן הזה:

1. פסלו כל כלי שאינו יכול לפעול שוב בבטחה וללא שכפול.
2. פסלו כל כלי שאינו יכול למפות תיקיות באופן צפוי.
3. פסלו כל כלי שמסתיר כשלים ברמת הפריט.
4. פסלו כל כלי שמניח ששיטות אימות ישנות עדיין פועלות בכל מקום.
5. העדיפו דרך שמשפרת גם את עלויות התפעול לטווח ארוך, ולא רק את ההעברה הנוכחית.

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

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