क्या SRS पुनर्लेखन एक अग्रेषण मेलस्वर के लिए बिल्कुल आवश्यक है?


14

मैं अपने डोमेन के लिए एक पोस्टफिक्स ईमेल सर्वर का संचालन कर रहा हूं, mydomain.com कहते हैं। यह ज्यादातर एक अग्रेषण ईमेल सर्वर के रूप में कार्य करता है: उपयोगकर्ताओं को एक ईमेल पता @ mydomain.com प्राप्त होता है, लेकिन आमतौर पर उनका पता बाहरी इनबॉक्स (जीमेल, याहू, आदि) के लिए चुना जाता है। कुछ हज़ार पते अग्रेषित किए जा रहे हैं, इसलिए सर्वर मेल ट्रैफ़िक की काफी महत्वपूर्ण मात्रा को संभालता है।

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

इसे ध्यान में रखते हुए, क्या एसआरएस पुनर्लेखन को सक्षम करना आवश्यक है? मैं इसे सक्षम करने पर विचार कर रहा हूं, लेकिन मेरी मुख्य चिंता यह है कि मेरे डोमेन को स्पैम भेजने के लिए ब्लैकलिस्ट किया जाएगा जब स्पैम अनिवार्य रूप से फ़ॉवर्ड हो जाता है। क्या यह फिर से लिखना नहीं होगा जैसे कि मैं स्पैम का प्रवर्तक हूं? (कम से कम, यह मेरी समझ जीमेल के बेस्ट प्रैक्टिसेज फॉर फॉरवर्डिंग मेलसेवर्स पढ़ने से है )।

दी, मैं पहले से ही सुझाए गए कुछ सावधानियों का उपयोग कर रहा हूं जैसे कि स्पैम से संबंधित स्पैम की विषय पंक्ति में "स्पैम" को जोड़ने से पहले फॉरवर्ड करने से पहले, उच्च आत्मविश्वास (स्कोर 15+) स्पैम को अग्रेषित नहीं करना और स्पैमहॉस ब्लॉकलिस्ट का उपयोग करना, लेकिन ये उपाय नहीं हैं 't सही और स्पैम अभी भी बिना चिह्नित किए पर्ची कर सकते हैं।

क्या एसआरएस को फिर से लिखने में सक्षम किया गया है, अगर यह एक स्पैमर के रूप में गलत तरीके से चिह्नित होने के जोखिम को बढ़ाता है? या फिर इसे छोड़ देना ही सुरक्षित होगा और एसपीएफ़ विफलताओं को नज़रअंदाज़ करना होगा?


मैं अनुभव से जानता हूं कि यूके में कुछ आईएसपी इनबाउंड ईमेल को अस्वीकार कर देंगे जो अपने स्वयं के ग्राहकों से होने का दावा करते हैं, लेकिन यह अपने स्वयं के मेलर्स से नहीं भेजा गया है। जीमेल, याहू और एओएल के लिए भी यही सच हो सकता है। ऐसी स्थितियों को केवल प्रेषक पते को फिर से लिखकर हल किया जा सकता है।
रोइमा

जवाबों:


9

यह मुझे प्रतीत होता है कि आपका प्रश्न क्या उबलता है " आने वाले ईमेल पर कितने मेल सर्वर एसपीएफ रिकॉर्ड की जांच करते हैं? "। यदि यह उनमें से अधिकांश है, एसआरएस एक अग्रेषण सर्वर के लिए एक परम आवश्यकता है; यदि यह उनमें से कोई नहीं है, तो आपको एसआरएस की आवश्यकता नहीं है।

दुर्भाग्य से, मैं तुरंत इस पर किसी भी शैक्षणिक कार्य के लिए हाथ नहीं रख सकता। लेकिन जब से मैं आने वाले ईमेल पर SPF की जांच करता हूं, मैं निश्चितता के साथ कह सकता हूं कि कुछ मेल सर्वर इसकी जांच करते हैं। आपका कोई भी क्लाइंट जिनके पास आपका सर्वर मेरे सर्वर पर खातों के लिए आगे है, उन प्रेषकों से भेजे गए ईमेल को खो देगा जो एक एसपीएफ़ का विज्ञापन करते हैं जो समाप्त होता है (जैसा कि वे सभी को करना चाहिए) -all, जब तक कि आप एसआरएस का उपयोग न करें। इसलिए मैं निश्चितता के साथ कह सकता हूं कि एसआरएस के बिना आपके कुछ ग्राहकों का ईमेल डिलीवर नहीं होगा

मैं मार्क से माफी मांगता हूं कि मैं जर्मन नहीं पढ़ सकता हूं, इसलिए मैं यह नहीं कह सकता कि पीडीएफ वह सम्मोहक तर्कों को उद्धृत करता है, लेकिन मैं यह दोहरा सकता हूं कि एसआरएस के बिना, आपके ग्राहकों के ईमेल का कुछ अंश वितरित नहीं किया जाएगा। मैं यह नहीं कह सकता कि वह अंश क्या है, लेकिन यह शून्य नहीं है - और यह देखते हुए, मुझे नहीं लगता कि आपके पास एसआरएस चलाने के अलावा कोई विकल्प नहीं है।

