העברת דואר בין ספקי אחסון: כפילויות ותיקיות

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

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

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

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

מה קורה בפועל כשמעבירים דואר לספק אחר?

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

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

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

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

מדוע נוצרות הודעות כפולות בהעברה?

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

מלכודת UIDVALIDITY

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

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

לדוגמה: הסבב הראשון מעתיק 38,000 הודעות מ-Inbox. המנהל מפעיל שוב לאחר חריגה מהזמן, אבל תיקיית המקור או היעד נוצרה מחדש בלילה. אם מיפוי ה-UID הישן אינו תקף ואין התאמה חלופית מתאימה, עשויות להתווסף עוד 38,000 הודעות ל-Inbox.

בעיית התוויות של Gmail

Gmail משתמש בתוויות ולא רק בתיקיות רגילות. הודעה יכולה לשאת כמה תוויות, ודואר שהועבר לארכיון נשאר ב-All Mail. תיעוד Gmail מסביר שהעברה לארכיון מוציאה הודעה מ-Inbox אך משאירה אותה זמינה ב-All Mail.

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

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

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

imapsync \
  --host1 imap.gmail.com \
  --user1 user@gmail.com \
  --password1 'APP_PASSWORD' \
  --host2 mail.newhost.com \
  --user2 user@example.com \
  --password2 'DEST_PASSWORD' \
  --exclude "\\[Gmail\\]/All Mail" \
  --useheader "Message-ID" \
  --dry

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

מדוע תיקיות נראות חסרות לאחר המעבר?

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

הבדלים במרחבי שמות ובמפרידים

שרתי IMAP משתמשים במרחבי שמות ומפרידי היררכיה שונים. אחד משתמש בנקודות כמו INBOX.Sent, אחר בקווים נטויים כמו Inbox/Sent Items, ואחר דורש קידומת INBOX..

ללא מיפוי מתאים, Project.Alpha עלולה להפוך לתת-תיקייה של Project. תיקיית מערכת עשויה להיראות כתיקייה רגילה. יישום נייד יכול להירשם לתיקייה הלא נכונה ולא להציג את הרצויה.

הבדלי Sent ו-Sent Items

היסטוריית שליחה היא מקום שמשתמשים בודקים במהירות. ספק אחד שומר ב-Sent, אחר מצפה ל-Sent Items, ואחר מציג Sent Messages.

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

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

תוכנית העברה ב-3 שלבים לצמצום סיכונים

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

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

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

; Example cutover records
@      MX   10 mail.trekmail.net.
@      TXT     "v=spf1 include:spf.trekmail.net -all"
_dmarc TXT     "v=DMARC1; p=quarantine;"

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

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

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

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

1. השוו מספר פריטים ולא רק נפח

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

2. בדקו את ההודעות הישנות והחדשות ביותר

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

3. חפשו תיקיות שלא מופו כראוי

חפשו INBOX.Sent בלתי צפויה ברמה הראשית, תיקיות [Gmail] שנותרו או תיקיות שליחה כפולות. אלו יכולות להיות סימני מיפוי לקוי, אך בדקו אם המבנה נשמר בכוונה.

4. בדקו קבלה ושליחה בפועל

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

5. בדקו את ההגדרות החדשות בתוכנות הדואר

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

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

השוואת שיטות עבודה ישנות וחדשות

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

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

לסיכום

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

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