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

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

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

רשימת בדיקה לפני העתקת הודעה אחת

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

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

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

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

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

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

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

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

יש שלושה דפוסים נפוצים:

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

1. T פחות 14 ימים: להעביר תחילה דואר ישן ולזהות תיבות איטיות.
2. T פחות 7 ימים: לאשר כינויים, כללי העברה ומיפוי תיבות היעד.
3. T פחות 2 ימים: להנמיך TTL של DNS, לבדוק אימות ולעבור על יומני כשל.
4. T אפס: להחליף MX, לעדכן SPF ו-DKIM, להריץ דלתא ואז לתקן לקוחות.
5. T ועוד 1 יום: לאמת ספירות, לבדוק דואר נכנס ויוצא ולחסום גישה ישנה.

שגיאת DNS משבשת את זרימת הדואר. הנמיכו TTL לפחות 48 שעות מראש, ואז השוו את רשומות היעד לרשומות ה-DNS הנדרשות של TrekMail.

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=none; rua=mailto:dmarc@example.com"

# DKIM value is generated per domain in the TrekMail dashboard.

במהלך 24 עד 48 השעות הראשונות אחרי שינוי MX, מדיניות DMARC זמנית של p=none יכולה לצמצם דחיות עצמיות בזמן שהמטמונים מתייצבים. לאחר התייצבות המעבר, חזרו לאכיפה. הדבר חשוב במיוחד בשליחת נפח גדול אל Gmail. הנחיות השולחים של Google דורשות כיום SPF, DKIM, התאמה, TLS ו-DMARC משולחים בכמות גדולה.

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

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

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

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

imapsync \
  --host1 oldmail.example.com --user1 alice@example.com --password1 'SOURCE_PASS' \
  --host2 imap.trekmail.net --user2 alice@example.com --password2 'DEST_PASS' \
  --ssl1 --ssl2 \
  --syncinternaldates \
  --exclude 'Calendar|Contacts' \
  --skipsize

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

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

רשימת בדיקה לאימות לאחר החלפת DNS

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

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

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

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

dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com

רשימת בדיקה לניסיונות, יומנים וחזרה

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

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

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

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

למה הרשימה הזאת עובדת טוב יותר ב-TrekMail

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

TrekMail מתאימה למודל. היא תומכת בדומיינים מותאמים, תיבות IMAP, catch-all, העברה, העברה בצד השרת, אשף SPF, DKIM ו-DMARC, SMTP עצמאי או כלול ו-API. תוכניות בתשלום מתחילות ב-$3.50 לחודש ב-Starter וכוללות כלי העברה. לניסוי תכונות בתשלום יש תקופה חינמית של 14 יום המחייבת כרטיס. להתחלה בלי כרטיס, Nano תמיד בחינם.

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

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

סיכום: שמרו על רשימת העברה משעממת

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