ટૂંકમાં, MTA-STS એ મેઇલ સર્વર્સ વચ્ચે ટ્રાન્સમિટ થાય ત્યારે ઇમેલને ઇન્ટરસેપ્શન (એટલે ​​​​કે, મેન-ઇન-ધ-મિડલ એટેક ઉર્ફે MitM)થી વધુ સુરક્ષિત કરવાનો માર્ગ છે. તે ઈમેલ પ્રોટોકોલની લેગસી આર્કિટેક્ચરલ સમસ્યાઓને આંશિક રીતે હલ કરે છે અને પ્રમાણમાં તાજેતરના સ્ટાન્ડર્ડ RFC 8461માં તેનું વર્ણન કરવામાં આવ્યું છે. Mail.ru એ આ સ્ટાન્ડર્ડને લાગુ કરવા માટે રૂનેટ પરની પ્રથમ મોટી મેઈલ સેવા છે. અને તે કટ હેઠળ વધુ વિગતવાર વર્ણવેલ છે.

MTA-STS કઈ સમસ્યાનો ઉકેલ લાવે છે?

ઐતિહાસિક રીતે, ઈમેલ પ્રોટોકોલ્સ (SMTP, POP3, IMAP) સ્પષ્ટ લખાણમાં માહિતી પ્રસારિત કરે છે, જેણે તેને અટકાવવાનું શક્ય બનાવ્યું છે, ઉદાહરણ તરીકે, સંચાર ચેનલને ઍક્સેસ કરતી વખતે.

એક વપરાશકર્તા પાસેથી બીજા વપરાશકર્તાને પત્ર પહોંચાડવા માટેની પદ્ધતિ કેવી દેખાય છે:

ઐતિહાસિક રીતે, MitM હુમલો એ તમામ સ્થળોએ શક્ય હતો જ્યાં મેઇલ ફરે છે.

RFC 8314 ને મેલ યુઝર એપ્લિકેશન (MUA) અને મેઇલ સર્વર વચ્ચે TLS નો ઉપયોગ કરવાની જરૂર છે. જો તમારું સર્વર અને તમે ઉપયોગ કરો છો તે મેઇલ એપ્લિકેશન્સ RFC 8314 સાથે સુસંગત છે, તો તમે (મોટા પ્રમાણમાં) વપરાશકર્તા અને મેઇલ સર્વર્સ વચ્ચેના મેન-ઇન-ધ-મિડલ હુમલાની શક્યતાને દૂર કરી દીધી છે.

સામાન્ય રીતે સ્વીકૃત પ્રથાઓને અનુસરીને (RFC 8314 દ્વારા પ્રમાણિત) વપરાશકર્તાની નજીકના હુમલાને દૂર કરે છે:

Mail.ru મેઇલ સર્વર્સે માનક અપનાવવામાં આવે તે પહેલાં જ RFC 8314 નું પાલન કર્યું; વાસ્તવમાં, તે ફક્ત પહેલેથી જ સ્વીકૃત પ્રથાઓ કેપ્ચર કરે છે, અને અમારે કંઈપણ વધારાની ગોઠવણી કરવાની જરૂર નથી. પરંતુ, જો તમારું મેઇલ સર્વર હજુ પણ વપરાશકર્તાઓને અસુરક્ષિત પ્રોટોકોલનો ઉપયોગ કરવાની મંજૂરી આપે છે, તો આ ધોરણની ભલામણોને અમલમાં મૂકવાની ખાતરી કરો, કારણ કે મોટે ભાગે, ઓછામાં ઓછા તમારા કેટલાક વપરાશકર્તાઓ એન્ક્રિપ્શન વિના મેઇલ સાથે કામ કરે છે, પછી ભલે તમે તેને સમર્થન આપતા હોવ.

