एसपीएफ बनाम डीकेआईएम - सटीक उपयोग के मामले और अंतर


20

मुझे अस्पष्ट शीर्षक के लिए खेद है। मुझे पूरी तरह से समझ नहीं आया कि SPF और DKIM का एक साथ उपयोग क्यों किया जाना चाहिए।

पहला: SPF पास हो सकता है जहां यह विफल होना चाहिए अगर प्रेषक या DNS "स्पूफ़्ड" है और यह विफल हो सकता है जहां यह पास होना चाहिए अगर प्रॉक्सी और फ़ॉरवर्डर्स के कुछ उन्नत सेटअप शामिल हैं।

डीकेआईएम पास हो सकता है जहां यह विफल होना चाहिए, या तो क्रिप्टोग्राफी में एक त्रुटि / कमजोरी के कारण (हम इसे बाहर निकालते हैं, इसलिए सरलीकृत बिंदु), या क्योंकि DNS क्वेरी खराब हो गई है।

चूंकि क्रिप्टोग्राफी त्रुटि से इंकार किया जाता है, अंतर (जैसा कि मैं इसे देखता हूं) यह है कि डीकेआईएम का उपयोग सेटअप में किया जा सकता है जहां एसपीएफ विफल हो जाएगा। मैं ऐसे किसी भी उदाहरण के साथ नहीं आ सकता जहाँ दोनों का उपयोग करने से किसी को लाभ होगा। यदि सेटअप SPF के लिए अनुमति देता है, तो DIKM को कोई अतिरिक्त सत्यापन नहीं जोड़ना चाहिए।

क्या कोई मुझे दोनों के उपयोग के लाभ का उदाहरण दे सकता है?

जवाबों:


15

SPF में पास / फेल की तुलना में कई अधिक रैंकिंग हैं। इनको ह्यूरिस्टली स्कोरिंग स्पैम में इस्तेमाल करने से प्रक्रिया आसान और सटीक हो जाती है। "एडवांस सेटअप" के कारण फेल होना यह दर्शाता है कि मेल एडमिन को पता नहीं था कि वह एसपीएफ़ रिकॉर्ड स्थापित करने में क्या कर रहा है। ऐसा कोई सेटअप नहीं है जिसे SPF सही तरीके से खाता न हो।

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

एक उदाहरण जहां किसी को दोनों का उपयोग करने से लाभ होगा: दो अलग-अलग पार्टियों को भेजना जहां एक एसपीएफ की जांच करता है और दूसरा डीकेआईएम की जांच करता है। एक अन्य उदाहरण, सामग्री के साथ एक पार्टी को भेजना जो आम तौर पर स्पैम परीक्षण में उच्च रैंक करेगा, लेकिन वह डीकेआईएम और एसपीएफ दोनों द्वारा ऑफसेट किया जाता है, जिससे मेल को वितरित किया जा सकता है।

अधिकांश मामलों में न तो आवश्यकता होती है, हालांकि व्यक्तिगत मेल प्रशासक अपने स्वयं के नियम निर्धारित करते हैं। दोनों SPAM के अलग-अलग पहलुओं को संबोधित करने में मदद करते हैं: SPF जो ई-मेल को रिले कर रहा है और DKIM को ई-मेल की अखंडता और मूल की प्रामाणिकता बताया जा रहा है।


ठीक है, मैं आपके बिंदुओं का पालन करता हूं (विशेष रूप से कि कुछ केवल दो में से एक का उपयोग कर सकते हैं - मैंने यह कैसे नहीं देखा!)। इसलिए एसपीएफ और डीकेआईएम में अलग-अलग सेटिंग्स और रैंकिंग हो सकती हैं, लेकिन कुल मिलाकर, वे एक ही सिक्के के सामने हैं। आपके अंतिम बिंदु पर: अधिकृत रिले (SPF) के एक मेल पर सिर्फ एक मान्य DKIM हस्ताक्षर पर भरोसा किया जाना चाहिए .. आखिरकार, डोमेन के मालिक ने दोनों को मंजूरी दे दी है। मैंने अपने मेल का परीक्षण केवल SPF के साथ किया, और जबकि मेरे विश्वविद्यालय और जीमेल ने इसे स्वीकार करने के लिए हॉटमेल को स्पैम के रूप में माना - शायद इसलिए कि वे DIKM पर भरोसा करते हैं। आपकी टिप्पणी के लिए धन्यवाद क्रिस!
हटाए गए उपयोगकर्ता 42

हॉटमेल SenderID (SPF 2.0 को कहने के लिए) का उपयोग करता है, DKIM, SenderScore, PBLs, और अपनी स्वयं की फ़िल्टर तकनीक। वे सटीक सूत्र के बारे में थोड़ा गुप्त हैं।
क्रिस एस

18

यह कुछ समय पहले उत्तर दिया गया था, लेकिन मुझे लगता है कि स्वीकृत उत्तर में इस बात का अभाव है कि दोनों को एक साथ प्रभावी होने के लिए क्यों इस्तेमाल किया जाना चाहिए।

