העברה עם SRS: הגדרת PostSRSd ובדיקת ARC

העברת דוא״ל אמורה להיות פשוטה: מגדירים הפניה וזהו. אבל ללא העברה עם SRS ‏(Sender Rewriting Scheme), ‏SPF עלול להיכשל. נניח ש-bank.com שולח הודעה לכתובת שמועברת דרך השרת שלכם, והשרת מעביר אותה ליעד. החיבור מגיע מכתובת ה-IP שלכם, בעוד שולח המעטפת עדיין משתמש ב-bank.com. אם הדומיין אינו מאשר את הכתובת שלכם, SPF נכשל. במדיניות DMARC מסוג p=reject, ההודעה עשויה להידחות כאשר גם אין חתימת DKIM תקפה ומותאמת. ייתכנו דחיית SMTP או הודעת כשל במסירה; ההודעה אינה תמיד נעלמת בשקט.

המדריך עוסק בהגדרה התפעולית של SRS. ‏המדריך המלא להגדרת העברת דוא״ל ולגורמי כשל מציג את התמונה הרחבה. כאן נתמקד בשכבת SRS: ארכיטקטורה, תחביר השכתוב, שילוב עם Postfix ו-ARC כאמצעי משלים אפשרי להחלטת האימות של הנמען.

מה העברה עם SRS עושה בפועל

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

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

שתי שכבות של זהות בדוא״ל

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

• שולח המעטפת (RFC 5321 MAIL FROM): כתובת ההחזרה שבה שרתי דואר משתמשים לניתוב הודעות כשל במסירה. SPF בודק אם כתובת ה-IP של החיבור מורשית לשלוח מטעם הדומיין. אפשר לבדוק את הכתובת הזו גם ב-Return-Path בכותרות הגולמיות.
• From בכותרת (RFC 5322 From): הכתובת המוצגת בתוכנות הדוא״ל. DMARC בודק התאמה לפחות לדומיין אחד שאומת בהצלחה באמצעות SPF או DKIM. SRS משאיר את השדה הזה ללא שינוי.

הדוגמה הבאה מציגה תוצאות SPF בהעברה עם SRS ובלעדיו, בהתאם להרשאות הדומיינים המוצגות:

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

תחביר SRS: משמעות הרכיבים

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

שכתוב SRS בתחנה הראשונה (SRS0) נראה כך:

SRS0=Hash=Timestamp=OriginDomain=OriginLocalPart@AnchorDomain

הרכיבים:

• Hash: קוד אימות HMAC מקוצר שנוצר ממפתח סודי מקומי; חלק מהמימושים משתמשים ב-SHA1. הוא מקשה על זיוף כתובות החזרה של SRS בדומיין שלכם. ללא אימות מתאים, כתובות SRS0 שנראות תקינות עלולות לשמש לשליחת הודעות כשל לא רצויות. ההגנה תלויה במנגנון ובניהול המפתחות.
• Timestamp: בדוגמה הזו, מקודד ב-Base32 עם חלון תוקף שניתן להגדרה של כ-7-21 ימים. אפשר לדחות כתובות שפג תוקפן. הדבר מגביל סיכונים מסוימים של שימוש חוזר, אך אינו מבטל אותם.
• Origin: המידע הדרוש לשחזור השולח המקורי במקרה של כשל במסירה. השרת שלכם מקבל את ההודעה, משחזר את הכתובת המקורית ומנתב את הודעת הכשל לשולח הנכון.
• AnchorDomain: הדומיין שבשליטתכם. רשומת SPF שלו צריכה לאשר את השרת המעביר, ומסלול החזרה נגיש צריך לקבל הודעות כשל במסירה. בדרך כלל מגדירים MX לצורך זה; בתנאים מסוימים גם מסלול משתמע דרך A או AAAA אפשרי.

בהעברה נוספת, SRS0 עשוי להפוך ל-SRS1:

SRS1=NewHash=PreviousAnchorDomain==SRS0_Suffix@NewAnchorDomain

