העברת תיבת דואר: בדיקת תיקיות, דגלים ודואר שנשלח

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

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

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

מדוע בעיות מתגלות אחרי שינוי MX

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

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

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

לדוגמה, המנהל רואה 8,000 הודעות שלא נקראו. ייתכן שהתוכן הועתק ללא מצב \Seen המקורי. בדקו את היקף הבחירה במקור וביעד לפני קביעת הגורם.

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

בדקו את תיקיית הדואר שנשלח, \Seen, ערכי INTERNALDATE והעתקי Gmail All Mail. הבדלים עשויים להישאר אחרי השלמת התהליך ולהתגלות רק בשימוש.

1. אי-התאמה בתיקיית הדואר שנשלח

השמות שונים בין מערכות: Sent, Sent Items, בחלק מסביבות cPanel INBOX.Sent, וב-Gmail [Gmail]/Sent Mail.

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

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

2. דגל \Seen

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

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

\Recent שונה: זהו דגל תלוי-סשן במפרט הישן ולא מצב רגיל שאפשר להעביר. לא כל שרת מודרני משתמש בו. הודעה היסטורית עשויה להופיע כחדשה לסשן ביעד; הסבירו מראש את הבדלי התצוגה.

3. שינוי INTERNALDATE

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

RFC 3501 ממליץ ש-APPEND ישתמש בתאריך ובשעה שסופקו כתאריך הפנימי; בהיעדרם השרת עשוי להשתמש בזמן הנוכחי. כך עשר שנות ארכיון עשויות להיראות חדשות. שמרו INTERNALDATE שהמקור מדווח, עם היסט אזור הזמן והדיוק הנתמכים. אי אפשר לשחזר את זמן הקבלה בשרת המקורי מכותרת Date לבדה.

4. העתקי Gmail All Mail

Gmail משתמשת בתוויות ש-IMAP עשוי להציג כתיקיות. בהתאם לכלי ולתצוגה המתוכננת, אותה הודעה עשויה להועתק לכמה מקומות ביעד.

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

מיפוי נכון של תיקיות

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

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

imapsync \
  --host1 old.example.com --user1 user@old.example.com --password1 'oldpass' \
  --host2 new.example.com --user2 user@new.example.com --password2 'newpass' \
  --regextrans2 's/^Sent Messages$/Sent Items/' \
  --regextrans2 's/^INBOX\\.Sent$/Sent Items/' \
  --regextrans2 's/^INBOX\\.Trash$/Deleted Items/' \
  --exclude "\\[Gmail\\]/All Mail"

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

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

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

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

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

1. השוו Inbox, דואר שנשלח וארכיון באותו היקף, עם החרגות מאושרות ושינויים במקור.
2. חקרו פער בין 50 הודעות שלא נקראו במקור לבין 4,000 ביעד. הוא עשוי להעיד על אובדן \Seen, אך בדקו גם מיפוי, בחירה ושינויים במקור.
3. פתחו הודעות היסטוריות ובדקו ש-2019 עדיין מוצגת כתאריך המתאים של 2019, כולל התאריך הפנימי וכותרת Date.
4. שלחו הודעה חדשה ובדקו שהעותק נשמר בתיקייה המתוכננת לצד ההיסטוריה.

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

אחרי המעבר, בדקו הגדרות IMAP ו-SMTP עדכניות, כתובת תיבה מלאה וסיסמת התיבה, לא פרטי כניסה ללוח הבקרה, ושרשרת תעודות השרת ושם המארח וערכי Apps & devices בפועל. TrekMail מתוארת כשירות IMAP ללא POP3. דואר POP מקומי עשוי שלא להימצא בשרת ודורש גיבוי נפרד.

סנכרון שינויים, כפילויות ו-UIDVALIDITY

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

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

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

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

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

העברה ידנית לעומת TrekMail

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

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

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

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

סיכום: העברת תיבה שנבדקה

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

מפו תיקיות מראש ושמרו דגלים נתמכים, במיוחד \Seen. שמרו INTERNALDATE זמין ב-APPEND עם אזור הזמן. החריגו Gmail All Mail רק אחרי אישור כיסוי הארכיון. השוו כמות ותוכן, לא רק נפח אחסון.

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

לרקע בפרוטוקולים, ראו RFC 3501 ל-IMAP וRFC 6154 לתיקיות בעלות שימוש מיוחד.