העברת חשבונות דואר: תיבות, ניתוב ו-DNS

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

התרחיש מוכר: מייצאים PST, גוררים תיקיות ב-Outlook ומניחים שכל כתובת היא תיבה רגילה. ביום שני sales@ אינו מקבל, תיבה גדולה עוד מסתנכרנת ולא ברור איזו מערכת היא הקובעת. התייחסו למעבר כתשתית פעילה ולא רק כהעתקת קבצים.

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

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

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

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

למעשה מדובר בשלוש משימות:

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

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

מה עובר ב-IMAP ומה לא?

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

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

היעזרו בחלוקה הזאת:

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

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

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

רשימת משתמשים אינה מספיקה; חפשו גם תלות שאינה גלויה.

בדקו לפחות:

1. תיבות עיקריות: משתמשים פעילים, תיבות משותפות ותיבות תפקיד.
2. כינויים: כתובות נוספות שמגיעות לתיבה אחרת.
3. רשימות תפוצה וקבוצות: ניתוב שאינו תיבת IMAP רגילה.
4. העברות: כללי שרת כמו info@ אל owner@ עם הרשאות ומדיניות מתאימות.
5. Catch-all: החלטה אם לשמר, להגביל או להפסיק.
6. תיבות גדולות: הכנה והעתקה מוקדמות.

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

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

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

תוכנית שלבים לכמה תיבות

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

סדר מעשי:

שלב 1: ניסיון

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

שלב 2: העתקה מקדימה

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

שלב 3: שינויים ומעבר

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

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

העברה ידנית עם imapsync

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

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

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

הדוגמה אינה מוכנה להרצה: שורת המפרש אינה תקינה, והשרת והאפשרויות דורשים השוואה להגדרות תוכנות הדואר ולגרסה המותקנת. --log מפעיל רישום ואינו מקבל שם קובץ; בדקו --logfile ואפשרויות תקפות אחרות. פיצול לפי פסיק אינו מפענח CSV מלא ואינו מטפל בפסיקים מצוטטים, מרכאות או שורות חדשות בפרטי גישה. הצפנה לבדה אינה אימות שרשרת תעודות ושם שרת; הפעילו בדיקות אלה במפורש.

#!$0

# users.csv format:
# source_user,source_pass,dest_user,dest_pass

while IFS=, read -r src_user src_pass dest_user dest_pass
do
  echo "[START] $src_user -> $dest_user"

  imapsync \
    --host1 imap.old-provider.com --user1 "$src_user" --pass1 "$src_pass" --ssl1 \
    --host2 mail.trekmail.net --user2 "$dest_user" --pass2 "$dest_pass" --ssl2 \
    --automap \
    --usecache \
    --fast \
    --skipsize \
    --subfolder2 "Imported_Mail" \
    --log "logs/${src_user}.log"

  echo "[DONE] Review logs/${src_user}.log"
done < users.csv

הערות מעשיות:

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

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

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

מעבר מבוקר ב-DNS

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

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

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

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

@                 MX   10 mail.trekmail.net.
@                 TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey   TXT  "<unique TrekMail DKIM value>"
_dmarc            TXT  "v=DMARC1; p=quarantine;"

בדקו במעבר:

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

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

העברת חשבונות עם TrekMail

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

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

התהליך המתואר דורש הכנה:

1. הוספת דומיין והכנת DNS; MX רק לאחר הכנת יעד ובדיקת העתקה.
2. יצירת תיבות ואובייקטי ניתוב ביעד.
3. פתיחת העברה בלוח הבקרה.
4. הזנת שרת IMAP, יציאה, משתמש מלא ופרטי גישה מותרים.
5. בחירת תיבת TrekMail כיעד.
6. הפעלת ייבוא ובדיקת מצב ונתונים.

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

מחיר Starter המתואר הוא $3.50 לחודש ו-Nano במחיר $0, לצד Starter, Pro, Agency ו-Enterprise בתשלום. Nano מתואר כחינמי ללא כרטיס, וניסיון חינמי של 14 ימים למסלול בתשלום דורש כרטיס לפי התיאור. בדקו תנאים כיום. אחסון משותף יכול לעזור לתיבה גדולה, אך מגבלות חשבון ושירות עדיין חלות.

השוו במסך מחירי TrekMail העדכני.

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

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

לפני המעבר:

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

זה תהליך מסודר: גילוי תלות לפני השינוי ואימות התוצאות, לא הסתמכות על מזל.

סיכום: העברת חשבונות עם תהליך

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

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