SRS1 מגביל את התארכות החלק המקומי של הכתובת. המגבלה של 64 תווים ב-RFC 5321 עדיין חשובה; המנגנון אינו מבטיח עמידה בה בכל שרשרת. בכשלי העברה עם כמה תחנות, בדקו את אורך הכתובת לצד ניתוב ואימות.

שילוב עם Postfix: הגדרת PostSRSd

PostSRSd הוא אפשרות נפוצה לשילוב SRS במערכות Linux/Postfix. שירות רקע מספק ל-Postfix כתובות מעטפת משוכתבות באמצעות ממשקי מיפוי מתאימים. הדוגמאות הבאות חייבות להתאים לגרסה המותקנת בפועל. בדקו את התחביר, את נתיב השקע, את הרשאות הגישה ואת השילוב עם הגדרת Postfix הקיימת לפני החלת שינויים.

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

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

• רשומות MX: הודעות כשל במסירה מנותבות לדומיין הזה. ודאו שמסלול ההחזרה אכן מקבל הודעות. היעדר קבלה עלול לגרום לאובדן הודעות הכשל. RFC 5321 מתאר גם מסירה באמצעות MX משתמע דרך A או AAAA בתנאים מסוימים; לכן היעדר MX מפורש לבדו אינו מוכיח שהדומיין אינו נגיש.
• רשומת SPF: שרתי היעד בודקים את SPF של הדומיין מול כתובת ה-IP השולחת שלכם. אם המסלול בפועל אינו מורשה, SPF עלול להיכשל גם כאשר שכתוב SRS פעיל.
• מוניטין טוב: ספאם שמועבר דרככם עלול לפגוע במוניטין כתובת ה-IP ודומיין העוגן ולתרום להכללה ברשימות חסימה. זה אינו בלתי נמנע, אך SRS אינו מבודד אתכם מהדואר שאתם מעבירים.

# Verify SPF record exists for your anchor domain
dig relay.yourdomain.com TXT +short
# Expected output - must include your server IP:
"v=spf1 ip4:203.0.113.10 -all"

# Check MX records exist for bounce delivery
dig relay.yourdomain.com MX +short

שלב 2: הגדרת PostSRSd

בהתאם לחבילה ולגרסה, ההגדרות עשויות להימצא ב-/etc/default/postsrsd ‏(Debian/Ubuntu) או ב-/etc/postsrsd/postsrsd.conf. ודאו איזה קובץ משמש בפועל ומה התחביר הנתמך, כולל החרגות דומיינים שמשתנות בין גרסאות. היעדר רשימת החרגות אינו גורם בהכרח ללולאת ניתוב:

# Domain that appears in SRS-rewritten envelope senders
SRS_DOMAIN=relay.yourdomain.com

# Secret key path
# In a multi-server cluster, this file MUST be identical on all nodes.
# If nodes have different secrets, they can't validate each other's bounces.
SRS_SECRET=/etc/postsrsd.secret

# Exclusion list - critical config, don't skip this
# Without it, Postfix rewrites local-to-external mail too,
# causing routing confusion and potential delivery loops.
SRS_EXCLUDE_DOMAINS=yourdomain.com,client-one.com,client-two.com

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

openssl rand -base64 32 > /etc/postsrsd.secret
chmod 600 /etc/postsrsd.secret

שלב 3: שילוב עם Postfix

השילוב מוגדר ב-/etc/postfix/main.cf. הדוגמה הבאה מציגה socketmaps עבור PostSRSd 2.x ו-TCP עבור גרסה 1.x. אל תעתיקו אותה ללא התאמה: בדקו את נתיב השקע בפועל, הרשאות, נגישות ואת תחביר הגרסה המותקנת:

# PostSRSd 2.x - modern installs (unix socket maps)
sender_canonical_maps = socketmap:unix:srs:forward
sender_canonical_classes = envelope_sender
recipient_canonical_maps = socketmap:unix:srs:reverse
recipient_canonical_classes = envelope_recipient

