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

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

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

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

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

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

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

1. מפו כל דבר שיכול לקבל דואר

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

כאן הדברים מסתבכים. מישהו מייצא ״משתמשים פעילים״, יוצר תיבות יעד, משנה DNS ומניח שהעבודה הסתיימה. ואז פניות מכירה אל sales@ חוזרות, חשבוניות אל ap@ נראות כאילו נעלמו והמדפסת במשרד מתחילה להציג שגיאות SMTP.

השתמשו ברשימת המיפוי הזאת לפני שנוגעים בנתונים:

1. תיבות של משתמשים בעלי רישיון
2. תיבות משותפות וחשבונות תפקיד כגון info@,‏ billing@ ו-support@
3. כתובות חלופיות שממופות למשתמשים או לתיבות משותפות
4. רשימות תפוצה וכתובות של קבוצות
5. כללי העברה, התנהגות catch-all וחריגי ניתוב
6. מכשירים ויישומים ששולחים דרך הספק הישן
7. אובייקטים ישנים של Exchange, כולל הפניות X.500 או LegacyExchangeDN

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

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

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

2. בדקו מה IMAP מעביר ומה לא

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

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

לפני הפרויקט, הגדירו בכתב את היקף העבודה:

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

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

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

אלה אילוצים טכניים ממשיים. גם בחיבור מהיר במשרד, תיבה של 50 GB עשויה להתקדם לאט כי המקור מאט בקשות, מגביל חיבורים או משעה פעילות IMAP כבדה. Google מפרסמת מגבלות רוחב פס של Gmail ומכסות API, וגם סביבות Microsoft מגבילות תעבורה בדרכן.

לכן אל תתכננו להעביר את כל התיבות בבת אחת בסוף שבוע. חלקו את העבודה:

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

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

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

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

4. הקטינו TTL לפני המעבר, לא במהלכו

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

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

השתמשו בתזמון הזה:

רשומות TrekMail מתועדות ברשומות DNS נדרשות. אם שני הספקים שולחים בתקופת המעבר, ייתכן ש-SPF יצטרך לאשר זמנית את שניהם. SPF מוגדר בRFC 7208, והתנהגות DMARC בRFC 7489.

example.com. 300 IN MX 10 mail.trekmail.net.
example.com. 300 IN TXT "v=spf1 include:_spf.google.com include:spf.trekmail.net -all"

האיחוד הזמני הזה ב-SPF הוא סעיף חשוב ברשימת בדיקה להעברת דואר. הסירו את include הישן אחרי הבדיקות, לא חמש דקות אחרי שינוי MX.

5. בדקו לפי מספר פריטים, לא לפי גודל התיבה

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

כאן מנהלים עלולים להילחץ בלי סיבה. המקור מציג 10.2 GB והיעד 9.8 GB. אין פירוש הדבר בהכרח אובדן נתונים. קידוד MIME, מנגנוני אחסון ומניעת כפילויות עשויים לשנות את הגודל המדווח.

סדר הבדיקה צריך להיות:

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

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

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

6. תכננו אימות מחדש ויצירת פרופילים מחדש

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

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

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

IMAP host: imap.trekmail.net
IMAP port: 993
SMTP host: smtp.trekmail.net
SMTP port: 465
Username: full email address
Password: mailbox password

עוד דבר: בהקשר של חומר זה, TrekMail משתמשת רק ב-IMAP, בלי POP3. ב-2026, מצב משותף בדרך כלל מועיל יותר מהמודל הישן של הורדה ומחיקה.

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

7. החליטו אם כל הדואר הישן צריך לעבור

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

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

ההשוואה בין הגישות פשוטה:

הגישה הישנה: ממשיכים לשלם לפי משתמש כי תיבה אחת מחזיקה 40 GB של היסטוריה שאיש אינו פותח.

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

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

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

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

1. מפו כל תיבה, כתובת חלופית, תיבה משותפת, קבוצה, נתיב ויישום שליחה.
2. אשרו מה IMAP מעביר ומה דורש ייצוא נפרד.
3. העתיקו דואר ישן לפני המעבר.
4. הקטינו TTL של MX מראש, 24 עד 48 שעות קודם.
5. הכינו אישור זמני לשתי המערכות ב-SPF אם שתיהן ישלחו במהלך המעבר.
6. הריצו סנכרון הפרשים אחרון לפני שינוי MX, עקבו אחר הודעות מאוחרות בשרת הישן וחזרו על הסנכרון לפי הצורך.
7. בדקו מספרי פריטים, תיקיות ובדיקות שליחה וקבלה אמיתיות.
8. צרו פרופילים מחדש לפי הצורך אחרי שמירת נתונים מקומיים. אל תבזבזו שעות על ״תיקון״ תצורות מטמון לא תקינות.
9. ארכבו היסטוריה לא פעילה בהתאם לחובות השימור, במקום להעביר הכול כברירת מחדל.
10. שמרו גישה למערכת הישנה לצורך חזרה לאחור עד סיום הבדיקות.

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

אם מחפשים יעד להעברות IMAP, השוו תוכניות במחירי TrekMail. בהתאם לתוכנית, ההיצע המתואר כולל דומיינים מותאמים, תיבות IMAP, תמיכת catch-all,‏ SMTP עצמאי או מנוהל, העברת הודעות וכלי העברה מובנה, בלי חיוב לכל משתמש.