מדריך תפעולי להעברת אימייל בטוחה עם imapsync לשנת 2026

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

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

מהו imapsync ומה הוא אינו

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

זה אינו כלי גיבוי ואינו ממסר SMTP. הוא לא נוגע ביומן Google, באנשי הקשר של Outlook או בכללי התעבורה של Exchange. הוא מתקשר ב-IMAP בלבד. אם שרת המקור נמצא מאחורי חומת אש או אינו מקוון, imapsync לא יוכל להגיע אליו. נקודה.

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

• תוכן: גוף ההודעה בתקן RFC 822, קבצים מצורפים, קידוד MIME וכל מה שנמצא בתוך המעטפת.
• מטא-נתונים: הדגלים. \Seen (נקראה), \Answered (נענתה), \Flagged (סומנה בכוכב). אם הדגלים האלה לא יעברו, כל משתמש יחשוב שביום הראשון ממתינות לו 4,000 הודעות חדשות שלא נקראו.
• מבנה: היררכיית התיקיות. INBOX/Clients/ProjectA צריכה להיראות זהה בשרת החדש, ולא להפוך לתיקייה שטוחה ששמה המילולי INBOX.Clients.ProjectA ובתוכו נקודות.

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

המגבלות הקשיחות: הכלי אינו מכיר מעצמו את מגבלות הקצב של Gmail או את הגבלות ה-API של Microsoft. הפעלה בקצב מרבי עלולה להביא לחסימת כתובת ה-IP שלכם. הוא גם לא דוחף נתונים: אם צריך להעביר נתונים למקום כלשהו, יש למשוך אותם מהמקור. כברירת מחדל הוא גם אינו מוחק דבר ביעד. זו תכונת בטיחות שעלולה גם לגרום לבעיה אם לא שמים לב, כפי שיוסבר בשלב 6.

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

שלב 1: מיפוי יסודי לפני ההעברה, אל תדלגו עליו

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

1. אתרו את תיבות הדואר הענקיות

יש לכם משתמש עם תיבת דואר בנפח 45GB. אולי זה ה-CEO, ואולי האדם שמחזיק בכינוי sales@ מאז 2011. אם תנסו להעביר אותו באותה קבוצה עם משתמשים בעלי 500MB, הקבוצה תיתקע ואתם תבהו במסוף קפוא בלי לדעת כמה מהעבודה הושלמה.

תחילה הריצו סריקה מקדימה:

imapsync \
  --host1 imap.source.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.dest.com --user2 user@dest.com --passfile2 /secret/pass2 \
  --dry --justfoldersizes

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

2. בעיית הנתונים האפלים

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

השוו את רשימת המשתמשים בשרת המקור למשתמשים הפעילים בפועל. אם bob@company.com עזב לפני שלוש שנים, החליטו כעת אם להעביר את התיבה שלו או לשמור אותה כייצוא EML. אם לא תחליטו לפני המעבר, תיאלצו להחליט תחת לחץ ברגע הגרוע ביותר. במדריך לניהול הדואר האלקטרוני של לקוחות תמצאו תבנית מלאה למיפוי מקדים.

3. האמת נמצאת במספר הפריטים

לעולם אל תסתמכו על הנפח בגיגה-בייט. שרת המקור A עשוי לדווח על תיבה בנפח 10GB, ואילו שרת היעד B ידווח שאותם נתונים בדיוק תופסים 11GB. זו אינה תקלה: שרתים שונים מחשבים נפח אחסון בדרכים שונות. Exchange כולל את תיקיית Recoverable Items, המכונה "Dumpster", ואילו Gmail מסיר כפילויות של הודעות בין תוויות.

המדד החשוב הוא מספר הפריטים. אם במקור יש 14,200 הודעות וביעד יש 14,200 הודעות, סיימתם. הבדל של פחות מ-10% בנפח הבתים הוא רגיל וצפוי. אם ההבדל גדול מ-10%, בדקו את הסיבה לפני האישור הסופי.

שלב 2: תהליך העברה בטוח

הטעות הגדולה ביותר בכל העברה היא גישת ה"Big Bang": להעביר הכול ביום שישי בלילה ולקוות שהתהליך יסתיים עד יום שני בבוקר. אם יש לכם 50GB של דואר והגבלה של 500KB/s, החישוב אינו מסתדר. ביום שני השירות עדיין לא יהיה זמין, ואתם תצטרכו להסביר ל-CEO מדוע תיבת הדואר הנכנס שלו ריקה.

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

שלב 1: הרצת ניסיון

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

imapsync \
  --host1 imap.gmail.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.trekmail.net --user2 user@dest.com --passfile2 /secret/pass2 \
  --dry --justfolders

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

שלב 2: סנכרון עיקרי מקדים

הריצו אותו 1-2 שבועות לפני המעבר, כאשר המשתמשים עדיין עובדים במערכת הישנה. המטרה היא להעביר מראש 90-95% מהנתונים ולהוציא אותם מהנתיב הקריטי.

