अक्सर पूछे जाने वाले सवाल

echo.email हर एड्रेस पर एक ईमेल का विश्लेषण करता है और नतीजा समझाता है। नीचे दिए जवाब बताते हैं कि सेवा कैसे काम करती है और रिपोर्ट की हर जाँच का क्या मतलब है।

echo.email कैसे काम करता है?

होम पेज तीन शब्दों से बना एक नया एड्रेस देता है, जैसे power.file.tube@echo.email। इस एड्रेस पर भेजा गया मैसेज echo.email के मेल सर्वर पर पहुँचता है। सर्वर SMTP बातचीत रिकॉर्ड करता है और मैसेज को विश्लेषण के लिए आगे भेजता है। कुछ सेकंड बाद पेज एक रिपोर्ट दिखाता है, जिसमें ऑथेंटिकेशन, कंटेंट, नियमों का पालन और डिलीवरी शामिल हैं। कुछ भी इंस्टॉल नहीं करना पड़ता और कोई अकाउंट नहीं होता।

एड्रेस कितनी देर तक काम करता है?

जब तक पेज खुला है, एड्रेस चालू रहता है। पेज हर दो सेकंड में सर्वर से संपर्क करता है, और 10 मिनट के अंदर रीलोड करने पर उसी टैब में वही एड्रेस बना रहता है। पेज 10 मिनट से ज़्यादा बंद रहने पर मेल सर्वर उस एड्रेस पर नया मेल एक स्थायी एरर के साथ रिजेक्ट कर देता है।

जो मैसेज पहले पहुँचता है, वही गिना जाता है। उसी एड्रेस पर बाद में आए मैसेज रिजेक्ट कर दिए जाते हैं, इसलिए हर रिपोर्ट सिर्फ़ एक ही ईमेल की होती है। 10 MB से बड़े मैसेज SMTP बातचीत के दौरान ही रिजेक्ट कर दिए जाते हैं।

रिपोर्ट कितने समय तक रखी जाती हैं?

मैसेज पहुँचने के 24 घंटे बाद हर रिपोर्ट, सेव किया गया मैसेज और डाउनलोड किया गया इमेज डेटा अपने आप डिलीट हो जाता है। इन 24 घंटों में रिपोर्ट का लिंक हर उस व्यक्ति के लिए काम करता है जिसके पास लिंक है, और उसके बाद लिंक काम करना बंद कर देता है। सिर्फ़ सैंपल रिपोर्ट इसका अपवाद है, क्योंकि वह इसी काम के लिए भेजे गए एक टेस्ट मैसेज से बनी है।

मैसेज के कंटेंट का क्या होता है?

echo.email पूरा मैसेज सेव करता है, यानी हेडर, बॉडी और अटैचमेंट। साथ में SMTP सेशन की जानकारी भी, जैसे भेजने वाला IP एड्रेस, HELO नाम और TLS वर्ज़न। डेटा EU में रखा जाता है, और मेल सर्वर जर्मनी के Falkenstein में चलता है। रिपोर्ट के लिंक वाला कोई भी व्यक्ति पूरा मैसेज देख सकता है, इसलिए टेस्ट के लिए ऐसा कंटेंट सबसे अच्छा है जिसे शेयर करने में कोई दिक्कत न हो। न्यूज़लेटर में अक्सर ट्रैकिंग लिंक और किसी एक प्राप्तकर्ता से जुड़ा अनसब्सक्राइब लिंक होता है। किसी टेस्ट लिस्ट पर भेजी गई कॉपी में ये प्राइवेट रहते हैं।

दो एड्रेस सीधे ऑपरेटर तक पहुँचते हैं: सवालों और शिकायतों के लिए contact@echo.email, और डेटा से जुड़े अनुरोधों के लिए privacy@echo.email। पूरी जानकारी प्राइवेसी पॉलिसी में है।

SPF जाँच क्या टेस्ट करती है?

SPF उन सर्वरों की लिस्ट है जिन्हें return path में किसी डोमेन के साथ मेल भेजने की अनुमति है। echo.email डोमेन को envelope sender (MAIL FROM एड्रेस, जिसे return path भी कहते हैं) से लेता है और उस डोमेन के SPF रिकॉर्ड को मैसेज डिलीवर करने वाले सर्वर के IP एड्रेस से जाँचता है। सिर्फ़ pass ही अच्छा नतीजा है। Softfail, neutral और none, तीनों में रिसीवर के पास सेंडर का कोई SPF सबूत नहीं होता।

