[ परिवहन सुरक्षा ]

MTA-STS नीति खोज और DNS नीति पहचानकर्ता

किसी नीति संशोधन की घोषणा करने के लिए DNS आईडी का उपयोग करें, इसे स्वयं नीति या प्रेषक कैश साफ़ करने वाला आदेश न मानें।

EmailAuth अनुसंधान टीम द्वारा

[ प्रमुख बिंदु ]

  • वास्तविक प्राप्तकर्ता या कॉन्फ़िगर स्मार्ट-होस्ट नीति डोमेन का उपयोग करें।
  • एक चयनित डिस्कवरी TXT रिकॉर्ड रखें और उसकी स्ट्रिंग सीमाओं को सुरक्षित रखें।
  • नई आईडी की घोषणा करने से पहले HTTPS बॉडी प्रकाशित करें।
इस पेज पर

MTA-STS खोज _mta-sts से शुरू होती है और उसके बाद पॉलिसी डोमेन आता है। user@example.com को संबोधित मेल के लिए, सामान्य खोज स्वामी _mta-sts.example.com है। TXT मान समर्थन और एक संशोधन पहचानकर्ता का विज्ञापन करता है; वास्तविक पॉलिसी HTTPS पर अलग से प्राप्त की जाती है।

प्राप्तकर्ता डोमेन का सटीक रूप से पालन करें

सन्दर्भ: RFC 8461 §3.1, RFC 8461 §3.4.

user@mail.example.com को भेजा गया एक संदेश मूल example.com नीति को प्राप्त करने के बजाय mail.example.com को अपने नीति डोमेन के रूप में उपयोग करता है। RFC 8461 प्रशासनिक रूप से कॉन्फ़िगर किए गए स्मार्ट होस्ट के लिए विशेष हैंडलिंग भी देता है: स्मार्ट-होस्ट डोमेन नीति डोमेन बन जाता है। अनुपस्थित रिकॉर्ड की व्याख्या करने से पहले रिकॉर्ड करें कि आप किस रूटिंग स्थिति का परीक्षण कर रहे हैं।

The TXT रिकॉर्ड v=STSv1 से शुरू होना चाहिए और इसमें 1-32 ASCII अक्षरों या अंकों की एक आईडी शामिल होनी चाहिए। पहचानकर्ता विशिष्ट रूप से किसी पॉलिसी के उदाहरण की पहचान करता है। इसका कोई निहित आदेश नहीं है: 20261107बी एक सुविधाजनक परिचालन लेबल है, न कि समय प्रोटोकॉल या केवल बड़ी संख्याओं को स्वीकार करने का निर्देश।

स्क्रीन पंक्तियों के बजाय रिकॉर्ड गिनें

सन्दर्भ: RFC 8461 §3.1, RFC 8461 §8.2.

यदि कई TXT रिकॉर्ड लौटाए जाते हैं, तो डिस्कवरी उन रिकॉर्ड्स को खारिज कर देती है जो v=STSv1; . बिल्कुल एक लागू, वाक्यविन्यास की दृष्टि से मान्य रिकॉर्ड अवश्य रहना चाहिए। दो स्वतंत्र MTA-STS रिकॉर्ड एक सुरक्षित रोलओवर तंत्र नहीं हैं। एक TXT संसाधन रिकॉर्ड के अंदर एकाधिक स्ट्रिंग्स को रिक्त स्थान जोड़े बिना संयोजित किया जाता है।

CNAME खोज की अनुमति है और यह TXT रिकॉर्ड तक एक श्रृंखला का अनुसरण कर सकता है। मालिक और उपनाम चेन को साक्ष्य में रखें। डिस्कवरी डेलिगेशन प्राप्तकर्ता डोमेन की पॉलिसी होस्टनाम के तहत HTTPS पॉलिसी पुनर्प्राप्ति की आवश्यकता को नहीं हटाता है।

खोज विफलताओं को पुन: प्रस्तुत करें

एक पृथक DNS फ़िक्स्चर में, v=STSv1; id=A1 और एक असंबंधित सत्यापन TXT रिकॉर्ड। इच्छित चयन में एक MTA-STS उम्मीदवार को बरकरार रखा जाता है। दूसरा स्वतंत्र v=STSv1; id=A2 रिकॉर्ड और परिणाम उस उत्तर के माध्यम से खोजी गई कोई उपलब्ध नीति नहीं है। फिर मूल रिकॉर्ड को दो स्ट्रिंग्स में विभाजित करें, v=STSv1; और एक स्थान जिसके बाद id=A1, और संयोजन को सत्यापित करने से एक वैध मान पुनर्स्थापित हो जाता है।

