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

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

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

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

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

  • הם דורשים שהאימייל יישלח דרך חיבור מאובטח (TLS).
  • הם משתמשים בגרסה 1.2 ואילך של TLS
  • האישורים לשרתי 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 לא נאכפות.

  • אכיפה: אם חיבור ה-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