කෙටියෙන් කිවහොත්, 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 ක්‍රියා කරන ආකාරය

ලබන්නා

1. තැපැල් සේවාදායකයේ වලංගු සහතිකයක් සමඟ STARTTLS සහාය වින්‍යාස කරයි. 
2. HTTPS හරහා MTA-STS ප්‍රතිපත්තිය ප්‍රකාශයට පත් කරයි; උදාහරණයක් ලෙස ප්‍රකාශනය සඳහා විශේෂ mta-sts වසමක් සහ විශේෂ සුප්‍රසිද්ධ මාර්ගයක් භාවිත කෙරේ. https://mta-sts.mail.ru/.well-known/mta-sts.txt. මෙම වසම සඳහා තැපැල් ලැබීමට අයිතිය ඇති තැපැල් සේවාදායක (mx) ලැයිස්තුවක් ප්‍රතිපත්තියේ අඩංගු වේ.
3. ප්‍රතිපත්ති අනුවාදය සමඟ 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 ප්‍රමිතියට වඩා අඩු ආරක්ෂිත කරයි, නමුත් වඩා තාක්ෂණික වශයෙන් විශ්වාසදායකය, i.e. MTA-STS සඳහා ප්‍රමිතිය ක්‍රියාත්මක කිරීම නිසා ඇති වන තාක්ෂණික ගැටළු හේතුවෙන් ලිපිය භාර නොදීමට අඩු සම්භාවිතාවක් ඇත.

තරඟකාරී සම්මතය - DANE

සහතික තොරතුරු ප්‍රකාශයට පත් කිරීමට DANE DNSSEC භාවිතා කරන අතර වඩා ආරක්ෂිත වන බාහිර සහතික බලධාරීන් කෙරෙහි විශ්වාසයක් අවශ්‍ය නොවේ. නමුත් DNSSEC භාවිතය සැලකිය යුතු ලෙස බොහෝ විට තාක්ෂණික අසමත්වීම් වලට තුඩු දෙයි, වසර කිහිපයක භාවිතයේ සංඛ්‍යාලේඛන මත පදනම්ව (සාමාන්‍යයෙන් DNSSEC හි විශ්වසනීයත්වය සහ එහි තාක්ෂණික සහාය පිළිබඳ ධනාත්මක ප්‍රවණතාවක් ඇතත්). ලබන්නාගේ පැත්තෙන් SMTP හි DANE ක්‍රියාත්මක කිරීම සඳහා, DNS කලාපය සඳහා DNSSEC තිබීම අනිවාර්ය වන අතර DNSSEC හි පද්ධතිමය ගැටළු ඇති DANE සඳහා NSEC/NSEC3 සඳහා නිවැරදි සහාය අත්‍යවශ්‍ය වේ.

DNSSEC නිවැරදිව වින්‍යාස කර නොමැති නම්, ලැබෙන පාර්ශවය ඒ ගැන කිසිවක් නොදැන සිටියද, යැවීමේ පැත්ත DANE සඳහා සහය දක්වන්නේ නම්, තැපැල් බෙදා හැරීම අසාර්ථක වීමට හේතු විය හැක. එබැවින්, DANE පැරණි සහ වඩාත් ආරක්ෂිත ප්‍රමිතියක් වන අතර යවන්නාගේ පැත්තේ සමහර සේවාදායක මෘදුකාංගවල දැනටමත් සහය ලබා ඇතත්, ඇත්ත වශයෙන්ම එහි විනිවිද යාම නොවැදගත් ලෙස පවතී, DNSSEC ක්‍රියාත්මක කිරීමේ අවශ්‍යතාවය හේතුවෙන් බොහෝ සංවිධාන එය ක්‍රියාත්මක කිරීමට සූදානම් නැත. මෙය ප්‍රමිතිය පැවති වසර ගණනාව තුළ DANE ක්‍රියාත්මක කිරීම සැලකිය යුතු ලෙස මන්දගාමී කර ඇත.

DANE සහ MTA-STS එකිනෙක ගැටෙන්නේ නැති අතර එකට භාවිතා කළ හැක.

Mail.ru තැපෑලෙහි MTA-STS සහාය සමඟ ඇත්තේ කුමක්ද?

Mail.ru බොහෝ කාලයක් තිස්සේ සියලුම ප්‍රධාන වසම් සඳහා MTA-STS ප්‍රතිපත්තියක් ප්‍රකාශයට පත් කර ඇත. අපි දැනට ප්‍රමිතියේ සේවාදායක කොටස ක්‍රියාත්මක කරමින් සිටිමු. ලියන අවස්ථාවේදී, ප්‍රතිපත්ති අවහිර නොවන ආකාරයෙන් යොදනු ලැබේ (ප්‍රතිපත්තියක් මඟින් බෙදා හැරීම අවහිර කර ඇත්නම්, ප්‍රතිපත්ති යෙදීමෙන් තොරව ලිපිය “අමතර” සේවාදායකයක් හරහා ලබා දෙනු ඇත), එවිට අවහිර කිරීමේ මාදිලිය කුඩා කොටසකට බල කෙරෙනු ඇත. පිටතට යන SMTP ගමනාගමනයෙන්, ක්‍රමයෙන් 100% ගමනාගමනය සඳහා එය ප්‍රතිපත්ති බලාත්මක කිරීම සඳහා සහය දක්වයි.

