សរុបមក MTA-STS គឺជាមធ្យោបាយមួយដើម្បីការពារអ៊ីមែលពីការស្ទាក់ចាប់ (ឧ. ការវាយប្រហារដោយមនុស្សនៅកណ្តាល aka MitM) នៅពេលបញ្ជូនរវាងម៉ាស៊ីនមេ។ វាដោះស្រាយបញ្ហាស្ថាបត្យកម្មមួយផ្នែកនៃពិធីការអ៊ីមែល ហើយត្រូវបានពិពណ៌នានៅក្នុងស្តង់ដារ RFC 8461 ថ្មីៗនេះ។ Mail.ru គឺជាសេវាកម្មសំបុត្រដ៏សំខាន់ដំបូងគេនៅលើ RuNet ដើម្បីអនុវត្តស្តង់ដារនេះ។ ហើយវាត្រូវបានពិពណ៌នាលម្អិតបន្ថែមទៀតនៅក្រោមការកាត់។

តើ MTA-STS ដោះស្រាយបញ្ហាអ្វីខ្លះ?

ជាប្រវត្តិសាស្ត្រ ពិធីការអ៊ីមែល (SMTP, POP3, IMAP) បានបញ្ជូនព័ត៌មានជាអត្ថបទច្បាស់លាស់ ដែលធ្វើឱ្យវាអាចស្ទាក់ចាប់វា ឧទាហរណ៍ នៅពេលចូលប្រើបណ្តាញទំនាក់ទំនង។

តើយន្តការនៃការបញ្ជូនសំបុត្រពីអ្នកប្រើប្រាស់ម្នាក់ទៅអ្នកផ្សេងទៀតមើលទៅដូចអ្វី៖

ជាប្រវត្តិសាស្ត្រ ការវាយប្រហារ MitM អាចធ្វើទៅបាននៅគ្រប់កន្លែងទាំងអស់ដែលសំបុត្រចរាចរ។

RFC 8314 តម្រូវឱ្យមានការប្រើប្រាស់ TLS រវាងកម្មវិធីអ្នកប្រើប្រាស់សំបុត្រ (MUA) និងម៉ាស៊ីនមេសំបុត្រ។ ប្រសិនបើម៉ាស៊ីនមេរបស់អ្នក និងកម្មវិធីសំបុត្រដែលអ្នកប្រើគឺអនុលោមតាម RFC 8314 នោះអ្នកបាន (យ៉ាងធំ) លុបបំបាត់លទ្ធភាពនៃការវាយប្រហារកណ្តាលរវាងអ្នកប្រើប្រាស់ និងម៉ាស៊ីនមេ។

អនុវត្តតាមការអនុវត្តដែលទទួលយកជាទូទៅ (ស្តង់ដារដោយ RFC 8314) លុបបំបាត់ការវាយប្រហារនៅជិតអ្នកប្រើប្រាស់៖

ម៉ាស៊ីនមេអ៊ីមែល Mail.ru បានអនុលោមតាម RFC 8314 សូម្បីតែមុនពេលស្តង់ដារត្រូវបានអនុម័តក៏ដោយ តាមពិតវាគ្រាន់តែចាប់យកការអនុវត្តដែលបានទទួលយករួចហើយ ហើយយើងមិនចាំបាច់កំណត់រចនាសម្ព័ន្ធអ្វីបន្ថែមនោះទេ។ ប៉ុន្តែប្រសិនបើម៉ាស៊ីនមេសំបុត្ររបស់អ្នកនៅតែអនុញ្ញាតឱ្យអ្នកប្រើប្រើពិធីការដែលមិនមានសុវត្ថិភាព ត្រូវប្រាកដថាអនុវត្តការណែនាំនៃស្តង់ដារនេះ ពីព្រោះ ភាគច្រើនទំនងជា យ៉ាងហោចណាស់អ្នកប្រើប្រាស់មួយចំនួនរបស់អ្នកធ្វើការជាមួយសំបុត្រដោយគ្មានការអ៊ិនគ្រីប ទោះបីជាអ្នកគាំទ្រវាក៏ដោយ។

