Catch-all לדומיין: ניתוב, בדיקה וסיכונים

מפעילים catch-all לדומיין כדי לקבל פניות גם כשלקוח מקליד saels@ במקום sales@. זה מובן. אבל בטווח הכתובות שהכלל מכסה, השרת מפסיק לדחות נמענים לא מוכרים ומקבל הודעות לכתובות אקראיות, לרבות בדיקות אוטומטיות של כתובות. תצורה לא מתאימה עלולה ליצור הודעות אי-מסירה לא רצויות, המכונות backscatter, לולאות של תשובות אוטומטיות ובעיות מסירה בהעברה חיצונית. אלה סיכונים אפשריים, לא תוצאות בלתי נמנעות של כל כלל catch-all.

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

מהו catch-all לדומיין?

זהו כלל בשרת העברת הדואר, MTA, שמקבל הודעות לכתובות בדומיין שאינן תואמות לנמען מוכר. רשימת הנמענים התקפים צריכה לכלול גם כינויים, קבוצות ונמענים אחרים, ולא רק תיבות. במקום 550 User Unknown, השרת עשוי להשיב לבדיקת הנמען ב-250 OK ולנתב את ההודעה ליעד חלופי. קבלת הנמען אינה הקבלה הסופית לאחר DATA. catch-all משנה את ניתוב הנמען במעטפת SMTP ואינו פוגע באימות כשלעצמו; העברה או הודעות נוספות לאחר מכן עשויות להוסיף סיכונים.

מעטפת לעומת כותרת: מדוע ההבדל חשוב

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

RFC 5321 מגדיר את מעטפת SMTP, לרבות הפקודות RCPT TO ו-MAIL FROM המוחלפות במהלך ההעברה. RFC 5322 מגדיר את כותרות ההודעה, ובהן To: ו-From: שתוכנת הדואר מציגה.

catch-all ממפה נמען מעטפת לא מוכר ליעד חלופי, ועשוי להשאיר את הכותרות הגלויות ללא שינוי. המיפוי הזה אינו מבטל אימות כשלעצמו. SPF בודק את כתובת ה-IP השולחת לפי דומיין MAIL FROM או HELO כשזה רלוונטי; DKIM מאמת באופן קריפטוגרפי את החלקים החתומים בכותרות ובגוף ההודעה. DMARC דורש שלפחות אחת מבדיקות SPF ו-DKIM תצליח עם התאמה לדומיין שבכותרת From הגלויה. העברה חיצונית נוספת עשויה להשפיע על הבדיקות האלה.

תרחיש כשל בהעברה חיצונית

העברת הודעות catch-all ל-Gmail או ל-Outlook.com מוסיפה תחנת SMTP. הודעה שכבר עברה אימות עלולה להיכשל בבדיקה בהמשך:

1. השולח המקורי: client@bank.com (IP: 1.2.3.4)
2. השרת שלכם מקבל את typo@yourdomain.com ומעביר אל you@gmail.com
3. Gmail רואה חיבור מכתובת ה-IP של השרת שלכם, כאשר bank.com הוא דומיין שולח המעטפת
4. SPF נכשל בדוגמה מפני שרשומת SPF של bank.com אינה מתירה את כתובת ה-IP שלכם
5. אם bank.com משתמש ב-DMARC p=reject וגם אין חתימת DKIM תקפה עם התאמת דומיין, הנמען עשוי לדחות את ההודעה. ייתכנו שגיאת SMTP או הודעת אי-מסירה

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

שלושה סיכונים של catch-all לדומיין

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

1. Backscatter: סיכון למוניטין

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

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

2. לולאות תגובה (שגיאת Exchange 5.4.14)

catch-all מנתב נמענים לא מוכרים לתיבה חלופית שהופעלה בה תשובת היעדרות. שולח ספאם כותב אל random@yourdomain.com, וההודעה מגיעה לתיבה. התשובה האוטומטית נשלחת לכתובת שולח מזויפת וחוזרת כהודעת אי-מסירה. אם היא חוזרת אל random@yourdomain.com ומעובדת שוב, עלולה להיווצר לולאה, בהתאם לניתוב ולהגנות הקיימות. Exchange עשוי לדווח אז על 550 5.4.14 Hop count exceeded - possible mail loop.