बड़े मेलबॉक्स प्रोवाइडर बल्क मेल के लिए SPF की जाँच HELO नाम पर नहीं करते। echo.email भी HELO नाम की जाँच नहीं करता। रिपोर्ट रास्ते का हर रिकॉर्ड और mechanism दिखाती है, इसलिए अंतिम नतीजे तक का रास्ता साफ़ दिखता है।

DNS लुकअप की संख्या क्यों मायने रखती है?

एक SPF मूल्यांकन में ज़्यादा से ज़्यादा 10 DNS लुकअप की अनुमति है। include, a, mx, ptr, exists और redirect, हर mechanism इस सीमा में गिना जाता है, nested include के अंदर वाले भी। सीमा पार होने पर नतीजा एक स्थायी एरर बन जाता है, और रिसीवर मैसेज को ऐसे मानते हैं जैसे उसका कोई मान्य SPF हो ही नहीं। खाली (void) लुकअप, यानी ऐसी क्वेरी जिनसे कोई रिकॉर्ड नहीं मिलता, की अलग सीमा है: दो। आम वजह थर्ड-पार्टी include की लंबी चेन होती है, और सेवाओं की लिस्ट छोटी करने से समस्या ठीक हो जाती है।

DKIM क्या साबित करता है?

DKIM मैसेज के हेडर में एक क्रिप्टोग्राफ़िक सिग्नेचर जोड़ता है। साइन करने वाला डोमेन public key को DNS में एक सेलेक्टर के नीचे पब्लिश करता है। echo.email वह key लेता है और मिले हुए हेडर और बॉडी पर सिग्नेचर की जाँच करता है। Pass का मतलब है कि साइन किए गए हिस्से बिना बदले पहुँचे और साइन करने वाले डोमेन ने उनकी पुष्टि की।

रिपोर्ट ये चीज़ें दिखाती है: साइन करने वाला डोमेन (d=), सेलेक्टर (s=), साइन किए गए हेडर (h=), और key का टाइप और साइज़। अगर बॉडी की लंबाई की सीमा (l=) लगी है, तो रिपोर्ट उस पर चेतावनी देती है, क्योंकि इस सीमा से साइन करने के बाद अतिरिक्त कंटेंट जोड़ा जा सकता है।

DMARC क्या है?

DMARC का काम SPF और DKIM को दिखने वाले From एड्रेस के डोमेन से जोड़ना है। From डोमेन _dmarc.<domain> पर एक पॉलिसी पब्लिश करता है। यह पॉलिसी रिसीवर को बताती है कि ऑथेंटिकेशन में फ़ेल हुए मेल के साथ क्या करना है: none, quarantine या reject। कोई मैसेज DMARC पास करता है जब From डोमेन से अलाइन किसी डोमेन के लिए SPF या DKIM पास होता है।

DMARC खुद कोई ऑथेंटिकेशन नहीं जोड़ता। इसकी अहमियत अलाइनमेंट की शर्त में है, और उन aggregate रिपोर्ट (rua=) में, जिन्हें रिसीवर वापस डोमेन के मालिक को भेजते हैं।

अलाइन का क्या मतलब है?

अलाइनमेंट किसी ऑथेंटिकेटेड डोमेन की तुलना From डोमेन से करता है। Relaxed अलाइनमेंट में ऑर्गनाइज़ेशनल डोमेन एक होना चाहिए, इसलिए mail.example.com और example.com आपस में अलाइन होते हैं। Strict अलाइनमेंट में होस्टनेम बिल्कुल एक जैसा होना चाहिए। ऑर्गनाइज़ेशनल डोमेन Public Suffix List से तय होता है। यह लिस्ट जानती है कि example.co.uk जैसा नाम एक ही रजिस्टर किए जा सकने वाला डोमेन गिना जाता है। जब रिपोर्ट बिना किसी और जानकारी के अलाइन कहती है, तो तुलना From डोमेन से होती है।

BIMI क्या है?

