2012-07-27 12 views
9

इसे जारी होने के बाद से मैं stackednotion.com के लिए Google Apps FYD का उपयोग कर रहा हूं। मेरे द्वारा भेजे जाने वाले सभी ईमेल Google के सर्वर के माध्यम से जाते हैं और मैं अपना ईमेल देखने के लिए जीमेल का उपयोग करता हूं। मुझे पहले कोई समस्या नहीं थी, हालांकि हाल ही में मैं सभी खाते को पकड़ने में अजीब बाउंसबैक देख रहा हूं। ऐसा लगता है कि कोई स्पैम भेजने के लिए मेरे डोमेन का उपयोग कर रहा है। मैं वास्तव में नहीं चाहता कि मेरा डोमेन खराब प्रतिष्ठा के साथ चिह्नित हो, तो मैं इसे कैसे रोक सकता हूं?स्पैम मेरे डोमेन का उपयोग करके भेजा जा रहा है, मैं क्या कर सकता हूं?

मैं Google Apps पर गाइड का पालन करके डोमेन पर सेटअप एसपीएफ़, DMARC और DKIM है, यहाँ मेरी क्षेत्र फ़ाइल है:

; stackednotion.com [9548] 
$TTL 86400 
@ IN SOA ns1.linode.com. luca.stackednotion.com. 2012072633 7200 7200 1209600 86400 
@  NS ns1.linode.com. 
@  NS ns2.linode.com. 
@  NS ns3.linode.com. 
@  NS ns4.linode.com. 
@  NS ns5.linode.com. 
@   MX 1 ASPMX.L.GOOGLE.COM. 
@   MX 5 ALT1.ASPMX.L.GOOGLE.COM. 
@   MX 5 ALT2.ASPMX.L.GOOGLE.COM. 
@   MX 10 ASPMX2.GOOGLEMAIL.COM. 
@   MX 10 ASPMX3.GOOGLEMAIL.COM. 
@   MX 30 ASPMX4.GOOGLEMAIL.COM. 
@   MX 30 ASPMX5.GOOGLEMAIL.COM. 
@   TXT "v=spf1 include:_spf.google.com ~all" 
google._domainkey   TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDi19ipSdqDEpnJEWrVF7MarSLnlzXi0wPOHws2BY6oMQInbY5OHzdw9LcFr1biVvipErm4odyJfjZAIp5s8r6z50ZxQdW5Uwdy9krA1A9HMPaqVN+fm2xpntU//uXn0wD8sGc9CljYQIl+MusxQ690PfVGnAz/QeLqaZFxpHHmmQIDAQAB" 
_dmarc   TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" 
@   A 178.79.164.64 
*   A 178.79.164.64 
_xmpp-server._tcp  SRV 5 0 5269 xmpp-server.l.google.com. 
_xmpp-server._tcp  SRV 20 0 5269 alt1.xmpp-server.l.google.com. 

इसके अलावा यहां एक स्पैम संदेश के शीर्ष लेख हैं (किसी susbscribe करने की कोशिश की मुझे एक Zend मेलिंग सूची के लिए, बीमार लोगों की किस तरह वे कर रहे हैं):?!?

Return-Path: <[email protected]> 
Received: (qmail 20117 invoked from network); 27 Jul 2012 06:51:01 -0000 
Received: from exprod7mx200.postini.com (HELO psmtp.com) (64.18.2.92) 
    by rsmx2.zend.com with SMTP; 27 Jul 2012 06:51:01 -0000 
Received: from source ([188.51.41.223]) by exprod7mx200.postini.com ([64.18.6.13]) with SMTP; 
     Fri, 27 Jul 2012 02:51:00 EDT 
To: <[email protected]> 
Subject: Invoice #48469883494 
From: "Order" <[email protected]> 
Date: Sat, 28 Jul 2012 09:40:03 +0300 
X-Priority: 3 
X-MSMail-Priority: Normal 
X-Mailer: IPS PHP Mailer 
MIME-Version: 1.0 
Content-type: text/plain; charset="iso-8859-1" 
Content-Transfer-Encoding: 8bit 
Message-ID: <[email protected]> 
X-pstn-neptune: 500/484/0.97/100 
X-pstn-levels:  (S: 0.00346/89.11253 CV:99.9000 FC:95.5390 LC:95.5390 R:95.9108 P:95.9108 M:97.0282 C:98.6951) 
X-pstn-dkim: 0 skipp 
+0

आपको ईमेल को भेजने के तरीके में गहराई से काम करना चाहिए। आप पाएंगे कि जब आप इसे जानते हैं तो आप लोगों को अपने पते का उपयोग करने से नहीं रोक सकते हैं। इसके लिए कोई मतलब नहीं है। यदि बिलकुल प्राप्त रिले इसे फ़िल्टर करने का प्रयास कर सकते हैं। – arkascha

+0

मुझे भी देर से एक ही समस्या हो रही है और अभी तक कोई समाधान नहीं मिला है ... –

+0

उचित एसपीएफ़ रिकॉर्ड मदद करते हैं जब प्राप्तकर्ता एसपीएफ़ विफलता पर अस्वीकार करता है, लेकिन यह उन पर निर्भर करता है। बहुत से नहीं करते हैं। कुछ "अच्छे ईमेल" के साथ "अच्छा एसपीएफ़" को निष्पक्ष रूप से समझाएंगे, जो स्पष्ट रूप से मामला नहीं है (एक स्पैमर अपने लिए एसपीएफ़ को छोटा रूप से स्थापित कर सकता है) लेकिन "खराब एसपीएफ़" व्यावहारिक रूप से "खराब ईमेल" होने की गारंटी है। – tripleee

उत्तर

2

मैं भी पिछले कुछ सप्ताहों में स्पूफिंग इस तरह की संख्या में वृद्धि देखी है।

