சுருக்கமாக, MTA-STS என்பது மின்னஞ்சல் சேவையகங்களுக்கு இடையே அனுப்பப்படும் போது குறுக்கீடு (அதாவது, மேன்-இன்-தி-மிடில் அட்டாக்ஸ் aka 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 இன் நன்மைகள்

பெரும்பாலான நிறுவனங்களில் (SMTP+STARTTLS, HTTPS, DNS) ஏற்கனவே செயல்படுத்தப்பட்ட தொழில்நுட்பங்களை MTA-STS பயன்படுத்துகிறது. பெறுநர் பக்கத்தில் செயல்படுத்த, தரநிலைக்கு சிறப்பு மென்பொருள் ஆதரவு தேவையில்லை.

MTA-STS இன் தீமைகள்

இணையம் மற்றும் அஞ்சல் சேவையக சான்றிதழின் செல்லுபடியாகும் தன்மை, பெயர்களின் கடிதப் பரிமாற்றம் மற்றும் சரியான நேரத்தில் புதுப்பித்தல் ஆகியவற்றைக் கண்காணிக்க வேண்டியது அவசியம். சான்றிதழில் உள்ள சிக்கல்கள் அஞ்சல் அனுப்ப முடியாமல் போகும்.

அனுப்புநரின் பக்கத்தில், MTA-STS கொள்கைகளுக்கான ஆதரவுடன் MTA தேவை; தற்போது, ​​MTA-STS ஆனது MTA இல் உள்ள பெட்டிக்கு வெளியே ஆதரிக்கப்படவில்லை.

MTA-STS நம்பகமான ரூட் CAகளின் பட்டியலைப் பயன்படுத்துகிறது.

தாக்குபவர் சரியான சான்றிதழைப் பயன்படுத்தும் தாக்குதல்களுக்கு எதிராக MTA-STS பாதுகாக்காது. பெரும்பாலான சந்தர்ப்பங்களில், சேவையகத்திற்கு அருகிலுள்ள MitM ஒரு சான்றிதழை வழங்கும் திறனைக் குறிக்கிறது. சான்றிதழ் வெளிப்படைத்தன்மையைப் பயன்படுத்தி இத்தகைய தாக்குதலைக் கண்டறியலாம். எனவே, பொதுவாக, MTA-STS போக்குவரத்து இடைமறிப்பு சாத்தியத்தை குறைக்கிறது, ஆனால் முற்றிலும் அகற்றாது.

கடைசி இரண்டு புள்ளிகள் SMTP (RFC 7672) க்கான போட்டியிடும் DANE தரநிலையை விட MTA-STS ஐக் குறைவான பாதுகாப்பானதாக்குகிறது, ஆனால் தொழில்நுட்ப ரீதியாக மிகவும் நம்பகமானது, அதாவது. 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 மற்றும் ஓரளவு Verizon (AOL, Yahoo). மற்ற பல அஞ்சல் சேவைகள் தரநிலைக்கான ஆதரவு விரைவில் எதிர்காலத்தில் செயல்படுத்தப்படும் என்று அறிவித்துள்ளன.

இது என்னை எப்படி பாதிக்கும்?

உங்கள் டொமைன் MTA-STS கொள்கையை வெளியிடும் வரை இல்லை. நீங்கள் கொள்கையை வெளியிட்டால், உங்கள் அஞ்சல் சேவையகத்தின் பயனர்களுக்கான மின்னஞ்சல்கள் இடைமறிப்பதில் இருந்து சிறப்பாகப் பாதுகாக்கப்படும்.

MTA-STS ஐ எவ்வாறு செயல்படுத்துவது?

பெறுநரின் பக்கத்தில் MTA-STS ஆதரவு

கொள்கையை HTTPS மூலமாகவும், DNSல் பதிவுகள் மூலமாகவும் வெளியிடுவது போதுமானது, MTA இல் STARTTLS க்கு நம்பகமான CA களில் ஒன்றின் (என்கிரிப்ட் செய்யலாம்) செல்லுபடியாகும் சான்றிதழை உள்ளமைக்கவும் (எல்லா நவீன MTAக்களிலும் STARTTLS ஆதரிக்கப்படுகிறது), எந்த சிறப்பு ஆதரவும் இல்லை. MTA தேவை.

படிப்படியாக, இது போல் தெரிகிறது:

1. நீங்கள் பயன்படுத்தும் MTA இல் STARTTLSஐ உள்ளமைக்கவும் (postfix, exim, sendmail, Microsoft Exchange, முதலியன).
2. நீங்கள் சரியான சான்றிதழைப் பயன்படுத்துகிறீர்கள் என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள் (நம்பகமான CA ஆல் வழங்கப்பட்டது, காலாவதியாகவில்லை, சான்றிதழின் பொருள் உங்கள் டொமைனுக்கான அஞ்சலை வழங்கும் MX பதிவோடு பொருந்துகிறது).
3. TLS-RPT பதிவை உள்ளமைக்கவும், இதன் மூலம் கொள்கை பயன்பாட்டு அறிக்கைகள் வழங்கப்படும் (TLS அறிக்கைகளை அனுப்புவதை ஆதரிக்கும் சேவைகள் மூலம்). எடுத்துக்காட்டு உள்ளீடு (example.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. டிஎன்எஸ்ஸில் 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% ஐ எட்டுகிறது. இப்போது சில கட்டுப்பாட்டாளர்கள் தனிப்பட்ட டொமைன்களுடன் "கட்டாய TLS" ஐ செயல்படுத்த வேண்டும், ஆனால் "கட்டாய TLS" ஐ உறுதி செய்வதற்கான வழிமுறை வரையறுக்கப்படவில்லை மற்றும் நடைமுறையில் இந்த அமைப்பு பெரும்பாலும் ஏற்கனவே இருக்கும் உண்மையான தாக்குதல்களுக்கு எதிராக குறைந்தபட்சம் கூட பாதுகாக்காத வகையில் செயல்படுத்தப்படுகிறது. DANE அல்லது MTA-STS போன்ற வழிமுறைகளில் வழங்கப்படுகிறது.

தனித்தனி டொமைன்களுடன் "கட்டாய TLS" ஐ ஒழுங்குபடுத்துவதற்கு ரெகுலேட்டருக்கு தேவைப்பட்டால், MTA-STS அல்லது அதன் பகுதி அனலாக் மிகவும் பொருத்தமான பொறிமுறையாகக் கருத பரிந்துரைக்கிறோம், ஒவ்வொரு டொமைனுக்கும் தனித்தனியாக பாதுகாப்பான அமைப்புகளை உருவாக்க வேண்டிய அவசியத்தை இது நீக்குகிறது. MTA-STS இன் கிளையன்ட் பகுதியை செயல்படுத்துவதில் உங்களுக்கு சிக்கல்கள் இருந்தால் (நெறிமுறை பரவலான ஆதரவைப் பெறும் வரை, அவை பெரும்பாலும் இருக்கும்), இந்த அணுகுமுறையை நாங்கள் பரிந்துரைக்கலாம்:

1. ஒரு MTA-STS கொள்கை மற்றும்/அல்லது DANE பதிவுகளை வெளியிடவும் (DNSSEC ஏற்கனவே உங்கள் டொமைனுக்காக இயக்கப்பட்டிருந்தால் மட்டுமே DANE பயன்தரும், மற்றும் MTA-STS எப்படியிருந்தாலும்), இது உங்கள் திசையில் போக்குவரத்தைப் பாதுகாக்கும் மற்றும் பிற அஞ்சல் சேவைகளைக் கேட்க வேண்டிய தேவையை நீக்கும். அஞ்சல் சேவை ஏற்கனவே MTA-STS மற்றும்/அல்லது DANE ஐ ஆதரித்தால், உங்கள் டொமைனுக்கான கட்டாய TLS ஐ உள்ளமைக்க.
2. பெரிய மின்னஞ்சல் சேவைகளுக்கு, ஒவ்வொரு டொமைனுக்கும் தனித்தனி போக்குவரத்து அமைப்புகள் மூலம் MTA-STS இன் "அனலாக்" ஐ செயல்படுத்தவும், இது அஞ்சல் அனுப்புவதற்குப் பயன்படுத்தப்படும் MX ஐ சரிசெய்யும் மற்றும் அதற்கு TLS சான்றிதழின் கட்டாய சரிபார்ப்பு தேவைப்படும். டொமைன்கள் ஏற்கனவே MTA-STS கொள்கையை வெளியிட்டிருந்தால், இது வலியின்றிச் செய்யப்படலாம். ரிலேவை சரிசெய்யாமல், அதற்கான சான்றிதழைச் சரிபார்க்காமல், டொமைனுக்கான கட்டாய TLSஐ இயக்குவது பாதுகாப்புக் கண்ணோட்டத்தில் பயனற்றது மற்றும் தற்போதுள்ள STARTTLS வழிமுறைகளில் எதையும் சேர்க்காது.

ஆதாரம்: www.habr.com