सवाल अगर एसपीएफ़ बहुत ही सीमित है तो मेलिंग सूचियां "ब्रेक" होगी?


मैंने हाल ही में अपना खुद का मेल सर्वर (लिनक्स-आधारित पोस्टफिक्स + कबूतर परिदृश्य) कॉन्फ़िगर किया है। यह सिर्फ व्यक्तिगत उपयोग के लिए है - मेरे पास कोई थोक मेल नहीं है, मेजबान से स्वचालित रूप से जेनरेट की गई मेल आउटबाउंड नहीं है, ऐसा कुछ नहीं। मैं सभी अतिरिक्त मजेदार-से-डीबग ईमेल DNS रिकॉर्ड्स को कॉन्फ़िगर करने के लिए परेशानी से गुजर चुका हूं:

@                 IN  TXT  v=spf1 +mx -all
_domainkey        IN  TXT  o=-; r=dkim@example.com
mail._domainkey   IN  TXT  v=DKIM1; h=sha256; k=rsa; s=email; p=deadbeef
_adsp._domainkey  IN  TXT  dkim=all
_dmarc            IN  TXT  adkim=s; aspf=s; fo=1; p=none; pct=100; rf=afrf; ri=86400; rua=mailto:aggrep@example.com; ruf=mailto:authfail@example.com; sp=none; v=DMARC1;

मेरे पास एक आईपी है जो किसी भी ब्लैकलिस्ट पर नहीं है, एक पीटीआर सही तरीके से कॉन्फ़िगर किया गया है, डीकेआईएम हस्ताक्षर पूरी तरह से मान्य हैं, मैंने सोचा कि सब ठीक से स्थापित किया गया था।

लेकिन अब मैं मेलिंग सूचियों में योगदान नहीं दे सकता। जब मैं सूची के पते पर भेजता हूं, कभी-कभी संदेश ब्लैक होल में जाता है, कभी-कभी मुझे अपने लिए एक ईमेल मिलता है authfail@ पता, और अन्य मामलों में मैं उन प्रविष्टियों को देखता हूं जो मुझे विश्वास है कि भेजे गए रिपोर्ट में संबंधित हैं aggrep@

मेरा सिद्धांत यह है कि एसपीएफ़ नीति बहुत ही सीमित है। मेलमैन (या अन्य) सूची सर्वर मेरे संदेशों के लिए एक एसएमटीपी रिले के रूप में कार्य कर रहा है, है ना? तो मैंने बदल दिया

@                 IN  TXT  v=spf1 +mx -all

सेवा मेरे

@                 IN  TXT  v=spf1 +mx ~all

एक हार्डफाइल की बजाय डिफ़ॉल्ट कार्रवाई को सॉफ्टफेल बनाना। समस्या यह है कि, मैं इस परिवर्तन का परीक्षण करने के किसी भी अच्छे कारण के लिए स्पैमिंग सूचियों के चारों ओर नहीं जाना चाहता हूं। क्या कोई और यहां पहले रहा है और मेरे सिद्धांत को सत्यापित / अस्वीकार कर सकता है?


संपादित करें 1:

वापस सोचकर, और सीधे मुझे सेट करने के लिए @Alex धन्यवाद, मैंने वास्तव में सटीक मूल्यांकन करने के लिए पर्याप्त डेटा प्रदान नहीं किया है। मेरे द्वारा प्राप्त एक नोटिस का उदाहरण यहां दिया गया है authfail@ मेलिंग सूची में पोस्ट करने का प्रयास करते समय पता करें:

This is a spf/dkim authentication-failure report for an email message received from IP 66.211.214.132 on Thu, 10 Jul 2014 20:58:52 +0800.
Below is some detail information about this message:
 1. SPF-authenticated Identifiers: archlinux.org;
 2. DKIM-authenticated Identifiers: none;
 3. DMARC Mechanism Check Result: Identifier non-aligned, DMARC mechanism check failures;

For more information please check Aggregate Reports or mail to abuse@126.com.



