एससीएल, बीसीएल और अन्य माइक्रोसॉफ्ट फैसले: उन्हें प्रमाणीकरण परिणामों से अलग करते हैं

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

वर्तमान Microsoft मार्गदर्शन पढ़ें

माइक्रोसॉफ्ट का वर्तमान हेडर संदर्भ अलग है Authentication-Results एक्स-फ़ोरफ़्रंट-एंटीस्पैम-रिपोर्ट और एक्स-माइक्रोसॉफ्ट-एंटीस्पैम से। यह बीसीएल को डोमेन प्रमाणीकरण के बजाय थोक शिकायत संभावना के रूप में वर्णित करता है। इसमें यह भी कहा गया है कि, क्लाउड संगठनों में, एससीएल स्पैम वर्गीकरण या कार्रवाई का निर्धारण नहीं करता है; इसके बजाय CAT और DIR फ़िल्टरिंग संदर्भ प्रदान करते हैं। पुरानी एससीएल-टू-फ़ोल्डर तालिका को सार्वभौमिक क्लाउड निर्णय नियम के रूप में लागू न करें। इसका मतलब यह नहीं है कि एससीएल कॉन्फ़िगरेशन के लिए अप्रासंगिक है: माइक्रोसॉफ्ट अभी भी मेल-फ्लो नियमों का दस्तावेजीकरण करता है जो बायपास या स्पैम उपचार का अनुरोध करता है। मुद्रांकित एससीएल और वास्तविक कार्रवाई की जांच लागू नियम और वर्गीकरण संदर्भ के साथ की जानी चाहिए। माइक्रोसॉफ्ट हेडर संदर्भ.

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

अर्थों को नष्ट किए बिना एक साक्ष्य तालिका बनाएं

सन्दर्भ: RFC 8601 §5, RFC 8601 §7.

प्राप्तकर्ता का रिकॉर्ड रखें SPF, DKIM और DMARC उनके मूल्यांकित डोमेन के साथ परिणाम। एक अलग समूह में, CAT, DIR, BCL और किसी भी प्रासंगिक SFV मान को बिल्कुल प्राप्त अनुसार रिकॉर्ड करें। अप्रलेखित फ़ील्ड को बिना व्याख्या किए छोड़ दें। फिर अधिकृत ट्रेस, संगरोध रिकॉर्ड या मेलबॉक्स अवलोकन से वास्तविक स्वभाव जोड़ें। एक लुप्त फ़ील्ड एक अज्ञात है, शून्य या उत्तीर्ण परिणाम नहीं है।

इन अवलोकनों के स्रोत को प्रमाणित करें। अविश्वसनीय संदेशों में भ्रामक हेडर टेक्स्ट हो सकता है, और अग्रेषित प्रतिलिपि जानकारी जोड़ या हटा सकती है। RFC 8601 प्रमाणीकरण परिणामों के आसपास एक विश्वास सीमा की आवश्यकता का वर्णन करता है; यही खोजी सावधानी तब लागू होती है जब कोई व्यक्ति उत्पाद-विशिष्ट मेटाडेटा का स्क्रीनशॉट भेजता है। RFC 8601 अनुभाग 7.

परिणामों की सिंथेटिक जोड़ी की तुलना करें

आपूर्ति किए गए फिक्स्चर में dmarc=pass, CAT:BULK, DIR:INB और BCL:7 के साथ जानबूझकर आविष्कार किया गया संदेश शामिल है। यह एक प्रोटोकॉल पास और एक थोक वर्गीकरण के सह-अस्तित्व को प्रदर्शित करता है। पार्सर फ़ील्ड को स्वतंत्र रूप से निकालता है। यह माइक्रोसॉफ्ट के क्लासिफायरियर को नहीं चलाता है, वास्तविक सीमा स्थापित नहीं करता है, या प्राप्तकर्ता द्वारा देखे जाने वाले फ़ोल्डर की भविष्यवाणी नहीं करता है।

वास्तविक जांच में, उस समय प्राप्तकर्ता पर लागू नीति और प्रसंस्करण साक्ष्य को पुनः प्राप्त करें। यह न मानें कि संख्यात्मक बीसीएल मान हमेशा संगठनों में समान कार्रवाई की ओर ले जाता है। एक प्रेषक को बेहतर दर्शकों की सहमति, भेजने की प्रथाओं या सामग्री की आवश्यकता हो सकती है, जबकि एक अलग मामले में प्रमाणीकरण मरम्मत की आवश्यकता होती है। साक्ष्य से यह पहचानना चाहिए कि कौन सा कार्य लागू होता है।

केवल जिम्मेदार परत बदलें

सन्दर्भ: RFC 9989 §8.

यदि प्रमाणीकरण विफल हो जाता है, तो भेजने वाले कॉन्फ़िगरेशन को सही करें और उसी मार्ग को सत्यापित करें। यदि प्रमाणीकरण पास हो जाता है और एक थोक या खतरा श्रेणी प्रबंधन की व्याख्या करती है, तो प्राप्तकर्ता संगठन की समर्थित समीक्षा प्रक्रिया के माध्यम से उस वर्गीकरण की जांच करें। प्रमाणीकरण पास को कभी भी मैलवेयर, प्रतिरूपण या स्पैम सुरक्षा को बायपास करने की अनुमति के रूप में न समझें।

अनुमोदित सुधार के बाद पुराने और नए साक्ष्य रिकॉर्ड करें। बताएं कि क्या सुधार एक प्रमाणीकरण परिवर्तन था, एक नीति परिवर्तन था या एक नया देखा गया स्वभाव था। एक संदेश को हल करने के लिए एक ही स्कोर से इनबॉक्स डिलीवरी या सभी मेल के लिए सीमा बदलने का वादा करने से बचें।

विश्वास जताए बिना एनोटेट किए गए नमूने को पढ़ें

सन्दर्भ: RFC 8601 §5.

बनाए रखा गया एनोटेशन रजिस्टर प्रत्येक कच्चे फ़ील्ड को उसके वास्तविक जनरेटर, दावा किए गए मूल और विश्वास सीमा के क्रम में सूचीबद्ध करता है। से एक लेखक द्वारा प्रदत्त पहचान है; SMTP लिफाफे के प्रमाण के बजाय एक प्रदर्शित प्राप्तकर्ता है। संदेश-आईडी, दिनांक और विषय प्रेषक-नियंत्रित संदर्भ हैं। प्रत्येक Authentication-Results फ़ील्ड एक रिपोर्टिंग सेवा और परिणाम का दावा करता है, लेकिन न तो trusted.example और न ही untrusted.example वास्तविक रिसीवर उद्गम स्थापित करता है। सूची-आईडी दावा की गई सूची का नाम देता है; सदस्यता समाप्त फ़ील्ड एक कार्रवाई तंत्र का वर्णन करते हैं, सूची स्वामित्व का नहीं। वर्गीकरण नमूने में, CAT, DIR, SCL और BCL का आविष्कृत Microsoft-शैली के निर्णय हैं, न कि Microsoft के अवलोकन। कोई प्राप्त श्रृंखला, SPF लिफाफा पहचान या कनेक्टिंग आईपी स्थापित नहीं किया गया था।

इस मानचित्र का उपयोग एनोटेटेड शिक्षण उदाहरण के रूप में करें। वास्तविक संदेश के लिए, प्रत्येक कल्पित मूल को संग्रह और प्राप्तकर्ता साक्ष्य से बदलें, और किसी भी असत्यापित सीमा को स्पष्ट रूप से अनसुलझा छोड़ दें।