העברת דוא"ל מ-Gmail ללא כפילויות או השבתה

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

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

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

מדוע Gmail משבש העברות IMAP רגילות

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

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

זו המלכודת.

אם להודעה יש Inbox, Project A ו-Urgent, כלי בסיסי עשוי לנסות להעתיק אותה שלוש פעמים. Microsoft מתעדת את בעיית הכפילות הזו בהעברות Gmail אל IMAP עם תוויות כאשר תיקיית [Gmail] אינה מוחרגת. IMAP הוא רק שכבת ההעברה שמוגדרת ב-RFC 3501. החריג הוא הצגת התיקיות של Gmail, לא הפרוטוקול.

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

להסבר ייעודי ל-TrekMail, ראו את מסמך ההעברה מ-Gmail. סקירת העברת IMAP מסבירה את מודל היבוא בצד השרת.

מה עובר בהעברת דוא"ל מ-Gmail

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

כאן אנשים מעריכים יתר על המידה העברת דוא"ל. IMAP מעביר דוא"ל, וזה הכול.

החלוקה הברורה:

גם האימות חשוב. כדי להעביר עם כלי צד שלישי, לעיתים דרושה סיסמת יישום. Google מציינת שסיסמאות יישום הן קודים בני 16 ספרות ופועלות רק כאשר 2-Step Verification מופעלת. הן גם אינן זמינות בחלק מחשבונות העבודה או הלימודים, מגבלה ממשית בסביבות Google Workspace. בדקו את מסמך העזרה של Google על סיסמאות יישומים לפני קביעת המעבר.

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

הדרך הבטוחה ביותר לעבור מ-Gmail

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

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

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

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

פקודה ידנית להעברה מ-Gmail באמצעות imapsync

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

תבנית מעשית:

imapsync \
  --host1 imap.gmail.com --port1 993 --ssl1 \
  --user1 "user@source-domain.com" --passfile1 "/path/to/gmail_pass" \
  --host2 imap.trekmail.net --port2 993 --ssl2 \
  --user2 "user@dest-domain.com" --passfile2 "/path/to/dest_pass" \
  --gmail1 \
  --exclude "\\[Gmail\\]/All Mail" \
  --exclude "\\[Gmail\\]/Trash" \
  --exclude "\\[Gmail\\]/Spam" \
  --regextrans2 "s/^\\[Gmail\\]\\/Sent Mail/Sent Items/" \
  --regextrans2 "s/^\\[Gmail\\]\\/Drafts/Drafts/" \
  --dry

תפקיד כל אפשרות:

הריצו תמיד תחילה בדיקה יבשה.

הגדרות TrekMail התקניות הן imap.trekmail.net, יציאה 993 ו-SSL/TLS. TrekMail משתמשת ב-IMAP בלבד, לא POP3, הבחירה הנכונה לתיבות מסונכרנות. היעזרו במסמך הגדרות IMAP ו-SMTP.

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

דפוסי כשל חשובים בהעברת Gmail

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

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

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

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

היגיון גרוע: להריץ הכול שוב עד שהדוח נקי לגמרי.

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

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

כיצד לאמת העברה נקייה מ-Gmail

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

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

1. השוו את מספר הפריטים הכולל ב-Gmail וביעד.
2. בדקו את מספר ההודעות ב-Inbox ואת מספר ההודעות שלא נקראו.
3. פתחו Sent Items ואשרו שהדואר הנשלח לא הגיע לתיקייה אקראית.
4. פתחו 3 עד 5 תיקיות עם שמות חריגים או תוויות מקוננות.
5. חפשו כמה הודעות ישנות עם קבצים מצורפים ואשרו שהן נפתחות.
6. שלחו הודעת בדיקה נכנסת אחרי שינוי MX.
7. השיבו מהתיבה החדשה ואמתו SMTP ו-DNS.

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

הדרך הישנה מול הדרך החדשה

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

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

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

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

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