अच्छा विचार? हमारे अपने डोमेन के समाप्त होने के साथ आने वाले ईमेल को मना करें? (क्योंकि वे नकली होना चाहिए)

33

हमारे पास हमारे एक्सचेंज सर्वर के बारे में एक प्रश्न है: क्या आपको लगता है कि आने वाले बाहरी ई-मेल को अस्वीकार करने के लिए एक अच्छा विचार है जो अंत में हमारा अपना डोमेन है?

बाहरी eMail की तरह से fake@example.com?

क्योंकि अगर यह हमारी कंपनी में एक वास्तविक प्रेषक का होगा, तो ईमेल बाहर से कभी नहीं आएगा?

यदि हाँ, तो ऐसा करने का सबसे अच्छा तरीका क्या है?

security email-server exchange-2013

— स्टीफन मैयर
स्रोत

3

क्या आपके पास अभी किसी प्रकार का स्पैम फ़िल्टरिंग समाधान है?

— ewwhite

14

आपको अपने स्वयं के डोमेन से भेजने की कोशिश करने वाले किसी भी वेब एप्लिकेशन का कोई भी विक्रेता नहीं होना चाहिए। जैसे अगर आपके पास एक पेरोल सिस्टम है जो आपके कर्मचारियों को "payroll@example.com" से ई-मेल भेज सकता है। यह भी जांचें कि क्या मार्केटिंग या एचआर एक बाहरी थोक मेल सेवा का उपयोग कर सकते हैं और वे चाहते हैं कि कर्मचारी उन संदेशों को प्राप्त करें। आमतौर पर उन संदेशों में प्रेषक या मार्केटिंग या एचआर में किसी के पते का कम से कम जवाब होता है। उन स्थितियों में, आप आमतौर पर सेवा के ई-मेल सर्वर को एक अनुमति सूची में डाल सकते हैं और अभी भी अपने स्वयं के डोमेन को आने वाले ब्लॉक कर सकते हैं (यही हम करते हैं)।

— टोड विलकॉक्स

6

@NeilMcGuigan क्या बात होगी? मेल को अभी भी आंतरिक मेल सर्वर से उत्पन्न होना चाहिए? यह केवल नेटवर्क के बाहर से नहीं आएगा क्योंकि वह शारीरिक रूप से मौजूद नहीं है।

— मैट

@ मट्ट गइया, ब्रेनफार्ट

— नील

1

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

— रेयान

53

हाँ, यदि आप जानते हैं कि आपके डोमेन के लिए ईमेल केवल आपके स्वयं के सर्वर से आ रही है, तो आपको उस डोमेन के लिए किसी भी ईमेल को किसी अन्य सर्वर से उत्पन्न करना चाहिए। यहां तक कि अगर प्रेषक का ईमेल क्लाइंट किसी अन्य होस्ट पर है, तो उन्हें ईमेल भेजने के लिए आपके सर्वर (या जो भी ईमेल सर्वर आप उपयोग करते हैं) में लॉगिंग होनी चाहिए।

इसे एक कदम आगे बढ़ाते हुए, आप अपने सर्वर को SPF रिकॉर्ड की जांच करने के लिए कॉन्फ़िगर कर सकते हैं। यह है कि कितने मेजबान ईमेल गतिविधि को रोकते हैं। एसपीएफ रिकॉर्ड एक डीएनएस रिकॉर्ड, एक TXT रिकॉर्ड है, जो नियमों के बारे में बताता है कि कौन से सर्वर को आपके डोमेन के लिए ईमेल भेजने की अनुमति है। SPF रिकॉर्ड जाँच को कैसे सक्षम किया जाए, यह आपकी ईमेल सेवा पर निर्भर करेगा, और यहाँ क्या कवर करना है, इसके दायरे से परे होगा। सौभाग्य से, अधिकांश होस्टिंग वातावरण और सॉफ़्टवेयर में एसपीएफ़ रिकॉर्ड के साथ काम करने के लिए प्रलेखन होगा। आप सामान्य रूप से एसपीएफ के बारे में अधिक जानना चाह सकते हैं। यहाँ विकिपीडिया लेख है: https://en.wikipedia.org/wiki/Sender_Policy_Framework