Google support page on this issue नोट:

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

"तुम भी [email protected] पर संघीय व्यापार आयोग को इन अवैध संदेशों के पूर्ण हेडर भेज कर बंद स्पैमर्स कर सकते हैं।"

1

अफैइक, ऐसा माना जाता है कि डीएमएआरसी आपको इसे प्राप्त करने में मदद करेगा। Google Apps Article about DMARC के अनुसार, आप की तरह एक "रूढ़िवादी तैनाती चक्र" का उपयोग शुरू कर देना चाहिए:

Monitor all. 
Quarantine 1%. 
Quarantine 5%. 
Quarantine 10%. 
Quarantine 25%. 
Quarantine 50%. 
Quarantine all. 
Reject 1%. 
Reject 5%. 
Reject 10%. 
Reject 25%. 
Reject 50%. 
Reject all. 

तो, मेरे सुझाव देने वाले ईमेल quaranting रोक होगा, थोड़ी देर के लिए नजर रखने के लिए और फिर ऊपर जा रहा शुरू करते हैं।

10

वर्तमान में, जिस तरह से send spam purportedly from your domain को शरारती तत्वों की क्षमता को कम करने के लिए अन्य मेल सर्वर क्या सर्वर आपके डोमेन ओर से मेल भेजने के लिए अनुमति दी जाती है सूचित करने के लिए है। तंत्र SPF है और आप पहले से ही एक SPF रिकॉर्ड है:

TXT "v=spf1 include:_spf.google.com ~all" 

तो जालसाजी प्रयास अवरुद्ध अपनी इच्छा है, इस पर सुधार किया जा सकता है। SPF Record Syntax page पढ़ें जो बताता है कि आपकी एसपीएफ़ नीति क्या होनी चाहिए। आप अपने डोमेन की ओर से मेल भेजने के अन्य मेल सर्वर है, तो उन्हें SPF रिकॉर्ड करने के लिए जोड़ सकते हैं और विफल अपनी नीति बदलने के लिए:

TXT "v=spf1 include:_spf.google.com -all" 

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

_dmarc TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" 

आपकी पॉलिसी केवल संगरोध DMARC संदेशों में नाकाम रहने के लिए है:

यह जहां DMARC में आता है आप पहले से ही एक DMARC रिकॉर्ड जोड़ लिया है। यदि डीएमएआरसी रिपोर्ट किसी वैध संदेश को अवरुद्ध नहीं करती है, और/या आप कुछ किनारे के मामलों के साथ रहने के इच्छुक हैं जहां वैध संदेश अस्वीकार कर दिए जाते हैं, तो आप पी = अस्वीकार के साथ इस पर सुधार कर सकते हैं।

आश्चर्य की बात नहीं है कि, मेरे डोमेन में से किसी एक से होने वाले स्पैम के लिए मेल सर्वर से बाउंस प्राप्त करना ठीक है, जो मुझे DKIM शुरू करने के लिए मजबूर करता है, ताकि मैं डीएमएआरसी को तैनात कर सकूं। डीएमएआरसी एक नीति तंत्र है जो एसपीएफ़ और डीकेआईएम को जोड़ती है, ताकि डोमेन मालिक अन्य मेल सर्वरों पर जोर दे सकें, "अगर यह आईपी (एसपीएफ़) की सूची से नहीं है और यह डीकेआईएम हस्ताक्षरित नहीं है, तो [अस्वीकार | क्वारंटाइन | अनुमति दें] । "

डीएमएआरसी शानदार ढंग से काम करता है। उछाल संदेश प्राप्त करने के बजाय, अब मुझे डीएमएआरसी रिपोर्ट मिलती है। रिपोर्टों को पार्स करने और सारांश को डेटाबेस में रखने के लिए मैं Mail::DMARC का उपयोग करता हूं।

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

मैंने पहले किनारे के मामलों का उल्लेख किया, इसलिए मुझे एक साझा करने के लिए मजबूर होना लगता है।

Google उपयोगकर्ताओं को स्पैम फ़ोल्डर में छोड़कर गलत हस्ताक्षर किए गए संदेशों (जो एसपीएफ़ और डीकेआईएम संरेखण दोनों में विफल रहता है) को संभालता है। मैं इससे परिचित हो गया हूं क्योंकि मेरे डोमेन से भेजे गए ईमेल आमतौर पर जीमेल द्वारा अच्छी तरह से इलाज किए जाते हैं। कुछ ईमेल सूचियों जैसे कि [email protected] के माध्यम से भेजे गए संदेशों के लिए अपवाद है। उस सूची में भेजे गए संदेश सूची प्रोसेसिंग सॉफ़्टवेयर द्वारा संशोधित होते हैं, जो मेरे डीकेआईएम हस्ताक्षर को अमान्य करते हैं। जब संदेश जीमेल प्राप्तकर्ताओं को भेजा जाता है, तो उन संदेशों को स्पैम के रूप में चिह्नित किया जाता है क्योंकि ए) मैंने डीएमएआरसी नीति को अस्वीकार कर दिया है, और बी) कि ईमेल सूची tnpi.net से ईमेल का वैध एसपीएफ़ प्रेषक नहीं है, और सी) मेरे डोमेन वाले डीकेआईएम हस्ताक्षर सत्यापन विफल रहता है।

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

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

+1

दोस्त, जवाब चट्टानों! –

0

संभावना है कि आपके मेल वापस उछाल रहे हैं। इसलिए यदि आप उसी खाते पर मेल प्राप्त कर रहे हैं जिससे आप भेजते हैं। अपने डेटाबेस में डोमेन नियंत्रण के व्यवस्थापक के अधिकार को बदलने का प्रयास करें।

संबंधित मुद्दे