העברת דוא"ל בפועל: DNS, העתקת IMAP והמעבר לספק החדש
הביטוי "העברת דוא"ל" עלול להטעות. בעולם הפיזי, העברת קובץ פירושה שהוא עוזב את מקום א' ומגיע למקום ב'. בתשתיות דוא"ל זה לא מה שקורה.
העברת דוא"ל מורכבת למעשה משתי פעולות עצמאיות שמתבצעות במקביל: שכפול מסד הנתונים באמצעות סנכרון IMAP והפניית התעבורה באמצעות מעבר DNS. ערבוב בין שתי השכבות האלה הוא הגורם העיקרי לאובדן נתונים, לניתוב מפוצל ולפניות תמיכה שמחכות ביום שני בבוקר.
המדריך מסביר מהי "העברה" בפועל, אילו פריטים עוברים ואילו לא, וכיצד לבחור בדרך המתאימה למצב שלכם.
שלושה סוגים של העברת דוא"ל
לפני שנוגעים בשרת, חשוב להגדיר את היקף העבודה. המונח "העברה" משמש לתיאור שלוש פעולות שונות, והבלבול ביניהן גורם לבעיות ממשיות.
1. העברת דומיין (החלפת רשם)
אתם מעבירים את ניהול example.com מ-GoDaddy ל-Namecheap. הפעולה משנה את הגורם שמחייב אתכם עבור שם הדומיין. השפעה על הדוא"ל: אין, בתנאי שמעתיקים את אזור ה-DNS במדויק. אם מחליפים שרתי שמות בלי לשכפל את רשומות ה-MX, שירות הדוא"ל יפסיק לפעול מיד.
2. הגירת דוא"ל (החלפת ספק)
אתם מפסיקים להשתמש ב-Google Workspace ועוברים ל-TrekMail, או לכל ספק אירוח דוא"ל אחר. לשם כך מקימים שירות חדש, מעתיקים אליו את הנתונים הישנים ומשנים את ניתוב ה-DNS כך שהודעות חדשות יגיעו אליו. השפעה על הדוא"ל: מלאה. זהו שחזור שיטתי של הנתונים, ובו עוסק המאמר.
לתוכנית ביצוע מפורטת, עיינו במדריך לסנכרון IMAP.
3. העברת בעלות על חשבון
שינוי כתובת המנהל בחשבון מ-bob@ ל-alice@. זהו עדכון של הרשאות במסד הנתונים. השפעה על הדוא"ל: אפס.
שתי השכבות שצריך לנהל במהלך העברת דוא"ל
העברה מוצלחת מחייבת לנהל שני לוחות זמנים במקביל. תקלה בכל אחד מהם עלולה ליצור בעיות.
שכבת הנתונים (העתקה באמצעות IMAP)
ספק חדש אינו מקבל את הנתונים הישנים מעצמו. מושכים אותם דרך פרוטוקול IMAP (RFC 3501). זו העתקה, לא העברה שמוחקת את המקור. הנתונים המקוריים נשארים בשרת המקור עד שמוחקים אותם.
מלכודת UIDVALIDITY: IMAP נועד להצגת הודעות, לא לשכפול בהיקף גדול. לכל תיקייה יש ערך UIDVALIDITY. אם שרת המקור קורס או בונה מחדש את האינדקס במהלך ההגירה, הערך עשוי להשתנות. כלי ההגירה עלול לזהות את כל ההודעות כחדשות ולהוריד אותן שוב, ואז המשתמשים יראו 10,000 כפילויות. הפתרון הוא כלי שמסיר כפילויות לפי כותרות Message-ID ולא רק לפי מזהי UID של IMAP.
שכבת הניתוב (מעבר DNS)
בזמן העתקת הנתונים צריך להפנות את הדואר החדש. רשומת MX (Mail Exchange) קובעת לאן הוא יישלח:
Old: MX 10 aspmx.l.google.com
New: MX 10 mx1.trekmail.net
הסיכון לניתוב מפוצל: ספקי אינטרנט ברחבי העולם שומרים רשומות DNS במטמון. אם ערך ה-TTL הוא 86,400 שניות (24 שעות) ואתם מחליפים את רשומת ה-MX ביום שישי בשעה 5 אחר הצהריים, שרתים מסוימים ימשיכו לשלוח לספק הישן עד שבת בשעה 5 אחר הצהריים.
הפתרון הוא "כלל 300 השניות". הורידו את ה-TTL של רשומת ה-MX ל-300 שניות לפחות 24 שעות לפני המעבר. לתהליך המלא של מעבר DNS, קראו כיצד להגדיר דוא"ל בדומיין שלכם.
מה עובר ב-IMAP ומה לא
TrekMail היא פלטפורמת דוא"ל ייעודית: IMAP ו-SMTP לדואר, לצד סנכרון לוחות שנה ואנשי קשר לכל תיבת דואר באמצעות CalDAV ו-CardDAV. היא אינה חבילת יישומי פרודוקטיביות, ולכן אינה כוללת מסמכים, גיליונות אלקטרוניים או שיחות וידאו. במעבר מחבילה כמו Google או M365 לספק דוא"ל ממוקד, חשוב לדעת בדיוק מה אפשר להעביר.
| פריט | עובר באמצעות IMAP? | מה קורה בפועל |
|---|---|---|
| הודעות דוא"ל | כן | הנושא, גוף ההודעה, הקבצים המצורפים והתאריכים מועתקים ככל שהם נתמכים בשני השרתים; לאחר מכן משווים ספירות ודגימות למקור |
| מבנה התיקיות | כן | תיקיות מקוננות נוצרות מחדש ככל ששני השרתים תומכים בהן; Exchange מגביל את העומק ל-300 |
| סימוני נקרא/לא נקרא | כן | הדגל Seen נשמר כאשר שני השרתים תומכים בו |
| אנשי קשר | לא | מייצאים לקובץ CSV או vCard ומייבאים למכשיר המקומי |
| לוחות שנה | לא | מייצאים לקובץ .ics ומאחסנים במקום אחר או שומרים מקומית |
| כינויים | לא | יוצרים אותם מחדש ידנית בלוח הבקרה של TrekMail |
| כללים בצד השרת | לא | יש ליצור מחדש כללי העברה וסינון |
מכשול האימות המודרני
אם אתם עוברים מספק שמחייב OAuth, כגון Google, מכשירים ישנים כמו סורקים ותיקים או Outlook 2013 עלולים שלא להתחבר לשרת IMAP רגיל. תיעוד ההגירה של Google Workspace מסביר כיצד סיסמאות לאפליקציות יכולות לגשר על הפער. TrekMail תומכת באימות IMAP ו-SMTP תקני באמצעות TLS 1.2. ודאו שהמכשירים שלכם תומכים בכך.
איזה מסלול העברת דוא"ל מתאים לכם?
תרחיש א': צמצום עלויות Google Workspace
- הגדירו חשבון TrekMail עם הדומיין שלכם
- השתמשו בכלי ההגירה של TrekMail כדי להעתיק את נתוני הדוא"ל הנתמכים
- ייצאו אנשי קשר (.vcf) ולוחות שנה (.ics) לקבצים מקומיים
- שנו את רשומות ה-MX ל-
mx1.trekmail.net/mx2.trekmail.net - בטלו את Google Workspace רק לאחר אימות ההעתקה והניתוב והשוואת הנתונים למקור
תרחיש ב': העברת הדומיין לרשם חדש
- אפשרו העברת דומיין אצל הרשם הנוכחי
- קבלו קוד EPP או קוד הרשאה
- התחילו את ההעברה אצל הרשם החדש
- חשוב: ודאו ששרתי השמות אינם משתנים, או העתיקו את קובץ האזור במדויק
כלי העברת הדוא"ל המובנים של TrekMail
הגירות IMAP ידניות מועדות לשגיאות. אפילו מקרה אחד של חריגה מזמן ההמתנה או שינוי UIDVALIDITY עלול לפגוע בעקביות תיבת הדואר. ב-TrekMail ההגירה היא חלק מרכזי מהתשתית, לא תוספת שולית.
מנוע ההגירה
לוח הבקרה מתחבר ישירות לספק הישן שלכם, כגון Gmail, cPanel או Exchange, ומבצע בין השרתים את סנכרון ה-IMAP. ניסיונות חוזרים, השהיה הדרגתית בעת הגבלת קצב והסרת כפילויות לפי כותרות מתבצעים אוטומטית. אין צורך בשורת פקודה.
נפח אחסון משותף לסוכנויות
אם אתם ספקי שירות מנוהל שמעבירים 50 לקוחות, ניהול של 50 מכסות אחסון נפרדות הוא בזבוז זמן. TrekMail מציעה נפח אחסון משותף, לדוגמה 200 GB המשותפים לכל הדומיינים. כך אפשר להקצות מקום היכן שנדרש.
אימות DNS
כלי פשוט לבדיקת DNS מוודא שרשומות ה-MX, ה-SPF וה-DKIM מוגדרות כראוי, כדי שלא תנתבו בטעות את הדוא"ל שלכם ליעד שאינו מקבל אותו במהלך המעבר.
| תוכנית | מחיר | מנוע הגירה | אחסון משותף |
|---|---|---|---|
| Free | $0 (ללא כרטיס) | כלול | לא |
| Starter | $3.50 לחודש | כלול | לא |
| Pro | $10 לחודש | כלול | לא |
| Agency | $23.25 לחודש | כלול + כלים לפעולות מרוכזות | כן |
כל המסלולים בתשלום כוללים תקופת ניסיון חינם של 14 יום (נדרש כרטיס). למסלול Nano אין צורך בכרטיס.
סיכום: דעו איזו העברת דוא"ל אתם באמת צריכים
רוב הכשלים בהעברת דוא"ל נגרמים מערבוב בין העברת דומיין, הגירת דוא"ל ושינוי חשבון. הפרידו בין שכבת הנתונים, כלומר העתקת IMAP, לבין שכבת הניתוב, כלומר מעבר DNS. נהלו אותן לפי לוחות זמנים נפרדים, ובסיום השוו למקור את מספר הפריטים ובדקו דגימות.
אם אתם מוכנים לעבור, פתחו חשבון TrekMail חינמי ותנו למנוע ההגירה לטפל בעבודה המורכבת.
