כדי להעביר תיבת דואר אחת לספק חדש, לפעמים מספיק טופס עם שישה שדות. העברה מרוכזת של מאה תיבות היא בעיה אחרת, ולא רק בגלל הכמות. יש יותר הזדמנויות לתקלה שלא תבלוט לעין: סיסמה שגויה, שרת מקור שמתחיל להגביל בקשות אחרי החיבור הארבעים, או תיקייה שבה הועתקו רק 4,000 הודעות מתוך 12,000 ובכל זאת מוצגת כהושלמה.
קובץ CSV פותר את העבודה החוזרת: קובץ אחד, משימה מרוכזת אחת, עיבוד במקביל ומעקב אחר כל תיבה. אבל הצלחת ההעברה נקבעת לפי הבדיקות שנעשות אחרי שפסי ההתקדמות מגיעים לסוף. לא כל כלי בודק מה באמת הגיע ליעד.
כאן נסביר את מבנה הקובץ, את בדיקת השורות לפני פתיחת החיבורים, את מהלך המשימה ואת ההשוואה לאחר העתקת ההודעות.
לפני שמכינים CSV להעברה מרוכזת
יש שני תנאים מוקדמים. דילוג על אחד מהם עלול לבזבז ערב שלם.
תיבות היעד צריכות להיות קיימות מראש. ההעברה מעתיקה הודעות לתיבות, ואינה יוצרת את התיבות עצמן. אם אתם מכינים תיבות למאה אנשים, השתמשו קודם ביצירה מרוכזת: העלו CSV עם סיסמאות שקבע מנהל המערכת, או שלחו הזמנות כדי שכל אחד יבחר סיסמה בעצמו.
אין צורך בסיסמאות של תיבות היעד. האימות לתיבות שבחשבון שלכם מתבצע בתוך השירות. לכן ה-CSV מכיל רק את פרטי הגישה למקור. כלים אחרים עשויים לבקש פרטים לשני הצדדים. קובץ כזה דורש הגנה קפדנית במיוחד, אבל עצם הבקשה אינה הוכחה לשימוש לרעה.
מבנה הקובץ להעברה מרוכזת
שלוש עמודות מספיקות אם כל החשבונות נמצאים אצל אותו ספק. הגדרות השרת נלקחות מהספק שבחרתם בטופס:
source_email,source_password,destination_email
alice@oldhost.com,app-pw-1,alice@yourdomain.com
bob@oldhost.com,app-pw-2,bob@yourdomain.com
שש עמודות מאפשרות לשלב מקורות שונים, למשל לאחר רכישת חברה שחלק מהצוות שלה משתמש ב-Google Workspace וחלק בשרת cPanel. הדוגמאות אינן מעידות שהספק מאפשר כניסה באמצעות סיסמה:
source_email,source_password,destination_email,source_host,source_port,source_security
alice@gmail.com,app-pw-1,alice@yourdomain.com,imap.gmail.com,993,ssl
bob@outlook.com,app-pw-2,bob@yourdomain.com,outlook.office365.com,993,ssl
carol@oldhost.com,pw-3,carol@yourdomain.com,mail.oldhost.com,993,ssl
בקריאת הקובץ מזוהים כמה מבנים נפוצים, משום שקבצים כאלה מוכנים גם ידנית וגם באמצעות ייצוא מתוכנות שונות:
| כלל | פירוט |
|---|---|
| גודל הקובץ | עד 2 MB |
| קידוד | שמרו ב-UTF-8; קידודים שאינם נתמכים נדחים במקום לשנות נתונים בלי להתריע |
| שורת כותרות | אינה חובה ומזוהה אוטומטית |
| מפריד | פסיק, טאב או נקודה-פסיק, מזוהים אוטומטית |
| שורות ריקות | מדלגים עליהן |
| הערות | מדלגים על שורות שמתחילות ב-# |
| כתובות | מומרות לאותיות קטנות; רווחים בתחילת הכתובת ובסופה מוסרים |
| שורות למשימה | המאמר המקורי מציין 100 ב-Starter, 300 ב-Pro ו-1,000 ב-Agency; בדקו את המגבלות העדכניות |
התמיכה בנקודה-פסיק חשובה כשמשתמשים ב-Excel. בהתאם להגדרות האזור, התוכנה עשויה לבחור בה כמפריד בייצוא CSV. כלי שמזהה רק פסיקים עלול לקרוא את כל השורה כעמודה אחת.
היזהרו בגיליונות אלקטרוניים: סיסמה שמתחילה ב-=, ב-+ או ב-- עלולה להתפרש כנוסחה ולהשתנות בשמירה. הכינו את הקובץ בעורך טקסט, או הגדירו במפורש את עמודת הסיסמאות כטקסט בזמן הייבוא ובדקו את הקובץ שיוצא. מירכאות סביב הערך ב-CSV, כשלעצמן, אינן מבטיחות שהסיסמה תישמר ללא שינוי.
איסוף פרטי הגישה למקור הוא לרוב החלק המורכב
לכל תיבה דרושה גישת IMAP פעילה למקור. ה-CSV הזה משתמש בסיסמאות, אבל לא כל ספק מאפשר את שיטת האימות הזאת. בדקו תאימות לפני שאתם אוספים פרטי גישה.
| מקור | הגישה הדרושה |
|---|---|
| Gmail / Google Workspace | סיסמת אפליקציה, אם החשבון ומדיניות מנהל המערכת מאפשרים זאת; נדרש אימות דו-שלבי (2-Step Verification) |
| Microsoft 365 | אי אפשר עוד להפעיל מחדש אימות בסיסי ל-IMAP ב-Exchange Online. דרוש תהליך נתמך עם OAuth או דרך מתאימה אחרת; קובץ הסיסמאות הזה אינו תחליף להם |
| Yahoo, AOL, iCloud | סיסמת אפליקציה כאשר הספק והחשבון מאפשרים גישה כזאת |
| cPanel ואחסון מסורתי | סיסמת התיבה, אם השרת תומך באימות IMAP באמצעות סיסמה |
איסוף מאה סיסמאות אפליקציה ממאה אנשים עשוי להיות עיקר העבודה. קחו זאת בחשבון לפני שאתם מתחייבים למועד. אם יש לכם הרשאות ניהול במקור, בדקו אילו דרכי גישה זמינות והאם אפשר ליצור פרטי גישה באופן מרוכז. אחרת, שלחו הוראות עם צילומי מסך והקצו זמן לעזרה למי שזקוק לה.
מחקו את ה-CSV לאחר ההעברה, כאשר הוא כבר אינו נחוץ לבדיקות או לסבב נוסף. הוא מכיל פרטי גישה פעילים. נהלו גם את העותקים שלו ובטלו סיסמאות זמניות ככל האפשר.
בדיקה לפני החיבור
הדביקו את הנתונים או העלו את הקובץ ולחצו על תצוגה מקדימה ובדיקה. השורות מסווגות לפני שנפתחים חיבורי ההעברה:
- מוכנות: עברו את הבדיקה הראשונית ואפשר להוסיף אותן לתור.
- שגיאות: כתובת לא תקינה, סיסמה חסרה או תיבת יעד שאינה קיימת. מדלגים על שורות אלה.
- אזהרות: בוצעה לאחרונה העברה ליעד הזה; בדקו את הסיכון לייבוא כפול.
- כפילויות: אותו צמד של מקור ויעד מופיע בקובץ יותר מפעם אחת.
- חריגה מהמגבלה: שורות מעבר למספר המותר במשימה לפי החבילה שלכם.
תקנו את הקובץ וחזרו על התצוגה המקדימה לפי הצורך. בשלב הזה לא מתחילה העתקה, והבדיקה אינה מוכיחה שהסיסמאות פועלות. ההתראה «תיבת היעד לא נמצאה» מועילה במיוחד: טעות בשם הדומיין יכולה להשפיע על מאה שורות, ואחרת הייתה מתגלה רק בזמן החיבור.
הגדרות חשובות להעברה מרוכזת
התיקיות הכלולות. כל התיקיות, רק התיקיות הרגילות (דואר נכנס, דואר שנשלח, טיוטות, אשפה, ארכיון וספאם), או דואר נכנס בלבד. התיקיות הרגילות עשויות לעזור להימנע מתצוגות וירטואליות ומתוויות שמציגות אותה הודעה כמה פעמים. הן אינן מספיקות אם צריך לשמור תיקיות מותאמות אישית. קבעו את ההיקף הדרוש לפני ההתחלה.
ייבוא החל מתאריך. התאריך המוקדם ביותר להודעות. העתקת שנתיים במקום אחת עשרה שנים מקטינה את הכמות, אך מוציאה מההעברה הודעות ישנות יותר. הסכימו עם הצוות מה חייב להישמר ומה יועבר בנפרד אם יהיה צורך.
דילוג על כפילויות. השאירו את האפשרות פעילה בסבבים הבאים. היא עוזרת לא לייבא שוב הודעות שזוהו, אבל אינה מבטיחה שלא יהיו כפילויות בכל מצב, למשל כשאין מזהים שאפשר להשתמש בהם.
שם המשימה. בחרו שם ברור. בעוד שלושה שבועות, «Acme, שלב 2» יהיה שימושי יותר מחותמת זמן.
מה קורה בזמן העברה מרוכזת
חשבונות מעובדים במקביל בתוך מגבלות החבילה. המקור מציין 2 ב-Starter, 5 ב-Pro ו-10 ב-Agency; בדקו את ההגדרה הנוכחית. ספקי המקור עשויים להגביל חיבורים ובקשות. ארבעים חיבורי IMAP בו-זמנית מאותה כתובת עלולים לגרור הגבלה או חסימה זמנית, אך התגובה משתנה בין ספקים.
כל חשבון עובר דרך המתנה בתור, התחלה, בדיקה, תכנון וייבוא עם אחוזי התקדמות, ולבסוף מסתיים בהשלמה, בכישלון או בביטול. אפשר לסגור את הדף; העבודה ממשיכה בשרת.
במהלך העבודה זמינות שלוש פעולות:
- ביטול הכול מבקש לעצור חשבונות פעילים וממתינים. הודעות שכבר יובאו אינן נמחקות.
- ניסיון חוזר לנכשלים מחזיר לתור רק חשבונות שנכשלו. אם הסיבה הייתה סיסמת מקור שגויה, תקנו אותה קודם.
- המשך מחדש משימה שהושהתה.
כשניצול האחסון בחשבון מגיע ל-90%, קיים מנגנון השהיה עם התראה בדוא״ל. הוא מפחית את הסיכון שהמקום ייגמר באמצע ההעתקה, אבל אינו מבטיח קיבולת מספקת לכל מה שנותר. פנו מקום או הגדילו את הקיבולת, בדקו תוצאות חלקיות ואז המשיכו.
תקבלו הודעה גם בסיום המשימה והתראה נפרדת אם יותר ממחצית החשבונות נכשלו. דפוס כזה יכול להצביע על גורם משותף, כמו הגבלה אצל ספק המקור, במקום חמישים בעיות עצמאיות. צריך לבדוק את השגיאות כדי לוודא זאת.
הבדיקה אחרי פס ההתקדמות
זה סיכון שכדאי לבחון כשבוחרים כלי להעברת דואר.
העתקה ב-IMAP מורכבת מהרבה פעולות בודדות. ניתוק חיבור, הגבלה באמצע תיקייה או רשימה לא מלאה שהמקור החזיר עלולים להשאיר הודעות מאחור. הכלי עשוי לעבד את כל המידע שקיבל ולדווח על הצלחה. הפס מגיע ל-100%, הכול נראה תקין על המסך, ובכל זאת עלולות להיות חסרות ארבעת אלפים הודעות.
לכן קיימת בדיקת השוואה נוספת. אם ההשוואה האוטומטית פעילה וההעברה עוברת את סף מספר ההודעות שהוגדר, מתוזמן סבב נוסף בהשהיה של חמש דקות; התור עשוי לדחות את תחילתו בפועל. הבדיקה משווה את קבוצות ה-Message-ID הייחודיים במקור וביעד, תיקייה אחר תיקייה. כותרת זו נשמרת בדרך כלל בהעתקה, אבל היא יכולה להיות חסרה או לשמש שוב. לכן ההשוואה אינה מוכיחה את קיומה של כל הודעה או את שלמות כל התוכן שלה. כיסוי לא מספיק עלול להותיר תוצאה שאינה חד-משמעית.
כאשר מאושר שחסרות הודעות, קיימות שלוש פעולות:
- דוח על ההודעות והתיקיות הרלוונטיות נשמר ברשומת ההעברה.
- תיקיות לא מלאות מסומנות כ-הועברו חלקית, כדי שהמשך העבודה יוכל לעבד אותן שוב במקום לדלג עליהן כמושלמות.
- נשלחת הודעה עם התיקיות, מספר ההודעות החסרות שנמצאו והצעדים הבאים.
הבדיקה כוללת רק תיקיות שנכללו בתוכנית ההעברה. תיקיות שהוצאו במכוון אינן מדווחות כחסרות בגלל ההוצאה עצמה. למשל, כל הדואר ב-Gmail מכיל הודעות שמופיעות גם תחת תוויות אחרות ועשוי לכלול דואר שהועבר לארכיון. ודאו שהבחירה מכסה את ההודעות הדרושות.
התראה על העברה לא מלאה אינה נעימה, אבל מאפשרת לפעול כל עוד המקור קיים. זה עדיף על גילוי בנובמבר שחשבונית ממרץ נשארה מאחור. גם דוח ללא חוסרים שזוהו אינו מחליף בדיקת כיסוי ובדיקות ידניות.
סדר המעבר לספק החדש
ההעתקה היא רק חלק מהעבודה. סדר הפעולות סביב המעבר קובע אילו סיכונים צריך לנהל.
- צרו את תיבות היעד ובדקו שאפשר להיכנס אליהן.
- בצעו את סבב ההעברה הראשון בזמן שרשומות MX עדיין מפנות לספק הישן. המקור נשאר בשימוש; הגנו על פרטי הגישה והימנעו מהפסקת השירות.
- בדקו את התוצאה. קראו את הדוח ואת הכיסוי שלו ופתחו כמה תיבות: תיקיות, כמויות וההודעות הישנות והחדשות ביותר.
- שנו את רשומות MX לאחר שהפחתתם את TTL יום או יומיים קודם. משך TTL הישן צריך לחלוף; השינוי אינו חל מיד אצל כל השולחים.
- בצעו סבב שני עם דילוג על כפילויות כדי לאסוף הודעות שהגיעו למקור בזמן המעבר. לפי המטמונים וזרימת הדואר בפועל, ייתכן שיידרשו בדיקות או סבבים נוספים.
- השתמשו בחודש של שמירת התיבות הישנות כנקודת מוצא לתכנון. התאימו את התקופה לחובות השמירה ולתוצאות הבדיקות. אל תבטלו את המקור לפני אישור ההעברה: לאחר המחיקה ייתכן שלא יהיה אפשר להעתיק שוב.
אם אתם ממשיכים להשתמש בספק הישן, תיבת דואר נכנס מאוחדת יכולה להיות חלופה להעברה; השוו יכולות ועלויות. הוראות לפי ספק נמצאות בתיעוד של Google Workspace, Microsoft 365 ו-cPanel. בדקו ששיטת הגישה המתוארת עדיין זמינה.
שאלות נפוצות
כמה תיבות אפשר להעביר במשימה אחת?
המקור מציין 100 למשימה ב-Starter, 300 ב-Pro ו-1,000 ב-Agency. בתוך המשימה מעובדים במקביל בין 2 ל-10 חשבונות לפי החבילה. בדקו את המגבלות הנוכחיות ואת מגבלות המקור. התקרות מפחיתות עומס, אך אינן מבטלות מגבלות אחרות.
האם צריך את סיסמאות תיבות היעד?
לא. ה-CSV מכיל רק את פרטי הגישה למקור; האימות לתיבות שבחשבון שלכם מתבצע בתוך השירות.
אפשר להריץ שוב בלי ליצור עותק של כל הודעה?
הפעילו דילוג על כפילויות. סבבים נוספים מנסים להשלים הודעות חסרות בלי להעתיק שוב את אלה שזוהו. זה מועיל אחרי שינוי MX, אבל בדקו את התוצאה, במיוחד כשיש הודעות ללא מזהים שימושיים.
מה קורה אם סיסמת המקור שגויה?
החשבון הזה נכשל, והאחרים יכולים להמשיך. תקנו את הסיסמה והשתמשו ב-ניסיון חוזר לנכשלים כדי להחזיר לתור רק את הנכשלים. אם הספק דורש שיטת אימות אחרת, שינוי סיסמה לא יספיק.
האם התיקיות ומצב הקריאה נשמרים?
ההעברה מנסה לשמור תיקיות וסימונים כמו נקרא או מסומן בכוכב, לפי ההיקף שנבחר ויכולות היעד. תוויות Gmail אינן תואמות בדיוק לתיקיות IMAP. בחירה בתיקיות הרגילות בלבד מפשטת חלק מהמקרים, אך עלולה להוציא תיקיות מותאמות או הודעות מהארכיון. בדקו מה חייב לעבור.
איך בודקים שלא נשארו הודעות שלא הועברו?
אם ההשוואה פעילה ותנאיה מתקיימים, היא משווה Message-ID ייחודיים בשני הצדדים. חוסרים מאושרים מדווחים והתיקיות הרלוונטיות מסומנות כהועברו חלקית. בדקו גם את הכיסוי: ההשוואה אינה מוכיחה את קיומן של הודעות ללא מזהים שימושיים. השוו כמויות, פתחו את ההודעות הישנות והחדשות ביותר בכל תיקייה והוסיפו בדיקות אם הדואר חיוני במיוחד.
אפשר לנהל את ההעברה דרך API?
אפשר לנהל פעולות נתמכות דרך REST API או סוכן AI המחובר ב-MCP, עם ההרשאות הדרושות. בדקו אילו פעולות כל ממשק תומך בהן בפועל, במיוחד משימות מרוכזות וניסיונות חוזרים, בתיעוד של העברות דרך API.
כמה זמן כדאי להקצות?
הזמן תלוי בנפח, במספר ההודעות, בביצועים של שני הצדדים ובמגבלות המקור. המקור מציע כמה שעות לצוות קטן ולילה לצוות גדול כהערכה לתכנון, לא כמשך מובטח. בצעו ניסיון והתחילו את ההעתקה הראשונה לפני שינוי MX. כך אפשר להתאים את לוח הזמנים בלי למהר במעבר.