ಸಂಕ್ಷಿಪ್ತವಾಗಿ, MTA-STS ಎಂಬುದು ಮೇಲ್ ಸರ್ವರ್‌ಗಳ ನಡುವೆ ರವಾನೆಯಾದಾಗ ಪ್ರತಿಬಂಧಕದಿಂದ ಇಮೇಲ್‌ಗಳನ್ನು ಮತ್ತಷ್ಟು ರಕ್ಷಿಸುವ ಒಂದು ಮಾರ್ಗವಾಗಿದೆ (ಅಂದರೆ, ಮಧ್ಯ-ಮಧ್ಯದ ದಾಳಿಗಳು ಅಕಾ MitM). ಇದು ಇಮೇಲ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಪರಂಪರೆಯ ವಾಸ್ತುಶಿಲ್ಪದ ಸಮಸ್ಯೆಗಳನ್ನು ಭಾಗಶಃ ಪರಿಹರಿಸುತ್ತದೆ ಮತ್ತು ತುಲನಾತ್ಮಕವಾಗಿ ಇತ್ತೀಚಿನ ಪ್ರಮಾಣಿತ RFC 8461 ನಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ. Mail.ru ಈ ಮಾನದಂಡವನ್ನು ಅಳವಡಿಸಲು RuNet ನಲ್ಲಿ ಮೊದಲ ಪ್ರಮುಖ ಮೇಲ್ ಸೇವೆಯಾಗಿದೆ. ಮತ್ತು ಅದನ್ನು ಕಟ್ ಅಡಿಯಲ್ಲಿ ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ.

MTA-STS ಯಾವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ?

ಐತಿಹಾಸಿಕವಾಗಿ, ಇಮೇಲ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು (SMTP, POP3, IMAP) ಮಾಹಿತಿಯನ್ನು ಸ್ಪಷ್ಟ ಪಠ್ಯದಲ್ಲಿ ರವಾನಿಸುತ್ತವೆ, ಇದು ಅದನ್ನು ತಡೆಯಲು ಸಾಧ್ಯವಾಗಿಸಿತು, ಉದಾಹರಣೆಗೆ, ಸಂವಹನ ಚಾನಲ್ ಅನ್ನು ಪ್ರವೇಶಿಸುವಾಗ.

ಒಬ್ಬ ಬಳಕೆದಾರರಿಂದ ಇನ್ನೊಬ್ಬರಿಗೆ ಪತ್ರವನ್ನು ತಲುಪಿಸುವ ಕಾರ್ಯವಿಧಾನವು ಹೇಗೆ ಕಾಣುತ್ತದೆ:

ಐತಿಹಾಸಿಕವಾಗಿ, ಮೇಲ್ ಪ್ರಸಾರವಾಗುವ ಎಲ್ಲಾ ಸ್ಥಳಗಳಲ್ಲಿ MitM ದಾಳಿ ಸಾಧ್ಯವಾಗಿದೆ.

RFC 8314 ಗೆ ಮೇಲ್ ಬಳಕೆದಾರ ಅಪ್ಲಿಕೇಶನ್ (MUA) ಮತ್ತು ಮೇಲ್ ಸರ್ವರ್ ನಡುವೆ TLS ಬಳಕೆಯ ಅಗತ್ಯವಿದೆ. ನಿಮ್ಮ ಸರ್ವರ್ ಮತ್ತು ನೀವು ಬಳಸುವ ಮೇಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು RFC 8314 ಗೆ ಅನುಗುಣವಾಗಿದ್ದರೆ, ಬಳಕೆದಾರರು ಮತ್ತು ಮೇಲ್ ಸರ್ವರ್‌ಗಳ ನಡುವೆ ಮ್ಯಾನ್-ಇನ್-ದಿ-ಮಿಡಲ್ ದಾಳಿಯ ಸಾಧ್ಯತೆಯನ್ನು ನೀವು (ಹೆಚ್ಚಾಗಿ) ತೆಗೆದುಹಾಕಿದ್ದೀರಿ.

ಸಾಮಾನ್ಯವಾಗಿ ಅಂಗೀಕರಿಸಲ್ಪಟ್ಟ ಅಭ್ಯಾಸಗಳನ್ನು ಅನುಸರಿಸಿ (RFC 8314 ನಿಂದ ಪ್ರಮಾಣೀಕರಿಸಲಾಗಿದೆ) ಬಳಕೆದಾರರ ಬಳಿ ಆಕ್ರಮಣವನ್ನು ನಿವಾರಿಸುತ್ತದೆ:

Mail.ru ಮೇಲ್ ಸರ್ವರ್‌ಗಳು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವ ಮೊದಲು RFC 8314 ಅನ್ನು ಅನುಸರಿಸುತ್ತವೆ; ವಾಸ್ತವವಾಗಿ, ಇದು ಈಗಾಗಲೇ ಸ್ವೀಕರಿಸಿದ ಅಭ್ಯಾಸಗಳನ್ನು ಸರಳವಾಗಿ ಸೆರೆಹಿಡಿಯುತ್ತದೆ ಮತ್ತು ನಾವು ಹೆಚ್ಚುವರಿ ಏನನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗಿಲ್ಲ. ಆದರೆ, ನಿಮ್ಮ ಮೇಲ್ ಸರ್ವರ್ ಇನ್ನೂ ಅಸುರಕ್ಷಿತ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಬಳಸುವ ಬಳಕೆದಾರರನ್ನು ಅನುಮತಿಸಿದರೆ, ಈ ಮಾನದಂಡದ ಶಿಫಾರಸುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮರೆಯದಿರಿ, ಏಕೆಂದರೆ ಹೆಚ್ಚಾಗಿ, ನಿಮ್ಮ ಕೆಲವು ಬಳಕೆದಾರರು ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಇಲ್ಲದೆ ಮೇಲ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ, ನೀವು ಅದನ್ನು ಬೆಂಬಲಿಸಿದರೂ ಸಹ.