Feedback-Type: auth-failure
User-Agent: NtesDmarcReporter/1.0
Version: 1
Original-Mail-From: <arch-general-bounces@archlinux.org>
Arrival-Date: Thu, 10 Jul 2014 20:58:52 +0800
Source-IP: 66.211.214.132
Reported-Domain: example.com
Original-Envelope-Id: w8mowEA5UUwMjr5TlWQfBA--.250S2
Authentication-Results: 126.com; dkim=fail (signature error: RSA verify failed) header.d=example.com; spf=pass smtp.mailfrom=arch-general-bounces@archlinux.org
DKIM-Domain: example.com
Delivery-Result: delivered

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


संपादित करें 2:

Dmarcian.com पर डीएमएआरसी रिपोर्ट पार्सिंग टूल का संदर्भ देने के लिए @ क्रिस्टोफर करेल का धन्यवाद। प्रविष्टियों के शेरों का हिस्सा फॉरवर्डर्स के रूप में सूचीबद्ध है (जो समझ में आता है)। एक सर्वर (* .mailhop.org) "संरक्षित [आईएनजी] डीकेआईएम" के रूप में सूचीबद्ध है - मैंने सफलतापूर्वक रुबी भाषा मंचों में से एक पर मेल भेजा है, और मैं अपने शोध से जानता हूं कि वे mailhop.org का उपयोग करते हैं।

श्रेणी के तहत "सर्वर जो डीकेआईएम हस्ताक्षर तोड़ते हैं (या स्पूफेड हस्ताक्षर बनाते हैं)" सूचीबद्ध हैं *.archlinux.org, *.google.com, *.mailhop.org (ऐसा नहीं है कि यह यहां क्यों दिखाई देता है, हो सकता है कि मैं जिस दूसरी सूची में हूं, उनके साथ-साथ एक अलग कॉन्फ़िगरेशन में भी उपयोग करता है), दूसरों के बीच और जिन सूचियों पर मैं सबसे अधिक सक्रिय हूं, वे हैं आर्क और कुछ Google समूह द्वारा होस्ट किए गए हैं, इसलिए यह समझ में आता है। कुल में लगभग 400 संदेश - मैंने लगभग कई संदेशों को नहीं भेजा है, इसलिए मुझे लगता है कि यह रीट्रीज़ की गणना कर रहा है।

मैं निराश हो रहा हूं - फिलहाल ऐसा लगता है कि मेरे विकल्प हैं:

  1. एसपीएफ़, डीकेआईएम, डीएमएआरसी, और एडीएसपी रखें और मेलिंग सूचियों का उपयोग छोड़ दें, या
  2. इस DNS सुरक्षा / रिपोर्टिंग परत को छोड़ दें और मेरा सामान्य आउटगोइंग मेल Google, Yahoo!, Live, आदि द्वारा अस्वीकार कर दिया गया है।

6
2017-07-10 12:46


मूल


हे, एक कारण है कि मैंने अपना पहला जवाब "ई-मेल सुरक्षा बेकार" के साथ शुरू किया। =) - Christopher Karel
आप कौन सी मेलिंग सूची सॉफ्टवेयर भेज रहे हैं, आमतौर पर? - gf_


जवाब:


ई-मेल सुरक्षा बेकार है। तो अंत में, आपको शायद एक ऐसे निर्णय का सामना करना पड़ेगा जहां आपके सभी विकल्प भयानक हैं, और अलग-अलग कारणों से अलग-अलग चीजों को तोड़ते हैं।

एसपीएफ़ के लिए विशेष रूप से, एक मेलिंग सूची विफल होने का कारण बनती है अगर यह एक संदेश आगे बढ़ती है, हेडर को फिर से लिखने के बिना। एक सूची स्वयं को काम करने के लिए कॉन्फ़िगर कर सकती है हालांकि यह प्रसन्न होती है, इसलिए कोई अच्छा सामान्य उत्तर नहीं है। लेकिन अगर किसी सूची से संदेश सूची से ही आते हैं, तो यह हेडर को फिर से लिख रहा है। अगर ऐसा प्रेषक से आता है, शायद नहीं। सामान्य रूप से, मेलिंग सूचियां चाहिए अपने आप पर एसपीएफ़ के साथ अच्छी तरह से काम करें। दूसरी तरफ नियमित मेल अग्रेषण नहीं होगा।

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