BIMI एक ब्रांड लोगो पब्लिश करता है, जिसे मेलबॉक्स प्रोवाइडर ऑथेंटिकेटेड मेल के पास दिखाते हैं। रिकॉर्ड का पता default._bimi.<domain> है। रिकॉर्ड में एक SVG लोगो (l=) का लिंक होता है, और ज़्यादातर प्रोवाइडर के लिए एक Verified Mark Certificate (a=) का लिंक भी। BIMI सिर्फ़ उन डोमेन पर लागू होता है जिनकी DMARC पॉलिसी सख्ती से लागू है, यानी 100 प्रतिशत पर quarantine या reject। echo.email यह रिकॉर्ड दिखाता है और बताता है कि DMARC पॉलिसी यह शर्त पूरी करती है या नहीं।

रिवर्स DNS क्यों ज़रूरी है?

मेल भेजने वाले हर IP एड्रेस का एक PTR रिकॉर्ड होना चाहिए जो किसी होस्टनेम की ओर इशारा करे, और उस होस्टनेम का A या AAAA रिकॉर्ड वापस उसी IP एड्रेस की ओर इशारा करे। इस पूरे चक्कर को forward-confirmed reverse DNS या FCrDNS कहते हैं। बड़े मेलबॉक्स प्रोवाइडर FCrDNS को मेल भेजने वाले सर्वर की न्यूनतम शर्त मानते हैं, और बिना PTR रिकॉर्ड वाले IP एड्रेस का मेल अक्सर सीधे रिजेक्ट कर दिया जाता है।

जेनेरिक रिवर्स DNS क्या है?

कुछ PTR रिकॉर्ड ISP के नामकरण पैटर्न पर चलते हैं, जैसे 192-0-2-10.dynamic.example.net। ऐसे नाम घरेलू कनेक्शन या ऐसे सर्वर का संकेत देते हैं जिसे किसी ने मेल के लिए सेट नहीं किया, और फ़िल्टर इन्हें शक की नज़र से देखते हैं। सेंडर के अपने डोमेन में एक अलग नाम, जैसे mail.example.com, सोच-समझकर सेट किए गए मेल सर्वर जैसा दिखता है।

कौन सा HELO नाम सबसे अच्छा काम करता है?

भेजने वाला सर्वर SMTP बातचीत की शुरुआत में HELO या EHLO नाम से अपना परिचय देता है। अच्छा नाम भेजने वाले सर्वर का होता है, DNS में resolve होता है और भेजने वाले IP एड्रेस के PTR रिकॉर्ड से मेल खाता है। नाम की जगह सीधे IP एड्रेस, localhost जैसे नाम और बेतरतीब अक्षर malware और snowshoe स्पैम में आम हैं, और फ़िल्टर इन्हें उसी हिसाब से तौलते हैं।

TLS क्यों जाँचें?

जब रिसीव करने वाला सर्वर STARTTLS देता है, तो Opportunistic TLS SMTP बातचीत को एन्क्रिप्ट करता है। echo.email हर कनेक्शन पर STARTTLS देता है और सेंडर का चुना हुआ TLS वर्ज़न और cipher रिकॉर्ड करता है। बिना TLS के भेजा गया मेल दोनों सर्वरों के बीच plain text में जाता है, और Google और Yahoo बल्क सेंडर के लिए TLS को ज़रूरी मानते हैं। रिपोर्ट plain http से लोड होने वाले लिंक और इमेज भी गिनती है, क्योंकि वे अनुरोध भी बिना एन्क्रिप्शन के जाते हैं।

IPv6 क्यों जाँचें?

IPv6 की तैयारी दो सवालों से तय होती है। पहला सवाल यह है कि क्या सेंडर उन मेल सर्वरों तक पहुँच सकता है जो सिर्फ़ IPv6 इस्तेमाल करते हैं। IPv6 से पहुँचा मैसेज सीधे हाँ में जवाब देता है। IPv4 से पहुँचा मैसेज भी IPv6 सक्षम गिना जाता है, अगर भेजने वाले होस्ट का AAAA रिकॉर्ड है, उस IPv6 एड्रेस का रिवर्स DNS उसी होस्ट का नाम बताता है, और उस एड्रेस के लिए SPF पास होता है। ज़्यादातर मेल सर्वर हर कनेक्शन पर IPv4 या IPv6 चुनते हैं, इसलिए उसी होस्ट का अगला मैसेज अक्सर IPv6 से आता है। दूसरा सवाल यह है कि क्या मैसेज में इमेज और लिंक देने वाले हर होस्ट का AAAA रिकॉर्ड है, ताकि ऐसे नेटवर्क पर बैठा पाठक भी कंटेंट लोड कर सके जो सिर्फ़ IPv6 इस्तेमाल करता है, या जो carrier-grade NAT के पीछे है। जब दोनों जवाब हाँ हों, तो रिपोर्ट मैसेज को IPv6 के लिए तैयार बताती है।

