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 וקבלת הצעות להגדרות.

מפתח ערך
version גרסת הפרוטוקול. הערך חייב להיות 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