תיבת דואר נכנס מאוחדת לכל החשבונות, בלי העברה אוטומטית

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

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

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

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

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

העברה אוטומטית שולחת את ההודעה מחדש דרך שרת שהשולח המקורי בדרך כלל לא אישר ב-SPF. לכן בדיקת SPF עלולה להיכשל. DKIM נשאר לעיתים קרובות תקף כל עוד החלקים החתומים לא השתנו. DMARC דורש SPF או DKIM תקף, עם התאמת הדומיין לכתובת From. אם אף אחד מהם לא עומד בדרישה, מדיניות p=reject ממליצה לשרת המקבל לדחות את ההודעה. ההחלטה הסופית היא של הצד המקבל. כך עלולות להיווצר בעיות מסירה בהעברה אוטומטית.

Sender Rewriting Scheme מחליף את שולח מעטפת ה-SMTP בדומיין שמאשר את שרת ההעברה. במערכת המתוארת כאן, SRS מופעל אוטומטית ועוזר לאמת SPF עבור שולח המעטפת החדש. הוא לא יוצר התאמה ל-From המקורי, לא מתקן חתימת DKIM שנפגעה ולא מאפשר להשיב מהכתובת הישנה.

הנקודה האחרונה נוטה להישכח. העברה אוטומטית פועלת בכיוון אחד. הודעה אל you@oldcompany.com מגיעה לתיבה החדשה, אבל התשובה יוצאת מ-you@newcompany.com, אלא אם השליחה מהכתובת הישנה הוגדרה בנפרד. בשיחה עם לקוח זה עלול לבלבל. כלל העברה לא מעניק הרשאה לשלוח בשם הכתובת הקודמת.

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

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

איסוף באמצעות POP וסיום השיטה הישנה

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

המאמר המקורי מתאר את הפסקת התכונות האלה. Microsoft הסירה את החשבונות המחוברים מ-Outlook.com, ו-Google הודיעה על סיום Mail Fetcher ו-Gmailify. כדאי לבדוק אצל כל ספק את המועדים והזמינות העדכניים. מדובר בתכונות מסוימות, לא בביטול כל הדרכים לגשת לכמה חשבונות.

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

שלוש דרכים לאחד את הדואר

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

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

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

איך זה נראה בשימוש יומיומי

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

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

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

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

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

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

זה חשוב לאימות הדואר. SPF של Gmail מאשר את שרתי Google. שליחה בתור @gmail.com דרך תשתית חיצונית לא מורשית לא מבטיחה SPF או DKIM תקף ומתאים ל-From. שימוש בשרת המורשה של החשבון עוזר לבצע את הבדיקות כראוי. DMARC דורש SPF או DKIM תקף עם התאמה ל-From, לא בהכרח את שניהם, ולא מבטיח הגעה לתיבת הדואר הנכנס.

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

סיסמאות לאפליקציות ו-OAuth

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

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

הזיהוי אוטומטי. הדומיין מושווה לספקים מוכרים, ובדומיין פרטי נבדקות רשומות MX. כך אפשר לזהות Google Workspace ו-Microsoft 365 גם כשהכתובת לא מסתיימת ב-@gmail.com. אם השירות לא מזוהה, מזינים את פרטי השרת ידנית. הבדיקה לא משנה DNS.

חיבור ידני תומך ב-IMAP ביציאה 993 עם TLS מובנה או 143 עם STARTTLS, וב-SMTP ביציאות 465, 587 או 2525. בדיקת תעודת TLS היא חובה. תעודה בחתימה עצמית שאינה מהימנה או שם לא תואם מונעים חיבור. יש לבדוק את שרשרת האמון, התוקף ושם השרת, משום שהחיבור מעניק גישה לדואר.

חיבור חשבון

1. פותחים את דואר הדפדפן ועוברים אל הגדרות → חשבונות מחוברים.
2. לוחצים על חיבור חשבון ומזינים את הכתובת.
3. אם הספק זוהה, פועלים לפי ההנחיות ליצירת סיסמה לאפליקציה או לכניסה ל-Microsoft במקרה של Outlook.com. אחרת מזינים שרתי IMAP ו-SMTP, יציאות והצפנה לפי תיעוד הספק.
4. לוחצים על בדיקת חיבור. הקריאה והשליחה נבדקות בנפרד, כדי לדעת איזה חלק נכשל.
5. שומרים. החשבון מופיע בסרגל הצד והודעותיו מתווספות אל כל תיבות הדואר הנכנס.

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

בתיעוד יש מדריכים עבור Gmail, Outlook ו-Microsoft, iCloud, Yahoo ו-AOL ושרתי IMAP אחרים.

תקלות ואיך מזהים אותן

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

IMAP כבוי אצל הספק. מדיניות Google Workspace או Microsoft 365 עשויה להגביל גישה. הלקוח לא יכול לעקוף אותה. מנהל מערכת צריך לבדוק את ההרשאה.

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

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

מידע נוסף מופיע בפתרון בעיות בחשבונות מחוברים.

מגבלות

לפי התיאור המקורי, חשבונות מחוברים זמינים מחבילת Starter ומעלה:

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

שאלות נפוצות

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

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

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

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

האם תשובות יישלחו מהכתובת הנכונה?

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

למה Gmail משתמש בסיסמה לאפליקציה ולא בכפתור כניסה?

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

אפשר להוסיף תיבה בשרת שלי?

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

האם התיבה המאוחדת פועלת בטלפון?

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

מה קורה במעבר לחבילה בלי חשבונות מחוברים?

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