मैं इस बात से सहमत हूं कि आपका सर्वर SPAM को अग्रेषित करने में स्वयं की मदद नहीं करेगा, लेकिन मेरे अनुभव में इसके आईपी पते को सबसे अधिक नुकसान हुआ है, लिफाफा-डोमेन से नहीं; यह SRS उपयोग की परवाह किए बिना किया जाएगा।

आपके प्रश्न का गहरा उत्तर यह है कि, SPF और इसके (अशुभ माने जाने वाले और इंटरनेट-ब्रेकिंग) फॉलोअप DMARC के बीच, यह मुझे लगता है कि मेल अग्रेषण सेवाओं का दिन हो चुका है। मुझे पहले से ही अपने सर्वर पर अंतिम वितरण करने के लिए मेरे सभी उपयोगकर्ताओं में से एक की आवश्यकता है, और उस एक उपयोगकर्ता को 2016 में बदलना या छोड़ना होगा। आजकल, कई वेबमेल सिस्टम ऑफ-सर्वर मेल का उपयोग करके कई मेलबॉक्सों पर एकीकरण की अनुमति देंगे IMAP या POP, और कई मेल क्लाइंट एक ही एकीकृत INBOX के रूप में कई IMAP या POP खाते पेश करने की अनुमति देते हैं, इसलिए अग्रेषण केंद्रीयकृत पढ़ने के लिए वरदान नहीं है कि यह हुआ करता था।

संक्षेप में, मैं कहूंगा कि आपको अल्पावधि में एसआरएस की आवश्यकता है, और लंबी अवधि में एक नया व्यापार मॉडल।


बात यह है कि एसआरएस के मुद्दों को दूर करने के लिए एसआरएस एक उपाय है। एसआरएस फिर से लिखता है जैसे उपयोगकर्ता @ ए से ए = उपयोगकर्ता @ बी और बी के एसपीएफ रिकॉर्ड तब प्रभार में हैं। समस्या: B अभी भी आदतों को बना सकता है! इसलिए कुछ फिर से लिखित पते पर क्रिप्ट-हैश और समय टिकट जोड़ रहे हैं। इसके लिए बड़े पैमाने पर काम करने के लिए इसे वैश्विक अपनाने की जरूरत है जो कि नहीं है। यह केवल तभी काम करता है जब किसी चीज को एक बार आगे बढ़ाया जा रहा है, लेकिन अधिक नहीं। इसके अलावा जवाब एक समस्या है। यह भी ध्यान रखें, कि एसपीएफ आपके स्वयं के दुर्व्यवहार के डोमेन की रक्षा करने के लिए एक तकनीकी है, इससे ज्यादा कुछ नहीं।
मार्क स्टीमर

@ MarcStürmer " एसआरएस एसपीएफ़ के मुद्दों को आगे बढ़ाने के उपाय के लिए एक समाधान है ": हाँ, यह वास्तव में यही है। एसपीएफ़ को सरलीकरण अग्रेषण को तोड़ने के लिए जाना जाता है; यदि आपको नहीं लगता कि एसआरएस भुगतान करने लायक मूल्य है, तो एसपीएफ़ रिकॉर्ड का विज्ञापन न करें। " समस्या: बी अभी भी आदतों को बना सकता है ": एक एसपीएफ रिकॉर्ड द्वारा संरक्षित ए के डोमेन, या किसी अन्य डोमेन के लिए नहीं, या एसपीएफ के तहत मेल को अस्वीकार कर दिया जाएगा; लेकिन इसके अलावा, हाँ, यह कर सकता है, और मैं इसे एक समस्या के रूप में नहीं देखता हूं। " एसपीएफ अपने खुद के दुरुपयोग के अपने डोमेन की रक्षा के लिए एक तकनीकी है, इससे ज्यादा कुछ नहीं ": मैं सहमत हूं।
21

@ MarcStürmer: "यह केवल तभी काम करता है जब किसी चीज़ को एक बार आगे बढ़ाया जा रहा हो, लेकिन अधिक नहीं।" गलत है। SRS कई अग्रेषण सर्वरों पर पूरी तरह से काम करता है। यह केवल तभी पीड़ित होता है जब लाइन में कोई नॉन टैगिंग सर्वर हो। लेकिन सामान्य रूप से किसी भी गैर टैगिंग सर्वर की तुलना में यह एक ही समस्या है, चाहे वह पहले या बाद में आगे की उम्मीद हो। एक एसपीएफ़ दुनिया में, आपको एसआरएस की आवश्यकता नहीं है, आपको बस अग्रेषित मेल की जिम्मेदारी लेने की आवश्यकता है और सुनिश्चित करें कि आप एक संभावित उछाल वापस पहुंचा सकते हैं। SRS सिर्फ एक तकनीक है जो ऐसा करती है, जैसे Google कुछ अलग उपयोग करता है।
एड्रियन ज़ॉगग