ईमेल साइज़ कैसे मापा जाता है?

ईमेल साइज़ भेजे गए रूप में बाइट की संख्या है: सारे हेडर, हर MIME हिस्सा, अटैचमेंट और base64 या quoted-printable एन्कोडिंग का अतिरिक्त हिस्सा। Gmail लगभग 102 KB से ज़्यादा HTML वाले मैसेज को काट देता है और बाकी हिस्सा एक लिंक के पीछे छिपा देता है। कटे हुए हिस्से में अक्सर अनसब्सक्राइब लिंक और ट्रैकिंग पिक्सेल होते हैं।

इमेज का कुल साइज़ क्या है?

इमेज का कुल साइज़ <img> टैग में दी गई रिमोट इमेज का कुल आकार है, जिसे हर इमेज को एक बार डाउनलोड करके मापा जाता है। यह आँकड़ा न्यूनतम है, क्योंकि srcset एट्रिब्यूट और CSS बैकग्राउंड की इमेज नहीं गिनी जातीं। भारी मैसेज मोबाइल कनेक्शन पर धीरे लोड होता है और पाठक का डेटा खर्च करता है।

इमेज में फ़ालतू बाइट क्या हैं?

यह आँकड़ा बताता है कि अगर सेंडर हर इमेज को मैसेज में दिखने वाले साइज़ के करीब रखे, तो कितने बाइट बचेंगे। दिखने वाले साइज़ से दोगुनी तक की इमेज में फ़ालतू बाइट शून्य गिने जाते हैं, क्योंकि हाई-डेंसिटी स्क्रीन अतिरिक्त पिक्सेल का इस्तेमाल करती हैं। दोगुने से ज़्यादा होने पर अतिरिक्त पिक्सेल बाइट बढ़ाते हैं, पर कोई बारीकी नहीं जोड़ते। 1 KB से छोटी इमेज, जैसे spacer, इस आँकड़े में शामिल नहीं होतीं।

echo.email इमेज को कैसे संभालता है?

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

लिंक HTML से निकाले जाते हैं और होस्ट के हिसाब से ग्रुप किए जाते हैं, और query parameter आसानी से पढ़ने के लिए डिकोड किए जाते हैं। echo.email आम लिंक कभी नहीं खोलता, क्योंकि लिंक खोलने से कोई सब्सक्रिप्शन कन्फ़र्म हो सकता है, कोई कार्रवाई शुरू हो सकती है या क्लिक दर्ज हो सकता है। सिर्फ़ नीचे बताया गया वन-क्लिक अनसब्सक्राइब URL इसका अपवाद है।

List-Unsubscribe क्या है?

List-Unsubscribe, RFC 2369 में बताया गया एक हेडर है। इस हेडर में लिस्ट छोड़ने के एक या ज़्यादा तरीके होते हैं, जैसे mailto: एड्रेस, https: URL या दोनों। मेलबॉक्स प्रोवाइडर इस हेडर से सेंडर के नाम के पास अपना अनसब्सक्राइब बटन दिखाते हैं। सादे http URL पुराने हो चुके हैं, और https ही अपेक्षित रूप है।

वन-क्लिक अनसब्सक्राइब क्या है?

RFC 8058 एक दूसरा हेडर जोड़ता है, List-Unsubscribe-Post, जिसकी तय वैल्यू List-Unsubscribe=One-Click है। दोनों हेडर मौजूद होने पर मेलबॉक्स प्रोवाइडर https URL पर एक POST अनुरोध भेजता है, और प्राप्तकर्ता कोई वेब पेज खोले बिना लिस्ट छोड़ देता है। Google और Yahoo बल्क सेंडर से वन-क्लिक अनसब्सक्राइब माँगते हैं।

echo.email वही POST अनुरोध भेजता है और जवाब रिपोर्ट करता है। कोई भी 2xx स्टेटस सफल माना जाता है। यह अनुरोध सिर्फ़ अस्थायी echo.email एड्रेस को अनसब्सक्राइब करता है।

बिना इंटरैक्शन के अनसब्सक्राइब का क्या मतलब है?