ಮೇಲ್ ಕ್ಲೈಂಟ್ ಯಾವಾಗಲೂ ಅದೇ ಸಂಸ್ಥೆಯ ಅದೇ ಮೇಲ್ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮತ್ತು ನೀವು ಎಲ್ಲಾ ಬಳಕೆದಾರರನ್ನು ಸುರಕ್ಷಿತ ರೀತಿಯಲ್ಲಿ ಸಂಪರ್ಕಿಸಲು ಒತ್ತಾಯಿಸಬಹುದು ಮತ್ತು ನಂತರ ಸುರಕ್ಷಿತವಲ್ಲದ ಬಳಕೆದಾರರಿಗೆ ಸಂಪರ್ಕಿಸಲು ತಾಂತ್ರಿಕವಾಗಿ ಅಸಾಧ್ಯವಾಗುವಂತೆ ಮಾಡಬಹುದು (ಇದು ನಿಖರವಾಗಿ RFC 8314 ಅಗತ್ಯವಿದೆ). ಇದು ಕೆಲವೊಮ್ಮೆ ಕಷ್ಟ, ಆದರೆ ಕಾರ್ಯಸಾಧ್ಯ. ಮೇಲ್ ಸರ್ವರ್‌ಗಳ ನಡುವಿನ ಸಂಚಾರ ಇನ್ನೂ ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ. ಸರ್ವರ್‌ಗಳು ವಿಭಿನ್ನ ಸಂಸ್ಥೆಗಳಿಗೆ ಸೇರಿವೆ ಮತ್ತು ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ "ಸೆಟ್ ಮತ್ತು ಮರೆತುಬಿಡಿ" ಮೋಡ್‌ನಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ, ಇದು ಸಂಪರ್ಕವನ್ನು ಮುರಿಯದೆ ಏಕಕಾಲದಲ್ಲಿ ಸುರಕ್ಷಿತ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಬದಲಾಯಿಸಲು ಅಸಾಧ್ಯವಾಗುತ್ತದೆ. SMTP ದೀರ್ಘಕಾಲದಿಂದ STARTTLS ವಿಸ್ತರಣೆಯನ್ನು ಒದಗಿಸಿದೆ, ಇದು ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಬೆಂಬಲಿಸುವ ಸರ್ವರ್‌ಗಳು TLS ಗೆ ಬದಲಾಯಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಆದರೆ ದಟ್ಟಣೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುವ ಆಕ್ರಮಣಕಾರರು ಈ ಆಜ್ಞೆಯ ಬೆಂಬಲದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು "ಕತ್ತರಿಸಬಹುದು" ಮತ್ತು ಸರಳ ಪಠ್ಯ ಪ್ರೋಟೋಕಾಲ್ (ಡೌನ್‌ಗ್ರೇಡ್ ದಾಳಿ ಎಂದು ಕರೆಯಲ್ಪಡುವ) ಬಳಸಿಕೊಂಡು ಸಂವಹನ ನಡೆಸಲು ಸರ್ವರ್‌ಗಳನ್ನು ಒತ್ತಾಯಿಸಬಹುದು. ಅದೇ ಕಾರಣಕ್ಕಾಗಿ, STARTTLS ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಮಾಣಪತ್ರದ ಸಿಂಧುತ್ವವನ್ನು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ (ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರಮಾಣಪತ್ರವು ನಿಷ್ಕ್ರಿಯ ದಾಳಿಯಿಂದ ರಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಇದು ಸ್ಪಷ್ಟ ಪಠ್ಯದಲ್ಲಿ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುವುದಕ್ಕಿಂತ ಕೆಟ್ಟದ್ದಲ್ಲ). ಆದ್ದರಿಂದ, STARTTLS ನಿಷ್ಕ್ರಿಯ ಕದ್ದಾಲಿಕೆಯಿಂದ ಮಾತ್ರ ರಕ್ಷಿಸುತ್ತದೆ.

ಆಕ್ರಮಣಕಾರರು ದಟ್ಟಣೆಯ ಮೇಲೆ ಸಕ್ರಿಯವಾಗಿ ಪ್ರಭಾವ ಬೀರುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುವಾಗ, ಮೇಲ್ ಸರ್ವರ್‌ಗಳ ನಡುವೆ ಪತ್ರಗಳನ್ನು ಪ್ರತಿಬಂಧಿಸುವ ಸಮಸ್ಯೆಯನ್ನು MTA-STS ಭಾಗಶಃ ನಿವಾರಿಸುತ್ತದೆ. ಸ್ವೀಕರಿಸುವವರ ಡೊಮೇನ್ MTA-STS ನೀತಿಯನ್ನು ಪ್ರಕಟಿಸಿದರೆ ಮತ್ತು ಕಳುಹಿಸುವವರ ಸರ್ವರ್ MTA-STS ಅನ್ನು ಬೆಂಬಲಿಸಿದರೆ, ಅದು ಇಮೇಲ್ ಅನ್ನು TLS ಸಂಪರ್ಕದ ಮೂಲಕ ಮಾತ್ರ ಕಳುಹಿಸುತ್ತದೆ, ನೀತಿಯಿಂದ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಸರ್ವರ್‌ಗಳಿಗೆ ಮತ್ತು ಸರ್ವರ್‌ನ ಪ್ರಮಾಣಪತ್ರದ ಪರಿಶೀಲನೆಯೊಂದಿಗೆ ಮಾತ್ರ.