# PostSRSd 1.x - legacy installs (TCP)
# sender_canonical_maps = tcp:localhost:10001
# sender_canonical_classes = envelope_sender
# recipient_canonical_maps = tcp:localhost:10002
# recipient_canonical_classes = envelope_recipient

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

systemctl restart postsrsd
systemctl restart postfix

SRS לא תמיד מספיק: ARC כאמצעי משלים

SRS עשוי לטפל בבעיית SPF של דומיין המעטפת החדש, אך אינו יוצר אוטומטית התאמת דומיינים ב-DMARC. DMARC דורש שדומיין שאומת בהצלחה באמצעות SPF או הדומיין של חתימת DKIM תקפה יהיה מותאם ל-From בכותרת. אחרי שכתוב SRS, ‏SPF מאמת בדוגמה את relay.yourdomain.com, ולא את client.com. ללא ההתאמה הזו, חתימת DKIM תקפה ומותאמת נשארת הדרך למעבר DMARC.

העברה עלולה לפסול את DKIM. קידומת “External Sender” בנושא, קישורי הסרה בתחתית ההודעה או שינוי גבולות MIME עשויים לפסול את החתימה המקורית כאשר הם משנים חלקים חתומים באופן שמשפיע על האימות לפי כללי הקנוניזציה. לא כל שינוי פוסל את החתימה. אם לאחר מכן אין גם התאמת SPF וגם DKIM תקף ומותאם, DMARC נכשל ונמען בעל מדיניות מחמירה עשוי לדחות את ההודעה.

אמצעי משלים אפשרי הוא ARC, ‏Authenticated Received Chain, המוגדר ב-RFC 8617. השרת המעביר יכול לתעד בחתימות את תוצאות האימות שנצפו בפועל בעת הקבלה. נמענים שנותנים אמון בחותם ARC ובשרשרת עשויים להביא את המידע הזה בחשבון בהחלטה לגבי כשל DMARC נוכחי. ARC אינו מתקן התאמת דומיינים ואינו מבטיח מסירה.

ARC מוסיף שלוש כותרות להודעה המועברת:

• ARC-Authentication-Results: תוצאות האימות שנצפו בפועל בעת הקבלה, ולא בהכרח בדיקות שעברו
• ARC-Message-Signature: חותמת על כותרות נבחרות ועל הגוף במצבם בזמן יצירת חתימת ARC
• ARC-Seal: מקשרת קריפטוגרפית את קבוצת ARC לשרשרת לאורך התחנות

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

המקור הנורמטיבי של SPF, שבעיית ההעברה שלו מטופלת באמצעות SRS, הוא RFC 7208.

כשלים ייחודיים לספקים שכדאי להכיר לפני הפריסה

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

שגיאת M365 ‏550 5.7.520 עלולה לבזבז זמן רב כשמתייחסים אליה כאל בעיית SRS. בתרחיש הזה, מדיניות אבטחה בדייר השולח חוסמת העברה חיצונית לפני שההודעה יוצאת ממנו. SRS או ARC בשרת מאוחר יותר במסלול אינם מתקנים זאת. שינויים בפורטל Microsoft Defender דורשים הרשאות ניהול מתאימות ואישור הארגון.

בדיקה שהעברה עם SRS עובדת

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

1. בדקו את הכותרת Return-Path

שלחו הודעת בדיקה מחשבון חיצוני, כמו ProtonMail, לכתובת שמוגדרת להעברה. פתחו ביעד את מקור ההודעה הגולמי וחפשו את שורת Return-Path:

• Return-Path: <SRS0=...@yourdomain.com> → שכתוב SRS גלוי בהודעה הזו; בדקו גם את תוצאות האימות
• Return-Path: <alice@protonmail.com> → אין שכתוב גלוי; בדקו החרגות, מסלול שליחה ושילוב השירות

2. בדקו DNS של דומיין העוגן

# SPF record must cover your server IP
dig relay.yourdomain.com TXT +short

# MX record must exist so bounces can arrive
dig relay.yourdomain.com MX +short

3. בדקו את לוגי Postfix

grep -E "srs_forward|canonical" /var/log/mail.log | tail -50