મેઇલ ક્લાયંટ હંમેશા સમાન સંસ્થાના સમાન મેઇલ સર્વર સાથે કામ કરે છે. અને તમે બધા વપરાશકર્તાઓને સુરક્ષિત રીતે કનેક્ટ થવા માટે દબાણ કરી શકો છો, અને પછી બિન-સુરક્ષિત વપરાશકર્તાઓ માટે કનેક્ટ થવાનું તકનીકી રીતે અશક્ય બનાવી શકો છો (આરએફસી 8314 માટે આ જરૂરી છે). આ ક્યારેક મુશ્કેલ છે, પરંતુ શક્ય છે. મેઇલ સર્વર્સ વચ્ચેનો ટ્રાફિક હજુ પણ વધુ જટિલ છે. સર્વર્સ અલગ-અલગ સંસ્થાઓના છે અને ઘણીવાર "સેટ કરો અને ભૂલી જાઓ" મોડમાં ઉપયોગમાં લેવાય છે, જે કનેક્ટિવિટી તોડ્યા વિના એક જ સમયે સુરક્ષિત પ્રોટોકોલ પર સ્વિચ કરવાનું અશક્ય બનાવે છે. SMTP એ લાંબા સમયથી STARTTLS એક્સ્ટેંશન પ્રદાન કર્યું છે, જે સર્વર્સને TLS પર સ્વિચ કરવા માટે એન્ક્રિપ્શનને સમર્થન આપે છે. પરંતુ જે હુમલાખોર ટ્રાફિકને પ્રભાવિત કરવાની ક્ષમતા ધરાવે છે તે આ આદેશના સમર્થન વિશેની માહિતીને "કાપી" શકે છે અને સર્વર્સને સાદા ટેક્સ્ટ પ્રોટોકોલ (કહેવાતા ડાઉનગ્રેડ એટેક) નો ઉપયોગ કરીને વાતચીત કરવા દબાણ કરી શકે છે. આ જ કારણોસર, STARTTLS સામાન્ય રીતે પ્રમાણપત્રની માન્યતા તપાસતું નથી (એક અવિશ્વસનીય પ્રમાણપત્ર નિષ્ક્રિય હુમલાઓ સામે રક્ષણ આપી શકે છે, અને આ સ્પષ્ટ ટેક્સ્ટમાં સંદેશ મોકલવા કરતાં વધુ ખરાબ નથી). તેથી, STARTTLS માત્ર નિષ્ક્રિય છળકપટ સામે રક્ષણ આપે છે.

જ્યારે હુમલાખોર ટ્રાફિકને સક્રિય રીતે પ્રભાવિત કરવાની ક્ષમતા ધરાવે છે ત્યારે MTA-STS મેલ સર્વર્સ વચ્ચેના અક્ષરોને અટકાવવાની સમસ્યાને આંશિક રીતે દૂર કરે છે. જો પ્રાપ્તકર્તાનું ડોમેન MTA-STS નીતિ પ્રકાશિત કરે છે અને પ્રેષકનું સર્વર MTA-STS ને સમર્થન આપે છે, તો તે ફક્ત TLS કનેક્શન પર જ ઇમેઇલ મોકલશે, માત્ર નીતિ દ્વારા નિર્ધારિત સર્વર્સને અને માત્ર સર્વરના પ્રમાણપત્રની ચકાસણી સાથે.

શા માટે આંશિક રીતે? MTA-STS માત્ર ત્યારે જ કામ કરે છે જો બંને પક્ષોએ આ ધોરણને અમલમાં મૂકવાની કાળજી લીધી હોય, અને MTA-STS એવા સંજોગો સામે રક્ષણ આપતું નથી કે જેમાં હુમલાખોર સાર્વજનિક CAમાંથી કોઈ એક પાસેથી માન્ય ડોમેન પ્રમાણપત્ર મેળવવામાં સક્ષમ હોય.

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 ધોરણ કરતાં ઓછા સુરક્ષિત બનાવે છે, પરંતુ વધુ તકનીકી રીતે વિશ્વસનીય, એટલે કે. એમટીએ-એસટીએસ માટે પ્રમાણભૂતના અમલીકરણને કારણે તકનીકી સમસ્યાઓને કારણે પત્ર વિતરિત કરવામાં આવશે નહીં તેવી સંભાવના ઓછી છે.

સ્પર્ધાત્મક ધોરણ - 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 અને આંશિક રીતે વેરાઇઝન (AOL, Yahoo) દ્વારા સપોર્ટેડ છે. અન્ય ઘણી પોસ્ટલ સેવાઓએ જાહેરાત કરી છે કે નજીકના ભવિષ્યમાં ધોરણ માટે સમર્થન લાગુ કરવામાં આવશે.

આ મારા પર કેવી અસર કરશે?

જ્યાં સુધી તમારું ડોમેન MTA-STS નીતિ પ્રકાશિત ન કરે ત્યાં સુધી નહીં. જો તમે નીતિ પ્રકાશિત કરો છો, તો તમારા મેઇલ સર્વરના વપરાશકર્તાઓ માટેના ઇમેઇલ્સ અવરોધથી વધુ સારી રીતે સુરક્ષિત રહેશે.

હું MTA-STS કેવી રીતે અમલમાં મૂકી શકું?

પ્રાપ્તકર્તા બાજુ પર MTA-STS સપોર્ટ

તે HTTPS અને DNS માં રેકોર્ડ્સ દ્વારા નીતિ પ્રકાશિત કરવા માટે પૂરતું છે, MTA માં STARTTLS માટે વિશ્વસનીય CAsમાંથી એક માન્ય પ્રમાણપત્ર (ચાલો એન્ક્રિપ્ટ શક્ય છે) રૂપરેખાંકિત કરવા માટે પૂરતું છે (STARTTLS તમામ આધુનિક MTAs માં સમર્થિત છે), તરફથી કોઈ વિશેષ સમર્થન નથી. MTA જરૂરી છે.

