אירוח דואר catch-all: ‏8 בדיקות לפני הפעלה

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

במקום לדחות נמען לא מוכר באמצעות 550 5.1.1 User Unknown, השרת עשוי להשיב 250 OK לפקודת RCPT TO. זהו אישור נמען, לא קבלה סופית של ההודעה. התקפות איסוף כתובות מנסות שמות כמו admin@, invoice@, payroll@ ו-careers@. Catch-all מקשה לזהות כתובות קיימות לפי התשובה, אך יכול להוסיף תעבורה. סף Cisco של 25 נמענים לא תקינים בשעה הוא דוגמה למדיניות קבלה מוגדרת שבוחנת מארח שולח מרוחק, לא סף אוניברסלי לזיהוי דומיין catch-all. התקפה עשויה לכלול אלפי ניסיונות בדקה.

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

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

מה catch-all משנה בתהליך SMTP

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

לאחר קבלה סופית, הודעות עשויות להעמיס על תורים, סריקות ואחסון. שליחת NDR לכתובת MAIL FROM מזויפת עלולה ליצור backscatter. חלון של 2-4 שבועות להסרת רישום הוא דוגמה בלבד; מדיניות הרשימה והראיות קובעות את הזמן בפועל. משתמשים נוספים באותה כתובת IP עשויים להיפגע, אך אין השפעה אוטומטית על כל טווח הכתובות.

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

רשימת בדיקה עם 8 סעיפים

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

1. סינון SMTP לפני קבלה סופית

שאלו אילו בדיקות פועלות בחיבור, בנמען וב-DATA. תשובת 250 OK לנמען אינה מוכיחה אחסון הודעה או backscatter. האחרון נוצר כשלאחר קבלה סופית נשלח דוח כשל לשולח מעטפת מזויף.

דוגמה לדחייה לפני קבלת תוכן:

postfix/smtpd[1234]: NOQUEUE: reject: RCPT from unknown[192.0.2.1]:
  550 5.7.1 Service unavailable; Client host blocked using zen.spamhaus.org;
  from=<probe@attacker.com>, to=<random123@yourdomain.com>

מסנן תוכן עשוי לרשום:

amavis: Blocked SPAM {DiscardedInbound}, [192.0.2.1]
  <probe@attacker.com> -> <random123@yourdomain.com>, Score: 17.2

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

2. גישה בזמן מתאים ליומני SMTP

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

דוגמת יומן שימושית לבירור:

Jan 03 10:14:22 mail postfix/smtpd: connect from mail.outlook.com[40.107.100.99]
Jan 03 10:14:23 mail postfix/cleanup: message-id=<20260103.ABC@outlook.com>
Jan 03 10:14:24 mail amavis: Passed CLEAN {RelayedInbound}, [40.107.100.99]
  <client@outlook.com> -> <billing@yourdomain.com>, Hit: -1.5

כלי הניהול והמעקב של Google Workspace ושל Microsoft 365 תלויים במוצר. עיכוב של 30-60 דקות הוא תרחיש אפשרי, לא זמן קבוע לכל הנתונים. בדקו את רמת הפירוט, ההרשאות, הזמינות ומענה התמיכה במינוי שלכם.

3. מגבלות נפח שמתחשבות גם בדואר שלכם

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

שאלו למשל: ״אם הדומיין מקבל 10,000 הודעות בשעה בעקבות התקפת איסוף כתובות, האם אתם מגבילים את המקור, את החשבון או נוקטים פעולה אחרת?״

4. תמיכה ב-SRS וב-ARC להעברה

אם שרת א' מעביר דואר catch-all ל-Gmail או ל-Outlook, בדקו את אימות הקפיצה הנוספת. מסלול ההעברה יכול להשפיע על SPF ועל התאמת DKIM; catch-all עצמו אינו שובר את האימות.

SPF עלול להיכשל: המקבל רואה את כתובת הממסר. בזהות מעטפת מקורית עם v=spf1 ... -all, SPF עלול להיכשל אם הכתובת אינה מורשית. בדקו את הזהות ששימשה בפועל.

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

בדקו את התמיכה וההגדרות במסלול:

• SRS (Sender Rewriting Scheme): משכתב Envelope-From; ‏SPF של הדומיין החדש צריך להתיר בפועל את כתובת הממסר. אין בכך הבטחת התאמה ל-From המקורי. ראו העברת SRS: פעולה ותקלות.
• ARC (Authenticated Received Chain): מתואר בRFC 8617 ומשמר מידע אימות חתום בין קפיצות. המקבל צריך לאמת את השרשרת ולתת אמון בשירות חותם מאומת; המסירה נשארת כפופה למדיניות שלו.

השגיאה הראשונה בדוגמאות הבאות עוסקת במדיניות ארגונית להעברה חיצונית, והשנייה ב-DMARC. הן אינן מוכיחות כשלעצמן היעדר SRS או ARC:

550 5.7.520 Access denied, your organization does not allow external forwarding.
550 5.7.1 Unauthenticated email from domain.com is not accepted
  due to the domain's DMARC policy.

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

5. כינויים וזהות תשובה מורשית

Catch-all יכול לקבל דואר ל-billing@, support@ ול-project-2026@, אך תשובה דורשת הרשאות שליחה נפרדות. ב-Gmail, שליחה בשם billing@yourdomain.com כאשר החשבון הראשי הוא admin@yourdomain.com דורשת זהות ״Send As״ נתמכת, אימות נדרש והגדרת SMTP. האימות נעשה בהגדרת הזהות, לא מחדש בכל הודעה.

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

6. טיפול בטוח ב-backscatter וב-NDR

לאחר קבלה סופית עשוי להופיע כשל בשל תיבה מלאה, ניתוב או סריקה מאוחרת. NDR שנשלח אז ל-MAIL FROM מזויף יוצר backscatter. הדבר עלול להזיק למוניטין או להביא לרישום אצל Backscatterer.org, אך אינו הופך את השרת אוטומטית לממסר פתוח ואינו מבטיח רישום ברשימת חסימה.

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

7. גישת IMAP וייצוא שאפשר לאמת

תיבת catch-all עשויה לצבור נתונים רבים. בדקו מראש מעבר באמצעות IMAP או כלי ייצוא מתועד. ממשק אחר אינו אומר אוטומטית שאין אפשרות להעביר את הנתונים.

בדקו במיוחד:

• גישת IMAP נתמכת ביציאה 993 עם TLS
• ייצוא ל-.eml או ל-.mbox כשהוא נתמך
• מגבלות קריאה מוסכמות וחלון מתאים להעברה בכמות גדולה

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

8. מדיניות אחסון ברורה והתנהגות בחריגה מהמכסה

שאלו מה קורה כשהתיבה מלאה. תגובה זמנית כמו 452 4.2.2 Insufficient storage מסמנת לשרת השולח לנסות שוב בהתאם למדיניות שלו, לא ללא הגבלת זמן. מחיקה שקטה של דואר לגיטימי אינה רצויה; ודאו שניתן לראות כשלים ולקבל התראות קיבולת מוקדמות.

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

בחינת TrekMail לאחסון catch-all

TrekMail מתאר אחסון משותף ברמת החשבון וכמה תיבות במסגרת זכאות התוכנית. בדקו את מכסת החשבון, מגבלות התיבות הבודדות, הדומיינים והחיוב; אין להניח תמחור לכל דומיין או מספר בלתי מוגבל. הגדירו jobs@, billing@, support@ ו-archive@ לפי הצורך במקום לקלוט כל כתובת לא מוכרת מטעמי מחיר בלבד.

טווח היסטורי של $6-$12 למשתמש בחודש הוא דוגמה להשוואת עלות של כתובת תפקיד. חבילות דואר יכולות להציע גם כינויים ותיבות משותפות. השוו חלופות לכתובת שמקבלת שלוש הודעות בחודש:

לניתוב ישן או למערכות חיצוניות, בדקו תמיכה נוכחית ב-catch-all, ביומנים, ב-IMAP וב-SRS. נקודות ייחוס היסטוריות מציינות Starter במחיר $3.50 בחודש עם 50 דומיינים ואחסון משותף, ותקופת ניסיון של 14 ימים עם דרישת כרטיס. המודל החינמי המתואר מציין 10 דומיינים, 5GB משותפים ו-BYO SMTP. בדקו מחירים, מגבלות ותנאי כרטיס עדכניים. במודל Free/Nano הזה נדרש SMTP חיצוני משלכם לכל הודעה יוצאת ולכל תשובה.

לסיכום

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

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

בדקו את אחסון catch-all של TrekMail, את IMAP ואת תנאי התוכניות העדכניים.