2. יצירת מדיניות MTA-STS

כדי להגדיר MTA-STS בדומיינים, צריך ליצור ולפרסם מדיניות לכל דומיין. המדיניות מגדירה את שרתי האימייל בדומיין שמשתמשים ב-MTA-STS.

לכל דומיין צריך להיות קובץ מדיניות נפרד. כללי המדיניות יכולים להיות זהים, אבל צריך לארח אותם בנפרד לכל דומיין באמצעות MTA-STS.

דרישות השרת ל-MTA-STS

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

  • הם דורשים שהאימייל יישלח דרך חיבור מאובטח (TLS).
  • הם משתמשים ב-TLS בגרסה 1.2 ואילך
  • האישורים לשרתי TLS:
    • התאמה של שם הדומיין שמשמש את שרת הדואר הנכנס (השרת ברשומות ה-MX).
    • חתומים ומאושרים על ידי רשות אישורי בסיס.
    • המסמכים בתוקף.

מידע נוסף על אישורי TLS זמין במאמר שימוש באישורים של Google Workspace להעברה מאובטחת (TLS).

מצבי מדיניות MTA-STS

אפשר להגדיר מדיניות MTA-STS במצב בדיקה או במצב אכיפה.

מצב בדיקה

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

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

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

מצב אכיפה

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

אם החיבור לא מוצפן ומאומת:

  • שרתים שתומכים ב-MTA-STS לא ישלחו אימיילים לדומיין שלכם.
  • שרתים שלא תומכים ב-MTA-STS ימשיכו לשלוח הודעות לדומיין שלכם בחיבורי SMTP, כמו שהם עושים בדרך כלל. יכול להיות שחיבורי ה-SMTP האלה לא יהיו מוצפנים.

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

יצירת קובץ מדיניות

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

שם קובץ המדיניות: שם קובץ הטקסט חייב להיות mta-sts.txt

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

פורמט קובץ המדיניות: השדה version חייב להיות בשורה הראשונה של המדיניות. הסדר של שאר השדות לא משנה. דוגמה לקובץ מדיניות:

version: STSv1
mode: testing
mx: mail.solarmora.com
mx: *.solarmora.net
mx: backupmx.solarmora.com
max_age: 604800

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

מפתח ערך
גרסה גרסת הפרוטוקול. הערך חייב להיות STSv1
mode

מצב המדיניות:

  • בדיקה: שרתים חיצוניים שולחים לכם דוחות על הצפנה ועל בעיות אחרות שזוהו במהלך החיבור לדומיין. דרישות ההצפנה והאימות של MTA-STS לא נאכפות

  • enforce: אם חיבור ה-SMTP לא מאומת וגם לא מוצפן, שרתי אימייל שהוגדרו ל-MTA-STS לא ישלחו הודעות לדומיין. בנוסף, תקבלו דוחות משרתים חיצוניים על בעיות בחיבור, כמו במצב בדיקה.

  • ‫none: מציין לשרתים חיצוניים שהדומיין שלכם כבר לא תומך ב-MTA-STS. משתמשים בערך הזה אם מפסיקים להשתמש ב-MTA-STS. מידע נוסף על הסרת MTA-STS‏ (RFC 8461)
mx

רשומת MX של הדומיין.

  • במדיניות צריכה להיות רשומה של mx לכל רשומת MX שנוספה לדומיין.
  • כל ערך mx צריך להיות בשורה משלו בקובץ המדיניות, כמו בדוגמה.
  • שם שרת הדואר צריך להיות בפורמט שם נושא חלופי (SAN) סטנדרטי.
  • הערך mx צריך להיות באחד מהפורמטים שמוצגים בדוגמאות הבאות:

    ציון שרת יחיד בפורמט MX רגיל: alt1.aspmx.solarmora.com

    כדי לציין שרתים שתואמים לתבנית שמות, משתמשים בתו כללי. התו הכללי לחיפוש מחליף רק תווית אחת בצד ימין, לדוגמה: *.solarmora.com

מידע נוסף על רשומות MX וערכי רשומות MX
max_age

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

הערך צריך להיות בין 86,400 (יום אחד) לבין 31,557,600 (בערך שנה אחת).

במצב בדיקה, מומלץ להגדיר ערך בין 604800 לבין 1209600 (שבוע עד שבועיים).

השלבים הבאים

פרסום מדיניות MTA-STS