बिना इंटरैक्शन वाला अनसब्सक्राइब तब पूरा होता है जब प्राप्तकर्ता को ब्राउज़र खोलना या कुछ कन्फ़र्म नहीं करना पड़ता। RFC 8058 वन-क्लिक सबसे पसंदीदा तरीका है। List-Unsubscribe में mailto: एड्रेस भी गिना जाता है, हालाँकि मेल से अनसब्सक्राइब करना धीमा है और प्राप्तकर्ता को कोई पुष्टि नहीं मिलती, इसलिए प्रोवाइडर mailto को बैकअप तरीका मानते हैं।

बॉडी में अनसब्सक्राइब लिंक अब भी क्यों ज़रूरी है?

ज़्यादातर देशों के मार्केटिंग कानून मैसेज के अंदर लिस्ट छोड़ने का एक दिखने वाला तरीका माँगते हैं, आमतौर पर फ़ुटर में एक लिंक। हेडर मेलबॉक्स प्रोवाइडर के काम आते हैं, और फ़ुटर लिंक पाठक के। echo.email अनसब्सक्राइब वाले शब्दों या अनसब्सक्राइब जैसे URL वाला लिंक ढूँढता है। यह पहचान एक अनुमान पर आधारित है और कभी-कभी गलत लिंक चुन लेती है। फ़ुटर लिंक पर एक अलग ट्रैकिंग parameter लगाने से सेंडर के आँकड़ों में फ़ुटर और हेडर वाले अनसब्सक्राइब अलग-अलग दिखते हैं।

List-Id क्या है?

List-Id (RFC 2919) उस मेलिंग लिस्ट का नाम बताता है जिसका मैसेज हिस्सा है, जैसे News <news.example.com>। Google और Yahoo इस हेडर को ज़रूरी नहीं मानते। रिसीवर और प्राप्तकर्ता इस हेडर से मेल को स्ट्रीम के हिसाब से छाँटते और फ़िल्टर करते हैं, इसलिए इसे जोड़ना अच्छी प्रैक्टिस है।

अच्छी प्रैक्टिस की चेकलिस्ट क्या है?

यह चेकलिस्ट उन शर्तों पर आधारित है जो Google और Yahoo ने 2024 में बल्क सेंडर के लिए पब्लिश कीं: अलाइन SPF, अलाइन DKIM, forward-confirmed reverse DNS, TLS, फ़्री ईमेल प्रोवाइडर से बाहर का From डोमेन जिस पर DMARC फ़ेल न हो, एक पब्लिश की गई DMARC पॉलिसी, कम से कम एक अलाइन ऑथेंटिकेशन तरीका, वन-क्लिक अनसब्सक्राइब और एक दिखने वाला अनसब्सक्राइब लिंक। हर पंक्ति में हाँ या नहीं लिखा होता है। लाल पंक्ति इस बात की संभावित वजह है कि बड़े प्रोवाइडर के यहाँ कम मेल इनबॉक्स तक पहुँचते हैं। सभी पंक्तियों का पास होना बल्क मेल के लिए बुनियादी स्तर है।

कुछ पंक्तियाँ तभी गिनी जाती हैं जब वे लागू हों। अनसब्सक्राइब वाली दोनों पंक्तियाँ तब गिनी जाती हैं जब मैसेज में कोई बल्क मेल हेडर हो: List-Unsubscribe, List-Unsubscribe-Post, List-Id, या bulk, list या junk पर सेट Precedence। इनमें से कोई हेडर न होने पर निजी मैसेज के लिए ये पंक्तियाँ नहीं गिनी जातीं। जब envelope sender SRS से बदला गया हो और DMARC अलाइन DKIM के आधार पर पास हो, तो SPF अलाइनमेंट वाली पंक्ति स्कोर में नहीं गिनी जाती। SRS बदलाव के बाद SPF, From डोमेन की नहीं, बल्कि एड्रेस बदलने वाले सर्वर के डोमेन की जाँच करता है। फ़ॉरवर्डर अपने काम के लिए SRS इस्तेमाल करते हैं, और कुछ भेजने वाले सर्वर सारे बाहर जाने वाले मेल पर SRS लगाते हैं, जिससे SPF अलाइनमेंट नहीं रहता। स्कोर गिनी गई पंक्तियों में से पास हुई पंक्तियाँ दिखाता है।

मैसेज कैसे रेंडर किया जाता है?