પગલું દ્વારા, તે આના જેવું લાગે છે:

1. તમે જે MTA નો ઉપયોગ કરી રહ્યા છો તેમાં STARTTLS ને ગોઠવો (પોસ્ટફિક્સ, એક્ઝિમ, સેન્ડમેલ, માઈક્રોસોફ્ટ એક્સચેન્જ વગેરે).
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), મોડ પોલિસી એપ્લિકેશન મોડ, ટેસ્ટિંગ — ટેસ્ટ મોડ (નીતિ લાગુ નથી), અમલ — “લડાઈ” મોડ સેટ કરે છે. સૌપ્રથમ પૉલિસીને મોડ: ટેસ્ટિંગ સાથે પ્રકાશિત કરો, જો ટેસ્ટ મોડમાં પૉલિસીમાં કોઈ સમસ્યા ન હોય, તો થોડા સમય પછી તમે મોડ પર સ્વિચ કરી શકો છો: enforce.

   mx માં, તમારા ડોમેન માટે મેઇલ સ્વીકારી શકે તેવા તમામ મેઇલ સર્વર્સની સૂચિ ઉલ્લેખિત છે (દરેક સર્વર પાસે પ્રમાણપત્ર રૂપરેખાંકિત હોવું આવશ્યક છે જે mx માં ઉલ્લેખિત નામ સાથે મેળ ખાતું હોય). Max_age પોલિસીના કેશિંગ સમયને સ્પષ્ટ કરે છે (એકવાર યાદ રાખવાની નીતિ લાગુ કરવામાં આવશે, ભલે હુમલાખોર તેની ડિલિવરી અવરોધિત કરે અથવા કેશિંગ સમય દરમિયાન DNS રેકોર્ડને બગાડે, તો તમે mta-sts DNS બદલીને ફરીથી નીતિની વિનંતી કરવાની જરૂરિયાતનો સંકેત આપી શકો છો. રેકોર્ડ).

5. DNS માં TXT રેકોર્ડ પ્રકાશિત કરો: 

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

   id ફીલ્ડમાં મનસ્વી ઓળખકર્તા (ઉદાહરણ તરીકે, ટાઇમસ્ટેમ્પ) નો ઉપયોગ કરી શકાય છે; જ્યારે નીતિ બદલાય છે, ત્યારે તે બદલવી જોઈએ, આ પ્રેષકોને સમજવાની મંજૂરી આપે છે કે તેમને કેશ્ડ નીતિની ફરીથી વિનંતી કરવાની જરૂર છે (જો ઓળખકર્તા અલગ હોય તો કેશ્ડ એક).

પ્રેષક બાજુ પર MTA-STS સપોર્ટ

અત્યાર સુધી તે તેની સાથે ખરાબ છે, કારણ કે ... તાજા ધોરણ.

• એક્ઝિમ - કોઈ બિલ્ટ-ઇન સપોર્ટ નથી, ત્યાં તૃતીય-પક્ષ સ્ક્રિપ્ટ છે 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 રેકોર્ડ્સ પ્રકાશિત કરો (DANE નો અર્થ ત્યારે જ બને છે જો DNSSEC તમારા ડોમેન માટે પહેલેથી જ સક્ષમ હોય અને કોઈપણ કિસ્સામાં MTA-STS), આ તમારી દિશામાં ટ્રાફિકને સુરક્ષિત કરશે અને અન્ય મેઇલ સેવાઓને પૂછવાની જરૂરિયાતને દૂર કરશે. જો મેઇલ સેવા પહેલાથી જ MTA-STS અને/અથવા DANE ને સપોર્ટ કરતી હોય તો તમારા ડોમેન માટે ફરજિયાત TLS ગોઠવવા માટે.
2. મોટી ઈમેઈલ સેવાઓ માટે, દરેક ડોમેન માટે અલગ ટ્રાન્સપોર્ટ સેટિંગ્સ દ્વારા MTA-STS ના "એનાલોગ" નો અમલ કરો, જે મેઈલ રીલેઈંગ માટે ઉપયોગમાં લેવાતા MX ને ઠીક કરશે અને તેના માટે TLS પ્રમાણપત્રની ફરજિયાત ચકાસણીની જરૂર પડશે. જો ડોમેન્સ પહેલેથી જ MTA-STS નીતિ પ્રકાશિત કરે છે, તો આ સંભવતઃ પીડારહિત થઈ શકે છે. પોતે જ, રિલે ફિક્સ કર્યા વિના અને પ્રમાણપત્રની ચકાસણી કર્યા વિના ડોમેન માટે ફરજિયાત TLS સક્ષમ કરવું એ સુરક્ષાના દૃષ્ટિકોણથી બિનઅસરકારક છે અને હાલની STARTTLS મિકેનિઝમ્સમાં કંઈપણ ઉમેરતું નથી.

સોર્સ: www.habr.com