ಏಕೆ ಭಾಗಶಃ? ಈ ಮಾನದಂಡವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಎರಡೂ ಪಕ್ಷಗಳು ಕಾಳಜಿ ವಹಿಸಿದರೆ ಮಾತ್ರ MTA-STS ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಆಕ್ರಮಣಕಾರರು ಸಾರ್ವಜನಿಕ CA ಗಳಲ್ಲಿ ಒಬ್ಬರಿಂದ ಮಾನ್ಯವಾದ ಡೊಮೇನ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗುವಂತಹ ಸನ್ನಿವೇಶಗಳಿಂದ MTA-STS ರಕ್ಷಿಸುವುದಿಲ್ಲ.

MTA-STS ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

ಸ್ವೀಕರಿಸುವವರು

ಮೇಲ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಮಾನ್ಯವಾದ ಪ್ರಮಾಣಪತ್ರದೊಂದಿಗೆ STARTTLS ಬೆಂಬಲವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ.
HTTPS ಮೂಲಕ MTA-STS ನೀತಿಯನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ; ವಿಶೇಷ mta-sts ಡೊಮೇನ್ ಮತ್ತು ವಿಶೇಷ ಪ್ರಸಿದ್ಧ ಮಾರ್ಗವನ್ನು ಪ್ರಕಟಣೆಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ https://mta-sts.mail.ru/.well-known/mta-sts.txt. ಈ ಡೊಮೇನ್‌ಗೆ ಮೇಲ್ ಸ್ವೀಕರಿಸುವ ಹಕ್ಕನ್ನು ಹೊಂದಿರುವ ಮೇಲ್ ಸರ್ವರ್‌ಗಳ (mx) ಪಟ್ಟಿಯನ್ನು ನೀತಿಯು ಒಳಗೊಂಡಿದೆ.
ನೀತಿಯ ಆವೃತ್ತಿಯೊಂದಿಗೆ DNS ನಲ್ಲಿ ವಿಶೇಷ TXT ದಾಖಲೆ _mta-sts ಅನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ. ನೀತಿಯನ್ನು ಬದಲಾಯಿಸಿದಾಗ, ಈ ನಮೂದನ್ನು ನವೀಕರಿಸಬೇಕು (ಇದು ಕಳುಹಿಸುವವರಿಗೆ ನೀತಿಯನ್ನು ಮರು-ಪ್ರಶ್ನೆ ಮಾಡಲು ಸಂಕೇತಿಸುತ್ತದೆ). ಉದಾಹರಣೆಗೆ, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

ಕಳುಹಿಸುವವರು

ಕಳುಹಿಸುವವರು _mta-sts DNS ದಾಖಲೆಯನ್ನು ವಿನಂತಿಸುತ್ತಾರೆ ಮತ್ತು ಅದು ಲಭ್ಯವಿದ್ದರೆ, HTTPS ಮೂಲಕ ನೀತಿ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತಾರೆ (ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ). ಪರಿಣಾಮವಾಗಿ ನೀತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ (ದಾಳಿಕೋರರು ಅದಕ್ಕೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸಿದರೆ ಅಥವಾ DNS ದಾಖಲೆಯನ್ನು ವಂಚಿಸಿದರೆ).

ಮೇಲ್ ಕಳುಹಿಸುವಾಗ, ಇದನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ:

ಮೇಲ್ ಅನ್ನು ತಲುಪಿಸುವ ಸರ್ವರ್ ನೀತಿಯಲ್ಲಿದೆ;
ಸರ್ವರ್ TLS (STARTTLS) ಬಳಸಿಕೊಂಡು ಮೇಲ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಮಾನ್ಯವಾದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಹೊಂದಿದೆ.

MTA-STS ನ ಪ್ರಯೋಜನಗಳು

MTA-STS ಬಹುತೇಕ ಸಂಸ್ಥೆಗಳಲ್ಲಿ ಈಗಾಗಲೇ ಅಳವಡಿಸಲಾಗಿರುವ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಬಳಸುತ್ತದೆ (SMTP+STARTTLS, HTTPS, DNS). ಸ್ವೀಕರಿಸುವವರ ಬದಿಯಲ್ಲಿ ಅನುಷ್ಠಾನಕ್ಕೆ, ಮಾನದಂಡಕ್ಕೆ ಯಾವುದೇ ವಿಶೇಷ ಸಾಫ್ಟ್‌ವೇರ್ ಬೆಂಬಲ ಅಗತ್ಯವಿಲ್ಲ.

MTA-STS ನ ಅನಾನುಕೂಲಗಳು