កម្មវិធីអ៊ីមែលតែងតែធ្វើការជាមួយម៉ាស៊ីនមេសំបុត្រដូចគ្នានៃស្ថាប័នដូចគ្នា។ ហើយ​អ្នក​អាច​បង្ខំ​អ្នក​ប្រើ​ទាំងអស់​ឱ្យ​តភ្ជាប់​ក្នុង​លក្ខណៈ​សុវត្ថិភាព ហើយ​បន្ទាប់​មក​ធ្វើ​ឱ្យ​វា​មិន​អាច​ទៅ​រួច​តាម​បច្ចេកទេស​សម្រាប់​អ្នក​ប្រើ​ដែល​មិន​មាន​សុវត្ថិភាព​ក្នុង​ការ​តភ្ជាប់ (នេះ​ជា​អ្វី​ដែល RFC 8314 ទាមទារ)។ នេះជួនកាលពិបាក ប៉ុន្តែអាចធ្វើបាន។ ចរាចរណ៍រវាងម៉ាស៊ីនមេសំបុត្រនៅតែមានភាពស្មុគស្មាញជាង។ ម៉ាស៊ីនមេជាកម្មសិទ្ធិរបស់ស្ថាប័នផ្សេងៗគ្នា ហើយជារឿយៗត្រូវបានប្រើប្រាស់ក្នុងរបៀប "កំណត់ហើយភ្លេច" ដែលធ្វើឱ្យវាមិនអាចប្តូរទៅពិធីការដែលមានសុវត្ថិភាពក្នុងពេលតែមួយដោយមិនផ្តាច់ការភ្ជាប់។ SMTP បានផ្តល់ផ្នែកបន្ថែម STARTTLS ជាយូរមកហើយ ដែលអនុញ្ញាតឱ្យម៉ាស៊ីនមេដែលគាំទ្រការអ៊ិនគ្រីបប្តូរទៅ TLS ។ ប៉ុន្តែអ្នកវាយប្រហារដែលមានសមត្ថភាពមានឥទ្ធិពលលើចរាចរណ៍អាច "កាត់ចេញ" ព័ត៌មានអំពីការគាំទ្រសម្រាប់ពាក្យបញ្ជានេះ និងបង្ខំឱ្យម៉ាស៊ីនមេទំនាក់ទំនងដោយប្រើពិធីការអត្ថបទធម្មតា (ហៅថាការវាយប្រហារទម្លាក់ចំណាត់ថ្នាក់)។ សម្រាប់ហេតុផលដូចគ្នានេះ ជាធម្មតា STARTTLS មិនពិនិត្យមើលសុពលភាពនៃវិញ្ញាបនបត្រទេ (វិញ្ញាបនបត្រដែលមិនគួរឱ្យទុកចិត្តអាចការពារប្រឆាំងនឹងការវាយប្រហារអកម្ម ហើយវាមិនអាក្រក់ជាងការផ្ញើសារជាអក្សរច្បាស់លាស់ទេ)។ ដូច្នេះ STARTTLS ការពារតែពីការលួចស្តាប់អកម្មប៉ុណ្ណោះ។

MTA-STS មួយផ្នែកលុបបំបាត់បញ្ហានៃការស្ទាក់ចាប់អក្សររវាងម៉ាស៊ីនមេសំបុត្រ នៅពេលដែលអ្នកវាយប្រហារមានសមត្ថភាពមានឥទ្ធិពលលើចរាចរណ៍យ៉ាងសកម្ម។ ប្រសិនបើដែនរបស់អ្នកទទួលផ្សព្វផ្សាយគោលការណ៍ MTA-STS ហើយម៉ាស៊ីនមេរបស់អ្នកផ្ញើគាំទ្រ MTA-STS នោះវានឹងផ្ញើអ៊ីមែលតាមរយៈការតភ្ជាប់ TLS ទៅកាន់ម៉ាស៊ីនមេដែលកំណត់ដោយគោលការណ៍នេះតែប៉ុណ្ណោះ ហើយមានតែការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្ររបស់ម៉ាស៊ីនមេប៉ុណ្ណោះ។

ហេតុអ្វីបានជាផ្នែកខ្លះ? MTA-STS ដំណើរការបានលុះត្រាតែភាគីទាំងពីរបានយកចិត្តទុកដាក់ក្នុងការអនុវត្តស្តង់ដារនេះហើយ MTA-STS មិនការពារប្រឆាំងនឹងសេណារីយ៉ូដែលអ្នកវាយប្រហារអាចទទួលបានវិញ្ញាបនបត្រដែនត្រឹមត្រូវពី CAs សាធារណៈណាមួយឡើយ។

