সংক্ষেপে, MTA-STS হল মেল সার্ভারের মধ্যে ট্রান্সমিট করার সময় বাধা থেকে ইমেলগুলিকে আরও রক্ষা করার একটি উপায় (যেমন, ম্যান-ইন-দ্য-মিডল অ্যাটাক ওরফে MitM)। এটি আংশিকভাবে ইমেল প্রোটোকলের উত্তরাধিকারী স্থাপত্য সমস্যার সমাধান করে এবং তুলনামূলকভাবে সাম্প্রতিক স্ট্যান্ডার্ড RFC 8461-এ বর্ণনা করা হয়েছে। Mail.ru হল RuNet-এর প্রথম প্রধান মেল পরিষেবা যা এই মান প্রয়োগ করে। এবং এটি কাটা অধীনে আরো বিস্তারিত বর্ণনা করা হয়।

এমটিএ-এসটিএস কোন সমস্যা সমাধান করে?

ঐতিহাসিকভাবে, ইমেল প্রোটোকল (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 এর সুবিধা

এমটিএ-এসটিএস এমন প্রযুক্তি ব্যবহার করে যা ইতিমধ্যে বেশিরভাগ প্রতিষ্ঠানে প্রয়োগ করা হয়েছে (SMTP+STARTTLS, HTTPS, DNS)। প্রাপকের দিকে বাস্তবায়নের জন্য, স্ট্যান্ডার্ডের জন্য কোন বিশেষ সফ্টওয়্যার সমর্থন প্রয়োজন হয় না।

MTA-STS এর অসুবিধা

ওয়েব এবং মেল সার্ভার সার্টিফিকেটের বৈধতা, নামের চিঠিপত্র এবং সময়মত পুনর্নবীকরণ নিরীক্ষণ করা প্রয়োজন। শংসাপত্রের সমস্যাগুলির ফলে মেল বিতরণ করা যাবে না।

প্রেরকের পক্ষ থেকে, MTA-STS নীতিগুলির সমর্থন সহ একটি MTA প্রয়োজন; বর্তমানে, MTA-তে MTA-STS সমর্থিত নয়।

MTA-STS বিশ্বস্ত রুট CA-এর একটি তালিকা ব্যবহার করে।

MTA-STS আক্রমণ থেকে রক্ষা করে না যেখানে আক্রমণকারী একটি বৈধ শংসাপত্র ব্যবহার করে। বেশিরভাগ ক্ষেত্রে, সার্ভারের কাছাকাছি MitM একটি শংসাপত্র জারি করার ক্ষমতা বোঝায়। সার্টিফিকেট স্বচ্ছতা ব্যবহার করে এই ধরনের আক্রমণ সনাক্ত করা যেতে পারে। অতএব, সাধারণভাবে, এমটিএ-এসটিএস ট্র্যাফিক বাধার সম্ভাবনাকে প্রশমিত করে, কিন্তু সম্পূর্ণরূপে নির্মূল করে না।

শেষ দুটি পয়েন্ট এমটিএ-এসটিএসকে SMTP (RFC 7672) এর জন্য প্রতিযোগী DANE স্ট্যান্ডার্ডের তুলনায় কম সুরক্ষিত করে, কিন্তু প্রযুক্তিগতভাবে আরও নির্ভরযোগ্য, যেমন এমটিএ-এসটিএস-এর জন্য একটি কম সম্ভাবনা রয়েছে যে মান প্রয়োগের কারণে প্রযুক্তিগত সমস্যার কারণে চিঠিটি বিতরণ করা হবে না।

প্রতিযোগী মান - 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 সমর্থন

এইচটিটিপিএস এর মাধ্যমে নীতিটি প্রকাশ করা এবং ডিএনএস-এ রেকর্ড করা, এমটিএ-তে STARTTLS-এর জন্য বিশ্বস্ত CA-এর একটি থেকে একটি বৈধ শংসাপত্র কনফিগার করা (আসুন এনক্রিপ্ট করা সম্ভব) যথেষ্ট। 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), মোড নীতি অ্যাপ্লিকেশন মোড সেট করে, পরীক্ষা — পরীক্ষা মোড (নীতি প্রয়োগ করা হয় না), প্রয়োগ — “যুদ্ধ” মোড। প্রথমে মোড সহ নীতি প্রকাশ করুন: টেস্টিং, যদি পরীক্ষা মোডে নীতিতে কোনো সমস্যা না থাকে, কিছুক্ষণ পরে আপনি মোডে স্যুইচ করতে পারেন: প্রয়োগ করুন।

   mx-এ, আপনার ডোমেনের জন্য মেল গ্রহণ করতে পারে এমন সমস্ত মেল সার্ভারের একটি তালিকা নির্দিষ্ট করা হয়েছে (প্রতিটি সার্ভারের অবশ্যই একটি শংসাপত্র কনফিগার করা থাকতে হবে যা mx-এ উল্লেখিত নামের সাথে মেলে)। Max_age নীতির ক্যাশিং সময় নির্দিষ্ট করে (একবার মনে রাখা নীতিটি প্রয়োগ করা হবে এমনকি যদি আক্রমণকারী এটির ডেলিভারি ব্লক করে দেয় বা ক্যাশে করার সময় DNS রেকর্ডগুলিকে দূষিত করে, আপনি mta-sts DNS পরিবর্তন করে আবার নীতির অনুরোধ করার প্রয়োজনের ইঙ্গিত দিতে পারেন রেকর্ড)।