ವೆಬ್ ಮತ್ತು ಮೇಲ್ ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರದ ಮಾನ್ಯತೆ, ಹೆಸರುಗಳ ಪತ್ರವ್ಯವಹಾರ ಮತ್ತು ಸಮಯೋಚಿತ ನವೀಕರಣವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಅವಶ್ಯಕ. ಪ್ರಮಾಣಪತ್ರದೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳು ಮೇಲ್ ಅನ್ನು ತಲುಪಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ಕಳುಹಿಸುವವರ ಬದಿಯಲ್ಲಿ, MTA-STS ನೀತಿಗಳಿಗೆ ಬೆಂಬಲದೊಂದಿಗೆ MTA ಅಗತ್ಯವಿದೆ; ಪ್ರಸ್ತುತ, MTA-STS ಅನ್ನು MTA ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ.

MTA-STS ವಿಶ್ವಾಸಾರ್ಹ ಮೂಲ CAಗಳ ಪಟ್ಟಿಯನ್ನು ಬಳಸುತ್ತದೆ.

ಆಕ್ರಮಣಕಾರರು ಮಾನ್ಯವಾದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಬಳಸುವ ದಾಳಿಯಿಂದ MTA-STS ರಕ್ಷಿಸುವುದಿಲ್ಲ. ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸರ್ವರ್ ಬಳಿ MitM ಪ್ರಮಾಣಪತ್ರವನ್ನು ನೀಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಪ್ರಮಾಣಪತ್ರ ಪಾರದರ್ಶಕತೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಇಂತಹ ದಾಳಿಯನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದು. ಆದ್ದರಿಂದ, ಸಾಮಾನ್ಯವಾಗಿ, MTA-STS ಟ್ರಾಫಿಕ್ ಪ್ರತಿಬಂಧದ ಸಾಧ್ಯತೆಯನ್ನು ತಗ್ಗಿಸುತ್ತದೆ, ಆದರೆ ಸಂಪೂರ್ಣವಾಗಿ ನಿವಾರಿಸುವುದಿಲ್ಲ.

ಕೊನೆಯ ಎರಡು ಅಂಕಗಳು MTA-STS ಅನ್ನು SMTP (RFC 7672) ಗಾಗಿ ಸ್ಪರ್ಧಾತ್ಮಕ DANE ಮಾನದಂಡಕ್ಕಿಂತ ಕಡಿಮೆ ಸುರಕ್ಷಿತವಾಗಿಸುತ್ತವೆ, ಆದರೆ ಹೆಚ್ಚು ತಾಂತ್ರಿಕವಾಗಿ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ, ಅಂದರೆ. MTA-STS ಗಾಗಿ ಪ್ರಮಾಣಿತದ ಅನುಷ್ಠಾನದಿಂದ ಉಂಟಾದ ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಗಳಿಂದಾಗಿ ಪತ್ರವನ್ನು ತಲುಪಿಸಲಾಗುವುದಿಲ್ಲ ಎಂಬ ಕಡಿಮೆ ಸಂಭವನೀಯತೆಯಿದೆ.

ಸ್ಪರ್ಧಾತ್ಮಕ ಮಾನದಂಡ - DANE

ಪ್ರಮಾಣಪತ್ರ ಮಾಹಿತಿಯನ್ನು ಪ್ರಕಟಿಸಲು DANE DNSSEC ಅನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಬಾಹ್ಯ ಪ್ರಮಾಣಪತ್ರ ಪ್ರಾಧಿಕಾರಗಳಲ್ಲಿ ನಂಬಿಕೆಯ ಅಗತ್ಯವಿಲ್ಲ, ಇದು ಹೆಚ್ಚು ಸುರಕ್ಷಿತವಾಗಿದೆ. ಆದರೆ DNSSEC ಯ ಬಳಕೆಯು ಹಲವಾರು ವರ್ಷಗಳ ಬಳಕೆಯ ಅಂಕಿಅಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ಗಮನಾರ್ಹವಾಗಿ ತಾಂತ್ರಿಕ ವೈಫಲ್ಯಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ (ಆದಾಗ್ಯೂ DNSSEC ಮತ್ತು ಅದರ ತಾಂತ್ರಿಕ ಬೆಂಬಲದ ವಿಶ್ವಾಸಾರ್ಹತೆಯಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಧನಾತ್ಮಕ ಪ್ರವೃತ್ತಿ ಇದೆ). ಸ್ವೀಕರಿಸುವವರ ಬದಿಯಲ್ಲಿ SMTP ಯಲ್ಲಿ DANE ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, DNS ವಲಯಕ್ಕೆ DNSSEC ಉಪಸ್ಥಿತಿಯು ಕಡ್ಡಾಯವಾಗಿದೆ ಮತ್ತು NSEC/NSEC3 ಗಾಗಿ ಸರಿಯಾದ ಬೆಂಬಲವು DANE ಗೆ ಅತ್ಯಗತ್ಯವಾಗಿರುತ್ತದೆ, ಇದರೊಂದಿಗೆ DNSSEC ನಲ್ಲಿ ವ್ಯವಸ್ಥಿತ ಸಮಸ್ಯೆಗಳಿವೆ.