पूर्ण स्वामी से पूछताछ करें _mta-sts.example.test. प्रत्येक प्रयोगशाला प्राधिकरण के विरुद्ध प्रकार TXT और एक प्रयोगशाला पुनरावर्ती रिज़ॉल्वर, बचत स्थिति, रिकॉर्ड सीमाएँ और TTL के साथ। यह प्रक्रिया निर्दिष्ट है, निष्पादित सार्वजनिक DNS परीक्षण नहीं। आपूर्ति की गई स्थानीय स्थिरता को इस समीक्षा के लिए दोबारा चलाया गया था और केवल उम्मीदवार-गणना तर्क का उपयोग किया गया था; यह DNS रिज़ॉल्वर या पूर्ण खोज पार्सर नहीं है।

घोषणा से पहले HTTPS अपडेट करें

सन्दर्भ: RFC 8461 §3.3, RFC 8461 §5.1, RFC 8461 §8.1.

पहले नई पॉलिसी बॉडी को प्रकाशित और सत्यापित करें, फिर आईडी बदलें। अन्यथा प्रेषक पुरानी बॉडी लाते समय भी नई आईडी देख सकता है। संक्रमण के दौरान पुराने मार्गों को प्रयोग योग्य रखें। गुम या अनुपयोगी खोज एक वैध गैर-समाप्त कैश्ड पॉलिसी को नहीं मिटाती है, और एक आईडी परिवर्तन प्रत्येक प्रेषक द्वारा तत्काल लाने की गारंटी नहीं है। DNS और प्रेषक कैश को परिवर्तन के अलग-अलग हिस्सों के रूप में मानें।

ऐतिहासिक साक्ष्य और शेष गुंजाइश बरकरार रखी

निम्नलिखित 7 नवंबर 2026 का प्रयोगशाला रिकॉर्ड है, जिसका निरीक्षण किया गया लेकिन इस समीक्षा के लिए नेटवर्क प्रयोग के रूप में दोबारा नहीं चलाया गया। नए ऑफ़लाइन फ़िक्स्चर निष्पादन को अलग से रिकॉर्ड किया जाता है।

एक कैप्चर की गई तार्किक समयरेखा A1 से शुरू होती है जिसे प्रकाशित किया गया है और युग 1000000 पर लाया गया है: लागू करें, केवल पुराना MX , अधिकतम आयु 86400, प्रेषक की समाप्ति 1086400। A1 को अंतिम बार 1000300 पर परोसा गया था, इसलिए उस सीमा पर लाने वाला कोई अन्य प्रेषक इसे 1086700 तक बनाए रख सकता था। B2 को पुराने और नए के साथ 1000300 पर प्रकाशित किया गया था। MX पैटर्न और अधिकतम आयु 3600; इसका मॉडल अंतिम-सेवा समय 1000600 है, जो समाप्ति 1004200 देता है। 1000600 पर सी3 केवल नए को अनुमति देता है, अंतिम-सेवा समय 1000900 और समाप्ति 1004500 के साथ। ये स्पष्ट सिंथेटिक समय हैं, देखे गए इंटरनेट ईवेंट नहीं हैं। 7 नवंबर के बनाए गए ट्रेस रिकॉर्ड में बताया गया है कि लैब ने अपनी DNS प्रतिक्रिया को B2 में बदल दिया और HTTPS पर डुअल-एमएक्स बॉडी प्राप्त की। एक दावे ने पिछले A1 कैश को अपरिवर्तित रखा; पुराने को अनुमति दी गई और नए को वहां अनुमति नहीं दी गई, जबकि ताज़ा B2 बॉडी को नए की अनुमति दी गई। इस प्रकार एक पहचानकर्ता घोषणा और एक सफल नया फ़ेच स्वयं किसी अन्य कैश्ड स्नैपशॉट को परिवर्तित नहीं करता है।

[ ले लेना ]

नई आईडी की घोषणा करने से पहले HTTPS बॉडी प्रकाशित करें।

[भूमिका के अनुसार]

आपके लिए इसका क्या मतलब है

व्यावहारिक अगले चरणों के लिए अपनी भूमिका चुनें।

आईटी/मेल एडमिन

रिकॉर्ड सीमाओं का निरीक्षण करें

डुप्लिकेट नीतियाँ एक रिकॉर्ड में कई स्ट्रिंग फ़्रैगमेंट से भिन्न होती हैं।

अगले कदम

  1. सटीक प्राप्तकर्ता डोमेन क्वेरी करें.
  2. TXT रिकॉर्ड सीमाओं का निरीक्षण करें।
  3. आईडी बदलने से पहले HTTPS सत्यापित करें।

सीआईएसओ/सेकऑप्स

प्रत्यायोजित प्रभाव को ट्रैक करें