— DKing
स्रोत

3

@ कर्टोविक एक अच्छी तरह से कॉन्फ़िगर किया गया ईमेल सर्वर ईमेल को अस्वीकार कर देता है, इसलिए प्रेषक को सूचित किया जाएगा।

— कैलिमो जूल

8

@ कैलीमो तब नहीं जब यह स्पैम होने के लिए ईमेल को खारिज कर देता है। ऐसा करने से वह स्पैममर को तब तक प्रयास करने में सक्षम बनाएगा जब तक कि उसने यह नहीं जान लिया कि आपका एल्गोरिथ्म क्या अनुमति देता है और अनुमति नहीं देता है।

— जॉन बेंटले

27

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

— कैस

2

@cas: एक तीसरा विकल्प है: SMTP स्वीकृति समय पर अस्वीकार करें। यह भेजने वाले SMTP सर्वर पर त्रुटि प्रतिक्रिया उत्पन्न करने का बोझ छोड़ देता है, यदि वह ऐसा करना चाहता है, और इस तरह कई वैध प्रेषकों को यह देखने की अनुमति देता है कि क्या गारंटी देते समय कि उनके मेल को अस्वीकार कर दिया गया था, तो आप कभी भी स्पैम का उत्पादन नहीं करेंगे।

— आर ..

2

@ आर .. मुझे लगता है कि आप पाएंगे कि यह तीसरा विकल्प नहीं है, यह मैंने जो कहा है उसका एक विरोधाभास है "बस अवांछित मेल को अस्वीकार करें - इससे निपटने के लिए भेजने वाले मेजबान की समस्या है।"

— कैस

31

पहले से ही ऐसा करने के लिए एक मानक है। इसे DMARC कहा जाता है । आप इसे डीकेआईएम हस्ताक्षर के साथ लागू करते हैं (जो वैसे भी लागू करने के लिए एक अच्छा विचार है)।

उच्च स्तर का अवलोकन आप हर एक ईमेल पर हस्ताक्षर करते हैं जो आपके डोमेन को डीकेआईएम हेडर के साथ छोड़ देता है (जो वैसे भी अच्छा अभ्यास है)। फिर आप DMARC को अपने मेल सर्वर को हिट करने वाले प्रत्येक ईमेल को अस्वीकार करने के लिए कॉन्फ़िगर करते हैं, जो आपके स्वयं के डोमेन से है, जो कि वैध DKK हेडर के साथ हस्ताक्षरित नहीं है।

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

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

नीचे की ओर यह है कि आपको यह सुनिश्चित करने की आवश्यकता है कि आपको पहले से पूरी तरह से सब कुछ मिल गया है या आप वैध ईमेल छोड़ना शुरू कर सकते हैं।

— मार्क हेंडरसन
स्रोत

3

DMARC के परीक्षण से पहले SPF के साथ-साथ DKIM को लागू करने की अत्यधिक अनुशंसा की जाती है।

— टॉड विलकॉक्स

DMARC ईमेल के साथ कैसे काम कर सकता है, यह आपके सर्वर से अलग है, जैसे कि बाहरी सेवाओं के साथ, क्योंकि आपके सर्वर द्वारा साइन इन नहीं किया जाएगा?

— jpaugh

1

@jpaugh आप अपने DNS में अपने DMARC रिकॉर्ड के लिए अन्य सर्वर सार्वजनिक कुंजी जोड़ते हैं। वे आपको जोड़ने के लिए रिकॉर्ड देने में सक्षम होंगे।

— मार्क हेंडरसन

मैंने इस उत्तर को +1 किया क्योंकि तकनीकी रूप से यह सही है - ठीक यही DMARC के लिए है, और यह क्या करता है - लेकिन DMARC एक बहुत बुरा विचार है यदि आप मेलिंग सूचियों जैसी चीजों के साथ हस्तक्षेप करना चाहते हैं, क्योंकि यह RFC का उल्लंघन करता है आम तौर पर दुर्व्यवहार करता है।

— MadHatter

11

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

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

विशेष रूप से मौजूदा डोमेन पर इसे लागू करने पर सावधानी से चलें।

— पीटर ग्रीन
स्रोत

