העברת IMAP בקנה מידה גדול: מדריך בטוח 2026

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

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

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

מדוע העברות IMAP מסתבכות בפועל

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

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

הבעיה השנייה היא מרחב שמות התיקיות. ספק אחד עשוי לפרש `INBOX.Sent` כתיקייה מקוננת, ואחר מצפה ל-`INBOX/Sent`. Gmail מציגה גם תוויות כתיקיות דרך IMAP. גלו את המבנה ואת השמות לפני ההרצה המלאה, כדי שהבדל בנתיבים לא ייראה למשתמשים כמו ארכיון חסר.

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

בדיקה מקדימה: מפו את הנתונים לפני המעבר

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

התחילו בתיבות הגדולות: מייסדים שלא מוחקים הודעות, מחלקת כספים עם שנים של קובצי PDF ותיבות תמיכה שהפכו לארכיון. הן משפיעות על לוח הזמנים ועל עלות המכסות האישיות. תיבה של 60 GB עשויה לחייב תוכנית יקרה יותר אצל ספק מסוים. מאגר האחסון של TrekMail מאפשר לחלק קיבולת בין הצוות אם התוכנית תומכת בנפח הזה ונותר מספיק מקום; הוא אינו מבטל מכסות או מגבלות יבוא.

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

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

מעבר בבת אחת לעומת הכנה מראש

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

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

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

בדקו גם את עלות תקופת החפיפה. ב-Google Workspace או Microsoft 365 ייתכן שצריך לרכוש רישיונות יעד לפני תחילת השימוש, בהתאם לתוכנית ולחוזה. מודל TrekMail מאפשר להכין את היעד ולייבא מראש בלי תמחור לכל משתמש, אך העלות והקיבולת עדיין תלויות בתוכנית. $3.50 לחודש הוא מחיר חודשי מחושב בחיוב שנתי, לפי ההצעה והתנאים הנוכחיים. בדקו זכאות לתקופת ניסיון לתוכנית בתשלום שאורכה 14 ימים. Nano היא תוכנית נפרדת, חינמית לפי התנאים הנוכחיים וללא צורך בכרטיס בהרשמה; כל שליחה ומענה בה דורשים שרת SMTP משלכם.

נוהל מעשי להעברת IMAP מדורגת

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

1. צרו קודם דומיינים ותיבות יעד. עיינו בתיעוד TrekMail על הוספת דומיין ועל הגדרות IMAP, והעתיקו את ערכי DNS והחיבור שמוצגים לחשבון שלכם. התיעוד מציג יעד MX בשם `mail.trekmail.net` בעדיפות `10`; אמתו את ההוראות העדכניות לפני היישום.
2. בדקו את מבנה התיקיות לפני העתקת נפח גדול. אמתו את מיפוי השמות והמפרידים וטפלו מוקדם בהבדל בין נקודה לקו נטוי.
3. העתיקו את הדואר הישן לפי המיפוי שנבדק. ב-Gmail בדקו את תוכן `[Gmail]/All Mail` ו-Trash לפני החרגתם; All Mail עשויה להכיל הודעות ארכיון שאינן מופיעות בתיקייה אחרת. ודאו שההודעות הנדרשות נכללות ובחנו כיצד התוויות משפיעות על כפילויות.
4. אפשר לתכנן TTL של 300 שניות ולהנמיך אותו לפחות 24 שעות לפני המעבר כנקודת מוצא. זמן ההמתנה בפועל תלוי ב-TTL הקודם ובמטמונים, כולל תשובות שליליות; הדוגמה אינה מבטיחה שכל התשובות הישנות כבר נעלמו.
5. שנו MX, בדקו תשובות ממקורות שונים והריצו סנכרון הפרשים עם דילוג על כפילויות כשהכלי תומך בכך. עיינו בתהליך היבוא של TrekMail ובהגדרות המשימה. הדילוג מסייע לצמצם עותקים חוזרים בהרצות נוספות, אך אינו מחליף אימות הודעות וחריגות.