imapsync \
  --host1 imap.source.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.dest.com --user2 user@dest.com --passfile2 /secret/pass2 \
  --usecache --skipsize --maxsize 25000000

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

--maxsize 25000000 מדלג בהרצה הראשונה על הודעות שגודלן עולה על 25MB. קבצים מצורפים גדולים גורמים למרבית מקרי החריגה מזמן ההמתנה וניתוקי החיבור. תעבירו אותם בהרצה ייעודית עם זמני המתנה ארוכים יותר.

שלב 3: סנכרון ההשלמה

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

שלב 4: המעבר

זה הרגע. פעלו לפי הסדר:

1. הנמיכו את ה-TTL של ה-DNS: 48 שעות לפני המעבר, הגדירו את ה-TTL של רשומת ה-MX ל-300 שניות. אם תחכו לרגע האחרון, פותרי DNS מסוימים עשויים לשמור במטמון את רשומת ה-MX הישנה עד 24 שעות, והדואר ינחת בשרת הישן לאחר שכבר ביצעתם את המעבר.
2. החליפו את רשומות ה-MX: הפנו אותן לספק החדש.
3. המתינו 60 דקות להתייצבות ההפצה אצל פותרי ה-DNS המרכזיים.
4. הריצו את ההשלמה הסופית: מעבר אחרון של imapsync יתפוס הודעות שנחתו בשרת הישן במהלך חלון ההפצה.

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

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

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

בעיית התו המפריד

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

שרתי IMAP שונים משתמשים בתווים שונים כדי להפריד בין הרמות בהיררכיית התיקיות:

• Dovecot משתמש בדרך כלל בנקודה: INBOX.Clients.ProjectA
• Exchange/Outlook משתמש בלוכסן: INBOX/Clients/ProjectA
• שרתים מסוימים אינם משתמשים בתו מפריד כלל ומסתמכים על פקודת IMAP בשם NAMESPACE

אם תעבירו נתונים בלי לבדוק, imapsync עלול ליצור ביעד תיקייה ששמה המילולי INBOX.Clients.ProjectA. זו תהיה תיקייה שטוחה אחת שבשמה נקודות, ולא היררכיה מקוננת בעלת שלוש רמות. מבנה התיקיות של כל משתמש ייראה כאילו התפוצץ.

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

הבלגן בתיקיית הדואר הנשלח

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

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

מפו אותן במפורש:

--regextrans2 's/^\[Gmail\]\/Sent Mail/Sent Items/'

הפקודה אומרת ל-imapsync: "אם תיקיית המקור מתחילה ב-[Gmail]/Sent Mail, שנה את שמה ל-Sent Items ביעד". תחילה הריצו את כל מיפוי התיקיות עם --dry, כדי לוודא שכל כלל מופעל כראוי לפני הביצוע בפועל.

המלכודת All Mail של Gmail

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

אם תעבירו את All Mail וגם את Inbox וגם את Sent Mail, כל הודעה תשוכפל פעמיים או שלוש ביעד. תיבה בנפח 10GB תהפוך לתיבה בנפח 30GB, וכל הודעה תופיע מספר פעמים. זו תהיה קטסטרופה.

תמיד החריגו אותה:

--exclude "All Mail"

החריגו גם את [Gmail]/Spam ואת [Gmail]/Trash, אלא אם יש סיבה מוגדרת להעביר אותן. איש אינו רוצה להעביר את דואר הזבל הישן שלו.

שלב 4: כוונון ביצועים והגבלת קצב

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

ההגבלה לאחר חריגה

אם תחרגו ממגבלות הקצב, בדרך כלל כ-1 הודעה בשנייה או 500MB בשעה ב-Gmail, השרת יתחיל להחזיר HTTP 429, NO [OVERQUOTA] או פשוט שגיאות BAD. אם תמשיכו, החשבון יינעל למשך 24 שעות. זו שיחת תמיכה שלא תרצו לבצע.

פרמטרים לכוונון

--maxmessagespersecond 1     # Hard speed limit: 1 email per second
--maxbytespersecond 500000   # Bandwidth cap: 500KB/s
--timeout 120                # Network timeout in seconds (default is often too short for big attachments)
--reconnectretry1 3          # Retry on source connection drops
--reconnectretry2 3          # Retry on destination connection drops

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

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

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

שלב 5: אימות, המכשול של אימות מודרני

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

סיסמאות יישום (המסלול לעסקים קטנים ובינוניים)

ברוב ההעברות של דומיין יחיד, סיסמאות יישום הן האפשרות המהירה ביותר. אלה מחרוזות בנות 16 תווים שעוקפות 2FA ופועלות עם לקוחות IMAP ישנים:

