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

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

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

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

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

1. פיצול DNS הוא ההשבתה הראשונה בהעברה

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

Microsoft ממליצה לקצר את TTL של MX לפני מעבר IMAP כדי שרשומות מעודכנות יתפשטו מהר יותר. העצה משעממת, אבל מצילה העברות. אם ה-TTL הנוכחי הוא 86,400 שניות ואתם מחליפים MX בליל המעבר, כבר איבדתם שליטה בלוח הזמנים.

;; T-48 hours: inspect current MX TTL
example.com.  86400  IN MX 10 oldmail.example.com.

;; T-48 hours: lower it before cutover
example.com.    300  IN MX 10 oldmail.example.com.

;; T-0: switch to new provider
example.com.    300  IN MX 10 mail.trekmail.net.

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

מעבר גרוע: להחליף MX ב-10 PM, לסגור את המארח הישן ב-10:05 PM ולגלות ביום שני ששער של ספק שמר את הרשומה הישנה כל סוף השבוע.

מלכודת נוספת היא SPF. אם הדואר הנכנס מצביע למערכת החדשה אך האימות היוצא עדיין שגוי, תשובות מגיעות לספאם. כללי השולחים של Google כבר אינם רשות. השתמשו ברשומת SPF אחת, התאימו DKIM ופרסמו DMARC.

2. הגבלת קצב מנפצת את חלום ההעברה בסוף שבוע אחד

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

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

הפתרון הוא העברה בשלבים:

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

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

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

3. UIDVALIDITY יכול ליצור שלושה עותקים מאותה תיבה

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

IMAP4rev1 (RFC 3501) מגדיר UIDVALIDITY מסיבה. אם הוא משתנה, מזהי UID הישנים אינם אמינים עוד. זהו התנהגות תקינה של הפרוטוקול אך התנהגות איומה להעברה שמסתמכת רק על UID.

גורמים נפוצים:

• משתמש משנה שם תיקייה או יוצר אותה מחדש בזמן המעבר.
• שרת המקור בונה אינדקסים מחדש.
• מנהל מבצע תחזוקה שמשנה את מצב התיבה.

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

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

4. מיפוי תיקיות הופך העברה למוזרה במהירות

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

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

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

# Example folder rules
^INBOX\.Sent$        -> Sent Items
^INBOX\.Trash$       -> Deleted Items
^\[Gmail\]/Trash$   -> Deleted Items
^\[Gmail\]/All Mail$ -> [SKIP]

בהעברה מ-Gmail, דלגו על [Gmail]/All Mail אלא אם יש חריג מסוים מאוד. אחרת אתם מזמינים כפילויות. אחרי המעבר TrekMail מפשטת הגדרת לקוחות באמצעות ערכי IMAP תקניים במדריך הגדרות IMAP ו-SMTP לכל הלקוחות.

5. התיבה הענקית הורסת תקציב ולוח זמנים

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

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

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

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

למעקב אחרי השימוש לאחר המעבר, TrekMail מתעדת מגבלות ומכסות במכסות אחסון לתיבות.

6. הודעות פגומות הן רגילות ודורשות טיפול תפעולי

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

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

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

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

7. LegacyExchangeDN היא מלכודת Exchange ששורדת את ההעברה

הכשל הזה מסוים, מכוער ונפוץ. משתמשים עונים לשרשור פנימי ישן ב-Outlook ומקבלים שגיאת IMCEAEX או נמען לא נמצא, אף שהתיבה קיימת ודואר חדש עובד. הסיבה אינה SMTP, אלא זהות Exchange ישנה שמוטמעת בהודעות היסטוריות ובכתובות שמורות.

Exchange שומר כתובות ישנות בסגנון X.500 בתכונת LegacyExchangeDN. בהעברה בין סביבות Exchange, או ביציאה גרועה מאחת, תשובות להודעות ישנות עדיין עשויות להפנות לזהות הזאת. אם היעד אינו כולל את הערך הישן ככתובת מתווכת X500, התשובה נכשלת.

# Find the old LegacyExchangeDN on source
Get-Mailbox -Identity user@example.com | Format-List LegacyExchangeDN

# Add it as an X500 proxy address on destination
Set-Mailbox -Identity user@example.com -EmailAddresses @{add="X500:/o=OldOrg/ou=Exchange Administrative Group/cn=Recipients/cn=user"}

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

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

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

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

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

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

סיכום: העברת דוא"ל היא עבודה תפעולית ולא העתקה

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

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