इसके शीर्ष पर, आपने कार्यान्वित किया है DMARC। यह अनिवार्य रूप से डीकेआईएम और एसपीएफ़ के चारों ओर लिपटे एक रिपोर्टिंग आधारभूत संरचना है। यह सर्वोत्तम काम करता है यदि आप दोनों प्रमाणीकरण उपायों को लागू करते हैं, लेकिन केवल एक के साथ ठीक काम करेंगे। आप अपने संदेशों के लिए एक ड्रॉप अनुरोध संवाद करने के लिए DMARC को कॉन्फ़िगर कर सकते हैं, लेकिन अधिक महत्वपूर्ण बात यह है कि आप सफलता / विफलता रिपोर्ट प्राप्त करने के लिए एक पता निर्दिष्ट कर सकते हैं। ये अधिकांश प्रमुख ई-मेल रिसीवर द्वारा समर्थित हैं। (जीमेल, हॉटमेल, याहू) यह आपको अंतर्दृष्टि दे सकता है कि कौन से संदेश एसपीएफ़ चेक विफल हो रहे हैं, और क्यों। इसे सूचित करने के लिए इसका इस्तेमाल करें -all बनाम ~all फेसला।

दुर्भाग्य से, डीएमएआरसी विनिर्देश के लिए प्रेषक डोमेन और एसपीएफ़ रिकॉर्ड के बीच संरेखण की आवश्यकता होती है जो चेक हो जाती है। आपके मामले में, मेलिंग सूची का एसपीएफ़ चेक किया जा रहा है, और गुजरता है, लेकिन आपके डोमेन से संरेखित नहीं होता है। तो डीएमएआरसी बम। यहाँ एक है एक मेलिंग सूची व्यवस्थापक से संदर्भ ज्यादा के बारे में पकड़ना।

निष्कर्ष मेरे उद्घाटन वाक्य के समान है: ई-मेल सुरक्षा बेकार है। और आपके सभी विकल्प भी चूसते हैं। आईएमएचओ, मेलिंग सूचियां भी चूसती हैं, और यदि हम उन्हें बदल देते हैं तो जीवन बेहतर होगा। ;-)


7
2017-07-10 15:43



