फिल्टर जो जवाबी हमला करते हैं

अगस्त 2003

हम बायेसियन स्पैम फ़िल्टर की सटीकता को बेहतर बनाने में सक्षम हो सकते हैं, उन्हें लिंक का अनुसरण करने के लिए कहकर यह देखने के लिए कि दूसरे छोर पर क्या इंतज़ार कर रहा है। डेथ2स्पैम के रिचर्ड जॉसी अब सीमांत मामलों में ऐसा करते हैं, और रिपोर्ट करते हैं कि यह अच्छी तरह से काम करता है।

ऐसा केवल सीमांत मामलों में ही क्यों किया जाता है? और ऐसा केवल एक बार ही क्यों किया जाता है?

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

इसलिए मैं स्पैम फ़िल्टर पर काम करने वालों के लिए एक अतिरिक्त सुविधा का सुझाव देना चाहूँगा: एक "दंड" मोड, जो अगर चालू हो, तो संदिग्ध स्पैम में प्रत्येक URL को n बार स्पाइडर करेगा, जहाँ n को उपयोगकर्ता द्वारा सेट किया जा सकता है। [1]

जैसा कि कई लोगों ने कहा है, मौजूदा ईमेल सिस्टम की एक समस्या यह है कि यह बहुत निष्क्रिय है। आप इसे जो भी कहते हैं, यह वही करता है। अब तक समस्या को ठीक करने के लिए सभी सुझाव नए प्रोटोकॉल को शामिल करते प्रतीत होते हैं। यह ऐसा नहीं होगा।

यदि व्यापक रूप से उपयोग किया जाए, तो ऑटो-रिट्रीविंग स्पैम फ़िल्टर ईमेल सिस्टम को फिर से सक्रिय कर देगा। स्पैम की विशाल मात्रा, जो अब तक स्पैमर के पक्ष में काम करती थी, अब उसके खिलाफ काम करेगी, जैसे कि उसके चेहरे पर एक शाखा टूट कर गिर रही हो। ऑटो-रिट्रीविंग स्पैम फ़िल्टर स्पैमर की लागत बढ़ा देंगे, और उसकी बिक्री कम हो जाएगी: उसका बैंडविड्थ उपयोग छत से ऊपर चला जाएगा, और उसके सर्वर लोड के नीचे ठप हो जाएंगे, जिससे वे उन लोगों के लिए अनुपलब्ध हो जाएंगे जिन्होंने स्पैम का जवाब दिया होगा।

प्रति घंटे दस लाख ईमेल भेजें, अपने सर्वर पर प्रति घंटे दस लाख हिट्स प्राप्त करें।

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

ऐसी साइटों की सुरक्षा और दुरुपयोग को रोकने के लिए, ऑटो-रिट्रीवल को स्पैमवर्टाइज़्ड साइटों की ब्लैकलिस्ट के साथ जोड़ा जाना चाहिए। केवल ब्लैकलिस्ट वाली साइटों को ही क्रॉल किया जाएगा, और साइटों को केवल मनुष्यों द्वारा निरीक्षण किए जाने के बाद ही ब्लैकलिस्ट किया जाएगा। स्पैम का जीवनकाल कम से कम कई घंटों का होना चाहिए, इसलिए नई साइट को बढ़ावा देने वाले स्पैम को रोकने के लिए समय पर ऐसी सूची को अपडेट करना आसान होना चाहिए। [2]

हाई-वॉल्यूम ऑटो-रिट्रीवल केवल हाई-बैंडविड्थ कनेक्शन वाले उपयोगकर्ताओं के लिए ही व्यावहारिक होगा, लेकिन स्पैमर को गंभीर परेशानी देने के लिए उनमें से बहुत सारे हैं। वास्तव में, यह समाधान समस्या को स्पष्ट रूप से दर्शाता है। स्पैम के साथ समस्या यह है कि कुछ भोले-भाले लोगों तक पहुँचने के लिए स्पैमर सभी को मेल भेजता है। गैर-भोले प्राप्तकर्ता केवल संपार्श्विक क्षति हैं। लेकिन गैर-भोले बहुमत तब तक स्पैम प्राप्त करना बंद नहीं करेंगे जब तक कि वे भोले-भाले लोगों को इसका जवाब देने से रोक नहीं सकते (या रोकने की धमकी नहीं देते)। ऑटो-रिट्रीविंग स्पैम फ़िल्टर उन्हें ऐसा करने का एक तरीका प्रदान करते हैं।

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

इस परिदृश्य में, स्पैम, ऑपरेटिंग सिस्टम क्रैश, वायरस और पॉपअप की तरह, उन विपत्तियों में से एक बन जाएगा जो केवल उन लोगों को परेशान करती हैं जो सही सॉफ्टवेयर का उपयोग करने की जहमत नहीं उठाते हैं।

नोट्स

[1] ऑटो-रिट्रीविंग फ़िल्टर को रीडायरेक्ट का पालन करना होगा, और कुछ मामलों में (जैसे कि एक पेज जो सिर्फ "यहां क्लिक करें" कहता है) लिंक के एक से अधिक स्तर का पालन करना चाहिए। यह भी सुनिश्चित करें कि http अनुरोध लोकप्रिय वेब ब्राउज़रों से अलग न हों, जिसमें ऑर्डर और रेफ़रर शामिल हैं।

यदि x समय के भीतर प्रतिक्रिया नहीं मिलती है, तो स्पैम की संभावना काफी अधिक हो जाती है।

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

[2] इस लेख के मूल संस्करण में "ब्लैकलिस्ट" के बजाय "श्वेतसूची" शब्द का इस्तेमाल किया गया था। हालाँकि उन्हें ब्लैकलिस्ट की तरह काम करना था, लेकिन मैंने उन्हें श्वेतसूची कहना पसंद किया क्योंकि इससे वे कानूनी हमले के प्रति कम संवेदनशील हो सकते थे। हालाँकि, ऐसा लगता है कि इससे पाठक भ्रमित हो गए हैं।

संभवतः कई ब्लैकलिस्ट होनी चाहिए। विफलता का एक भी बिंदु हमले और दुरुपयोग दोनों के लिए असुरक्षित होगा।

इस ड्राफ्ट को पढ़ने के लिए ब्रायन बर्टन, बिल येराज़ुनिस, डैन गिफिन, एरिक रेमंड और रिचर्ड जॉसी को धन्यवाद ।