DNSSEC ಅನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡದಿದ್ದರೆ, ಕಳುಹಿಸುವ ಭಾಗವು DANE ಅನ್ನು ಬೆಂಬಲಿಸಿದರೆ, ಸ್ವೀಕರಿಸುವ ಭಾಗವು ಅದರ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲದಿದ್ದರೂ ಸಹ ಮೇಲ್ ವಿತರಣಾ ವೈಫಲ್ಯಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ಆದ್ದರಿಂದ, DANE ಹಳೆಯ ಮತ್ತು ಹೆಚ್ಚು ಸುರಕ್ಷಿತ ಮಾನದಂಡವಾಗಿದೆ ಮತ್ತು ಕಳುಹಿಸುವವರ ಬದಿಯಲ್ಲಿರುವ ಕೆಲವು ಸರ್ವರ್ ಸಾಫ್ಟ್‌ವೇರ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ ಬೆಂಬಲಿತವಾಗಿದೆ ಎಂಬ ಅಂಶದ ಹೊರತಾಗಿಯೂ, ವಾಸ್ತವವಾಗಿ ಅದರ ನುಗ್ಗುವಿಕೆಯು ಅತ್ಯಲ್ಪವಾಗಿ ಉಳಿದಿದೆ, DNSSEC ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಅಗತ್ಯತೆಯಿಂದಾಗಿ ಅನೇಕ ಸಂಸ್ಥೆಗಳು ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಿದ್ಧವಾಗಿಲ್ಲ. ಇದು ಮಾನದಂಡವು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದ ಎಲ್ಲಾ ವರ್ಷಗಳಲ್ಲಿ DANE ಅನುಷ್ಠಾನವನ್ನು ಗಣನೀಯವಾಗಿ ನಿಧಾನಗೊಳಿಸಿದೆ.

DANE ಮತ್ತು MTA-STS ಪರಸ್ಪರ ಸಂಘರ್ಷ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಒಟ್ಟಿಗೆ ಬಳಸಬಹುದು.

Mail.ru ಮೇಲ್‌ನಲ್ಲಿ MTA-STS ಬೆಂಬಲದೊಂದಿಗೆ ಏನಿದೆ?

Mail.ru ಎಲ್ಲಾ ಪ್ರಮುಖ ಡೊಮೇನ್‌ಗಳಿಗೆ ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ MTA-STS ನೀತಿಯನ್ನು ಪ್ರಕಟಿಸುತ್ತಿದೆ. ನಾವು ಪ್ರಸ್ತುತ ಸ್ಟ್ಯಾಂಡರ್ಡ್‌ನ ಕ್ಲೈಂಟ್ ಭಾಗವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತಿದ್ದೇವೆ. ಬರೆಯುವ ಸಮಯದಲ್ಲಿ, ನೀತಿಗಳನ್ನು ನಿರ್ಬಂಧಿಸದ ಮೋಡ್‌ನಲ್ಲಿ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ (ನೀತಿಯಿಂದ ವಿತರಣೆಯನ್ನು ನಿರ್ಬಂಧಿಸಿದರೆ, ನೀತಿಗಳನ್ನು ಅನ್ವಯಿಸದೆ ಪತ್ರವನ್ನು “ಬಿಡಿ” ಸರ್ವರ್ ಮೂಲಕ ತಲುಪಿಸಲಾಗುತ್ತದೆ), ನಂತರ ನಿರ್ಬಂಧಿಸುವ ಮೋಡ್ ಅನ್ನು ಸಣ್ಣ ಭಾಗಕ್ಕೆ ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ ಹೊರಹೋಗುವ SMTP ದಟ್ಟಣೆಯ, ಕ್ರಮೇಣ 100% ದಟ್ಟಣೆಗೆ ಇದು ನೀತಿಗಳ ಜಾರಿ ಬೆಂಬಲಿತವಾಗಿದೆ.

ಮಾನದಂಡವನ್ನು ಬೇರೆ ಯಾರು ಬೆಂಬಲಿಸುತ್ತಾರೆ?

ಇಲ್ಲಿಯವರೆಗೆ, MTA-STS ನೀತಿಗಳು ಸರಿಸುಮಾರು 0.05% ಸಕ್ರಿಯ ಡೊಮೇನ್‌ಗಳನ್ನು ಪ್ರಕಟಿಸುತ್ತವೆ, ಆದರೆ, ಆದಾಗ್ಯೂ, ಅವುಗಳು ಈಗಾಗಲೇ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಮೇಲ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ರಕ್ಷಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಅನ್ನು ಪ್ರಮುಖ ಆಟಗಾರರು ಬೆಂಬಲಿಸುತ್ತಾರೆ - Google, Comcast ಮತ್ತು ಭಾಗಶಃ ವೆರಿಝೋನ್ (AOL, Yahoo). ಇತರ ಹಲವು ಅಂಚೆ ಸೇವೆಗಳು ಗುಣಮಟ್ಟಕ್ಕೆ ಬೆಂಬಲವನ್ನು ಮುಂದಿನ ದಿನಗಳಲ್ಲಿ ಜಾರಿಗೆ ತರಲಾಗುವುದು ಎಂದು ಘೋಷಿಸಿವೆ.

ಇದು ನನ್ನ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ?