5. DNS এ একটি TXT রেকর্ড প্রকাশ করুন: 

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

   একটি নির্বিচারে শনাক্তকারী (উদাহরণস্বরূপ, একটি টাইমস্ট্যাম্প) আইডি ক্ষেত্রে ব্যবহার করা যেতে পারে; যখন নীতি পরিবর্তন হয়, তখন এটি পরিবর্তন করা উচিত, এটি প্রেরকদের বুঝতে দেয় যে তাদের ক্যাশে করা নীতির পুনরায় অনুরোধ করতে হবে (যদি সনাক্তকারীর থেকে আলাদা হয় ক্যাশে করা একটি)।

প্রেরকের পক্ষ থেকে 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), এটি আপনার দিকের ট্র্যাফিককে রক্ষা করবে এবং অন্যান্য মেল পরিষেবাগুলিকে জিজ্ঞাসা করার প্রয়োজনীয়তা দূর করবে৷ আপনার ডোমেনের জন্য বাধ্যতামূলক TLS কনফিগার করতে যদি মেল পরিষেবা ইতিমধ্যে MTA-STS এবং/অথবা DANE সমর্থন করে।
2. বড় ইমেল পরিষেবাগুলির জন্য, প্রতিটি ডোমেনের জন্য পৃথক পরিবহন সেটিংসের মাধ্যমে MTA-STS-এর একটি "অ্যানালগ" প্রয়োগ করুন, যা মেল রিলেিংয়ের জন্য ব্যবহৃত MX ঠিক করবে এবং এটির জন্য একটি TLS শংসাপত্রের বাধ্যতামূলক যাচাইকরণের প্রয়োজন হবে৷ যদি ডোমেনগুলি ইতিমধ্যেই একটি MTA-STS নীতি প্রকাশ করে, তবে এটি সম্ভবত ব্যথাহীনভাবে করা যেতে পারে। নিজেই, রিলে ঠিক না করে এবং সার্টিফিকেট যাচাই না করে একটি ডোমেনের জন্য বাধ্যতামূলক TLS সক্ষম করা নিরাপত্তার দৃষ্টিকোণ থেকে অকার্যকর এবং বিদ্যমান STARTTLS মেকানিজমগুলিতে কিছু যোগ করে না।

উত্স: www.habr.com