एक सुरक्षा गेटवे एक रिपोर्टिंग रिसीवर द्वारा देखे गए स्रोत के रूप में प्रकट हो सकता है क्योंकि यह संदेश को रिले करता है। इसकी उपस्थिति यह स्थापित नहीं करती है कि इसने संदेश बनाया है, भेजने वाले एप्लिकेशन का मालिक है या प्रमाणीकरण विफलता का कारण बना है। DNS या गेटवे-नीति परिवर्तन करने से पहले उस मार्ग और बिंदु की जांच करें जिस पर संदेश सामग्री बदल गई।
गेटवे भूमिका स्थापित करें
सन्दर्भ: RFC 9990 §3.1.1.8, RFC 9990 §3.1.1.10.
आवेदन से अंतिम प्राप्ति प्रणाली तक इच्छित मार्ग बनाएं। आउटबाउंड रिले, इनबाउंड गेटवे और अग्रेषण मध्यस्थ के बीच अंतर करें। रिकॉर्ड करें कि कौन सा संगठन प्रत्येक हॉप को नियंत्रित करता है और रिपोर्टिंग रिसीवर ने वास्तव में कौन सा हॉप देखा। एक परिचित गेटवे होस्टनाम केवल एक बुनियादी ढांचा सुराग है जब तक कि मार्ग की पुष्टि नहीं हो जाती।
स्रोत आईपी, रिपोर्टर, अंतराल, गिनती, लेखक डोमेन, लिफाफा पहचान, सुरक्षित रखें DKIM डोमेन और रिपोर्ट किया गया संरेखण परिणाम। इनकी तुलना अधिकृत गेटवे लॉग और विश्वसनीय रिसीवर साक्ष्य से करें। कच्चे संदेशों तक पहुंच प्रतिबंधित करें क्योंकि उनमें व्यक्तिगत या गोपनीय सामग्री हो सकती है।
हस्ताक्षर सीमा का पता लगाएँ
सन्दर्भ: RFC 6376 §3.4, RFC 6376 §3.7.
RFC 6376 परिभाषित करता है कि DKIM चयनित हेडर और कैनोनिकलाइज्ड बॉडी सामग्री को कैसे कवर करता है। एक गेटवे जो हस्ताक्षर करने के बाद कवर की गई सामग्री को बदलता है, हस्ताक्षर को अमान्य कर सकता है। प्रत्येक परिवर्तन आवश्यक रूप से नहीं होता: हस्ताक्षरित फ़ील्ड, कैनॉनिकलाइज़ेशन और सटीक परिवर्तन का मामला।
अधिकृत होने पर संदिग्ध परिवर्तन के तुरंत पहले और बाद से सुरक्षित प्रतिनिधि संदेश प्राप्त करें। उनके मूल बाइट्स को सुरक्षित रखें और सत्यापन परिणामों, चयनित हेडर और कैनोनिकलाइज्ड बॉडी इनपुट की तुलना करें। स्क्रीनशॉट या पुनः सहेजे गए टेक्स्ट की तुलना न करें जैसे कि वे हस्ताक्षरित संदेश को सटीक रूप से संरक्षित करते हैं। स्थापित करें कि क्या हस्ताक्षर पादलेख प्रविष्टि, विषय पुनर्लेखन या अन्य प्रसंस्करण से पहले या बाद में हुए थे।
SPF अलग से मूल्यांकन करें
सन्दर्भ: RFC 7208 §4.1, RFC 9989 §4.4, RFC 9989 §5.3.5.
एक डाउनस्ट्रीम रिसीवर प्रासंगिक के विरुद्ध कनेक्टिंग स्रोत का मूल्यांकन करता है SPF पहचान। इसलिए एक रिले DKIM जीवित रहने पर भी SPF स्थिति को बदल सकता है। रॉ SPF सफलता संतुष्ट नहीं करती DMARC यदि वह प्रमाणित पहचान लागू संरेखण नियम के तहत लेखक डोमेन से असंबंधित है।
DMARC या तो पासिंग एलाइन्ड SPF या DKIM पथ से गुजर सकता है। अन्य तंत्र की जाँच किए बिना किसी विफल हस्ताक्षर को समग्र DMARC विफलता के प्रमाण के रूप में मानने से बचें। इसी तरह, गेटवे के स्वयं के असंबंधित हस्ताक्षर को मूल लेखक के लिए स्वचालित रूप से संरेखित न मानें।
नियंत्रित तुलना के माध्यम से कार्य करें
काल्पनिक परिदृश्य, इस समीक्षा में निष्पादित परीक्षण नहीं: एक एप्लिकेशन example.com के लिए संकेत देता है, फिर एक आउटबाउंड गेटवे एक अस्वीकरण जोड़ता है। मान लीजिए कि प्राप्त परीक्षण मेलबॉक्स उस हस्ताक्षर के लिए बॉडी-हैश विफलता दिखाता है। SPF एक असंबंधित सेवा लिफ़ाफ़ा डोमेन के लिए पास होता है। कोई अन्य संरेखित पासिंग तंत्र नहीं होने से, यह उदाहरण DMARC विफल हो जाता है।
जांच में पहले और बाद के नमूनों की तुलना करने और यह पुष्टि करने की आवश्यकता होगी कि ढका हुआ शरीर प्रवेश द्वार पर बदल गया है। एक प्रस्तावित मरम्मत एक समर्थित डिज़ाइन का उपयोग करके इच्छित परिवर्तन के बाद अधिकृत संरेखित हस्ताक्षर करना है। यह एक उम्मीदवार समाधान है, यह दावा नहीं है कि प्रत्येक गेटवे सुविधा प्रदान करता है या हस्ताक्षरकर्ता को ले जाना हमेशा सुरक्षित होता है।
चुनी गई मरम्मत को सत्यापित करें
क्या जिम्मेदार मालिकों ने डिजाइन और सुरक्षा निहितार्थों को मंजूरी दे दी है। प्रतिनिधि सामग्री के साथ वास्तविक मार्ग का परीक्षण करें, जिसमें पुनर्लेखन को ट्रिगर करने वाले टेम्पलेट भी शामिल हैं। किसी बाहरी रिसीवर पर संरेखित प्रमाणीकरण की पुष्टि करें और व्यावसायिक वर्कफ़्लो को सत्यापित करें। सुरक्षा स्कैनिंग को प्रभावी रखें; परीक्षण पास करने के लिए नियंत्रणों को अंधाधुंध अक्षम न करें।
सत्यापित मार्ग, सटीक परिवर्तन, हस्ताक्षर प्लेसमेंट, बनाए रखा परीक्षण साक्ष्य और रोलबैक मानदंड के साथ घटना को बंद करें। यदि पहले और बाद के साक्ष्य उपलब्ध नहीं हैं, तो संदिग्ध कारण को अस्थायी रखें और नियंत्रित पुनरुत्पादन प्राप्त करें। अकेले गेटवे लेबल मूल-कारण निष्कर्ष या व्यापक SPF प्राधिकरण को उचित नहीं ठहरा सकता है।