සම්මතයට අනුබල දෙන්නේ වෙන කවුද?

මෙතෙක්, MTA-STS ප්‍රතිපත්ති මඟින් සක්‍රීය වසම් වලින් 0.05% ක් පමණ ප්‍රකාශයට පත් කරයි, නමුත්, කෙසේ වෙතත්, ඒවා දැනටමත් විශාල තැපැල් ගමනාගමනයක් ආරක්ෂා කරයි, මන්ද ප්‍රමිතියට ප්‍රධාන ක්‍රීඩකයින් සහාය දක්වයි - Google, Comcast සහ අර්ධ වශයෙන් Verizon (AOL, Yahoo). තවත් බොහෝ තැපැල් සේවා ප්‍රමිතිය සඳහා සහය නුදුරු අනාගතයේදී ක්‍රියාත්මක කරන බව නිවේදනය කර ඇත.

මෙය මට කෙසේ බලපානු ඇත්ද?

ඔබේ වසම MTA-STS ප්‍රතිපත්තියක් ප්‍රකාශ කරන්නේ නම් මිස නොවේ. ඔබ ප්‍රතිපත්තිය ප්‍රකාශයට පත් කරන්නේ නම්, ඔබේ තැපැල් සේවාදායකයේ පරිශීලකයින් සඳහා වන විද්‍යුත් තැපෑල වඩා හොඳින් බාධා කිරීම් වලින් ආරක්ෂා වනු ඇත.

MTA-STS ක්‍රියාත්මක කරන්නේ කෙසේද?

ලබන්නාගේ පැත්තෙන් MTA-STS සහාය

HTTPS හරහා ප්‍රතිපත්තිය ප්‍රකාශයට පත් කිරීම සහ DNS හි වාර්තා කිරීම ප්‍රමාණවත් වේ, MTA හි STARTTLS සඳහා විශ්වාසදායක CAs (අපි සංකේතනය කරමු) එකකින් වලංගු සහතිකයක් වින්‍යාස කිරීම (STARTTLS සියලුම නවීන MTAs සඳහා සහය දක්වයි), වෙතින් විශේෂ සහායක් නොමැත. MTA අවශ්‍යයි.

පියවරෙන් පියවර, එය මේ වගේ ය:

1. ඔබ භාවිතා කරන MTA තුළ STARTTLS වින්‍යාස කරන්න (postfix, exim, sendmail, Microsoft Exchange, ආදිය).
2. ඔබ වලංගු සහතිකයක් භාවිතා කරන බවට සහතික කර ගන්න (විශ්වාසදායී CA විසින් නිකුත් කරන ලද, කල් ඉකුත් වී නැත, සහතිකයේ විෂය ඔබගේ වසම සඳහා තැපෑල ලබා දෙන MX වාර්තාවට ගැලපේ).
3. ප්‍රතිපත්ති යෙදුම් වාර්තා ලබා දෙන TLS-RPT වාර්තාවක් වින්‍යාස කරන්න (TLS වාර්තා යැවීමට සහාය වන සේවාවන් මගින්). උදාහරණ ඇතුළත් කිරීම (උදාහරණ.com වසම සඳහා):

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»

   මෙම ප්‍රවේශය තැපැල් යවන්නන්ට SMTP හි TLS භාවිතය පිළිබඳ සංඛ්‍යාන වාර්තා යැවීමට උපදෙස් දෙයි [email protected].

   දෝෂ නොමැති බවට වග බලා ගැනීම සඳහා දින කිහිපයක් සඳහා වාර්තා නිරීක්ෂණය කරන්න.

4. 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 වෙනස් කිරීමෙන් නැවත ප්‍රතිපත්තිය ඉල්ලීමේ අවශ්‍යතාව සංඥා කළ හැක. වාර්තාව).

5. DNS හි TXT වාර්තාවක් ප්‍රකාශයට පත් කරන්න: 

   _mta-sts.example.com. TXT “v=STS1; id=someid;”
   

   id ක්ෂේත්‍රය තුළ අත්තනෝමතික හැඳුනුම්කාරකයක් (උදාහරණයක් ලෙස, වේලා මුද්‍රාවක්) භාවිත කළ හැක; ප්‍රතිපත්ති වෙනස් වූ විට, එය වෙනස් විය යුතුය, මෙය යවන්නන්ට හැඹිලිගත ප්‍රතිපත්තිය නැවත ඉල්ලීමට අවශ්‍ය බව තේරුම් ගැනීමට ඉඩ සලසයි (හඳුනාගැනීම වෙනස් නම් හැඹිලිගත එකක්).

යවන්නාගේ පැත්තෙන් MTA-STS සහාය