בדקו דיכוי של תשובות אוטומטיות להודעות catch-all. הכותרת X-Auto-Response-Suppress: All היא אמצעי בקרה חשוב, במיוחד ב-Exchange, אך אינה הבטחה כללית. השפעתה על תשובות היעדרות, אישורי מסירה ואישורי קריאה תלויה בתוכנה המקבלת. בדקו את מניעת הלולאות ואת התנהגות התשובות בפועל.

3. מתקפות איסוף כתובות (DHA)

אם כל כתובת בדומיין משיבה ב-250 OK, תוקפים יכולים לבדוק אוטומטית אלפי צירופים, כגון admin@, hr@, ceo@ ו-invoice@. catch-all גורף מאשר שהכתובות מתקבלות ב-SMTP, לא שקיימות תיבות אמיתיות. הדבר עשוי לעודד הפצת ספאם לדומיין, אולי במשך שנים, אך אינו מאמת את הכתובות ואינו קובע את משך המתקפות.

דפוסי כתובות מוגדרים, במקום catch-all גורף, יכולים לצמצם את טווח הקבלה. אסטרטגיה 2 מסבירה את הגישה הזאת.

אסטרטגיה 1: תיבת בדיקה נפרדת

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

היגיון ההגדרה:

1. קבלה: השרת מקבל *@domain.com בטווח catch-all שהוגדר
2. זיהוי: הנמען אינו תיבה, כינוי, קבוצה או נמען תקף אחר
3. הפרדה: ניתוב לתיבה משותפת ייעודית, כגון catchall_sink@domain.com
4. דיכוי תשובות: בסביבת Microsoft מתאימה, הגדרת Spam Confidence Level לערך 9 והחלת X-Auto-Response-Suppress: All; לאחר מכן יש לבדוק את הפעולות בפועל

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

כלל תעבורה ב-Microsoft 365 / Exchange Online

ההגדרה הבאה היא דוגמה רעיונית, לא שינוי ברירת מחדל לכל סביבת M365. סוג הדומיין Internal Relay משבית את Directory Based Edge Blocking (DBEB), אך אינו מממש catch-all כשלעצמו. השתמשו בו רק בטופולוגיה מאושרת עם מחבר לשרת הדואר המיועד שלכם לטיפול בנמענים האחרים, ולא כאשר כל הנמענים מתארחים כאן בלבד. בדקו את רשימת הנמענים התקפים המלאה; חברות בקבוצה לבדה אינה מזהה נמענים לא מוכרים. בדקו מסלולי חזרה ומניעת לולאות, ובצעו שינוי באבטחה ובניתוב רק באישור מתאים. כלל תעבורה עשוי להתחשב בתנאים הבאים:

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

אסטרטגיה 2: דפוסים ממוקדים באמצעות Postfix PCRE

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

ב-Postfix אפשר להשתמש במפת כינויים וירטואליים עם PCRE (Perl Compatible Regular Expression) אם התמיכה בה מותקנת. הדפוסים הבאים הם דוגמאות שיש לבדוק מול התאמות רצויות ולא רצויות ועם אימות מחלקות הנמענים; היעדר התאמה במפה אינו מבטיח דחייה כשלעצמו:

# /etc/postfix/virtual_pcre

# Catch any address starting with "sales-" (sales-q1, sales-webinar, etc.)
/^sales-.*@yourdomain\.com$/    sales-team@yourdomain.com

# Catch common "support" typos (suport, supprt)
/^supp?o?rt@yourdomain\.com$/   support@yourdomain.com

# No wildcard below = hard 550 reject for everything else

השילוב מוגדר ב-/etc/postfix/main.cf. שימו לב: החלפת ההגדרה בהשמה הבאה עלולה להסיר מפות כינויים קיימות. גבו את התצורה, שלבו את המפה החדשה עם הקיימות ובדקו את הסדר, את הדפוסים ואת אימות הנמענים:

virtual_alias_maps = pcre:/etc/postfix/virtual_pcre

לאחר שינוי מאושר ובדיקת התצורה, אפשר לטעון אותה מחדש: postfix reload

כדי להרחיב את הכיסוי, הוסיפו דפוסים שמרניים לכתובות נפוצות במקום catch-all גורף:

/^(info|contact|hello|team)@yourdomain\.com$/    info@yourdomain.com

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

מתי catch-all לדומיין מתאים

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

שימושים מתאימים:

• כתובות לקמפיינים קצרים: משתמשים ב-promo-jan@, ב-promo-feb@ וב-promo-mar@, ולא רוצים ליצור כל כתובת ידנית
• קליטת לקוחות: קבלת הודעות לפני השלמת ההגדרה הרשמית של הכתובות
• מעבר ממערכת ישנה: עדיין אין רשימה מלאה של הכתובות הפעילות, ורוצים לצמצם אובדן הודעות במהלך המעבר

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

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

TrekMail: תצורה מתוכננת במקום פתרונות עוקפים

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

הדוגמה ההיסטורית של תוכנית TrekMail Starter היא $3.50 לחודש. בדקו מחירים, מגבלות ותכונות עדכניים לפני יצירת הכתובות הדרושות במקום מיון כל הדואר דרך catch-all. במודל Nano המתואר נדרש שרת SMTP חיצוני משלכם לכל הודעה יוצאת, לרבות תשובות; שליחה מנוהלת בתוכניות בתשלום תלויה בהרשאות בפועל. מעבר דורש גישה מאושרת למקור, בדיקת תאימות, אימות ההעתקה וסנכרון סופי; אנשי קשר ויומנים דורשים בדיקה נפרדת. המדריך להגדרת דואר בדומיין שלכם מציג DNS, SPF, DKIM, DMARC ותיבות בסדר מתאים.

רשימת בדיקות לפני הפעלת catch-all

בדקו את כל הסעיפים לפני ההפעלה. פערים עלולים ליצור עבודה נוספת; השפעתם תלויה בתצורה ובדואר הנכנס:

1. אימות נמעני SMTP פעיל: דחיית כתובות לא מוכרות מחוץ לדפוסי catch-all שמתקבלים במכוון, בזמן חיבור SMTP. הימנעות מהודעות לא רצויות לשולחים שכתובתם עשויה להיות מזויפת.
2. תשובות אוטומטיות מבוקרות: החלת X-Auto-Response-Suppress: All על הודעות מתאימות כשיש תמיכה. בדיקת תשובות היעדרות ומניעת לולאות; הכותרת לבדה אינה הבטחה.
3. תיבת הבדיקה מוכנה: תיבת catch-all ייעודית ונפרדת מהעבודה היומיומית, עם מגבלות קיבולת ואחראי מוגדר.
4. סיווג הספאם נבדק: סיווג זהיר של הודעות לנמענים לא מוכרים ובדיקה יזומה שלהן לפי המדיניות. אין להשמיט דואר לגיטימי ללא הודעה כברירת מחדל.
5. SPF ו-DMARC נבדקו: בשימוש ב-SRS, ודאו ש-SPF של דומיין שולח המעטפת ששוכתב בפועל מתיר את כתובת ה-IP המתחברת. DMARC דורש שלפחות אחת מבדיקות SPF ו-DKIM תצליח עם התאמת דומיין. DKIM תקף שנותר עם התאמה עשוי לעבור ללא SRS; SRS לבדו אינו משחזר התאמה ל-From המקורי.
6. עדיפות לדפוסי PCRE ממוקדים: שימוש בדפוסים חלקיים אם ה-MTA תומך בהם. אין לקבל כתובות אקראיות ללא צורך עסקי; יש לבדוק את שאר בקרות הנמענים.
7. הודעות אי-מסירה מבוקרות: מניעת backscatter לשולחים מזויפים בלי להשבית את כל ההודעות הלגיטימיות. טיפול בהודעות שהתקבלו לפי מדיניות הבדיקה והשמירה.

סיכום

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

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