धन्यवाद क्रिस्टोफर, मैंने वास्तव में इस पोस्ट को पोस्ट करते समय एक ऐसे रिपोर्टिंग संदेश के साथ अपनी पोस्ट को संशोधित किया। जैसा कि आप मेरे ओपी द्वारा देख सकते हैं मेरे पास डीकेआईएम, एसपीएफ़, और डीएमएआरसी (एडीएसपी के साथ लेकिन मैं वास्तव में उस पर बेचा नहीं जाता) कॉन्फ़िगर और रिपोर्टिंग टूल्स (जैसे पोर्ट25.com सत्यापनकर्ता, एट अल।) घोषित करता है कि मैं ' मैंने यह सब सही ढंग से किया है, और मुझे नियमित रिपोर्ट मिल रही है (दोनों को authfail तथा aggrep) उन कॉन्फ़िगर किए गए पते पर। - Chris Tonkinson
क्या आपने अपनी डीएमएआरसी .xml रिपोर्ट को उचित पार्सर के माध्यम से डालने का प्रयास किया है? यह पता लगाने में काफी मदद कर सकता है कि क्या असफल रहा, और क्यों। एक त्वरित और गंदा ऑनलाइन एक यहां उपलब्ध है: dmarcian.com/dmarc-xml। मुझे आपके पोस्ट किए गए संदेश को दोपहर के भोजन के बाद अधिक देखना होगा, लेकिन पहली नज़र में यह डोमेन दिखाई देता है कि इसकी जांच आपके डीएमएआरसी रिकॉर्ड और एसपीएफ़ रिकॉर्ड को संरेखित नहीं कर रही है। - Christopher Karel
वहां भी नहीं पता था थे डीएमएआरसी। एक्सएमएल पार्सिंग टूल्स। dmarcian.com एक रिपोर्ट ब्रेकडाउन देता है - मैं जानकारी के साथ संपादित करूंगा। - Chris Tonkinson
यह शायद सबसे नकारात्मक जवाब है जिसे मैंने कभी ऊपर उठाया है स्टैक एक्सचेंज। क्या स्थिति अभी भी 7 साल बाद निराशाजनक है? - Anthony Geoghegan
मुझे डर है कि सबकुछ अभी भी उतना ही खराब है जितना 2010 में था। एसपीएफ़, डीएमएआरसी, और डीकेआईएम अभी भी ई-मेल प्रमाणीकृत करने के लिए उपलब्ध एकमात्र मानक हैं। ई-मेल कितना वैध है यह जानने के लिए व्यक्तिगत स्पैम फ़िल्टर अनिवार्य रूप से केवल 'गुप्त सॉस' रखते हैं। यह आश्चर्यजनक रूप से अच्छी तरह से काम करता है, लेकिन जिन स्थानों पर इसके मुद्दे हैं वे लगभग पूरी तरह से छोटे व्यवसाय होने जा रहे हैं। ई-मेल विकास में किए गए वास्तुशिल्प निर्णयों में से एक है जो मूल रूप से इसे ठीक से ठीक करना असंभव बना देता है। = ( - Christopher Karel


मैंने डीकेआईएम भाग को नहीं देखा है।

एसपीएफ़ रिकॉर्ड के बारे में मैं निम्नलिखित उदाहरणों में निम्नलिखित का उपयोग करता हूं:

v = spf1 mx -all

यह यहां दस्तावेज है: http://www.openspf.org/SPF_Record_Syntax

हालांकि आरएफसी 7208 के अनुसार "+ एमएक्स" भी सही होना चाहिए (धन्यवाद क्रिस इसे इंगित करने के लिए)। शायद यह एक कोशिश के लायक है ...

मैं वास्तव में नहीं जानता कि अन्यथा क्या सुझाव देना है ... अपने सभी DNS रिकॉर्ड (ए / पीटीआर / एमएक्स) को दोबारा जांचें। आप शायद पहले से ही ऐसा किया है। वास्तव में डोमेन नाम को जानना लोगों की समस्या निवारण में मदद कर सकता है - कम से कम यदि DNS संबंधित है।


1
2017-07-10 13:01



इसके अनुसार आरएफसी 7208 "+" तंत्र मान्य है, और यदि कोई तंत्र प्रदान नहीं किया जाता है तो डिफ़ॉल्ट होता है। अगर मैं सही ढंग से समझता हूं तो दोनों अर्थात् समकक्ष हैं, नहीं? - Chris Tonkinson
@ क्रिस आप निश्चित रूप से सही हैं, वे दोनों वैध और वाक्य रचनात्मक रूप से समकक्ष हैं - अधिकांश लोग इससे बचते हैं + क्योंकि यह स्ट्रिंग थोड़ा "अनावश्यक" है - Mathias R. Jessen


बाहर निकलता है मेरे विन्यास के साथ कुछ भी गलत नहीं लगता है। क्या हो रहा है कि मेरे संदेशों को मेलमैन द्वारा सही तरीके से संसाधित किया जा रहा है, और सूची में रिले किया जा रहा है। हालांकि कुछ रिसीवर हैं (जो भी कारण उनके लिए अद्वितीय है) संदेश को खारिज कर दें। क्योंकि वास्तव में मेरे पास है सही ढंग से कॉन्फ़िगर किया गया एसपीएफ़, मैं उन गंतव्य SMTP सर्वर से अस्वीकृति संदेश देख रहा हूं, मेलिंग सूची रिले से नहीं।

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


1
2017-07-10 19:02