क्या किया जा सकता है यह इस बात पर निर्भर करता है कि आपके पास कितना बुनियादी ढांचा है, जिस पर आपका नियंत्रण है, और क्या आप अपने स्वयं के डोमेन नाम का उपयोग कर रहे हैं या किसी अन्य द्वारा नियंत्रित डोमेन के तहत एक पता है।
यदि आपके पास अपना डोमेन है, तो उसी डोमेन के तहत एक नया ईमेल पता स्विच करना आसान है। इसके अतिरिक्त आप दुनिया को यह बताने के लिए DNS रिकॉर्ड सेट कर सकते हैं कि आपके डोमेन के सभी ईमेल डिजिटल रूप से हस्ताक्षरित होने चाहिए। (एसपीएफ़, डीकेआईएम और डीएमएआरसी यह देखने के लिए शब्द हैं कि क्या यह वह तरीका है जिसे आप लेना चाहते हैं।)
आप इन हस्ताक्षरों को सत्यापित करने के लिए हर किसी से अपेक्षा नहीं कर सकते हैं, इसलिए भले ही आप सेटअप DNS रिकॉर्ड करते हों जो यह दर्शाता है कि आपके डोमेन से ईमेल पर हस्ताक्षर किए जाने चाहिए, फिर भी आपके डोमेन से प्राप्त होने का दावा करने वाले अहस्ताक्षरित ईमेल भेजने वाले और उन अहस्ताक्षरित ईमेल को स्वीकार करने वाले रिसीवर होंगे।
यदि आप डोमेन को नियंत्रित नहीं करते हैं, तो ईमेल पते को बदलना उतना आसान नहीं है, और आपके पास इस बात का बहुत कम प्रभाव है कि DNS रिकॉर्ड का उपयोग आउटगोइंग ईमेल में डोमेन को बिगाड़ने की क्षमता को सीमित करने के लिए किया जाता है या नहीं।
अनचाहे स्रोत पते का उपयोग करके स्पैम संदेशों के साथ समस्या जिसके कारण वैध पते पर वापस आ रहा है कम से कम सिद्धांत रूप में हल करना आसान है।
आप अपने Message-IDद्वारा भेजे जा रहे सभी ईमेल को रिकॉर्ड कर सकते हैं। सभी बाउंस Message-IDको मूल संदेश को कहीं न कहीं शामिल करना होगा - अन्यथा उछाल वैसे भी पूरी तरह से बेकार है, क्योंकि वही आपको बताता है कि कौन सा संदेश बाउंस हो गया। कोई भी बाउंस किया हुआ संदेश जिसमें Message-IDआपके पास पहले नहीं है, सीधे स्पैम फोल्डर में भेजा जा सकता है या प्राप्त करने के समय पर खारिज कर दिया जा सकता है (जो समस्या को स्रोत के करीब एक कदम आगे बढ़ाने का अच्छा लाभ है)।
MAIL Fromपते द्वारा अन्य ईमेल के अलावा बाउंस को भी बताया जा सकता है । बाउंस में हमेशा एक खाली MAIL Fromपता होता है, अन्य ईमेल में कभी भी खाली MAIL Fromपता नहीं होता है।
तो अगर MAIL Fromखाली है - और DATAशामिल नहीं है एक Message-IDआपने पहले भेजने के लिए, मेल को सुरक्षित रूप से अस्वीकार कर दिया जा सकता है।
यही सिद्धांत है। इसे व्यवहार में लाना थोड़ा कठिन है। आउटगोइंग और इनकमिंग ईमेल के लिए सबसे पहले इंफ्रास्ट्रक्चर अलग हो सकता है, इससे आने वाले ईमेल के लिए इन्फ्रास्ट्रक्चर के लिए समस्याग्रस्त हो सकता है Message-IDजो हमेशा आउटगोइंग ईमेल के लिए इन्फ्रास्ट्रक्चर से गुजरे हैं।
इसके अतिरिक्त कुछ प्रदाता बाउंस भेजने पर जोर देते हैं जो सामान्य ज्ञान के अनुरूप नहीं है। उदाहरण के लिए मैंने उन प्रदाताओं को बाउंस करते देखा है जो मूल ईमेल के बारे में कोई जानकारी नहीं रखते थे जो बाउंस हो गया था। इस तरह के बेकार उछाल के लिए मेरी सबसे अच्छी सिफारिश उन्हें स्पैम के रूप में व्यवहार करना है, भले ही वे एक अन्यथा वैध मेल सिस्टम से उत्पन्न हों।
याद रखें कि जिसने भी ईमेल पते की सूची प्राप्त की है, वह किसी भी पते को स्रोत पते के रूप में और किसी भी पते को गंतव्य पते के रूप में रख सकता है। इस प्रकार जब तक आपके पास अतिरिक्त जानकारी नहीं है आप सुनिश्चित नहीं कर सकते कि रिसाव आपके ही सिस्टम से हुआ है। यह आपका कोई भी संपर्क हो सकता है जिसने आपके सहित पतों की सूची लीक कर दी है।
जितना अधिक आप यह पता लगा सकते हैं कि लीक की गई सूची में कौन से पते हैं और जो नहीं हैं, बेहतर होगा कि आप यह पता लगा पाएंगे कि यह कहां से लीक हुआ था। हो सकता है कि आपने पहले ही ऐसा कर लिया हो और यह निष्कर्ष निकाला हो कि रिसाव आपकी संपर्क सूची से उत्पन्न हुआ होगा क्योंकि आपके किसी भी संपर्क को लीक होने की पुष्टि किए गए सभी पते नहीं पता होंगे।
उस पर मेरा दृष्टिकोण अपने स्वयं के डोमेन और उस ईमेल के तहत एक अलग ईमेल पते का उपयोग करना है जिसके साथ मैं प्रत्येक संपर्क के लिए संपर्क करता हूं। मैं मेल पते में संपर्क के साथ पहले संचार की तारीख को शामिल करता हूं, जैसे कि यह देख सकता है कि kasperd@mdgwh.04.dec.2015.kasperd.netक्या मैं आज एक नए संपर्क के लिए एक ईमेल लिख रहा था। यह दृष्टिकोण स्पष्ट रूप से हर किसी के लिए नहीं है, लेकिन मेरे लिए यह निश्चित रूप से यह जानने में मदद करता है कि कौन ईमेल पते की सूची लीक कर रहा है जहां मेरा एक है। इसका मतलब यह भी है कि मैं व्यक्तिगत पते को बंद कर सकता हूं, जैसे कि मेरे पते को लीक करने वाले व्यक्ति को मेरे लिए अपनी संपर्क जानकारी अपडेट करनी होगी।