របៀបដែល MTA-STS ដំណើរការ

អ្នកទទួល

1. កំណត់រចនាសម្ព័ន្ធការគាំទ្រ STARTTLS ជាមួយនឹងវិញ្ញាបនបត្រត្រឹមត្រូវនៅលើម៉ាស៊ីនមេសំបុត្រ។ 
2. បោះផ្សាយគោលការណ៍ MTA-STS តាមរយៈ HTTPS ដែន mta-sts ពិសេស និងផ្លូវល្បីពិសេសត្រូវបានប្រើសម្រាប់ការបោះពុម្ពផ្សាយ ឧទាហរណ៍ https://mta-sts.mail.ru/.well-known/mta-sts.txt. គោលការណ៍នេះមានបញ្ជីម៉ាស៊ីនមេសំបុត្រ (mx) ដែលមានសិទ្ធិទទួលសំបុត្រសម្រាប់ដែននេះ។
3. បោះផ្សាយ TXT record _mta-sts ពិសេសនៅក្នុង DNS ជាមួយនឹងកំណែគោលការណ៍។ នៅពេលដែលគោលការណ៍ផ្លាស់ប្តូរ ធាតុនេះត្រូវតែធ្វើបច្ចុប្បន្នភាព (នេះផ្តល់សញ្ញាដល់អ្នកផ្ញើឱ្យសួរគោលការណ៍ឡើងវិញ)។ ឧទាហរណ៍, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

អ្នកផ្ញើ

អ្នកផ្ញើស្នើសុំកំណត់ត្រា DNS _mta-sts ហើយប្រសិនបើវាមាន សូមធ្វើការស្នើសុំគោលការណ៍តាមរយៈ HTTPS (ពិនិត្យមើលវិញ្ញាបនបត្រ)។ គោលការណ៍លទ្ធផលត្រូវបានទុកក្នុងឃ្លាំងសម្ងាត់ (ក្នុងករណីដែលអ្នកវាយប្រហាររារាំងការចូលប្រើវា ឬក្លែងបន្លំកំណត់ត្រា DNS)។

នៅពេលផ្ញើសំបុត្រវាត្រូវបានពិនិត្យថា:

• ម៉ាស៊ីនមេដែលសំបុត្រត្រូវបានបញ្ជូនគឺស្ថិតនៅក្នុងគោលការណ៍។
• ម៉ាស៊ីនមេទទួលយកសំបុត្រដោយប្រើ TLS (STARTTLS) និងមានវិញ្ញាបនបត្រត្រឹមត្រូវ។

គុណសម្បត្តិនៃ MTA-STS

MTA-STS ប្រើប្រាស់បច្ចេកវិទ្យាដែលត្រូវបានអនុវត្តរួចហើយនៅក្នុងស្ថាប័នភាគច្រើន (SMTP+STARTTLS, HTTPS, DNS)។ សម្រាប់ការអនុវត្តនៅខាងអ្នកទទួល មិនត្រូវការការគាំទ្រផ្នែកទន់ពិសេសសម្រាប់ស្តង់ដារនោះទេ។

គុណវិបត្តិនៃ MTA-STS

វាចាំបាច់ក្នុងការត្រួតពិនិត្យសុពលភាពនៃវិញ្ញាបនបត្រម៉ាស៊ីនមេគេហទំព័រ និងសំបុត្រ ការឆ្លើយឆ្លងនៃឈ្មោះ និងការបន្តឡើងវិញទាន់ពេលវេលា។ បញ្ហាជាមួយវិញ្ញាបនបត្រនឹងនាំឱ្យសំបុត្រមិនអាចបញ្ជូនបាន។

ខាងអ្នកផ្ញើ MTA ដែលមានការគាំទ្រសម្រាប់គោលការណ៍ MTA-STS គឺត្រូវបានទាមទារ ហើយបច្ចុប្បន្ន MTA-STS មិនត្រូវបានគាំទ្រចេញពីប្រអប់នៅក្នុង MTA ទេ។