මෙතෙක් එය ඇය සමඟ නරකයි, මන්ද ... නැවුම් සම්මත.

• Exim - ගොඩනඟන ලද සහාය නැත, තෙවන පාර්ශවීය ස්ක්‍රිප්ට් එකක් ඇත https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix - ගොඩනඟන ලද ආධාරකයක් නොමැත, Habré හි විස්තරාත්මකව විස්තර කර ඇති තෙවන පාර්ශවීය පිටපතක් ඇත https://habr.com/en/post/424961/

"අනිවාර්ය TLS" පිළිබඳ පසු වදනක් ලෙස

මෑතකදී, නියාමකයින් ඊමේල් ආරක්ෂාව කෙරෙහි අවධානය යොමු කර ඇත (එය හොඳ දෙයක්). උදාහරණයක් ලෙස, එක්සත් ජනපදයේ සියලුම රාජ්‍ය ආයතන සඳහා DMARC අනිවාර්ය වන අතර එය මූල්‍ය අංශයේ වැඩි වැඩියෙන් අවශ්‍ය වේ, ප්‍රමිතියේ විනිවිද යාම නියාමනය කරන ලද ප්‍රදේශවල 90% දක්වා ළඟා වේ. දැන් සමහර නියාමකයින්ට තනි වසම් සමඟ “අනිවාර්‍ය TLS” ක්‍රියාත්මක කිරීම අවශ්‍ය වේ, නමුත් “අනිවාර්‍ය TLS” සහතික කිරීමේ යාන්ත්‍රණය නිර්වචනය කර නොමැති අතර ප්‍රායෝගිකව මෙම සැකසුම බොහෝ විට ක්‍රියාත්මක වන්නේ දැනටමත් පවතින සැබෑ ප්‍රහාරවලින් අවම වශයෙන් පවා ආරක්ෂා නොවන ආකාරයට ය. DANE හෝ MTA-STS වැනි යාන්ත්‍රණ සඳහා සපයා ඇත.

නියාමකයාට වෙනම වසම් සමඟ “අනිවාර්‍ය TLS” ක්‍රියාත්මක කිරීමට අවශ්‍ය නම්, අපි වඩාත් සුදුසු යාන්ත්‍රණය ලෙස MTA-STS හෝ එහි අර්ධ ප්‍රතිසමය සලකා බැලීමට නිර්දේශ කරමු, එය එක් එක් වසම සඳහා වෙන වෙනම ආරක්ෂිත සැකසුම් සෑදීමේ අවශ්‍යතාවය ඉවත් කරයි. MTA-STS හි සේවාදායක කොටස ක්‍රියාත්මක කිරීමේදී ඔබට දුෂ්කරතා තිබේ නම් (ප්‍රොටෝකෝලයට පුලුල් සහය ලැබෙන තුරු, ඔවුන් බොහෝ දුරට ඉඩ ඇත), අපට මෙම ප්‍රවේශය නිර්දේශ කළ හැකිය:

1. MTA-STS ප්‍රතිපත්තියක් සහ/හෝ DANE වාර්තා ප්‍රකාශ කරන්න (DANE අර්ථවත් වන්නේ ඔබේ වසම සඳහා DNSSEC දැනටමත් සක්‍රීය කර ඇත්නම් සහ MTA-STS ඕනෑම අවස්ථාවක), මෙය ඔබේ දිශාවට ගමනාගමනය ආරක්ෂා කරන අතර වෙනත් තැපැල් සේවා විමසීමේ අවශ්‍යතාවය ඉවත් කරයි. තැපැල් සේවාව දැනටමත් MTA-STS සහ/හෝ DANE සඳහා සහය දක්වන්නේ නම් ඔබේ වසම සඳහා අනිවාර්ය TLS වින්‍යාස කිරීමට.
2. විශාල විද්‍යුත් තැපැල් සේවා සඳහා, එක් එක් වසම සඳහා වෙන වෙනම ප්‍රවාහන සැකසුම් හරහා MTA-STS හි “ඇනලොග්” ක්‍රියාවට නංවන්න, එය තැපැල් යැවීම සඳහා භාවිතා කරන MX නිවැරදි කරන අතර ඒ සඳහා TLS සහතිකයක් අනිවාර්යයෙන් තහවුරු කිරීම අවශ්‍ය වේ. වසම් දැනටමත් MTA-STS ප්‍රතිපත්තියක් ප්‍රකාශ කරන්නේ නම්, මෙය වේදනා රහිතව සිදු කළ හැක. එය විසින්ම, රිලේ සවි කිරීමකින් තොරව වසම සඳහා අනිවාර්ය TLS සක්‍රීය කිරීම සහ ඒ සඳහා සහතිකය සත්‍යාපනය කිරීම ආරක්ෂක දෘෂ්ටි කෝණයකින් අකාර්යක්ෂම වන අතර පවතින STARTTLS යාන්ත්‍රණවලට කිසිවක් එකතු නොකරයි.

මූලාශ්රය: www.habr.com