సంక్షిప్తంగా, 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 ఉండటం తప్పనిసరి మరియు DANEకి NSEC/NSEC3కి సరైన మద్దతు అవసరం, దీనితో 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 అవసరం.
దశల వారీగా, ఇది ఇలా కనిపిస్తుంది:
- మీరు ఉపయోగిస్తున్న MTAలో STARTTLSని కాన్ఫిగర్ చేయండి (postfix, exim, sendmail, Microsoft Exchange మొదలైనవి).
- మీరు చెల్లుబాటు అయ్యే సర్టిఫికేట్‌ను ఉపయోగిస్తున్నారని నిర్ధారించుకోండి (విశ్వసనీయ CA ద్వారా జారీ చేయబడింది, గడువు ముగియలేదు, సర్టిఫికేట్ యొక్క విషయం మీ డొమైన్ కోసం మెయిల్‌ని అందించే MX రికార్డ్‌తో సరిపోలుతుంది).
- TLS-RPT రికార్డ్‌ను కాన్ఫిగర్ చేయండి, దీని ద్వారా పాలసీ అప్లికేషన్ నివేదికలు బట్వాడా చేయబడతాయి (TLS నివేదికలను పంపడానికి మద్దతు ఇచ్చే సేవల ద్వారా). ఉదాహరణ నమోదు (example.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 - అంతర్నిర్మిత మద్దతు లేదు, మూడవ పక్షం స్క్రిప్ట్ ఉంది
- పోస్ట్‌ఫిక్స్ - అంతర్నిర్మిత మద్దతు లేదు, హబ్రేలో వివరంగా వివరించబడిన మూడవ పక్షం స్క్రిప్ట్ ఉంది
“తప్పనిసరి TLS” గురించి ఒక అనంతర పదంగా
ఇటీవల, నియంత్రకాలు ఇమెయిల్ భద్రతపై శ్రద్ధ చూపుతున్నాయి (మరియు అది మంచి విషయం). ఉదాహరణకు, యునైటెడ్ స్టేట్స్‌లోని అన్ని ప్రభుత్వ ఏజెన్సీలకు DMARC తప్పనిసరి మరియు ఆర్థిక రంగంలో ఇది ఎక్కువగా అవసరం, ప్రమాణం యొక్క వ్యాప్తి నియంత్రిత ప్రాంతాల్లో 90%కి చేరుకుంటుంది. ఇప్పుడు కొన్ని రెగ్యులేటర్‌లకు వ్యక్తిగత డొమైన్‌లతో “తప్పనిసరి TLS” అమలు అవసరం, కానీ “తప్పనిసరి TLS”ని నిర్ధారించే విధానం నిర్వచించబడలేదు మరియు ఆచరణలో ఈ సెట్టింగ్ తరచుగా అమలు చేయబడుతుంది, ఇది ఇప్పటికే ఉన్న నిజమైన దాడుల నుండి కనీసం రక్షించబడదు. DANE లేదా MTA-STS వంటి మెకానిజమ్‌లలో అందించబడింది.
రెగ్యులేటర్‌కు ప్రత్యేక డొమైన్‌లతో “తప్పనిసరి TLS” అమలు అవసరమైతే, MTA-STS లేదా దాని పాక్షిక అనలాగ్‌ను అత్యంత అనుకూలమైన యంత్రాంగంగా పరిగణించాలని మేము సిఫార్సు చేస్తున్నాము, ఇది ప్రతి డొమైన్‌కు విడిగా సురక్షిత సెట్టింగ్‌లను చేయవలసిన అవసరాన్ని తొలగిస్తుంది. MTA-STS యొక్క క్లయింట్ భాగాన్ని అమలు చేయడంలో మీకు ఇబ్బందులు ఉంటే (ప్రోటోకాల్‌కు విస్తృత మద్దతు లభించే వరకు, వారు ఎక్కువగా ఉంటారు), మేము ఈ విధానాన్ని సిఫార్సు చేయవచ్చు:
- MTA-STS విధానం మరియు/లేదా DANE రికార్డ్‌లను ప్రచురించండి (DNSSEC ఇప్పటికే మీ డొమైన్‌కు మరియు MTA-STSని ఎనేబుల్ చేసినట్లయితే మాత్రమే DANE అర్ధవంతంగా ఉంటుంది), ఇది మీ దిశలో ట్రాఫిక్‌ను రక్షిస్తుంది మరియు ఇతర ఇమెయిల్ సేవలను అడగవలసిన అవసరాన్ని తొలగిస్తుంది మెయిల్ సేవ ఇప్పటికే MTA-STS మరియు/లేదా DANEకి మద్దతిస్తుంటే మీ డొమైన్ కోసం తప్పనిసరి TLSని కాన్ఫిగర్ చేయడానికి.
- పెద్ద ఇమెయిల్ సేవల కోసం, ప్రతి డొమైన్ కోసం ప్రత్యేక రవాణా సెట్టింగ్‌ల ద్వారా MTA-STS యొక్క “అనలాగ్”ని అమలు చేయండి, ఇది మెయిల్ రిలేయింగ్ కోసం ఉపయోగించే MXని పరిష్కరిస్తుంది మరియు దాని కోసం TLS సర్టిఫికేట్ యొక్క తప్పనిసరి ధృవీకరణ అవసరం. డొమైన్‌లు ఇప్పటికే MTA-STS విధానాన్ని ప్రచురిస్తే, ఇది నొప్పిలేకుండా చేయవచ్చు. స్వతహాగా, రిలేను పరిష్కరించకుండా మరియు దాని కోసం సర్టిఫికేట్‌ను ధృవీకరించకుండా డొమైన్ కోసం తప్పనిసరి TLSని ప్రారంభించడం అనేది భద్రతా కోణం నుండి అసమర్థమైనది మరియు ఇప్పటికే ఉన్న STARTTLS మెకానిజమ్‌లకు ఏమీ జోడించదు.
మూలం: www.habr.com