בדקו אם Postfix פונה לשירות SRS ומקבל כתובות משוכתבות; הפרטים הזמינים תלויים בהגדרה וברמת הרישום. “Connection refused” עשוי להעיד על שירות שאינו פועל, כתובת שגויה או בעיות בשקע וברשת. בדקו בין היתר את systemctl status postsrsd, את הממשק המוגדר ובמידת הצורך את כללי חומת האש.

4. בדקו נגישות ו-TLS

בעיות SRS ו-TLS עשויות להופיע ככשלי מסירה דומים. לכן בדקו גם את חיבור הרשת ואת STARTTLS:

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp

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

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

SRS, ‏ARC, דומיין העוגן, ניהול מפתחות, החרגות דומיינים וניטור מוניטין יוצרים עבודה תפעולית ממשית. ארגונים רבים משתמשים בהעברה כדי להימנע מרישוי לפי תיבה אצל ספקים גדולים. אתם מעבירים sales@ לתיבה אישית וחוסכים בדוגמה רישיון של $6 לחודש. מה שנראה סביר לכתובת אחת עשוי להיות יקר לתפעול עבור עשר.

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

מסלול TrekMail Pro המתואר עולה $10 לחודש ומציע 100 דומיינים ו-50GB אחסון משותף. בדקו מחירים, מגבלות ותכונות עדכניים. ארחו sales@, ‏support@ ו-info@ כתיבות IMAP אמיתיות ללא תשלום לפי משתמש בהתאם למודל המתואר. שלב ההעברה הנוסף ותחזוקת SRS שלו מתבטלים. מסירה ישירה ואחסון עדיין תלויים בהגדרה, במכסות ובהחלטות הספקים.

אם אתם צריכים העברה, למשל לריכוז כמה דומיינים ביעד אחד, ההעברה המנוהלת המתוארת במסלולי Pro ו-Agency מבצעת שכתוב SRS וחתימת OpenARC בשרת. ודאו את התמיכה הנוכחית. אתם מגדירים את כתובת היעד בלוח הבקרה; העיבוד בשרת אינו מבטיח התאמת DMARC או קבלה. Nano עם BYO SMTP אינו מקנה אוטומטית זכאות להעברה מנוהלת. אם אתם מעבירים דרך תשתית יוצאת משלכם, SRS רלוונטי שם; דוגמאות PostSRSd צריכות להתאים לגרסה ולארכיטקטורה שלכם.

למסלול המסוים מדומיין פרטי אל Gmail, המדריך להעברת דוא״ל של דומיין ל-Gmail מפרט את הכשלים הייחודיים ואת שלבי הבדיקה.

הגרסה הקצרה

העברה עם SRS משכתבת את שולח המעטפת כדי ש-SPF יבדוק את דומיין השרת המעביר. הבדיקה עשויה לעבור אם הדומיין מאשר כראוי את כתובת ה-IP השולחת. לא כל הודעה שמועברת נכשלת ללא SRS. PostSRSd הוא שילוב אפשרי עם Postfix, באמצעות דומיין עוגן נגיש, SPF מתאים, מפתח סודי, החרגות דומיינים מתאימות ומיפויים ב-main.cf. בדקו את הגרסה ואת התחביר. ARC עשוי להוסיף הקשר כאשר DKIM נפסל בדרך, אך אינו מתקן היעדר התאמת DMARC.

לאחר כל שינוי הגדרה, בדקו את הכותרות הגולמיות ואת תוצאות האימות בפועל. כשהעלות התפעולית של SRS עולה על החיסכון ברישוי, אירוח ישיר עשוי להתאים יותר. בדקו את מסלולי TrekMail ואת התנאים העדכניים של הצעת Nano המתוארת ללא כרטיס אשראי. ההפעלה תלויה ב-DNS ובהגדרה ואינה מיידית בכל מצב. Pro מציע העברה מנוהלת עם SRS ו-ARC בהיקף המתואר, אם אתם מעדיפים להעביר את הטיפול לספק.