مختصر ۾، MTA-STS اي ميلن کي وڌيڪ مداخلت کان بچائڻ جو هڪ طريقو آهي (يعني، مين-ان-دي-مڊل حملا عرف MitM) جڏهن ميل سرور جي وچ ۾ منتقل ڪيو وڃي. اهو جزوي طور تي اي ميل پروٽوڪول جي ورثي جي تعميراتي مسئلن کي حل ڪري ٿو ۽ نسبتا تازو معياري RFC 8461 ۾ بيان ڪيو ويو آهي. Mail.ru هن معيار کي لاڳو ڪرڻ لاء RuNet تي پهرين وڏي ميل سروس آهي. ۽ ان کي ڪٽ جي هيٺان وڌيڪ تفصيل سان بيان ڪيو ويو آهي.
MTA-STS ڪهڙو مسئلو حل ڪري ٿو؟
تاريخي طور تي، اي ميل پروٽوڪول (SMTP، POP3، IMAP) معلومات کي صاف متن ۾ منتقل ڪيو، جنهن ان کي مداخلت ڪرڻ ممڪن بڻايو، مثال طور، جڏهن رابطي واري چينل تائين رسائي.
هڪ صارف کان ٻئي ڏانهن خط پهچائڻ جو ميکانيزم ڇا نظر اچي ٿو:
تاريخي طور تي، هڪ MitM حملو سڀني هنڌن تي ممڪن هو جتي ميل گردش ڪري ٿي.
RFC 8314 کي ميل يوزر ايپليڪيشن (MUA) ۽ ميل سرور جي وچ ۾ TLS جي استعمال جي ضرورت آهي. جيڪڏهن توهان جو سرور ۽ ميل ايپليڪيشنون جيڪي توهان استعمال ڪندا آهيو RFC 8314 سان مطابقت رکن ٿا، ته پوءِ توهان (وڏي حد تائين) صارف ۽ ميل سرور جي وچ ۾ وچين حملن جي امڪان کي ختم ڪري ڇڏيو آهي.
عام طور تي قبول ٿيل عملن (RFC 8314 پاران معياري) استعمال ڪندڙ جي ويجهو حملي کي ختم ڪري ٿو:
Mail.ru ميل سرورز آر ايف سي 8314 جي تعميل ڪئي جيتوڻيڪ معيار کي اپنائڻ کان اڳ؛ حقيقت ۾، اهو صرف اڳ ۾ ئي قبول ٿيل عملن تي قبضو ڪري ٿو، ۽ اسان کي ڪا به اضافي ترتيب ڏيڻ جي ضرورت ناهي. پر، جيڪڏهن توهان جو ميل سرور اڃا تائين صارفين کي غير محفوظ پروٽوڪول استعمال ڪرڻ جي اجازت ڏئي ٿو، انهي معيار جي سفارشن تي عمل ڪرڻ جي پڪ ڪريو، ڇاڪاڻ ته گهڻو ڪري، گهٽ ۾ گهٽ توهان جا ڪجهه صارف ميل سان گڏ ڪم ڪن ٿا بغير انڪرپشن جي، جيتوڻيڪ توهان ان جي حمايت ڪريو ٿا.
ميل ڪلائنٽ هميشه ساڳئي تنظيم جي ساڳئي ميل سرور سان ڪم ڪري ٿو. ۽ توهان سڀني صارفين کي محفوظ طريقي سان ڳنڍڻ لاءِ مجبور ڪري سگهو ٿا، ۽ پوءِ غير محفوظ استعمال ڪندڙن لاءِ ڳنڍڻ لاءِ ٽيڪنيڪل طور تي ناممڪن بڻائي سگهو ٿا (اهو ئي آهي جيڪو RFC 8314 جي ضرورت آهي). اهو ڪڏهن ڪڏهن ڏکيو آهي، پر ممڪن آهي. ميل سرور جي وچ ۾ ٽرئفڪ اڃا به وڌيڪ پيچيده آهي. سرورز جو تعلق مختلف تنظيمن سان آهي ۽ اڪثر استعمال ڪيا ويندا آهن ”سيٽ ۽ وساريو“ موڊ ۾، جنهن ڪري ڪنيڪشن ٽوڙڻ کان سواءِ هڪ ئي وقت محفوظ پروٽوڪول تي سوئچ ڪرڻ ناممڪن آهي. SMTP ڊگھي عرصي کان STARTTLS ايڪسٽينشن مهيا ڪئي آھي، جيڪا سرورز کي اجازت ڏئي ٿي جيڪي انڪرپشن کي سپورٽ ڪن ٿيون ته جيئن TLS ڏانھن سوئچ ڪري سگھن. پر هڪ حملو ڪندڙ جيڪو ٽرئفڪ تي اثر انداز ڪرڻ جي صلاحيت رکي ٿو هن حڪم جي حمايت بابت معلومات کي "ڪٽ ڪڍي" ڪري سگهي ٿو ۽ سرورز کي هڪ سادي متن پروٽوڪول استعمال ڪندي گفتگو ڪرڻ تي مجبور ڪري ٿو (جنهن کي نام نهاد downgrade حملو). ساڳئي سبب، STARTTLS عام طور تي سرٽيفڪيٽ جي صحيحيت جي جانچ نه ڪندو آهي (هڪ ناقابل اعتماد سرٽيفڪيٽ غير فعال حملن کان بچائي سگهي ٿو، ۽ اهو واضح متن ۾ پيغام موڪلڻ کان وڌيڪ خراب ناهي). تنهن ڪري، STARTTLS صرف غير فعال eavesdropping کان بچائيندو آهي.
MTA-STS جزوي طور تي ميل سرور جي وچ ۾ خطن جي مداخلت جي مسئلي کي ختم ڪري ٿو، جڏهن حملي ڪندڙ کي فعال طور تي ٽرئفڪ تي اثر انداز ڪرڻ جي صلاحيت آهي. جيڪڏهن وصول ڪندڙ جو ڊومين MTA-STS پاليسي شايع ڪري ٿو ۽ موڪليندڙ جو سرور MTA-STS کي سپورٽ ڪري ٿو، اهو صرف هڪ TLS ڪنيڪشن تي اي ميل موڪليندو، صرف پاليسي طرفان بيان ڪيل سرورن ڏانهن، ۽ صرف سرور جي سرٽيفڪيٽ جي تصديق سان.
جزوي ڇو؟ MTA-STS صرف ان صورت ۾ ڪم ڪري ٿو جڏهن ٻنهي پارٽين هن معيار کي لاڳو ڪرڻ جو خيال رکيو آهي، ۽ MTA-STS انهن منظرنامي جي خلاف حفاظت نٿو ڪري جنهن ۾ هڪ حملو ڪندڙ عوامي CAs مان هڪ کان صحيح ڊومين سرٽيفڪيٽ حاصل ڪرڻ جي قابل آهي.
MTA-STS ڪيئن ڪم ڪري ٿو
وصول ڪندڙ
- ميل سرور تي صحيح سرٽيفڪيٽ سان STARTTLS سپورٽ کي ترتيب ڏئي ٿو.
- MTA-STS پاليسي کي HTTPS ذريعي شايع ڪري ٿو؛ هڪ خاص 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 قابل اعتماد روٽ CAs جي فهرست استعمال ڪري ٿو.
MTA-STS حملن جي خلاف حفاظت نٿو ڪري جنهن ۾ حملو ڪندڙ هڪ صحيح سرٽيفڪيٽ استعمال ڪري ٿو. اڪثر ڪيسن ۾، سرور جي ويجهو MitM هڪ سرٽيفڪيٽ جاري ڪرڻ جي صلاحيت رکي ٿو. اهڙي حملي کي سرٽيفڪيٽ شفافيت استعمال ڪندي ڳولي سگهجي ٿو. تنهن ڪري، عام طور تي، MTA-STS گھٽائي ٿو، پر مڪمل طور تي ختم نٿو ڪري، ٽرئفڪ جي مداخلت جو امڪان.
آخري ٻه نقطا MTA-STS کي SMTP (RFC 7672) لاءِ مقابلي ڪندڙ DANE معيار کان گهٽ محفوظ بڻائين ٿا، پر وڌيڪ ٽيڪنيڪل طور تي قابل اعتماد، يعني. 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 Mail ۾ MTA-STS سپورٽ سان ڇا آهي؟
Mail.ru ڪجهه وقت کان سڀني وڏن ڊومينز لاءِ MTA-STS پاليسي شايع ڪري رهيو آهي. اسان هن وقت معيار جي ڪلائنٽ جو حصو لاڳو ڪري رهيا آهيون. لکڻ جي وقت تي، پاليسيون غير بلاڪنگ موڊ ۾ لاڳو ٿينديون آهن (جيڪڏهن ترسيل پاليسي طرفان بلاڪ ڪئي وئي آهي، خط کي پاليسين لاڳو ڪرڻ کان سواء "اسپيئر" سرور ذريعي پهچايو ويندو)، پوء بلاڪنگ موڊ هڪ ننڍڙي حصي لاء مجبور ڪيو ويندو. ٻاھر نڪرندڙ SMTP ٽريفڪ، ٽريفڪ جي 100% لاءِ ھلندي، پاليسين جي نفاذ کي سپورٽ ڪيو ويندو.
ٻيو ڪير معيار جي حمايت ڪري ٿو؟
هينئر تائين، MTA-STS پاليسيون لڳ ڀڳ 0.05٪ فعال ڊومينز شايع ڪن ٿيون، پر، ان جي باوجود، اهي اڳ ۾ ئي وڏي تعداد ۾ ميل ٽرئفڪ جي حفاظت ڪن ٿيون، ڇاڪاڻ ته معيار جي حمايت ڪئي وئي آهي وڏن رانديگرن پاران - گوگل، ڪامريڊ ۽ جزوي طور تي Verizon (AOL، Yahoo). ڪيترن ئي ٻين پوسٽل خدمتن جو اعلان ڪيو آهي ته معيار جي حمايت ويجهي مستقبل ۾ لاڳو ڪيو ويندو.
اهو مون کي ڪيئن متاثر ڪندو؟
جيستائين توهان جو ڊومين MTA-STS پاليسي شايع نه ڪري. جيڪڏهن توهان پاليسي شايع ڪريو ٿا، توهان جي ميل سرور جي استعمال ڪندڙن لاءِ اي ميلون بهتر طور تي مداخلت کان محفوظ هونديون.
مان MTA-STS کي ڪيئن لاڳو ڪري سگهان ٿو؟
وصول ڪندڙ طرف MTA-STS سپورٽ
اهو ڪافي آهي ته پاليسي کي HTTPS ذريعي شايع ڪرڻ ۽ ڊي اين ايس ۾ رڪارڊ، هڪ قابل اعتماد CAs مان هڪ صحيح سرٽيفڪيٽ ترتيب ڏيو (اچو ته انڪرپٽ ممڪن آهي) MTA ۾ STARTTLS لاءِ (STARTTLS سڀني جديد MTAs ۾ سپورٽ ڪئي وئي آهي)، ڪا خاص مدد نه MTA گھربل آھي.
قدم سان، اهو هن طرح نظر اچي ٿو:
- MTA ۾ STARTTLS ترتيب ڏيو جيڪو توھان استعمال ڪري رھيا آھيو (پوسٽ فڪس، ايگزم، موڪليو ميل، Microsoft Exchange، وغيره).
- پڪ ڪريو ته توهان هڪ صحيح سرٽيفڪيٽ استعمال ڪري رهيا آهيو (هڪ قابل اعتماد CA پاران جاري ڪيو ويو، ختم نه ٿيو، سرٽيفڪيٽ جو موضوع MX رڪارڊ سان ملندو آهي جيڪو توهان جي ڊومين لاءِ ميل پهچائي ٿو).
- TLS-RPT رڪارڊ ترتيب ڏيو جنهن جي ذريعي پاليسي ايپليڪيشن رپورٽون پهچائي وينديون (انهن خدمتن پاران جيڪي TLS رپورٽون موڪلڻ جي حمايت ڪن ٿيون). مثال داخلا (مثال طور. 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;”هڪ ثالثي سڃاڻپ ڪندڙ (مثال طور، ٽائم اسٽيمپ) id فيلڊ ۾ استعمال ٿي سگهي ٿو؛ جڏهن پاليسي تبديل ٿئي ٿي، ان کي تبديل ڪرڻ گهرجي، هي موڪليندڙن کي اهو سمجهڻ جي اجازت ڏئي ٿو ته انهن کي ڪيش ڪيل پاليسي جي ٻيهر درخواست ڪرڻ جي ضرورت آهي (جيڪڏهن سڃاڻپ ڪندڙ کان مختلف آهي. محفوظ ٿيل هڪ).
موڪليندڙ پاسي تي MTA-STS سپورٽ
هينئر تائين اهو هن سان خراب آهي، ڇاڪاڻ ته ... تازو معيار.
- Exim - ڪو به تعمير ٿيل سپورٽ نه آهي، اتي هڪ ٽئين پارٽي اسڪرپٽ آهي
- پوسٽ فڪس - ڪو به تعمير ٿيل سپورٽ نه آهي، اتي هڪ ٽئين پارٽي اسڪرپٽ آهي جيڪو تفصيل سان بيان ڪيو ويو آهي Habré
"لازمي TLS" بابت بعد ۾ لفظ
تازو، ريگيوٽرز کي اي ميل سيڪيورٽي تي ڌيان ڏنو ويو آهي (۽ اهو سٺو شيء آهي). مثال طور، DMARC آمريڪا جي سڀني سرڪاري ادارن لاءِ لازمي آهي ۽ مالياتي شعبي ۾ وڌ کان وڌ گهربل آهي، ضابطي وارن علائقن ۾ 90٪ تائين پهچندي معيار جي دخول سان. هاڻي ڪجهه ريگيوليٽرن کي انفرادي ڊومينز سان ”لازمي TLS“ لاڳو ڪرڻ جي ضرورت آهي، پر ”لازمي TLS“ کي يقيني بڻائڻ جو ميکانيزم بيان نه ڪيو ويو آهي ۽ عملي طور تي هن سيٽنگ کي اڪثر اهڙي طريقي سان لاڳو ڪيو ويندو آهي جيڪو اڳ ۾ ئي موجود حقيقي حملن کان گهٽ ۾ گهٽ حفاظت نٿو ڪري. ميکانيزم ۾ مهيا ڪيل آهي جهڙوڪ DANE يا MTA-STS.
جيڪڏهن ريگيوليٽر کي الڳ الڳ ڊومينز سان ”لازمي TLS“ لاڳو ڪرڻ جي ضرورت آهي، اسان سفارش ڪريون ٿا MTA-STS يا ان جي جزوي اينالاگ کي سڀ کان مناسب ميڪانيزم جي طور تي، اهو هر ڊومين لاءِ الڳ الڳ محفوظ سيٽنگون ٺاهڻ جي ضرورت کي ختم ڪري ٿو. جيڪڏهن توهان کي MTA-STS جي ڪلائنٽ حصي تي عمل ڪرڻ ۾ مشڪلاتون آهن (جيستائين پروٽوڪول کي وسيع حمايت حاصل نه ٿئي، اهي گهڻو ڪري سگهندا)، اسان هن طريقي جي سفارش ڪري سگهون ٿا:
- MTA-STS پاليسي ۽/يا DANE رڪارڊ شايع ڪريو (DANE صرف ان صورت ۾ سمجھ ۾ اچي ٿو جڏهن DNSSEC اڳ ۾ ئي توهان جي ڊومين لاءِ فعال ٿيل آهي، ۽ ڪنهن به صورت ۾ MTA-STS)، اهو توهان جي هدايت ۾ ٽرئفڪ جي حفاظت ڪندو ۽ ٻين ميل سروسز کان پڇڻ جي ضرورت کي ختم ڪندو. پنهنجي ڊومين لاءِ لازمي TLS ترتيب ڏيڻ لاءِ جيڪڏهن ميل سروس اڳ ۾ ئي MTA-STS ۽/يا DANE کي سپورٽ ڪري ٿي.
- وڏين اي ميل سروسز لاءِ، لاڳو ڪريو MTA-STS جو ”اينالاگ“ هر ڊومين لاءِ الڳ ٽرانسپورٽ سيٽنگز ذريعي، جيڪو درست ڪندو MX ميل رليز لاءِ استعمال ٿيندو ۽ ان لاءِ TLS سرٽيفڪيٽ جي لازمي تصديق جي ضرورت پوندي. جيڪڏهن ڊومين اڳ ۾ ئي MTA-STS پاليسي شايع ڪري رهيا آهن، اهو ممڪن ٿي سگهي ٿو بي دردي سان. پنهنجي طرفان، ريل کي درست ڪرڻ کان سواءِ ڊومين لاءِ لازمي TLS کي فعال ڪرڻ ۽ ان لاءِ سرٽيفڪيٽ جي تصديق ڪرڻ سيڪيورٽي نقطي نظر کان غير اثرائتو آهي ۽ موجوده STARTTLS ميڪانيزم ۾ ڪجهه به شامل نٿو ڪري.
جو ذريعو: www.habr.com