ನಿಮ್ಮ ಡೊಮೇನ್ MTA-STS ನೀತಿಯನ್ನು ಪ್ರಕಟಿಸದ ಹೊರತು ಅಲ್ಲ. ನೀವು ನೀತಿಯನ್ನು ಪ್ರಕಟಿಸಿದರೆ, ನಿಮ್ಮ ಮೇಲ್ ಸರ್ವರ್‌ನ ಬಳಕೆದಾರರ ಇಮೇಲ್‌ಗಳು ಪ್ರತಿಬಂಧಕದಿಂದ ಉತ್ತಮವಾಗಿ ರಕ್ಷಿಸಲ್ಪಡುತ್ತವೆ.

MTA-STS ಅನ್ನು ನಾನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು?

ಸ್ವೀಕರಿಸುವವರ ಬದಿಯಲ್ಲಿ MTA-STS ಬೆಂಬಲ

HTTPS ಮೂಲಕ ನೀತಿಯನ್ನು ಪ್ರಕಟಿಸಲು ಮತ್ತು DNS ನಲ್ಲಿ ದಾಖಲೆಗಳನ್ನು ಪ್ರಕಟಿಸಲು ಸಾಕು, MTA ಯಲ್ಲಿ STARTTLS ಗಾಗಿ (ಎಲ್ಲಾ ಆಧುನಿಕ MTA ಗಳಲ್ಲಿ STARTTLS ಬೆಂಬಲಿತವಾಗಿದೆ), ವಿಶ್ವಾಸಾರ್ಹ CA ಗಳಲ್ಲಿ ಒಂದರಿಂದ ಮಾನ್ಯ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ (ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡೋಣ). MTA ಅಗತ್ಯವಿದೆ.

ಹಂತ ಹಂತವಾಗಿ, ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ನೀವು ಬಳಸುತ್ತಿರುವ MTA ನಲ್ಲಿ STARTTLS ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ (postfix, exim, sendmail, Microsoft Exchange, ಇತ್ಯಾದಿ.).
ನೀವು ಮಾನ್ಯವಾದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಬಳಸುತ್ತಿರುವಿರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ (ವಿಶ್ವಾಸಾರ್ಹ CA ಯಿಂದ ನೀಡಲಾಗಿದೆ, ಅವಧಿ ಮುಗಿದಿಲ್ಲ, ಪ್ರಮಾಣಪತ್ರದ ವಿಷಯವು ನಿಮ್ಮ ಡೊಮೇನ್‌ಗೆ ಮೇಲ್ ಅನ್ನು ತಲುಪಿಸುವ MX ದಾಖಲೆಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ).
TLS-RPT ದಾಖಲೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ ಅದರ ಮೂಲಕ ನೀತಿ ಅಪ್ಲಿಕೇಶನ್ ವರದಿಗಳನ್ನು ತಲುಪಿಸಲಾಗುತ್ತದೆ (TLS ವರದಿಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ಬೆಂಬಲಿಸುವ ಸೇವೆಗಳಿಂದ). ಉದಾಹರಣೆ ನಮೂದು (ಉದಾಹರಣೆ.com ಡೊಮೇನ್‌ಗಾಗಿ):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
ಈ ನಮೂದು SMTP ಯಲ್ಲಿ TLS ಬಳಕೆಯ ಅಂಕಿಅಂಶಗಳ ವರದಿಗಳನ್ನು ಕಳುಹಿಸಲು ಮೇಲ್ ಕಳುಹಿಸುವವರಿಗೆ ಸೂಚನೆ ನೀಡುತ್ತದೆ [email protected].

ಯಾವುದೇ ದೋಷಗಳಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಹಲವಾರು ದಿನಗಳವರೆಗೆ ವರದಿಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ.
HTTPS ಮೂಲಕ MTA-STS ನೀತಿಯನ್ನು ಪ್ರಕಟಿಸಿ. ನೀತಿಯನ್ನು ಸ್ಥಳದ ಮೂಲಕ CRLF ಲೈನ್ ಟರ್ಮಿನೇಟರ್‌ಗಳೊಂದಿಗೆ ಪಠ್ಯ ಫೈಲ್‌ನಂತೆ ಪ್ರಕಟಿಸಲಾಗಿದೆ.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
ಉದಾಹರಣೆ ನೀತಿ:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
ಆವೃತ್ತಿಯ ಕ್ಷೇತ್ರವು ನೀತಿಯ ಆವೃತ್ತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ (ಪ್ರಸ್ತುತ STSv1), ಮೋಡ್ ನೀತಿ ಅಪ್ಲಿಕೇಶನ್ ಮೋಡ್ ಅನ್ನು ಹೊಂದಿಸುತ್ತದೆ, ಪರೀಕ್ಷೆ - ಪರೀಕ್ಷಾ ಮೋಡ್ (ನೀತಿಯನ್ನು ಅನ್ವಯಿಸಲಾಗಿಲ್ಲ), ಜಾರಿಗೊಳಿಸಿ - "ಯುದ್ಧ" ಮೋಡ್. ಮೊದಲು ನೀತಿಯನ್ನು ಮೋಡ್‌ನೊಂದಿಗೆ ಪ್ರಕಟಿಸಿ: ಪರೀಕ್ಷೆ, ಪರೀಕ್ಷಾ ಮೋಡ್‌ನಲ್ಲಿ ನೀತಿಯಲ್ಲಿ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲದಿದ್ದರೆ, ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ನೀವು ಮೋಡ್‌ಗೆ ಬದಲಾಯಿಸಬಹುದು: ಜಾರಿಗೊಳಿಸಿ.