1. היכנסו לחשבון המקור (Gmail, Workspace וכדומה)
2. הפעילו אימות ב-2 שלבים אם הוא עדיין אינו פעיל, שכן הוא נדרש ליצירת סיסמאות יישום
3. עברו אל הגדרות אבטחה ← סיסמאות יישום
4. צרו סיסמה עבור "Mail" במכשיר "Other device"
5. השתמשו במחרוזת הזו כסיסמה בקובץ שמועבר ל-imapsync באמצעות --passfile

שמרו אותה בקובץ עם הרשאות chmod 600, ולא בשורת הפקודה. פרטי גישה בהיסטוריית Bash הם תקלה שמחכה להתרחש.

OAuth2 (המסלול ל-MSP ולארגונים)

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

1. רשמו יישום בדייר המקור (Azure AD עבור Microsoft או Google Cloud Console עבור Google)
2. העניקו לו גישה מלאה לכל תיבות הדואר בדייר, בכפוף לאישור של מנהל מערכת כללי
3. צרו Refresh Token לכל משתמש או השתמשו בהתחזות של חשבון שירות
4. העבירו את האסימון ל-imapsync באמצעות --oauthaccesstoken1

אם תגדירו באופן שגוי את הרשאות היישום ב-Azure AD או ב-GCP, הגישה תידחה בכל תיבה או, גרוע מכך, תעניקו בטעות הרשאות רחבות יותר מהמתוכנן. קראו היטב את טווחי ההרשאות לפני שתלחצו על "Grant admin consent".

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

שלב 6: תקלות נפוצות ודרכי התאוששות

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

1. בעיית UIDVALIDITY (תרחיש הבלהות)

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

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

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

--useheader

הפרמטר מאלץ את imapsync להשוות את כותרת Message-ID של כל הודעה, שהיא קבועה וייחודית, במקום להסתמך על ה-UID של התיקייה. הפעולה איטית יותר, אך מסייעת למנוע כפילויות. השתמשו בה כאשר יש חשד שנעשה שינוי באינדקס של שרת המקור.

2. הודעות פגומות והודעות בגודל אפס בתים

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

תסמין: imapsync מנסה להביא הודעה, השרת נתקע למשך 120 שניות ואז מנתק את החיבור. התהליך חוזר שוב ושוב ללא סוף באותה הודעה.

פתרון:

--minbytes 10

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

3. בעיית המחיקות שחוזרות לחיים

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

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

הפתרון הוא --delete2, אך יש להשתמש בו בזהירות רבה:

--delete2

הפרמטר מורה ל-imapsync: אם הודעה אינה קיימת במקור, מחק אותה מהיעד.

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

4. ניתוקי חיבור בקבצים מצורפים גדולים

קובץ PDF מצורף בנפח 40MB עלול לעיתים לתקוע חיבורי IMAP בעלי זמן המתנה קצר. השרת שולח את ההודעה, יש הפרעה רגעית ברשת, החיבור נופל ב-95%, ו-imapsync מתעד שגיאה וממשיך. ביעד נשארת הודעה חלקית.

פתרון: הגדילו את --timeout ל-300 שניות בהרצות המיועדות לקבצים מצורפים גדולים. אפשר גם להשתמש ב---maxsize 25000000 כדי לדלג עליהם בסנכרון העיקרי, ואז להריץ מעבר ייעודי עם הגבלת קצב מקלה יותר וזמני המתנה ארוכים יותר.

אימות התוצאה: כיצד להוכיח שההעברה הצליחה

הסקריפט הסתיים. במסוף כתוב שהפעולה הושלמה. כיצד תדעו שהודעות ה-CEO לא נעלמו בנתיב ריק כלשהו?

1. קראו את מקטע הסיכום

imapsync מציג סיכום בסוף כל הרצה. אלה שלושת המספרים החשובים:

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

2. בדיקה מדגמית

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

• Sent Items: האם שנות הדואר שנשלח נמצאות שם ומסודרות כראוי?
• תיקיית משנה מקוננת עמוק: האם ההיררכיה נכונה?
• ההודעה האחרונה: האם היא זהה להודעה שמופיעה במקור?
• הודעה מסומנת או מכוכבת: האם התכונה \Flagged נשמרה?

3. חיפוש פורנזי

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

grep -i "bob@sender.com" /var/log/imapsync/user@source.com.log

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

4. בדיקת מספר הפריטים

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

# On source (example for Dovecot)
doveadm mailbox status -u user@source.com messages '*'

# Or use imapsync's own count
imapsync ... --dry --justfoldersizes 2>&1 | grep "Messages"

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

החלופה: לוותר על המסוף

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

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

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

גם מודל התמחור שונה ממה שאתם כנראה מכירים. אין תשלום לפי משתמש. מסלולים במחיר קבוע מתחילים ב-$3.50 לחודש ומכסים עד 100 משתמשים ב-50 דומיינים, עם אחסון משותף לכולם. מנהל אחד עם 40GB של קבצים מצורפים לא מחייב שדרוג לכולם, מפני שהאחסון משותף ברמת החשבון.

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

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

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