मुहावरा DMARC बायपास बहुत भिन्न घटनाओं का वर्णन कर सकता है। किसी अति-अधिकृत स्रोत से वैध पास, असफल परिणाम के बावजूद डिलीवरी और कार्यान्वयन त्रुटि एक ही विफलता नहीं हैं। एक झूठे दावे से शुरुआत करें: किस पहचान का दावा किया गया था, किस सबूत पर भरोसा किया गया था और कौन सा निर्णय अपेक्षित नियम से भिन्न था?
देखे गए निर्णय का पुनर्निर्माण करें
लेखक डोमेन, लिफ़ाफ़ा डोमेन, हस्ताक्षरित डोमेन, विश्वसनीय प्रमाणीकरण परिणाम और प्राप्तकर्ता स्वभाव को सुरक्षित रखें। नीति और अवलोकन समय रिकॉर्ड करें. दिया जा रहा संदेश अपने आप में DMARC पास साबित नहीं होता है। रिसीवर हैंडलिंग में स्थानीय नीति शामिल है, और एक डोमेन मालिक का अनुरोधित उपचार सार्वभौमिक डिलीवरी गारंटी नहीं है। RFC 9989.
इसी तरह, एक प्रतिलिपि Authentication-Results स्ट्रिंग प्राप्तकर्ता सिस्टम के निर्णय का प्रमाण नहीं है। विश्वसनीय प्रमाणीकरण सेवा और प्रासंगिक हॉप स्थापित करें। RFC 8601. यदि एकमात्र सबूत पास कहने वाला स्क्रीनशॉट है, तो अंतर्निहित पहचान और विश्वास संदर्भ उपलब्ध होने तक दावे को अनसुलझे के रूप में सुरक्षित रखें।
अति-प्राधिकरण को नियम चोरी से अलग करें
ब्रेकएसपीएफ अध्ययन करता है कि कितना अनुमोदक है SPF प्राधिकरण और साझा बुनियादी ढांचे तक पहुंच अनुमति दे सकती है स्पूफिंग. इसका खतरा मॉडल हमलावर को एक योग्य स्रोत पथ देता है; इसके बाद प्राप्तकर्ता लिखित रूप में प्रकाशित प्राधिकरण का मूल्यांकन कर सकता है। ब्रेकएसपीएफ, अनुभाग III.ए और चित्र 3.
यदि हमलावर-नियंत्रित स्रोत एक अधिकृत सीमा के भीतर है और एक संरेखित लिफ़ाफ़ा पहचान का उपयोग करता है, तो साधारण पास नियम सफल हो सकता है। कमजोरी DMARC की नई परिभाषा के बजाय दिए गए अधिकार या सेवा सीमा में है। इसके विपरीत, यदि केवल एक असंबंधित पहचान प्रमाणित होती है और लेखक डोमेन संरेखित नहीं है, तो दावा किए गए पास के लिए एक अलग स्पष्टीकरण की आवश्यकता होती है।
तीन काल्पनिक निष्कर्षों को वर्गीकृत करें
alerts@brand.test से एक दृश्यमान और अन्यथा योग्य DMARC मूल्यांकन मान लें। ये लिखित परिकल्पनाएँ हैं, देखी गई घटनाएँ नहीं।
- प्राधिकरण मामला: स्रोत 192.0.2.99 निर्धारित SPF ip4:192.0.2.0/24 सीमा के भीतर है; मेल प्रेषक bounce@brand.test SPF पास करता है; नहीं DKIM हस्ताक्षर. संरेखित SPF पथ एक संदेश-स्तरीय DMARC पास उत्पन्न करता है। पूछें कि क्या वह स्रोत वास्तव में किसी अनपेक्षित प्रेषक द्वारा नियंत्रित किया जा सकता है और किस स्वामी ने उसे अधिकार दिया है।
- हैंडलिंग केस: bounce@other.test से मेल SPF पास करता है और DKIM d=other.test passes, but assume neither aligns with brand.test. DMARC fails. If the trusted receiver record separately says delivered, investigate its handling policy; delivery alone has not changed the failed संरेखण परिणाम।
- साक्ष्य मामला: कॉपी किया गया हेडर पास कहता है, लेकिन विश्वसनीय रिसीवर मूल, मूल्यांकन की गई पहचान और लागू नीति अज्ञात हैं। न तो कोई प्रोटोकॉल उल्लंघन और न ही कोई भरोसेमंद पास स्थापित किया गया है। मूल और रिसीवर-साइड रिकॉर्ड का अनुरोध करें।
एक अधिकृत सकारात्मक प्रेषक 192.0.2.10 और एक बाहरी स्रोत 198.51.100.10 पहले मामले की जांच करते समय प्रस्तावित नियंत्रण प्रदान कर सकते हैं। एक -all ip4:192.0.2.10/32 रिकॉर्ड केवल पहले वाले को ही स्वीकार करते हैं; इस उपसर्ग अंकगणित से कोई वास्तविक उत्पादन परिवर्तन नहीं होता है। यहां कोई निष्पादित पार्सर, हस्ताक्षर जांच या शोषण नहीं है।
RFC9989 अनुभाग 7.4 को डोमेन प्रकाशन के लिए वैध DKIM आवश्यकता है p=reject. एक पासिंग संरेखित SPF तंत्र किसी विशेष संदेश की पास स्थिति के लिए पर्याप्त है, लेकिन यह केवल एसपीएफ़ प्रवर्तन के लिए अनुशंसा नहीं है।
खोज को क्रियाशील बनाएं
पुनरुत्पादित स्थिति और अभी भी गायब साक्ष्य का नाम बताइए। एक उपयोगी खोज कहती है कि एक निर्दिष्ट स्रोत को एक निर्दिष्ट प्राधिकरण द्वारा स्वीकार किया जाता है और जवाबदेह मालिक की पहचान की जाती है। यह नहीं कहता कि सभी DMARC सुरक्षा समाप्त हो गई है। जांचें कि क्या वास्तविक सेवा किरायेदार की पहचान को प्रतिबंधित करती है, क्या स्रोत वास्तव में नियंत्रणीय है और क्या प्राप्तकर्ता ने दावा किए गए परिणाम को लागू किया है।
प्रस्तावित शमन का परीक्षण करते समय हानिरहित अधिकृत सकारात्मक नियंत्रण बनाए रखें। किसी सीमा को सीमित करने या कनेक्टर बदलने से वैध प्रेषक टूट सकते हैं। मार्ग-विशिष्ट परिवर्तन अनुमोदन और परिवर्तन के बाद सत्यापन की आवश्यकता है, और प्रयोगशाला में परीक्षण न किए गए प्रदाता व्यवहार को स्पष्ट रूप से अनसुलझा रखें। यह शैक्षिक मॉडल को उत्पादन की भेद्यता में बढ़ा-चढ़ाकर पेश किए बिना सटीक समाधान का समर्थन करता है।