אמתו DNS באמצעות פקודות, לא ניחושים:

dig MX example.com +short

dig TXT example.com +short

dig TXT _dmarc.example.com +short

בהרצה ידנית של imapsync בדקו תחילה את המיפוי וההחרגות על מדגם. הדוגמה הבאה כללית ואינה מספקת את הגדרת OAuth הנדרשת ל-Exchange Online; גם החרגות Gmail דורשות בדיקה לפני שימוש. העבירו סודות במנגנון מוגן שהכלי תומך בו, כגון קובץ סיסמאות מוגן או אסימוני גישה מאושרים, ואל תחשפו סיסמאות אמיתיות בהיסטוריית הפקודות או ברשימת התהליכים.

imapsync \
  --host1 old.mailhost.tld --user1 user@example.com --password1 'SOURCE_PASS' \
  --host2 imap.trekmail.net --user2 user@example.com --password2 'DEST_PASS' \
  --ssl1 --ssl2 \
  --exclude '\[Gmail\]/All Mail|\[Gmail\]/Trash' \
  --syncinternaldates \
  --useheader 'Message-Id' \
  --skipsize

דוגמת רשומת MX למעבר, בכפוף לערכים שבהוראות הדומיין שלכם:

example.com. 300 IN MX 10 mail.trekmail.net.

Gmail, Microsoft 365 ומקרים מיוחדים

מקורות IMAP אינם מתנהגים באותו אופן. Gmail מוסיפה תוויות ומגבלות תעבורה, ו-Microsoft 365 דורשת הגדרת אימות מתאימה לאחר הסרת Basic Auth לחיבורי IMAP ב-Exchange Online. גרסאות Exchange מקומיות ישנות עלולות להיתקל באי התאמת TLS. בדקו כל סוג מקור בנפרד.

Google מפרסמת בהנחיות Workspace מגבלת הורדת IMAP יומית של 2500 MB לחשבון; בדקו את המגבלות העדכניות לפני התזמון. אל תניחו שתיבת Gmail של 20 GB תועתק ברצף אחד. התאימו קצב ועבדו בסבבים; בהתאם לנתונים, להגבלות ולניסיונות חוזרים, ההעברה עשויה להימשך כמה ימים.

ב-Microsoft 365, שם משתמש וסיסמה דרך Basic Auth אינם מספיקים לחיבור IMAP ל-Exchange Online. השתמשו בכלי שתומך ב-OAuth, עם רישום היישום, הרשאות ואסימונים שמתאימים להגדרות הארגון. בדקו גישה לפני התזמון והכינו חלופה מאושרת אם הכלי או הרשאות החשבון אינם מתאימים למקור.

דוגמה מושגית: תיבת Gmail של 12 GB עם Inbox, Project, Important ו-All Mail אינה בהכרח עץ תיקיות עצמאיות של 12 GB. התוויות עשויות להפנות לאותן הודעות, ולכן נפח היעד והכפילויות תלויים במיפוי ובאופן ההעתקה.

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

אימות: בדקו הודעות, לא רק גיגה בייט

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

השוו מקור ויעד אחרי כל סבב. אם המקור מציג 14,200 הודעות והיעד 14,195, דוח החריגות עשוי להסביר את ההפרש בחמש הודעות פגומות, אך אינו מוכיח שההעברה הושלמה. בדקו אותן, שחזרו מה שאפשר או אשרו במפורש את החריגות, ואז אמתו את שאר ההודעות. אם היעד מציג 10,000, עצרו לבדיקה; גרף אחסון דומה אינו מספיק להכרזה על סיום.

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

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

סיכום: צמצמו סיכון בלי לעכב את הפרויקט

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

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

התחילו בתיעוד והכינו את היעד לפי לוח זמנים שנבדק. אם תמחור שאינו לפי משתמש מתאים לפרויקט שלכם, בדקו את התוכניות והתנאים הנוכחיים ב-trekmail.net.