समस्या एसआरएस टूटता DMARC संरेखण की जांच का उपयोग कर, है (यानी लिफ़ाफ़ा प्रेषक! = From:-Header) और Gmail संदेशों को अस्वीकार करता है, तो में डोमेन कर देगा From:हैडर है p=rejectउनके DMARC नीति में। यदि आप भी फिर से लिखते From:हैं, तो मेल को आपके स्वयं के डोमेन के नियमों के अनुसार जांचा जाएगा। लेकिन एक DKIM चेक फेल हो जाएगा और मेल क्लाइंट में दिखाया गया मैसेज मंगवा लिया जाता है।
मर्थथ

@ अम्बरीथ अफीक, आप सही कह रहे हैं। लेकिन मैं व्यक्तिगत रूप से DMARC को एक पूर्ण आपदा के रूप में मानता हूं, कम से कम नहीं क्योंकि यह एकतरफा मेलिंग सूचियों को तोड़ती है, और (मेरी क्षमता में एक बड़े समुदाय सूची के व्यवस्थापक के रूप में) बस लोगों को किसी भी आईएसपी का उपयोग करने के खिलाफ सलाह देता है जो एक p=rejectनीति प्रकाशित करता है। यदि SRS DMARC को तोड़ता है, तो ठीक है, यह DMARC पर कठिन है।
मध्याह्न

9

एसआरएस कागज पर एक अच्छा विचार है, लेकिन हेनलिन सपोर्ट के लोगों के अनुसार व्यवहार में बहुत अच्छा काम नहीं करता है (वे 100000 से अधिक खातों के साथ एक मध्यम आकार की मेल सेवा चला रहे हैं।)

विवरण उनकी बात में है, हालांकि जर्मन में, क्यों: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

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

हालांकि बड़े मेल प्रदाताओं के साथ समस्या यह है कि उनके पास आजकल वास्तविक बड़ा उपयोगकर्ता आधार है और वे अधिक से अधिक तकनीकों (DMARC के लिए उत्तराधिकारी पहले से ही पाइपलाइन में हैं) को लागू कर रहे हैं, जो सामान्य के लिए अधिक से अधिक कठिन बना देता है मेल सर्वर सेटअप एक विश्वसनीय तरह से उन्हें मेल भेजने के लिए।

यदि आप अपने मेल को जीमेल, हॉटमेल और जैसे बड़े मेल प्रदाताओं तक बेहतर तरीके से पहुंचाना चाहते हैं, तो आपको कम से कम DKIM और DMARC को लागू करना चाहिए, लेकिन साथ ही यह सबसे अच्छे तरीके से सॉफ्ट फेल होना चाहिए और हो सकता है कि मेल डिलीवरी पर कुछ रेट लिमिटिंग मैकेनिज्म लागू हो। आपके लिए अद्भुत काम करेगा।

बड़े प्रदाताओं के साथ यह समस्या यही कारण है कि आजकल Mailchimp, Mandrill या Returnpath जैसी सेवाएँ हैं। वे प्रदाता Google और Co को पैसे देते हैं। बेहतर वितरण गुणवत्ता के लिए।


1
यहाँ समस्या एसपीएफ़ नहीं एसआरएस है। जब तक कुछ आईएसपी एसपीएफ़ का उपयोग नहीं करते हैं, तब तक आपको इन सभी के साथ काम करने के लिए एसआरएस (या कुछ इसी तरह) लागू करने की आवश्यकता होती है। Greylisting के साथ समस्या अलग है, आपको greylisting के लिए प्रेषक पते को "अनपैक" करना चाहिए (BATV टैग किए गए मेल के रूप में अस्वस्थ)।
एड्रियन ज़ॉगग

3

मैं @MadHatter के प्रत्येक शब्द से सहमत हूं, लेकिन Google के बारे में महत्वपूर्ण तथ्य!

यदि आप gmail के लिए अग्रेषण सेवा प्रदान करते हैं, तो आप SMTP पहुँच प्रदान करने का एक अच्छा मौका है ताकि आपके gmail उपयोगकर्ता आपके द्वारा संग्रहीत पते पर gmail से मेल भेज सकें।

उस स्थिति में - जीमेल जानता है कि आप इस ईमेल के फारवर्डर हैं और स्पैम के रूप में अपने फॉर्वर्ड को फ्लैग नहीं करते हैं, हालांकि यह एसपीएफ़ की जांच में विफल है।

आप अपने ग्राहकों को bill@microsoft.com से मेल भेज सकते हैं। संदेश बिना किसी चेतावनी के उनके इनबॉक्स में पहुंच जाएगा! (माइक्रोसॉफ्ट है -all SPF रिकॉर्ड में)

जाँच की और सत्यापित किया। उदाहरण संलग्न है।

यह संदेश इनबॉक्स में गया।जीमेल शो ओरिजिनल

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