mx ನಲ್ಲಿ, ನಿಮ್ಮ ಡೊಮೇನ್‌ಗೆ ಮೇಲ್ ಅನ್ನು ಸ್ವೀಕರಿಸಬಹುದಾದ ಎಲ್ಲಾ ಮೇಲ್ ಸರ್ವರ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ (ಪ್ರತಿ ಸರ್ವರ್ mx ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಹೆಸರಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿರಬೇಕು). Max_age ನೀತಿಯ ಕ್ಯಾಶಿಂಗ್ ಸಮಯವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ (ಒಮ್ಮೆ ನೆನಪಿಸಿಕೊಳ್ಳುವ ನೀತಿಯನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ, ದಾಳಿಕೋರರು ಅದರ ವಿತರಣೆಯನ್ನು ನಿರ್ಬಂಧಿಸಿದರೂ ಅಥವಾ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಸಮಯದಲ್ಲಿ DNS ದಾಖಲೆಗಳನ್ನು ಭ್ರಷ್ಟಗೊಳಿಸಿದರೂ ಸಹ, mta-sts DNS ಅನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ ನೀತಿಯನ್ನು ಮತ್ತೊಮ್ಮೆ ವಿನಂತಿಸುವ ಅಗತ್ಯವನ್ನು ನೀವು ಸೂಚಿಸಬಹುದು ದಾಖಲೆ).
DNS ನಲ್ಲಿ TXT ದಾಖಲೆಯನ್ನು ಪ್ರಕಟಿಸಿ:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
ಐಡಿ ಕ್ಷೇತ್ರದಲ್ಲಿ ಅನಿಯಂತ್ರಿತ ಗುರುತಿಸುವಿಕೆಯನ್ನು (ಉದಾಹರಣೆಗೆ, ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್) ಬಳಸಬಹುದು; ನೀತಿಯು ಬದಲಾದಾಗ, ಅದು ಬದಲಾಗಬೇಕು, ಇದು ಕಳುಹಿಸುವವರಿಗೆ ಅವರು ಕ್ಯಾಶ್ ಮಾಡಲಾದ ನೀತಿಯನ್ನು ಮರು ವಿನಂತಿಸುವ ಅಗತ್ಯವಿದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅನುಮತಿಸುತ್ತದೆ (ಐಡೆಂಟಿಫೈಯರ್ ಬೇರೆಯಾಗಿದ್ದರೆ ಒಂದು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ).

ಕಳುಹಿಸುವವರ ಬದಿಯಲ್ಲಿ MTA-STS ಬೆಂಬಲ

ಇಲ್ಲಿಯವರೆಗೆ ಅದು ಅವಳೊಂದಿಗೆ ಕೆಟ್ಟದ್ದಾಗಿದೆ, ಏಕೆಂದರೆ ... ತಾಜಾ ಗುಣಮಟ್ಟ.

Exim - ಯಾವುದೇ ಅಂತರ್ನಿರ್ಮಿತ ಬೆಂಬಲವಿಲ್ಲ, ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸ್ಕ್ರಿಪ್ಟ್ ಇದೆ https://github.com/Bobberty/MTASTS-EXIM-PERL
ಪೋಸ್ಟ್ಫಿಕ್ಸ್ - ಯಾವುದೇ ಅಂತರ್ನಿರ್ಮಿತ ಬೆಂಬಲವಿಲ್ಲ, ಹಬ್ರೆಯಲ್ಲಿ ವಿವರವಾಗಿ ವಿವರಿಸಲಾದ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸ್ಕ್ರಿಪ್ಟ್ ಇದೆ https://habr.com/en/post/424961/

"ಕಡ್ಡಾಯ TLS" ಬಗ್ಗೆ ಒಂದು ನಂತರದ ಪದವಾಗಿ

ಇತ್ತೀಚೆಗೆ, ನಿಯಂತ್ರಕರು ಇಮೇಲ್ ಭದ್ರತೆಗೆ ಗಮನ ಕೊಡುತ್ತಿದ್ದಾರೆ (ಮತ್ತು ಅದು ಒಳ್ಳೆಯದು). ಉದಾಹರಣೆಗೆ, ಯುನೈಟೆಡ್ ಸ್ಟೇಟ್ಸ್‌ನಲ್ಲಿನ ಎಲ್ಲಾ ಸರ್ಕಾರಿ ಸಂಸ್ಥೆಗಳಿಗೆ DMARC ಕಡ್ಡಾಯವಾಗಿದೆ ಮತ್ತು ಹಣಕಾಸಿನ ವಲಯದಲ್ಲಿ ಹೆಚ್ಚು ಅಗತ್ಯವಿದೆ, ಪ್ರಮಾಣಿತದ ಒಳಹೊಕ್ಕು ನಿಯಂತ್ರಿತ ಪ್ರದೇಶಗಳಲ್ಲಿ 90% ತಲುಪುತ್ತದೆ. ಈಗ ಕೆಲವು ನಿಯಂತ್ರಕರಿಗೆ ವೈಯಕ್ತಿಕ ಡೊಮೇನ್‌ಗಳೊಂದಿಗೆ "ಕಡ್ಡಾಯ ಟಿಎಲ್‌ಎಸ್" ಅನುಷ್ಠಾನದ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದರೆ "ಕಡ್ಡಾಯ ಟಿಎಲ್‌ಎಸ್" ಅನ್ನು ಖಾತ್ರಿಪಡಿಸುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಈ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಹೆಚ್ಚಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಅದು ಈಗಾಗಲೇ ನೈಜ ದಾಳಿಯಿಂದ ಕನಿಷ್ಠವಾಗಿ ರಕ್ಷಿಸುವುದಿಲ್ಲ. DANE ಅಥವಾ MTA-STS ನಂತಹ ಕಾರ್ಯವಿಧಾನಗಳಲ್ಲಿ ಒದಗಿಸಲಾಗಿದೆ.

