העברת דוא"ל: הסיבות הנסתרות לכשל

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

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

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

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

למה פרויקטים להעברת דוא"ל נכשלים עוד לפני המעבר

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

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

חפשו קודם שלושה דברים.

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

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

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

כאן גם המודל של TrekMail עוזר. הדרך הישנה היא לשלם ל-Google או ל-Microsoft לפי משתמש ולמחוק היסטוריה כדי להוזיל עלויות. הדרך החדשה היא אחסון משותף ותשתית במחיר קבוע, כך שאפשר לשמור תיבות ישנות כארכיונים במקום להפוך אותן למוקשים תפעוליים. תוכנית Starter של TrekMail מתחילה ב-$3.50/mo, ותוכנית Nano נשארת בחינם ואינה דורשת כרטיס.

פיצול ב-DNS גורם לאובדן הודעות בזמן העברת דוא"ל

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

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

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

dig +short MX example.com
nslookup -type=mx example.com

אם אתם עוברים אל TrekMail, רשומות הבסיס הנדרשות מתועדות במדריך רשומות DNS נדרשות. התיעוד של TrekMail מציג גם את נתיב הדואר הנכנס הרגיל ואת הוראת ה-include של SPF, שאותה צריך למזג במקום לשכפל.

example.com.      300 IN MX  10 mail.trekmail.net.
example.com.      300 IN TXT "v=spf1 include:spf.trekmail.net -all"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine;"

הכלל המעשי פשוט:

1. ארבעים ושמונה שעות לפני העברת הדוא"ל, הנמיכו את ה-TTL של ה-MX ל-300 שניות.
2. המתינו מספיק זמן כדי שה-TTL הקודם יפוג בכל מקום שחשוב.
3. החליפו את רשומת ה-MX בזמן המעבר.
4. השאירו את שירות הדואר הישן פעיל למשך 72 שעות לפחות והריצו סנכרון מסכם.

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

האימות נשבר אחרי העברת הדוא"ל, לא במהלכה

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

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

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

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

DMARC הוא המלכודת השלישית. מצב הניטור של DMARC קיים מסיבה טובה. RFC 7489 מתאר במפורש את p=none כדרך לאסוף משוב בלי לשנות את הטיפול של הנמענים בזמן שבודקים שולחים לגיטימיים.

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

1. לפרסם את הרשאת ה-SPF של הספק החדש ולהסיר את הישנה ברגע שהדבר מעשי.
2. ליצור בורר DKIM חדש לפלטפורמה החדשה. לא לעשות שימוש חוזר בשמות בוררים.
3. להקל זמנית את מדיניות DMARC ל-p=none אם משנים כמה נתיבי שליחה בו זמנית.
4. לחזור לאכיפה אחרי שמוודאים שהנתיב החדש חותם ומתיישר כראוי.

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

IMAP גורם להעברה גדולה לחרוג מסוף השבוע

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

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

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

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

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

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

סדר המעבר קובע אם העברת הדוא"ל תהיה רגועה או כאוטית

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

זהו הסדר התפעולי שעובד.

1. אם אפשר, הקפיאו פעילות עתירת שינויים. עריכות בתיבות משותפות ומחיקת תיקיות בזמן המעבר יוצרות קשיי התאמה.
2. ודאו שתיבות היעד קיימות ושאפשר להיכנס אליהן.
3. פרסמו את רשומות ה-DNS והאימות החדשות לפני העברת התעבורה.
4. החליפו את רשומת ה-MX.
5. הריצו את מעבר הדלתא האחרון.
6. בדקו שליחה, קבלה, תשובה והעברה מרשתות חיצוניות.
7. השאירו את השירות הישן מקוון למשך 72 שעות ואספו הודעות שהתעכבו.

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

לקוחות דואר ואסימוני אימות הם החלק שאיש אינו מתקצב

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

זהו אזור הפאניקה של יום שני. צד השרת תקין ברובו. האנשים עדיין לא.

משתמשי iPhone ו-Android שנכנסו באמצעות Google או Microsoft אינם יכולים פשוט לשנות שדה אחד של שם מארח ולהמשיך. האסימונים האלה ייחודיים לספק. במילים פשוטות: מחקו את החשבון והוסיפו אותו מחדש.

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

TrekMail מפרסמת את הערכים המדויקים ללקוחות הדואר במדריך הגדרות IMAP ו-SMTP: הכתובת imap.trekmail.net ביציאה 993 עם SSL/TLS, והכתובת smtp.trekmail.net ביציאה 465 או 587 לפי ההצפנה. TrekMail משתמשת ב-IMAP בלבד, לא ב-POP3. זה חשוב בהעברת דוא"ל, כי המצב צריך להישאר מסונכרן בין המכשירים ולא להימשך ללקוח אחד ולהיעלם באחרים.

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

הדרך הישנה והחדשה: למה מפעילים מפסיקים לשלם לפי משתמש

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

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

TrekMail נבנתה סביב המציאות התפעולית: דומיינים מותאמים אישית, תיבות IMAP, תמיכה ב-catch-all, העברת תיבות, SMTP עצמאי בתוכנית Nano או SMTP כלול בתוכניות בתשלום, העברה בצד השרת ותהליך הגדרת DNS ואימות שאינו מעמיד פנים שדוא"ל הוא דבר פשוט. עבור סוכנויות וספקי שירות מנוהלים, מודל העלויות הזה משנה את החישוב. עבור יזמים יחידים הוא מבטל את התשלום לפי משתמש. עבור עסקים קטנים ובינוניים הוא מאפשר להפסיק למחוק כתובות חשובות רק כדי לחסוך כמה דולרים.

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

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

1. רשמו כל תיבה, כינוי, כלל העברה, כלל catch-all וכתובת שנמחקה ועדיין חשובה.
2. אתרו תיבות ענק וטענו אותן מראש.
3. הנמיכו את ה-TTL של ה-MX מוקדם והמתינו שחלון המטמון הישן יסתיים.
4. פרסמו SPF, DKIM ו-DMARC עבור הספק החדש.
5. החליטו אם DMARC צריך לעבור זמנית למצב ניטור.
6. צרו תיבות יעד ובדקו כניסה לפני המעבר.
7. הכינו הוראות ליום שני למשתמשי iPhone, Android, Outlook ו-Gmail.
8. השאירו את השירות הישן פעיל לסנכרון מסכם במקום לכבות אותו באותו לילה.

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

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