כתובת catch-all: אופן הפעולה, סיכונים וחלופות

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

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

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

מהי כתובת catch-all?

Catch-all, המכונה לעיתים כתובת wildcard, היא הגדרת שרת לדואר המיועד לנמענים לא מוגדרים בדומיין. השרת עשוי להשיב "250 OK" לפקודת RCPT TO במקום "550 User unknown", ולנתב נמענים לא מוכרים לתיבה מוגדרת. אישור הנמען אינו קבלה סופית של ההודעה לאחר DATA; בדיקות נוספות עדיין יכולות לחול.

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

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

איך catch-all פועל ברמת SMTP

ההבדל מתחיל ב-RCPT TO, המתואר בRFC 5321, לפני העברת כותרות, תוכן וקבצים מצורפים באמצעות DATA. הדוגמאות מפשטות את המשך התהליך: דחיית נמען אינה מחייבת סגירת חיבור, ואישור נמען אינו מבטיח קבלה סופית של ההודעה כולה.

ללא catch-all: הגבלת הנמענים המתקבלים

SENDER:      RCPT TO: <ghost@yourdomain.com>
YOUR SERVER: 550 5.1.1 User unknown
RESULT:      Connection closed. Zero data transferred.

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

עם catch-all: הרחבת קבלת הנמענים

SENDER:      RCPT TO: <ghost@yourdomain.com>
YOUR SERVER: 250 2.1.5 OK
RESULT:      Server accepts headers, body, and attachments.
             Routing logic directs mail to the catch-all mailbox.

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

שלושה סיכונים תפעוליים שכדאי לבדוק

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

1. התקפות איסוף כתובות DHA

מפיצי ספאם עשויים לנסות אוטומטית אלפי שמות נפוצים, כגון admin, invoice, hr, accounts, david, noreply, info ו-billing. המטרה יכולה להיות זיהוי כתובות קיימות או מסירת דואר לכתובות אקראיות.

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

2. Backscatter וסיכון למוניטין

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

דוגמה לטיפול לא בטוח:

1. תוקף שולח נוזקה אל random@yourdomain.com ומזייף MAIL FROM כ-innocent@gmail.com
2. מסלול catch-all מאפשר את הנמען הלא מוגדר והשרת מקבל את ההודעה סופית
3. סריקה מאוחרת מזהה נוזקה ולא ניתן למסור את ההודעה במסלול הרגיל
4. השרת שולח דוח אי-מסירה NDR אל innocent@gmail.com
5. משתמש Gmail שלא שלח את ההודעה מקבל הודעת החזרה לא מבוקשת

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

3. העברה ובעיות SPF

יש מנהלים שמעבירים catch-all כמו *@company.com לחשבון Gmail אישי. לצד הרשאה וניהול מידע, צריך לבדוק את האימות במסלול הממסר בפועל. Catch-all עצמו אינו משנה את SPF.

בהעברה רגילה, ההודעה מגיעה מכתובת IP של הממסר בעוד MAIL FROM עשוי להישאר בדומיין המקורי, למשל bankofamerica.com. SPF עלול להיכשל אם אותו דומיין אינו מתיר את כתובת הממסר. העברה באמצעות SRS‏ (Sender Rewriting Scheme) משכתבת את שולח המעטפת, ו-SPF של הדומיין המשוכתב צריך להתיר בפועל את כתובת ה-IP. הדבר אינו מבטיח התאמה ל-From המקורי. חתימת DKIM תקינה, שלמה ומיושרת יכולה להספיק למעבר DMARC גם בלי SRS או ARC. ARC דורש אימות שרשרת ואמון בשירות חותם שזהותו אומתה; Gmail מחליט על הקבלה והמיקום לפי המדיניות שלו.

חלופות לכתובת catch-all

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

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

בדקו מחדש את שיקול העלות

רישוי עשוי להשפיע על ההחלטה. במחיר היסטורי של $6 למשתמש בחודש, יצירת sales@, support@ ו-billing@ כתיבות עם רישיונות נפרדים עולה $18 בחודש. עם זאת, חבילות דואר עשויות לתמוך גם בכינויים ובתיבות משותפות בתנאים שלהן. לא כל כתובת תפקיד מחייבת רישיון משתמש, ולכן כדאי להשוות חלופות לפני הפעלת catch-all.

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

התיאור ההיסטורי של Starter מציין $3.50 בחודש, עד 50 דומיינים ו-100 תיבות לכל דומיין. בדקו את המחירים, הזכאות והמגבלות הנוכחיים לפני תכנון. הגדירו במפורש sales@, support@, billing@, info@ וכתובות נחוצות נוספות, עם בדיקת נמענים והרשאות גישה מתאימות.

תיבת קליטה מוגבלת כשצריך catch-all

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

1. צרו תיבה ייעודית: catchall-quarantine@yourdomain.com, בנפרד מתיבות העבודה האישיות.
2. הגדירו מסלול קליטה: נתבו רק נמענים לא מוכרים אל היעד המבוקר הזה.
3. צמצמו התראות: מנעו תשובות אוטומטיות והפרעה לעבודה; סימון עדיפות נמוכה אינו מחליף סינון או הגבלת גישה.
4. בדקו מדי שבוע: לאחר אימות הצורך בכתובת לגיטימית, צרו עבורה כינוי מפורש.
5. קבעו מועד הערכה: אפשר להשתמש ב-30 ימים ללא הודעה לגיטימית כדוגמת סף לבחינת סגירה, לאחר בדיקת תהליכים עסקיים ומדיניות שמירה.

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

לסוכנויות: כיסוי כתובות מוגדרות בדומיינים רבים

בניהול 100+ דומיינים, יצירה ידנית של כינויים רגילים עשויה לגזול זמן. תקננו כתובות כמו postmaster@, abuse@, accounts@ ו-info@ בדומיינים שבניהולכם, והשתמשו רק בפעולות זמינות ומתועדות. בדקו תמיכה בתבניות או באוטומציה לפני שמסתמכים עליה, ואמתו יעדים והרשאות לפני החלה רחבה.

התפקידים של postmaster@ ו-abuse@ תלויים ב-RFC 2142 ובדרישות SMTP והשירותים המופעלים. דומיין שמספק ממסר SMTP או מסירת דואר נדרש לתמוך ב-postmaster בהתאם להיקף השירות; דרישות abuse חלות לפי התפקיד והשירות המתאימים. בדקו גם תמיכה ומגבלות עדכניות של Agency לפני פריסה רחבה.

מתי catch-all עשוי להתאים

שלוש דוגמאות לשימוש זמני:

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

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

Catch-all הוא החלטה תפעולית שדורשת בקרות

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

אם העלות היא הסיבה, השוו רישיונות, כינויים, תיבות משותפות וקיבולת. בדקו אם אפשר ליצור Sales@, support@, billing@ ועוד 47 כתובות נחוצות במסגרת הזכאות הנוכחית ב-TrekMail. זו דוגמת מבנה כתובות, לא הבטחת מחיר קבוע או מספר תיבות בלתי מוגבל.

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