SPF "हार्डफ़ेल" के बावजूद ईमेल को सामान्य रूप से क्यों वितरित किया जा रहा है?

Question

मैं यह पता लगाने की कोशिश कर रहा हूं कि जाली ईमेल को प्रमुख ईमेल प्रदाताओं (gmail.com, आउटलुक डॉट कॉम) पर कैसे पहुंचाया जा रहा है, भले ही ईमेल एसपीएफ़ के साथ चिह्नित हो hardfail। ईमेल Microsoft Exchange को भी दिया जाता है, जो PermErrorसमान SPF रिकॉर्ड के लिए फेंक रहा है ।

मैं SOME_DOMAIN.com डोमेन का उपयोग करके ईमेल भेज रहा हूं, जो एक टूटे हुए एसपीएफ़ रिकॉर्ड को परिभाषित करता है। यह ईमेल मेरे अपने आईपी पते से प्रेषित किया गया है जो SOME_DOMAIN.com के SPF रिकॉर्ड में स्पष्ट रूप से सूचीबद्ध नहीं है। SOME_DOMAIN.com के लिए SPF रिकॉर्ड में निम्नलिखित तीन गुण हैं, पहले दो SPF RFC-4408 का उल्लंघन हैं:

1. पूरे SPF रिकॉर्ड को हल करने के लिए 10 से अधिक DNS प्रश्नों की आवश्यकता होती है, जिनके कारण include:।
2. SPF रिकॉर्ड्स में से एक में सिंटैक्स त्रुटि, अजगर-spf एक पार्स त्रुटि फेंकता है।
3. एसपीएफ़ रिकॉर्ड में नियम ~allऔर -allदोनों हैं, जिसमें कहा गया है कि सभी पतों का सेट softfailऔर होना चाहिएhardfail

एक ईमेल भेज दिया गया है। यह ईमेल सामान्य रूप से उपयोगकर्ता के इनबॉक्स में वितरित किया गया था :

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmail उपयोगकर्ता के इनबॉक्स में ईमेल भी पहुंचाएगा, लेकिन एक अलग SPF त्रुटि देगा:

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

तो यहां पर क्या हो रहा है? एक एसपीएफ़ के बावजूद ईमेल क्यों दिया जा रहा है hardfail? क्या एक टूटे हुए एसपीएफ़ रिकॉर्ड का मतलब है कि अन्य एसएमटीपी सर्वर पूरी तरह से एसपीएफ़ की अवहेलना करते हैं? या कुछ ऐसा है जो मुझे याद आ रहा है ...

Answer 1

एसपीएफ़ इतनी बुरी तरह से कई साइटों द्वारा कॉन्फ़िगर किया गया है कि एमटीए प्राप्त करना अक्सर hardfailकेवल सलाहकार के रूप में गिना जाता है, और केवल इसे अपने स्पैम पहचान स्कोर में कारक बनाता है । अंत में यह एमटीए के प्रशासक पर निर्भर करता है कि एसपीएफ़ विफलताओं का इलाज कैसे किया जाएगा।

Comments

माना। एक कठिन असफलता का मतलब यह नहीं है कि ईमेल स्वचालित रूप से अस्वीकार कर दिया जाएगा। यह निर्भर करता है कि एसपीएफ को संभालने के लिए प्राप्त सर्वर को कैसे कॉन्फ़िगर किया जाता है।

— जोवेर्विटी

वर्थ नोटिंग ऑफिस 365 (और आउटलुक डॉट कॉम इसी तरह, एक ही प्लेटफॉर्म) में डिफ़ॉल्ट रूप से एसपीएफ सत्यापन अक्षम है। आप इसे ईओपी सेटिंग्स में सक्षम कर सकते हैं।

— थॉमस

Answer 2

एसपीएफ त्रुटि की स्थिति वांछित नीति के बारे में कुछ भी संकेत नहीं देती है। जैसे कि वे संदेश को स्वीकार करने या न करने के लिए कोई मार्गदर्शन प्रदान नहीं करते हैं। यह संभव है कि इरादा नीति है +all। इस मामले में मेल स्वीकार करना सामान्य है। ऐसा प्रतीत होता है कि Google इस डोमेन के साथ मानक का पालन करने में विफल होने के लिए उत्तरदायी है।

-allप्रेषक पतों को मान्य करते समय भी एसपीएफ़ नीति अस्वीकार ( ) अविश्वसनीय हैं। ऐसे कई मामले हैं जिनमें इस तरह के मेल को अस्वीकार करना अनुचित होगा:

• अनुबंधित मेलर्स द्वारा भेजे गए मेल (इन लोगों को पॉलिसी का उल्लंघन करने के लिए भुगतान मिलता है।);
• मेल वेब रूपों और ऐसे अन्य स्वचालित प्रणाली से भेजे गए;
• मेलिंग सूचियों या अन्य अग्रेषण तंत्र द्वारा भेजे गए मेल; तथा
• एसपीएफ रिकॉर्ड्स का सिर्फ सादा ग़लतफ़हमी (आम नहीं, लेकिन बहुत दुर्लभ नहीं)।

मैं एक छोटा सा सर्वर चलाता हूं, जहां मैं हार्ड-फेल पर टाल सकता हूं। यह मुझे सफ़ेद सूची को वैध विफलताओं की अनुमति देता है। यदि मेल भेजने वाले को नोटिस नहीं दिया जाता है, तो वे अपने कॉन्फ़िगरेशन को ठीक कर सकते हैं। कुछ मामलों में मैं संबंधित से संपर्क करने का प्रयास करूंगा postmaster, लेकिन कई डोमेन में पता नहीं है postmaster।

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

SPF हार्ड विफल भेजने वाले सर्वर की पहचान को मान्य करने के लिए विश्वसनीय नहीं लगता है। मैंने कुछ समय पहले कुछ शोध किया था, और पाया कि हेलो नाम पर भी नरम विफल होना आने वाले संदेशों को विफल या स्थगित करने का एक उचित कारण है।

कई मेल सर्वरों में SPF रिकॉर्ड नहीं होता है। यदि मेल सर्वर में SPF रिकॉर्ड नहीं है, तो मैं SPF रिकॉर्ड के लिए मूल डोमेन के खिलाफ जाँच करता हूँ। यह गैर-मानक है, लेकिन प्रभावी है। मैं यह सुनिश्चित करने के लिए ईमेल प्रशासकों को प्रोत्साहित करता हूं कि सर्वर आईपी के लिए एक SPF रिकॉर्ड है जैसा कि PTR रिकॉर्ड में सूचीबद्ध है। आपके सर्वर को अपने PTR रिकॉर्ड द्वारा दिए गए नाम से ही पहचान करनी चाहिए। सत्यापित करें कि आपके पास रिवर्स DNS सत्यापन के लिए संबंधित ए रिकॉर्ड है।

Comments

Outlook.com अधिक उदार है। मैंने DMARC के बारे में नहीं सुना है, यह दिलचस्प है।

— Rook