3

हो सकता है, लेकिन इस तरह के बदलाव करने से पहले आपको कुछ मामलों पर विचार करने की आवश्यकता है।

1) क्या आपकी कंपनी में कोई भी किसी भी तरह की बाहरी सेवा का उपयोग करता है (उदाहरण के लिए सर्वेक्षण बंदर, लगातार संपर्क, आदि) जो आपके डोमेन से "दिखाई" देने वाले ईमेल भेजते हैं? भले ही वे इसे आज नहीं कर रहे हैं, लेकिन क्या वे भविष्य में ऐसा कर सकते हैं?

2) क्या आपके उपयोगकर्ताओं के लिए कोई बाहरी पता है? उदाहरण के लिए, gmail खाता "mycompany.sales@gmail.com" को "sales@mycompany.com" पर, और आपके उपयोगकर्ता "bob@mycompany.com" को "mycompany.sales@gmail.com" पर भेजें। उस स्थिति में, संदेश "बाहर" से आएगा, लेकिन "@ mycompany.com" से: पते से।

3) क्या आपका कोई उपयोगकर्ता बाहरी वितरण सूचियों की सदस्यता ले रहा है जो सूची के संदेशों पर मूल "से:" पता संरक्षित करते हैं? उदाहरण के लिए, यदि बॉब "foo-list@lists.apple.com" की सदस्यता लेता है और एक संदेश भेजता है, तो उसे एक इनबाउंड संदेश प्राप्त होगा जो कुछ इस तरह दिखाई देगा: from: bob@mycompany.com To: foo-list@lists.apple। कॉम प्रेषक:

यदि आपका सर्वर भोलेपन से "प्रेषक:" ("प्रेषक:" के बजाय) को देखता है, तो वह इस संदेश को अस्वीकार कर सकता है क्योंकि आप इसे बाहर से प्राप्त कर रहे हैं।

उपरोक्त सभी के कारण, हमारी कंपनी में एक वास्तविक प्रेषक से "... की ईमेल नीति कभी भी बाहर से नहीं आएगी" की कंबल नीति हमेशा संभव नहीं होती है।

— डेविड गेल्हर
स्रोत

2

बेनामी उपयोगकर्ताओं को आधिकारिक डोमेन प्रेषक के रूप में भेजने से रोकने के लिए आप अपने प्राप्तकर्ता की अनुमतियों को अपडेट करके PowerShell में ऐसा कर सकते हैं:

Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender

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

— नील
स्रोत

1

GMail की एक सेटिंग है, जहाँ यह आपको गैर-GMail डोमेन के साथ ईमेल भेजने की अनुमति देता है, बशर्ते ईमेल पता पहले सत्यापित हो। आपका निर्णय उन ईमेल को अवरुद्ध करेगा।

आपके पास ऐसे उपयोगकर्ता हैं, जो इस GMail सुविधा का उपयोग कर सकते हैं या नहीं और क्या यह उन्हें पूरा करने के लिए समझ में आता है, यह आपकी कंपनी के व्यवहार पर बहुत निर्भर करता है।

— ईसाई
स्रोत

-1

SPF इसे ठीक नहीं करेगा क्योंकि लिफाफा अच्छी तरह से एक उचित SPF पास (यानी समझौता सर्वर का उपयोग करने वाले स्पैमर्स) हो सकता है, जबकि वे लिफाफे के अंदर ईमेल को फोर्ज करेंगे। आपको जो चाहिए वह है अपने स्वयं के डोमेन ई-मेल संदेश पर एक ब्लॉक जिसमें लिफाफे पर एक मूल ईमेल सर्वर है जो आपको स्वीकार्य नहीं है।

— जिम
स्रोत

"आपको जिस चीज़ की आवश्यकता है वह आपके स्वयं के डोमेन ईमेल संदेश पर एक ब्लॉक है, जिसमें लिफाफा पर एक प्रचलित ईमेल सर्वर है जो आपको स्वीकार्य नहीं है" - ठीक यही आप एसपीएफ के साथ करते हैं, अपने डोमेन के लिए वैध मूल ईमेल सर्वरों की सूची बनाएं।

— गैथ्रॉन