डिस्कवरी उपनाम ऐसी निर्भरताएँ बनाते हैं जिनके लिए स्वामित्व की आवश्यकता होती है।

अगले कदम

  1. प्रत्यायोजित खोज स्वामित्व की समीक्षा करें.
  2. पिछली पॉलिसी जीवनकाल को सुरक्षित रखें।
  3. अनुपस्थित खोज को अनुपस्थित प्रवर्तन से अलग करें।

संस्थापक/गैर-तकनीकी

खोज के दोनों हिस्सों के मालिक

एक संशोधन घोषणा और दी गई नीति समन्वित रहनी चाहिए।

अगले कदम

  1. दोनों प्रकाशन समापनबिंदु के स्वामी।
  2. पुनरीक्षण इतिहास रखें.
  3. अनुमानित तत्काल रोलबैक से बचें।

[ पूछे जाने वाले प्रश्न ]

अक्सर पूछे जाने वाले प्रश्नों

क्या आईडी पॉलिसी हैश है?

नहीं, यह ऑपरेटर द्वारा चुना गया एक संक्षिप्त संशोधन पहचानकर्ता है।

RFC 8461 §3.1

क्या आईडी संख्यात्मक रूप से बढ़नी चाहिए?

कोई आदेश परिभाषित नहीं है.

RFC 8461 §3.1

क्या आईडी में हाइफ़न हो सकता है?

निर्दिष्ट आईडी व्याकरण केवल ASCII अक्षरों और अंकों की अनुमति देता है।

RFC 8461 §3.1

क्या दो STS TXT रिकॉर्ड एक साथ रह सकते हैं?

वैध खोज परिणाम के रूप में नहीं; बिल्कुल एक लागू रिकॉर्ड रहना चाहिए।

RFC 8461 §3.1

क्या खोज किसी CNAME अनुसरण कर सकती है?

हाँ। RFC 8461 को खोज उपनाम श्रृंखला का पालन करने की आवश्यकता है।

RFC 8461 §3.1

क्या उपडोमेन को शीर्ष नीति विरासत में मिलती है?

नहीं, वास्तविक प्राप्तकर्ता उपडोमेन के लिए नीति खोजें।

RFC 8461 §3.4

कौन सा परिवर्तन सबसे पहले आता है?

DNS आईडी बदलने से पहले HTTPS बॉडी प्रकाशित करें।

RFC 8461 §8.1

क्या आईडी हटाने से कैश साफ़ हो जाता है?

नहीं, एक वैध कैश्ड पॉलिसी अभी भी लागू हो सकती है।

RFC 8461 §3.3

[ सूत्रों का कहना है ]

सूत्रों का कहना है

  1. RFC 8461

    धारा §2 · §3.1 · §3.3 · §3.4 · §5.1 · §8.1 · §8.2

[ शब्दकोष ]

शब्दकोष

नीति डोमेन
लागू परिवहन-नीति खोज के लिए उपयोग किया जाने वाला डोमेन।

RFC 8461 §2

पॉलिसी आईडी
एक विशेष MTA-STS नीति उदाहरण की घोषणा करने वाला संक्षिप्त पहचानकर्ता।

RFC 8461 §3.1

TXT संसाधन रिकॉर्ड
एक DNS रिकॉर्ड जिसमें एकाधिक स्ट्रिंग टुकड़े हो सकते हैं।

RFC 8461 §3.1

उद्यम उद्गम

शीर्ष वित्तीय संस्थान और सरकारें ही क्यों? अपने ईमेल सुरक्षा डैशबोर्ड हटा दिए।

पारंपरिक ईमेल प्रमाणीकरण प्लेटफ़ॉर्म आपको एक डैशबोर्ड बेचते हैं और आपके इंजीनियरों से काम करने के लिए कहते हैं। उच्च जोखिम वाले वातावरण में, मैन्युअल निरीक्षण का अर्थ है विलंबित प्रवर्तन, कॉन्फ़िगरेशन बहाव और अनियंत्रित छाया डोमेन।

EmailAuth एजेंटिक ईमेल उद्गम मंच है। हमारे एजेंट लागू करते हैं p=reject, तृतीय-पक्ष प्रेषकों को संरेखित रखें और अपने डोमेन को पूर्ण रूप से स्थानांतरित करें RFC 9989 अनुपालन, नया DMARC मानक, मानव-इन-द-लूप ऑडिटेबिलिटी के साथ।

सरकारों बड़े उद्यम टियर-1 वित्तीय संस्थान

सास · समर्पित किरायेदारी · एयर-गैप्ड ऑन-प्रिमाइसेस · BYOK एन्क्रिप्शन

ज्ञानधार