एसपीएफ एक अधिकृत सूची के खिलाफ पिछले एसएमटीपी सर्वर हॉप के आईपी की जांच करता है। DKIM मेल को मान्य करता है शुरू में एक दिए गए डोमेन द्वारा भेजा गया था, और इसकी अखंडता को वारंट करता है।

मान्य DKIM हस्ताक्षरित संदेशों को बिना किसी संशोधन के नाराज होने के कारण स्पैम या फ़िशिंग के रूप में उपयोग किया जा सकता है। SPF संदेश अखंडता की जाँच नहीं करता है।

ऐसे परिदृश्य की कल्पना करें जहां आपको एक मान्य DKIM हस्ताक्षरित ईमेल प्राप्त हो (आपके बैंक से, एक मित्र, जो भी हो), और आपको इस मेल को बिना संशोधन के दोहन का एक अच्छा तरीका मिल जाए: फिर आप इस मेल को हजारों बार अलग-अलग लोगों को भेज सकते हैं। चूंकि मेल का कोई संशोधन नहीं है, डीकेआईएम हस्ताक्षर अभी भी मान्य होगा और संदेश वैध के रूप में पारित होगा।

वैसे भी, SPF मेल के मूल (SMTP सर्वर का वास्तविक IP / DNS) की जाँच करता है, इसलिए SPF मेल को अग्रेषित करने से रोकेगा क्योंकि आप एक अच्छी तरह से कॉन्फ़िगर किए गए SMTP सर्वर के माध्यम से एक वैध मेल को भेज नहीं सकते हैं, और अन्य IP से आने वाला मेल होगा अस्वीकार कर दिया, प्रभावी रूप से "मान्य" DKIM संदेशों को स्पैम के रूप में रोकने के लिए।


क्या आप कृपया कुछ ऐसे उदाहरण देंगे कि बिना संशोधन के मेल का कैसे फायदा उठाया जा सकता है?
user3413723

जेनेरिक "प्रिय ग्राहक", "प्रिय उपयोगकर्ता", या "प्रिय <> आपके ईमेल पते का पहला भाग @ साइन"> से पहले शुरू होने वाला कोई भी ईमेल। यही कारण है कि यह महत्वपूर्ण है कि आपके लिए वैध ईमेल में हमेशा आपकी व्यक्तिगत जानकारी का कम से कम 1 टुकड़ा हो, जैसे कि आपकी पोस्ट / ज़िप कोड, या आपका पूरा नाम। (जो उन्हें और अधिक प्रामाणिक और गैर-पुन: प्रयोज्य बनाता है।)
एडम्बियन

लेकिन अगर हेडर फ़ील्ड्स को प्राप्तकर्ताओं सहित हस्ताक्षरित किया गया है, तो निश्चित रूप से यह नए प्राप्तकर्ताओं के खिलाफ रिप्ले हमले की संभावना को हटा देता है? यानी हस्ताक्षर जोड़ना h=from:to;( RFC 6376 में आवश्यक होने से , वैकल्पिक होने के लिए ) केवल उसी प्राप्तकर्ता पर पुनरावृत्ति के हमलों की अनुमति चाहिए। जो बुरा है, लेकिन उतना बुरा नहीं है जितना कि यह उत्तर सुझाव दे रहा है।
रिचर्ड डन

4

यहां कुछ कारण दिए गए हैं जिन्हें आपको हमेशा एसपीएफ और डीकेआईएम दोनों प्रकाशित करना चाहिए ।

  1. कुछ मेलबॉक्स प्रदाता केवल एक या दूसरे का समर्थन करते हैं और कुछ दोनों का समर्थन करते हैं लेकिन वजन एक दूसरे से अधिक होता है।

  2. DKIM पारगमन में ईमेल को बदलने से बचाता है, SPF नहीं करता है।

मैं सूची में DMARC भी जोड़ूंगा। हमेशा पूर्ण ईमेल ऑर्ट को प्रकाशित करने के लिए नकारात्मक पहलू क्या है?


1
"हमेशा पूर्ण ईमेल को प्रकाशित करने का नकारात्मक पक्ष क्या है?", प्रयास मुझे लगता है कि देवोप्स पहले से ही पीआईटीए है जो दीवार में एक और ईंट है, या 3 जैसा मामला हो सकता है।
गॉर्डन Wrigley

ISP का किसी चीज से क्या लेना-देना है? क्या आपका मतलब मेल प्रदाता है?
विलियम

हां, मेरा मतलब मेलबॉक्स प्रदाता था। लोग अक्सर आईएसपी से ईमेल सेवा प्राप्त करते थे, इसलिए मुझे आईएसपी कहने की आदत पड़ गई।
नील अनुस्किविज़

इंगित करने के लिए धन्यवाद कि मैंने अब इसे मेलबॉक्स प्रदाता में बदल दिया है।
नील अनुस्कीविज़
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.