रेंडर व्यू HTML हिस्से को एक sandbox फ़्रेम के अंदर दिखाता है। रेंडरिंग ब्राउज़र करता है, इसलिए नतीजा किसी खास मेल क्लाइंट या डिवाइस की जगह डेस्कटॉप ब्राउज़र जैसा होता है। प्रीव्यू में स्क्रिप्ट, फ़ॉर्म और लिंक बंद रहते हैं। अलग व्यू मैसेज को बिना इमेज के और हर इमेज की जगह alt टेक्स्ट के साथ दिखाते हैं, क्योंकि कई पाठक मैसेज को पहली बार इसी तरह देखते हैं।

MIME सेक्शन क्या दिखाता है?

MIME मैसेज के अंदर की बनावट है: हिस्से, उनके कंटेंट टाइप, कैरेक्टर सेट, ट्रांसफ़र एन्कोडिंग और उन्हें अलग करने वाली boundary। एक आम न्यूज़लेटर में multipart/alternative कंटेनर होता है, जिसमें एक text/plain हिस्सा और एक text/html हिस्सा होता है। plain text हिस्से का न होना, बंद करने वाली boundary का न होना या असामान्य nesting इस ट्री में साफ़ दिखते हैं।

पेलोड सेक्शन क्या दिखाता है?

पेलोड सेक्शन मिला हुआ रॉ मैसेज आँकड़ों के साथ दिखाता है: कुल साइज़, पंक्तियों की संख्या, सबसे लंबी पंक्ति, ASCII से बाहर के अक्षर और अकेले line feed। RFC 5322 एक पंक्ति को 998 अक्षरों तक सीमित करता है, और कुछ सर्वर लंबी पंक्तियों को तोड़ देते हैं या रिजेक्ट कर देते हैं। carriage return के बिना अकेले line feed DKIM फ़ेल होने की एक आम वजह हैं, क्योंकि रास्ते के सर्वर उन्हें बदल देते हैं।

रॉ मैसेज व्यू उन trace हेडर से शुरू होता है जो mx.echo.email डिलीवरी पर रिकॉर्ड करता है: Return-Path, Authentication-Results, Received-SPF और Received। उनके नीचे मैसेज ठीक वैसा ही है जैसा मिला था, और डाउनलोड लिंक बिना बदली .eml फ़ाइल देता है।

रिपोर्ट कौन सी ब्लॉकलिस्ट जाँचती है?

रिसीवर भेजने वाले IP एड्रेस और सेंडर डोमेन को DNS ब्लॉकलिस्ट में देखते हैं, और किसी बहुत इस्तेमाल होने वाली लिस्ट में नाम होने पर मेल रिजेक्ट या फ़िल्टर हो जाता है। रिपोर्ट वही लिस्ट जाँचती है जो scan.mx जाँचता है: IP एड्रेस के लिए Spamhaus ZEN और AuthBL, From और envelope डोमेन के लिए Spamhaus DBL और ZRD, और IPv4 एड्रेस के लिए SpamCop, GBUdb Truncate और PSBL भी। हर पंक्ति में लिस्ट में है या नहीं लिखा होता है, साथ में लिस्ट ऑपरेटर के डीलिस्टिंग पेज का लिंक।

Spamhaus PBL पर पॉलिसी लिस्टिंग ऐसी एड्रेस रेंज को चिह्नित करती है जो सीधे मेल भेजने के लिए नहीं है, जैसे घर का कनेक्शन। ऐसे एड्रेस का मेल प्रोवाइडर के मेल सर्वर से जाना चाहिए। नतीजे दो घंटे तक कैश रहते हैं, इसलिए कोई सुधार ज़्यादा से ज़्यादा दो घंटे बाद नए टेस्ट में दिखता है।

SpamAssassin स्कोर का क्या मतलब है?

SpamAssassin एक open-source स्पैम फ़िल्टर है जिसे कई रिसीव करने वाले सर्वर इस्तेमाल करते हैं। मेल सर्वर हर टेस्ट मैसेज को SpamAssassin और उसके रोज़ अपडेट होने वाले स्टैंडर्ड नियमों से स्कोर करता है। रिपोर्ट कुल स्कोर, 5 की स्पैम सीमा और मैच हुआ हर नियम दिखाती है, सबसे ज़्यादा पॉइंट वाले पहले। नेगेटिव पॉइंट मैसेज के पक्ष में गिने जाते हैं, जैसे एक मान्य DKIM सिग्नेचर।