MTA-STS ប្រើបញ្ជីនៃ CAs root ដែលអាចទុកចិត្តបាន។

MTA-STS មិនការពារប្រឆាំងនឹងការវាយប្រហារដែលអ្នកវាយប្រហារប្រើវិញ្ញាបនបត្រត្រឹមត្រូវ។ ក្នុងករណីភាគច្រើន MitM នៅជិតម៉ាស៊ីនមេបង្កប់ន័យសមត្ថភាពក្នុងការចេញវិញ្ញាបនបត្រ។ ការវាយប្រហារបែបនេះអាចត្រូវបានរកឃើញដោយប្រើតម្លាភាពវិញ្ញាបនបត្រ។ ដូច្នេះជាទូទៅ MTA-STS កាត់បន្ថយ ប៉ុន្តែមិនលុបបំបាត់ទាំងស្រុងទេ លទ្ធភាពនៃការស្ទាក់ចាប់ចរាចរណ៍។

ចំណុចពីរចុងក្រោយធ្វើឱ្យ MTA-STS មានសុវត្ថិភាពតិចជាងស្តង់ដារ DANE ប្រកួតប្រជែងសម្រាប់ SMTP (RFC 7672) ប៉ុន្តែបច្ចេកទេសអាចទុកចិត្តបានជាង ពោលគឺឧ។ សម្រាប់ MTA-STS មានប្រូបាប៊ីលីតេទាបដែលសំបុត្រនឹងមិនត្រូវបានផ្តល់ឱ្យដោយសារតែបញ្ហាបច្ចេកទេសដែលបណ្តាលមកពីការអនុវត្តស្តង់ដារ។

ស្តង់ដារប្រកួតប្រជែង - DANE

DANE ប្រើ DNSSEC ដើម្បីផ្សព្វផ្សាយព័ត៌មានវិញ្ញាបនបត្រ និងមិនតម្រូវឱ្យមានការជឿទុកចិត្តលើអាជ្ញាធរវិញ្ញាបនបត្រខាងក្រៅ ដែលមានសុវត្ថិភាពជាង។ ប៉ុន្តែការប្រើប្រាស់ DNSSEC ច្រើនតែនាំទៅរកការបរាជ័យផ្នែកបច្ចេកទេស ដោយផ្អែកលើស្ថិតិក្នុងរយៈពេលជាច្រើនឆ្នាំនៃការប្រើប្រាស់ (ទោះបីជាជាទូទៅមាននិន្នាការវិជ្ជមាននៅក្នុងភាពជឿជាក់នៃ DNSSEC និងការគាំទ្របច្ចេកទេសរបស់វាក៏ដោយ)។ ដើម្បីអនុវត្ត DANE នៅក្នុង SMTP នៅផ្នែកអ្នកទទួល វត្តមានរបស់ DNSSEC សម្រាប់តំបន់ DNS គឺជាកាតព្វកិច្ច ហើយការគាំទ្រត្រឹមត្រូវសម្រាប់ NSEC/NSEC3 គឺចាំបាច់សម្រាប់ DANE ដែលមានបញ្ហាប្រព័ន្ធនៅក្នុង DNSSEC ។

ប្រសិនបើ DNSSEC មិនត្រូវបានកំណត់ត្រឹមត្រូវទេ វាអាចបណ្តាលឱ្យមានការបរាជ័យក្នុងការបញ្ជូនសំបុត្រ ប្រសិនបើភាគីផ្ញើគាំទ្រ DANE ទោះបីជាភាគីទទួលមិនដឹងអ្វីអំពីវាក៏ដោយ។ ដូច្នេះ ទោះបីជាការពិតដែលថា DANE គឺជាស្តង់ដារចាស់ជាង និងមានសុវត្ថិភាពជាង ហើយត្រូវបានគាំទ្ររួចហើយនៅក្នុងកម្មវិធីម៉ាស៊ីនមេមួយចំនួននៅផ្នែកអ្នកផ្ញើ តាមពិតការជ្រៀតចូលរបស់វានៅតែមិនសំខាន់ អង្គការជាច្រើនមិនទាន់ត្រៀមខ្លួនរួចរាល់ក្នុងការអនុវត្តវាដោយសារតែតម្រូវការក្នុងការអនុវត្ត DNSSEC ។ នេះបានធ្វើឱ្យថយចុះយ៉ាងខ្លាំងនូវការអនុវត្ត DANE គ្រប់ឆ្នាំទាំងអស់ដែលស្តង់ដារមាន។

