इसमें जो पता दिखाया गया है Return-Path पाठक द्वारा प्रेषक में देखे गए पते से अक्सर भिन्न होता है। ग्राहक की ओर से डिलीवरी सेवा के बाउंस को संभालने के लिए यह सामान्य हो सकता है। प्रासंगिक पहचान का निदान करें और यह तय करने से पहले कि क्या अंतर है, आशा करें स्पूफिंग सिग्नल या नियमित रूटिंग व्यवस्था।
लिफ़ाफ़े को संदेश सामग्री से अलग करें
मेल प्रेषक लेनदेन के दौरान SMTP रिवर्स पथ की आपूर्ति करता है। संदेश का प्रेषक फ़ील्ड इंटरनेट संदेश प्रारूप के अंतर्गत उसके लेखक की पहचान करता है। अंतिम डिलीवरी पर, डिलीवरी करने वाला SMTP सिस्टम रिवर्स पथ को संरक्षित करने के लिए Return-Path फ़ील्ड सम्मिलित करता है। यह केवल दृश्य लेखक के पते की एक और वर्तनी नहीं है। RFC 5321 अनुभाग 3.3 और 4.4; RFC 5322 अनुभाग 3.6.2.
एक शून्य रिवर्स पथ डिलीवरी सूचनाओं के लिए वैध है और अधिसूचना लूप से बचने में मदद करता है। इसलिए <> के दृश्यमान Return-Path व्याख्या संदेश के वास्तविक संदर्भ में की जानी चाहिए न कि इसे केवल इसलिए विकृत कहा जाना चाहिए क्योंकि इसमें कोई पता नहीं है।
जानें कि साक्ष्य किस हॉप का वर्णन करता है
अग्रेषण या रिले व्यवस्था बाद के लेनदेन के लिए उपयोग किए जाने वाले लिफाफे को बदल सकती है। इसलिए अंतिम संग्रहीत Return-Path हर पहले हॉप पर लिफाफे का वर्णन करने की आवश्यकता नहीं है। जब प्रश्न यह हो कि किसी विशेष रिसीवर ने क्या मूल्यांकन किया है तो प्राप्त लॉग या विश्वसनीय प्रमाणीकरण गुण प्राप्त करें। मार्ग की जांच किए बिना किसी ऐतिहासिक लिफाफे के स्थान पर अंतिम डिलीवरी हेडर न रखें।
SPF अपने नियमों के अनुसार SMTP पहचान की जाँच करता है। एक खाली रिवर्स पथ के साथ, RFC 7208 पोस्टमास्टर और से मेल फ्रॉम पहचान का निर्माण करता है HELO कार्यक्षेत्र; यह दृश्यमान फ़ील्ड से कोई पता नहीं लेता है। DMARCSPF साक्ष्य के उपयोग के लिए भी प्रासंगिक की आवश्यकता होती है संरेखण दृश्यमान डोमेन से। किसी असंबंधित रिटर्न डोमेन के लिए पास अपने आप में DMARC सफलता स्थापित नहीं करता है। RFC 7208 अनुभाग 2.3 और 2.4; RFC 9989.
लेन-देन साक्ष्य के साथ संपादन योग्य शीर्षलेख की तुलना करें
मान लीजिए कि एक चिपकाया गया संदेश Return-Path कहता है: < bounce@service.example >, जबकि दूसरी प्रति कहती है Return-Path : < edited@unrelated.example >। केवल एक टेक्स्ट एडिट न तो पिछले MAIL FROM कमांड को बदलता है और न ही यह साबित करता है कि कौन सी कॉपी अंतिम डिलीवरी को दर्शाती है। ये काल्पनिक मान हैं, कोई निष्पादित फ़ाइल-संपादन प्रयोग नहीं।
अधिकृत मूल निर्यात और अंतिम-डिलीवरी प्रणाली के प्रासंगिक रिकॉर्ड प्राप्त करें। अनपेक्षित डुप्लिकेट Return-Path फ़ील्ड की जांच की आवश्यकता है, न कि मनमाने ढंग से पहले या आखिरी नियम की। RFC 5321 खंड 4.4 अंतिम-डिलीवरी प्रविष्टि और बाद में अग्रेषण में संभावित निष्कासन/पुनर्निर्माण का वर्णन करता है; प्रत्येक चिपकाए गए फ़ील्ड को आधिकारिक मानने के बजाय ज्ञात मार्ग लागू करें।
जो पहचान गलत है उसे ही सुधारें
वैध सेवा के लिए, कॉन्फ़िगर किए गए बाउंस डोमेन, उसके स्वामित्व, वास्तविक प्रेषण पथ और प्रासंगिक प्रमाणीकरण परिणामों की पुष्टि करें। अकेले रिटर्न-डोमेन अंतर विक्रेता कॉन्फ़िगरेशन को हटाने का औचित्य नहीं बताता है। यदि मार्ग अनधिकृत है या लिफाफा अनुमोदित सेटअप से मेल नहीं खाता है, तो परिवर्तन नियंत्रण के तहत उस विशिष्ट कॉन्फ़िगरेशन को ठीक करें और अधिकृत संदेश का परीक्षण करें।
दृश्यमान लेखक के साथ बंद करें, मूल्यांकन किए गए हॉप पर लिफ़ाफ़ा पहचान, अंतिम Return-Path उद्गम और प्रमाणीकरण परिणाम। सफल SMTP सबमिशन, अंतिम डिलीवरी और संदेश की वैधता को अलग-अलग निष्कर्ष के रूप में रखें।
एक वैध सेवा व्यवस्था के माध्यम से चलें
मान लें कि किसी ब्रांड ने अपने बाउंस को संभालने के लिए एक अधिसूचना सेवा को अधिकृत किया है। इस काल्पनिक लेन-देन में, MAIL FROM bounce@service.example है, जबकि From notices@brand.example है। अंतिम डिलीवरी पर, प्राप्तकर्ता सिस्टम उस लेनदेन के रिवर्स पथ से Return-Path सम्मिलित करता है। विभिन्न रिटर्न और लेखक डोमेन अनुमानित सेवा व्यवस्था के अनुरूप हैं, लेकिन फ़ील्ड अकेले प्राधिकरण को साबित नहीं करते हैं।
वास्तविक सेटअप को सत्यापित करने के लिए, सेवा स्वामित्व और कॉन्फ़िगरेशन की पुष्टि करें, फिर प्रासंगिक प्राप्त हॉप के लिए विश्वसनीय परिणामों की जांच करें। अकेले service.example के लिए SPF पास इस उदाहरण में brand.example के साथ संरेखित नहीं होता है। एक वैध DKIM हस्ताक्षर d=brand.example का उपयोग लागू DMARC नीति और कोई अनसुलझे मूल्यांकन त्रुटि को मानते हुए एक संरेखित पथ प्रदान कर सकता है। यहां कोई DNS , हस्ताक्षर या डिलीवरी परीक्षण नहीं किया गया था।
संदेश-स्तरीय मूल्यांकन को परिनियोजन दायित्वों से अलग रखें: RFC 9989 अनुभाग 7.4 और 8 में डोमेन प्रकाशन की आवश्यकता होती है p=reject केवल SPF पर निर्भर न रहें और वैध आवेदन करें DKIM हस्ताक्षर. Return-Path टेक्स्ट को संपादित करना उन आवश्यकताओं को पूरा करने का एक तरीका नहीं है।
रिटर्न-डोमेन अंतर का निदान करें
- मूल्यांकित प्राप्ति हॉप पर FROM को MAIL FROM से अलग से पहचानें।
- स्थापित करें कि अंतिम Return-Path किसने डाला और क्या बाद में अग्रेषित करने से लिफाफा बदल गया।
- स्वीकृत सेवा और बाउंस-डोमेन कॉन्फ़िगरेशन की पुष्टि करें।
- विश्वसनीय SPF और संरेखित DKIM / DMARC साक्ष्य को प्राप्त किए बिना उसका निरीक्षण करें हेडर से अकेले पाठ.
- केवल प्रदर्शित कॉन्फ़िगरेशन दोष की मरम्मत करें और मूल साक्ष्य को सुरक्षित रखें।