नेटवर्क आधारित टेस्ट दो चीज़ें जाँचते हैं: भेजने वाला IP एड्रेस और लिंक में दिए गए डोमेन। इन्हें Spamhaus (DQS के ज़रिए), URIBL, SURBL और स्टैंडर्ड नियमों की बाकी लिस्ट में देखा जाता है। Bayesian लर्निंग और साझा hash नेटवर्क Razor, Pyzor और DCC बंद रहते हैं, इसलिए स्कोर सिर्फ़ मैसेज पर निर्भर करता है, और सीखने के लिए मैसेज की कोई जानकारी सर्वर से बाहर नहीं जाती।

यह स्कोर सिर्फ़ सलाह है और अच्छी प्रैक्टिस के स्कोर में नहीं गिना जाता। हर रिसीवर अपने नियमों और सीमाओं के साथ अपना फ़िल्टर चलाता है, और Gmail और Outlook SpamAssassin का इस्तेमाल बिल्कुल नहीं करते। शून्य से ऊपर का स्कोर सामान्य है। सबसे ज़्यादा पॉइंट वाले नियम दिखाते हैं कि बदलाव से सबसे ज़्यादा फ़ायदा कहाँ होगा। 500 KB से बड़े मैसेज स्कोर नहीं किए जाते।

सेंडर डोमेन को मेल सर्वर की ज़रूरत क्यों है?

जवाब From डोमेन पर जाते हैं, और बाउंस envelope sender के डोमेन पर। दोनों का एक MX रिकॉर्ड होना चाहिए, या कम से कम एक एड्रेस रिकॉर्ड, जिसे मेल सर्वर फ़ॉलबैक के तौर पर इस्तेमाल करते हैं। Null MX, यानी एक बिंदु की ओर इशारा करने वाला अकेला MX (RFC 7505), बताता है कि डोमेन कोई मेल स्वीकार नहीं करता, और कुछ रिसीवर ऐसे डोमेन के मैसेज रिजेक्ट कर देते हैं।

कौन से HTML एलिमेंट जोखिम वाले माने जाते हैं?

स्क्रिप्ट, फ़ॉर्म, iframe, object और embed की ईमेल में शायद ही कभी ज़रूरत होती है। ज़्यादातर मेल क्लाइंट इन्हें हटा देते हैं, और स्पैम फ़िल्टर इन्हें phishing का संकेत मानते हैं। सादे लिंक और इमेज बिना किसी नुकसान के वही काम करते हैं। कंटेंट सेक्शन HTML साइज़ और HTML में दिखने वाले टेक्स्ट की मात्रा भी दिखाता है, क्योंकि लगभग पूरी तरह markup या इमेज से बना मैसेज फ़िल्टर को संदिग्ध लगता है।

लिंक शॉर्टनर पर चेतावनी क्यों?

bit.ly जैसे पब्लिक शॉर्टनर असली मंज़िल छिपा देते हैं। Phishing अभियान इनका बहुत इस्तेमाल करते हैं, इसलिए फ़िल्टर इनसे होकर जाने वाले लिंक पर भरोसा नहीं करते। सीधे सेंडर के डोमेन पर जाने वाले लिंक इसके बजाय साख बनाते हैं।

DNS सेक्शन क्या दिखाता है?

रिपोर्ट के लिए की गई हर DNS क्वेरी DNS सेक्शन में दिखती है, मकसद के हिसाब से ग्रुप की हुई: रिवर्स DNS, SPF, DKIM, DMARC, BIMI, मेल सर्वर और IPv6 जाँच। ब्लॉकलिस्ट लुकअप इस लिस्ट में नहीं होते, क्योंकि उनके क्वेरी नामों में एक access key होती है। हर एंट्री नाम, रिकॉर्ड टाइप, रिस्पॉन्स कोड, TTL के साथ जवाब और authority रिकॉर्ड, अगर हों, दिखाती है। यह लिस्ट दिखाती है कि हर नतीजा किन रिकॉर्ड से बना, जो तब काम आता है जब हाल का कोई DNS बदलाव अभी हर resolver तक नहीं पहुँचा हो।

और भी मुफ़्त टूल

scan.mx
किसी डोमेन का मेल सेटअप जाँचें: MX, SPF, DKIM, DMARC, BIMI।
portscan.com
जाँचें कि किसी IP एड्रेस पर कौन से TCP पोर्ट खुले हैं, पोर्ट 25 समेत।