ನಿಯಂತ್ರಕಕ್ಕೆ ಪ್ರತ್ಯೇಕ ಡೊಮೇನ್‌ಗಳೊಂದಿಗೆ "ಕಡ್ಡಾಯ TLS" ಅನುಷ್ಠಾನದ ಅಗತ್ಯವಿದ್ದರೆ, MTA-STS ಅಥವಾ ಅದರ ಭಾಗಶಃ ಅನಲಾಗ್ ಅನ್ನು ಅತ್ಯಂತ ಸೂಕ್ತವಾದ ಕಾರ್ಯವಿಧಾನವಾಗಿ ಪರಿಗಣಿಸಲು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ, ಇದು ಪ್ರತಿ ಡೊಮೇನ್‌ಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಸುರಕ್ಷಿತ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಮಾಡುವ ಅಗತ್ಯವನ್ನು ನಿವಾರಿಸುತ್ತದೆ. MTA-STS ನ ಕ್ಲೈಂಟ್ ಭಾಗವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಿಮಗೆ ತೊಂದರೆಗಳಿದ್ದರೆ (ಪ್ರೋಟೋಕಾಲ್ ವ್ಯಾಪಕವಾದ ಬೆಂಬಲವನ್ನು ಪಡೆಯುವವರೆಗೆ, ಅವರು ಹೆಚ್ಚಾಗಿ ಮಾಡುತ್ತಾರೆ), ನಾವು ಈ ವಿಧಾನವನ್ನು ಶಿಫಾರಸು ಮಾಡಬಹುದು:

MTA-STS ನೀತಿ ಮತ್ತು/ಅಥವಾ DANE ದಾಖಲೆಗಳನ್ನು ಪ್ರಕಟಿಸಿ (ನಿಮ್ಮ ಡೊಮೇನ್‌ಗಾಗಿ DNSSEC ಅನ್ನು ಈಗಾಗಲೇ ಸಕ್ರಿಯಗೊಳಿಸಿದ್ದರೆ ಮಾತ್ರ DANE ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ ಮತ್ತು ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ MTA-STS), ಇದು ನಿಮ್ಮ ದಿಕ್ಕಿನಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ರಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ಇತರ ಮೇಲ್ ಸೇವೆಗಳನ್ನು ಕೇಳುವ ಅಗತ್ಯವನ್ನು ನಿವಾರಿಸುತ್ತದೆ ಮೇಲ್ ಸೇವೆಯು ಈಗಾಗಲೇ MTA-STS ಮತ್ತು/ಅಥವಾ DANE ಅನ್ನು ಬೆಂಬಲಿಸಿದರೆ ನಿಮ್ಮ ಡೊಮೇನ್‌ಗಾಗಿ ಕಡ್ಡಾಯ TLS ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು.
ದೊಡ್ಡ ಇಮೇಲ್ ಸೇವೆಗಳಿಗಾಗಿ, ಪ್ರತಿ ಡೊಮೇನ್‌ಗೆ ಪ್ರತ್ಯೇಕ ಸಾರಿಗೆ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಮೂಲಕ MTA-STS ನ "ಅನಾಲಾಗ್" ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ, ಇದು ಮೇಲ್ ಪ್ರಸಾರಕ್ಕಾಗಿ ಬಳಸಲಾದ MX ಅನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ TLS ಪ್ರಮಾಣಪತ್ರದ ಕಡ್ಡಾಯ ಪರಿಶೀಲನೆ ಅಗತ್ಯವಿರುತ್ತದೆ. ಡೊಮೇನ್‌ಗಳು ಈಗಾಗಲೇ MTA-STS ನೀತಿಯನ್ನು ಪ್ರಕಟಿಸಿದರೆ, ಇದನ್ನು ನೋವುರಹಿತವಾಗಿ ಮಾಡಬಹುದು. ಸ್ವತಃ, ರಿಲೇ ಅನ್ನು ಸರಿಪಡಿಸದೆ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪರಿಶೀಲಿಸದೆಯೇ ಡೊಮೇನ್‌ಗೆ ಕಡ್ಡಾಯ TLS ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಭದ್ರತಾ ದೃಷ್ಟಿಕೋನದಿಂದ ನಿಷ್ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ STARTTLS ಕಾರ್ಯವಿಧಾನಗಳಿಗೆ ಏನನ್ನೂ ಸೇರಿಸುವುದಿಲ್ಲ.

ಮೂಲ: www.habr.com

Mail.ru ಮೇಲ್ MTA-STS ನೀತಿಗಳನ್ನು ಪರೀಕ್ಷಾ ಕ್ರಮದಲ್ಲಿ ಅನ್ವಯಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