DANE និង MTA-STS មិនប៉ះទង្គិចគ្នាទេ ហើយអាចប្រើជាមួយគ្នាបាន។

តើមានអ្វីជាមួយការគាំទ្រ MTA-STS នៅក្នុង Mail.ru Mail?

Mail.ru បាននឹងកំពុងបោះផ្សាយគោលការណ៍ MTA-STS សម្រាប់ដែនសំខាន់ៗទាំងអស់អស់មួយរយៈ។ បច្ចុប្បន្នយើងកំពុងអនុវត្តផ្នែកអតិថិជននៃស្តង់ដារ។ នៅពេលសរសេរ គោលការណ៍ត្រូវបានអនុវត្តនៅក្នុងរបៀបមិនទប់ស្កាត់ (ប្រសិនបើការដឹកជញ្ជូនត្រូវបានរារាំងដោយគោលការណ៍ លិខិតនោះនឹងត្រូវបានបញ្ជូនតាមរយៈម៉ាស៊ីនមេ "ទំនេរ" ដោយមិនអនុវត្តគោលការណ៍) បន្ទាប់មករបៀបទប់ស្កាត់នឹងត្រូវបានបង្ខំសម្រាប់ផ្នែកតូចមួយ នៃចរាចរណ៍ SMTP ដែលចេញជាបណ្តើរៗសម្រាប់ 100% នៃចរាចរណ៍វានឹងត្រូវបានគាំទ្រ។

តើអ្នកណាទៀតគាំទ្រស្តង់ដារ?

រហូតមកដល់ពេលនេះ គោលការណ៍ MTA-STS បោះពុម្ពផ្សាយប្រហែល 0.05% នៃដែនសកម្ម ប៉ុន្តែទោះជាយ៉ាងណាក៏ដោយ ពួកគេការពារបរិមាណដ៏ធំនៃចរាចរណ៍សំបុត្ររួចហើយ ពីព្រោះ ស្តង់ដារនេះត្រូវបានគាំទ្រដោយអ្នកលេងសំខាន់ៗ - Google, Comcast និងមួយផ្នែកគឺ Verizon (AOL, Yahoo) ។ សេវាប្រៃសណីយ៍ជាច្រើនផ្សេងទៀតបានប្រកាសថាការគាំទ្រសម្រាប់ស្តង់ដារនឹងត្រូវបានអនុវត្តនាពេលខាងមុខ។

តើនេះនឹងប៉ះពាល់ដល់ខ្ញុំយ៉ាងដូចម្តេច?

មិនមែនទេ លុះត្រាតែដែនរបស់អ្នកផ្សព្វផ្សាយគោលការណ៍ MTA-STS ។ ប្រសិនបើអ្នកបោះផ្សាយគោលការណ៍នេះ អ៊ីមែលសម្រាប់អ្នកប្រើប្រាស់ម៉ាស៊ីនមេសំបុត្ររបស់អ្នកនឹងត្រូវបានការពារប្រសើរជាងមុនពីការស្ទាក់ចាប់។

តើខ្ញុំអនុវត្ត MTA-STS យ៉ាងដូចម្តេច?

ការគាំទ្រ MTA-STS នៅខាងអ្នកទទួល

វាគ្រប់គ្រាន់ហើយក្នុងការបោះផ្សាយគោលការណ៍តាមរយៈ HTTPS និងកំណត់ត្រានៅក្នុង DNS កំណត់រចនាសម្ព័ន្ធវិញ្ញាបនបត្រត្រឹមត្រូវពី CAs ដែលអាចទុកចិត្តបានមួយ (អនុញ្ញាតឱ្យការអ៊ិនគ្រីបគឺអាចធ្វើទៅបាន) សម្រាប់ STARTTLS នៅក្នុង MTA (STARTTLS ត្រូវបានគាំទ្រនៅក្នុង MTAs ទំនើបទាំងអស់) មិនមានការគាំទ្រពិសេសពី MTA ត្រូវបានទាមទារ។

មួយជំហានម្តង ៗ វាមើលទៅដូចនេះ:

1. កំណត់រចនាសម្ព័ន្ធ STARTTLS នៅក្នុង MTA ដែលអ្នកកំពុងប្រើ (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]»

   ធាតុនេះណែនាំអ្នកផ្ញើសំបុត្រឱ្យផ្ញើរបាយការណ៍ស្ថិតិស្តីពីការប្រើប្រាស់ TLS នៅក្នុង SMTP ទៅ [email protected].

   តាមដានរបាយការណ៍ជាច្រើនថ្ងៃ ដើម្បីប្រាកដថាមិនមានកំហុស។

4. ផ្សព្វផ្សាយគោលការណ៍ MTA-STS លើ HTTPS ។ គោលការណ៍នេះត្រូវបានបោះពុម្ពផ្សាយជាឯកសារអត្ថបទជាមួយឧបករណ៍បញ្ចប់បន្ទាត់ 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 នៅក្នុង DNS៖ 

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

   ឧបករណ៍កំណត់អត្តសញ្ញាណតាមអំពើចិត្ត (ឧទាហរណ៍ ត្រាពេលវេលា) អាចត្រូវបានប្រើនៅក្នុងវាលលេខសម្គាល់ នៅពេលដែលគោលការណ៍ផ្លាស់ប្តូរ វាគួរតែផ្លាស់ប្តូរ វាអនុញ្ញាតឱ្យអ្នកផ្ញើយល់ថាពួកគេត្រូវការស្នើសុំគោលការណ៍ដែលបានរក្សាទុកឡើងវិញ (ប្រសិនបើការកំណត់អត្តសញ្ញាណខុសពី ឃ្លាំងសម្ងាត់មួយ) ។

ការគាំទ្រ MTA-STS នៅផ្នែកអ្នកផ្ញើ

មក​ដល់​ពេល​នេះ​វា​អាក្រក់​ជាមួយ​នាង​ព្រោះ... ស្ដង់ដារស្រស់។

• Exim - គ្មានការគាំទ្រដែលភ្ជាប់មកជាមួយទេ មានស្គ្រីបភាគីទីបី https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix - មិនមានការគាំទ្រដែលភ្ជាប់មកជាមួយទេ មានស្គ្រីបភាគីទីបីដែលត្រូវបានពិពណ៌នាលម្អិតនៅលើHabre 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 ក្នុងករណីណាក៏ដោយ) វានឹងការពារចរាចរណ៍ក្នុងទិសដៅរបស់អ្នក និងលុបបំបាត់តម្រូវការក្នុងការសួរសេវាកម្មសំបុត្រផ្សេងទៀត។ ដើម្បីកំណត់រចនាសម្ព័ន្ធ TLS ចាំបាច់សម្រាប់ដែនរបស់អ្នក ប្រសិនបើសេវាកម្មសំបុត្រគាំទ្រ MTA-STS និង/ឬ DANE រួចហើយ។
2. សម្រាប់សេវាកម្មអ៊ីមែលធំ សូមអនុវត្ត "ការសន្ទនា" នៃ MTA-STS តាមរយៈការកំណត់ការដឹកជញ្ជូនដាច់ដោយឡែកសម្រាប់ដែននីមួយៗ ដែលនឹងជួសជុល MX ដែលប្រើសម្រាប់ការបញ្ជូនបន្តសំបុត្រ ហើយនឹងតម្រូវឱ្យមានការផ្ទៀងផ្ទាត់ជាកាតព្វកិច្ចនៃវិញ្ញាបនបត្រ TLS សម្រាប់វា។ ប្រសិនបើដែនបានផ្សព្វផ្សាយគោលការណ៍ MTA-STS រួចហើយ នោះទំនងជាអាចធ្វើបានដោយគ្មានការឈឺចាប់។ ដោយខ្លួនវាផ្ទាល់ ការបើកដំណើរការ TLS ចាំបាច់សម្រាប់ដែនដោយមិនចាំបាច់ជួសជុលការបញ្ជូនត និងផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រសម្រាប់វាមិនមានប្រសិទ្ធភាពតាមទស្សនៈសុវត្ថិភាព ហើយមិនបន្ថែមអ្វីទៅយន្តការ STARTTLS ដែលមានស្រាប់នោះទេ។

ប្រភព: www.habr.com